Hello.

If we are to build HTML in Workers then we need some 'DOM' in them.

I've released a new, open-source Microformat parser for .NET, available on Codeplex! This stream-based parser uses a flexible XML configuration to define how microformats like hCard and rel-tag are extracted from HTML/XML, allowing for easy adaptation to spec changes. The provided C# code example demonstrates the simplicity of using the framework to read and process microformat data. Feedback and contributions are welcome!

This post responds to Mike Champion's comment on my previous XLinq blog post. I clarify the XML file used (Wikipedia XML Abstract) and explain why I chose an XMLReader for its speed, especially when combined with custom data structures for a cyclic graph representation. XLinq's syntax and lambda expressions felt less intuitive for my task of converting XML into SQL statements. The project involves relating "title" elements with "sublink" entities, resulting in a complex graph structure not easily handled by XLinq without excessive data duplication and memory consumption. While XStreamingElement offers some improvement by avoiding redundant data scans, I desire deferred data loading for processing only necessary slices of the XML. This approach could handle selects, wheres, and counts efficiently in a single pass, and even joins with clever indexing. Defining a schema during XML iteration seems redundant when XLinq expressions already specify data requirements. Pre-loading entire XML documents into memory feels inefficient when only a small portion is used. I propose deferring data loading until needed, despite potential issues with repeated XDocument inspections. Ideally, XLinq should scale without forcing users to revert to less efficient methods due to data size limitations. I inquire about potential hard limits and scaling formulas related to XML document size in XLinq.

I'm highlighting a comment from Mike Champion, XLinq's program manager at Microsoft, addressing the issue of querying large XML files with XLinq. He discusses their current investigation into this problem and seeks feedback on how large XML documents are typically structured. Specifically, he asks about the structure of my 900MB XML file to better understand user needs and design appropriate solutions within XLinq. He mentions exploring options like a LINQ-queryable XmlReader or a lazy evaluation approach similar to XStreamingElement, while aiming for simplicity and avoiding dependencies on schemas or XPath. He's open to further discussion via his blog's contact form.

I've been experimenting with XLinq in C# 3.0, but I'm not impressed with its querying capabilities. It seems to require loading the entire XML document into memory, which caused problems when I tried to process a 900MB file. A simple XML reader was much more efficient for this task. I'd like to see an XLinq implementation that can process XML data in a streaming fashion, similar to SAX or XmlReader, to avoid memory issues. This would make it more practical for large documents. Perhaps XLinq already supports this, but I haven't found how. For now, it seems best suited for smaller files.

In this post, I explored C# 3.0 and XLinq by parsing a music style XML document from MusicMoz. I created a simple class "TagCategory" to store the style name and category. Then, using XLinq, I loaded the XML, extracted the "style" elements, and created a List of TagCategory objects. The code concisely retrieves and stores the data using object initializers. Feel free to share your feedback or suggestions for improvement!

I've just posted the C# source code for serializing and deserializing OPML files using a simple object model. The code demonstrates basic serialization and deserialization, creating an OPML structure with a head, body, and outline elements. While the object model is functional, it's not perfect and could be refined. The example code shows how to create an OPML object, populate it with sample data, serialize it to XML, and then deserialize it back into an object, useful for anyone working with OPML in C#.

I'm working on a .NET object model for OPML 2.0 to easily serialize and deserialize OPML files. Serialization is working well and creates correctly formatted files thanks to constraints based on the OPML spec. Deserialization is proving tricky as the XML Deserializer isn't enforcing those same constraints, allowing incorrectly structured OPML files to be loaded. I'll share the code and continue working on it.

My OPML files are not correctly formatted, specifically with unescaped apostrophes in attributes. This issue affects users of my Ajax Tagger v2, but I haven't received reports of any problems so far.

This post explains AJAX (Asynchronous JavaScript and XML) and its use in .NET. AJAX allows web pages to update small sections without reloading the entire page, improving user experience. Traditional ASP.NET (1.x) struggles with this as it's designed to reload entire pages. However, .NET's flexible request pipeline allows plugins/HTTPHandlers to manage AJAX requests, enabling developers to execute specific methods within a page. The post lists several .NET AJAX frameworks, including AjaxPro, Arshad.NET, and AjaxAspects, and points readers to ajaxpatterns.org for more options.

I've updated my Opensearch implementation based on feedback from Michael Fagan. Changes include correcting the short name length, fixing capitalization issues, and adding an RSS search URL using Google Blog Search. Unfortunately, full A9.com integration isn't possible because the search engine isn't on my domain. While proxying results is an option, I feel that would be unfair to Google.

I'm puzzled why Microsoft's new Feed Manager API is COM-based instead of a managed API. Given their push for managed code in Vista and .NET's excellent XML handling, a managed API for RSS (which is XML-based) seems logical. It's frustrating to need interop to use this new feature.

I'm exploring Microsoft's Simple List Extensions for RSS and looking for real-world examples of their implementation. I'm particularly interested in seeing how these extensions can be effectively utilized and would appreciate any insights or examples.

I'm struggling to understand the practical uses of OPML, especially given the inconsistent use of attributes like 'type', 'url', and 'xmlurl'. While I'm developing a JavaScript OPML object model for my own projects (like a tagging system where OPML stores related links for blog posts), I haven't found a clear standard for defining outlines. It seems like the 'standard' emerges from popular usage rather than formal specification. I'm particularly interested in how to determine the file type of items within an OPML outline, as my current application only uses links for pages and images (feed support is still pending). The lack of clear semantics in OPML makes it difficult to build dynamic applications that can 'mash up' content from different sources based on the OPML structure.

I'm working on a JavaScript Object Model for OPML and have found areas for improvement. I initially misunderstood the OPML spec, particularly regarding the attributes of the outline element, which are more flexible than I realized. This is important for handling things like files, links, HTML, and RSS. The current model has issues with proper quoting of characters like quotes and ampersands, but otherwise, the generated OPML XML seems good. I'll be updating the model to handle these attributes soon and will post more about the specific attributes in a future post.

I've created a basic JavaScript Object Model for OPML, which you can find here: http://www.kinlan.co.uk/AjaxExperiments/opml.js. It's not entirely finished yet, but the core structure is in place. I plan to write proper documentation soon.

In this final part of "The Failures of my First AJAX Application" series, I reflect on the cross-browser compatibility issues I encountered. Focusing on Internet Explorer during development led to problems in Firefox, particularly with security errors (cross-domain data retrieval) and differences in the XML DOM model. The key takeaway is to consider cross-browser support from the outset, anticipating discrepancies between browsers and coding around missing features, similar to CSS development. The next version will prioritize cross-browser compatibility, potentially including Safari. This series has been invaluable for shaping the requirements of the upcoming version.

In my last post about Perl, I forgot to mention my upcoming need for XML processing. Before I start looking at XML parsers, I'd appreciate recommendations for a lightweight Perl XML parser. My requirements include: lightweight, XPath support (potentially), SAX-like reader functionality, DOM support, and the ability to create XML documents (preferably via DOM or similar methods). Email me your suggestions!

I had this brilliant idea to create a merged RSS feed using client-side processing. The idea was to have a main RSS feed that linked to other feeds. My custom XML would include a list of sources. Then, using XSLT in the browser, the client could merge these external feeds into a single view. It worked perfectly locally! However, I hit a roadblock with cross-domain security restrictions when I uploaded it to my server. The browser wouldn't let me pull in feeds from other domains due to security concerns. Additionally, client-side XSLT processing isn't universally supported. So, even if the security issue wasn't there, many feed readers wouldn't be able to display the merged feed. In the end, the project failed. But, I learned a lot about browser security, XSLT limitations and client/server interactions!

IE7 finds the RSS feed on channel9.msdn.com but doesn't display it correctly, only showing the raw XML. I'm looking for other examples of feeds that IE7 can't render properly to compile a list and see if there's a pattern or bug. If you know of any, please email me!

I explored the idea of C# 3.0 XML Generics based on Matt War's blog post. I'm questioning the practicality of defining a generic from an XML Schema within the code itself, as it seems redundant compared to simply creating a class. However, the concept becomes more intriguing if the generic type could be derived from a streamed XML schema, offering dynamic type creation possibilities.

I'm exploring the concept of generics in C# 3.0, particularly how they might relate to XML types. I'm having trouble grasping the connection described in MattWar's blog, which suggests generics and XML are fundamentally linked. While I understand how generics allow parameterized specialization of classes (like a list of ints, longs, or custom objects), the example of XML generics like "Foo<int x="...">" confuses me. Is it parameterization, an attribute, element constraint, or class conversion? I don't see the advantage over generating classes from XSDs. I'm curious about how XML generics might be tied to schemas for constraining parameter values and eager to learn more about this potentially paradigm-shifting concept.

In this first part of my image processing series, I'm sharing how I used the Yahoo Search API to find images and load them into a C# application. I was excited to discover how straightforward it is to query for images and then seamlessly integrate the results into my project. The process involves constructing a REST query with search parameters, sending the request to Yahoo, receiving the XML response, and deserializing it into a custom data type. Then, I iterate through each image result in the response, create another query to download the image, and finally, convert the downloaded stream into a Bitmap and load it into an ImageList. Stay tuned for more in this series!

This blog post explores the arguments for and against Binary XML. While some argue that Binary XML addresses XML's verbosity, text processing speed, and inability to store binary data, I question its practicality. I've found that XML's drawbacks can be mitigated through compression and concise tags. Binary XML raises concerns about readability, schema management, querying, and the potential for increased complexity. The post links to external resources offering further insights into the debate.