In XLinq XML Tree is exposed in a heterogenos way, that is nodes in a tree don't belong to a common type. Traditionally XML tree models are homogeneous, e.g. in DOM every node belongs to a specific kind of XmlNode class. But in XLinq attributes and text nodes aren't actually nodes. Instead attributes are just name-value properties of element nodes and text nodes while being internally normal nodes, never get exposed as such, but only as values they contain, so in effect what you can get out of XLinq tree is XNode (XElement etc), XAttribute and String values (which you can cast to appropriate CLR types). Apparently the goal was to simplify API and data model comprehension for users.
That might be really good idea actually. And at the same time such design has drawbacks. Main one you can see immediately by looking at XLinq API - those nasty object and object[] all around the methods. Yes, lots and lots of methods accept and return anything or arrays of anything. That's the price XLinq pays for sacrifycing text and attribute nodes. What's wrong with object[] based API? It's loosly typed and no compile time checks. You are suposed to read API documentation to figure out what you should pass to a method or what you would get back. That's not really a good idea. I'm sure developers would try to put DataSets into XElement constructor and then wonder why it doesn't come back. It's object, so you can pass *anything* and when you get it back it's your responsibility to figure out what do you get. Hence type switches all around the code. OOP developer in me cries "That's wrong!", but may be I'm wrong and XLinq indeed means "anything"? XLinq seems to be escaping to object[] in API because that's the only way to say "XNode, XAttribute and String" (actually that might change once XLinq becomes strongly typed). And the reason why to escape is obviously lack of attribute and text nodes.
Btw, I have no idea why XDocument constructor accepts object[] and not XNode[]. After all XDocument can only contain XDocumentType, XDeclaration, XElement, XCommment or XProcessingInstruction and all they inherit XNode. So currently "new XDocument("hmmm");" compiles well, but crashes at runtime. Why not to catch it at compile time??
I'm sure loosly typed nature of XLinq API hides more such "ooops" moments.
Honestly speaking I'm not sure if it worth it. What's so wrong with attributes and text nodes so one would screw up his API just to avoid them? Unless you go nuts (just like W3C DOM) by allowing adjacent text nodes, text nodes within attributes or entity references or similar crazyness, you are safe. XPath and now XQuery (like every other XML Tree API) have text nodes and I never heard of any problems with them (well, except for whitespace-only text nodes). Not to mention that at the same time XQuery supports strongly typed elements with no any troubles. Really, what's the reason for not having attributes and text as nodes in XLinq?
I'm packing to the MVP summit, so sorry for messy thoughts.
Leave a comment