XLinq Bitter Words, Part I - XML functional construction

| 7 Comments | No TrackBacks

XLinq is new and hot technology everybody seems to be happy with. I'm going to post a different review series - not what I like, but what I dislike and want to be fixed in XLinq. Sorry in advance for bitter words, but it's better when your friend says them.

XML functional construction

XML Tree functional construction is a great stuff and definitely a big improvement over the upside down DOM-style XML building. I only wanted to note that one doesn't have to wait years for C# 3.0 to be able to build XML tree in a natural top-down way, that was actually possible from the very beginning (here is .NET 2.0 sample, in .NET 1.X one would need XmlNodeWriter):

    XmlDocument doc = new XmlDocument();    
    XmlWriter w = doc.CreateNavigator().AppendChild();
        w.WriteElementString("name", "Patrick Hines");
          w.WriteAttributeString("type", "home");
          w.WriteAttributeString("type", "work");
          w.WriteElementString("street1", "123 Main St");
          w.WriteElementString("city", "Mercer Island");
          w.WriteElementString("state", "WA");
          w.WriteElementString("postal", "68042");
Should admit XLinq's functional construction still looks shorter and tree-friendly, but it is seriously constrained to building only XLinq XML tree in-memory. If one day you decide that building in-memory XML tree just to be saved to a disk is a waste of memory (and it is a waste), you would need to rewrite completely XML construction code and that's bad. XmlWriter has no limits here - you can use it for building XML tree in memory or writing XML directly to a stream in a fast efficicent non-caching way. XmlWriter just does its job - writes XML with no coupling to the result and that's way any code that produces XML with XmlWriter is more reusable.

Ergo - please don't repeat System.Xml mistakes and treat XmlWriter as a first class citizen - provide a way to build XDocument/XElement with XmlWriter, that will be good architecturally and will provide smoother migration from XmlDocument v2. E.g. what about providing an editable XPathNavigator over XElement or XDocument?

Update. And as a matter of interest XQuery being truly functional language of course supports functional composition too. Here is a sample:

element book { 
   attribute isbn {"isbn-0060229357" }, 
   element title { "Harold and the Purple Crayon"},
   element author { 
      element first { "Crockett" }, 
      element last {"Johnson" }
Looks terribly familiar, huh?

But as Erik pointed out in comments neither form of composition can beat the ultimate way of building XML - literal one. Here is how it looks like in XQuery:

   <p> Here is a query. </p>
   <eg> $b/title </eg>
   <p> Here is the result of the query. </p>
   <eg>{ $b/title }</eg>
C# doesn't support it yet, while VB sort of does. "Sort of" because VB form of "literal XML" is not actually XML, but confusing ASP-like mess. But I'll address that later.

To be continued...

Related Blog Posts

No TrackBacks

TrackBack URL: http://www.tkachenko.com/cgi-bin/mt-tb.cgi/499


These are constructive comments (not so bitter). It sounds like you like functional construction. Providing a writer capability (and a reader) is important and we have it on the XLinq to-do list.

You are right, Matt.
But I didn't say XmlWriter allows functional construction, I just noted that building XML in top-down way was possible even in .NET 1.0.

Using the XmlWriter is not functional construction. It's just a bunch of statements with tabs injected to help you read it better. Functional construction means that you can construct an entire xml tree anywhere in an expression context.

Functional construction makes constructing XML and querying compositional. That would be hard to do in the streaming model. Erik is right. We are working on integrating XLinq and the current System.Xml 2.0 stack. You will hear about this in the coming months.

Ayende, extensibility is great, but:
1. Switching to XWriterElement still would require substantial changing of existing code. And then you get being locked to writig only to file. Not so good.
2. There is an impedance mismatch between in-memory-tree-based and streaming XML models. Tree allows more luxury, such as
new XElement("foo",
new XElement("bar"),
new XAttribute("attr", "foo attribute!"))
This one is easy to handle, but who said that XLinq based XML construction would be constrained to a forward-only composition? Having tree in memory enables modifying already created elements according to some logic later on. And that can't be translated to XmlWriter.

We are still very early in the life of XLinq, and one of the features on our list, but which we did not get done in time for the PDC and the preview release is integration with the rest of our stack. You will see much better integration in the final release.


BTW - If you thought Functional Construction was succinct, you should check out XML Literals in VB9 (see http://msdn.microsoft.com/vbasic/future/default.aspx?pull=/library/en-us/dnvs05/html/vb9overview.asp#vb9overview_topic6)

Nothing prevents you from providing an XWriterElement() that allows writing directly to file.
The whole thing is pretty extensible.

Leave a comment