September 24, 2005

MVP Summit

I'll be at the Microsoft MVP Summit in Redmond next week. I'm Microsoft MVP for second year, but that's going to be my first MVP Summit. That should be fun. ...

September 23, 2005

XLinq Bitter Words, Part I - XML functional construction

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 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...

September 22, 2005


Being excited about XLinq I couldn't stop myself from grabbing XLinq.NET domain name. I'm going to try to build a community portal for the XLinq technology. The goal is basically to push XLinq by growing a community around it. There is definitely a need for Microsoft-independent easily accessible place where ...

6 ways of associating XML Schema with XML document in VS 2005

Hmm, according to Stan Kitsis there is at least 6 ways to associate an XML Schema with an XML document in Visual Studio 2005: 1. Schemas Property on your XML document 2. Inline inside your XML document 3. xsi:schemaLocation or xsi:noNamespaceSchemaLocation attributes in your XML document 4. Open Document Window ...

"How we did XQuery in SQL Server 2005" paper

Microsoft's paper about "the experiences and the challenges in implementing XQuery in Microsoft's SQL Server 2005" is available here. [Via Michael Rys] ...

September 21, 2005

xml:id went W3C Recommendation

Little xml:id spec finally got W3C Recommendation status. I believe XML programming would be better be xml:id done in 1998, not in 2005. Anyway. xml:id provides a mechanism for annotating elements with unique identifiers. You just set xml:id attribute for an element and you done, no need for DTD, XML ...

I hope Microsoft XML Team would consider adding support for xml:id into the next .NET version and into XLinq. That's really valuable addition to the XML Core.

And of course I cannot avoid Canonical XML (C14N) and xml:id controversy. Read Norm for the crux of the issue. In short - Canonical XML is broken. Here is an illustration:

string xml = @"
<foo xml:id=""f42"" xml:base="""">
  <bar xml:base=""dir"">baz

XmlDocument doc = new XmlDocument();
XmlDsigC14NTransform c14n = new XmlDsigC14NTransform();
StreamReader sr = new StreamReader((Stream)c14n.GetOutput());
Guess what is the result?
<bar xml:base="dir" xml:id="f42"></bar>
Not only xml:id is inherited by bar element (so now you can get different element when searching by the same ID), but xml:base is broken (absolute base URI part is lost). Too bad. Canonical XML should definitely be fixed.

September 19, 2005

Upgraded to MT 3.2

This is a repetitive pattern: once in a 6 months I get tired of comment and trackback spam and go upgrade my blog engine or install some antispam plugins.This time is not different. I've been massively attacked by spam trackbacks so I had to upgrade to MovableType 3.2. Not without ...