史蒂文 :: Release 2.0

Microsoft asked people to comment on their XLinq implementation and ideas. Here are my comments (written pretty hastily). Follow ups will be posted here.

In a previous post Mike mentioned he'd like comments. I just completed reading the XLinq overview and trying a few things out (i will post code that compares System.Xml and XLinq to my blog).

So here are my comments (maybe some questions) - and maybe some bugs i found. Please bear with me - i wrote this as a read, so it won't win any awards and you'll be unlikely to find it between Dante to Shakespeare, but hopefully *some* of it will be useful. I will also post to my blog.

1. [comment] "Its public data model is aligned as much as possible with the W3C XML Information Set."
This is a little concerning in the sense i may design and architect a solution, only to discover it is not supported. It also means i need to start filtering out what i do and do not know. Also I imagine that at some point i may wish to create an XLinq Xml Document from a System.Xml XmlDocument - my worry would then be i wouldn't know what queries would start to fail. A general worry is over nuances in support for things like encoding, entities and so on between the two implementations. I'm not intending to be picky here, but i am thinking of the things clients would say to me :) I'll be interested to hear how the "bridging" mentioned at the end of the document is to work.


2. [bug] When creating an XDeclaration, you can set the "standalone" property to anything. It needs to be "yes" or "no". [1]. This correctlty throws an exception in CreateXmlDeclaration() of the XmlDocument class.

3. Namespaces [comments]

I'm not sure whether i like the syntax all that much, but who really cares so long as it does its job (feels like pure string concat to me). I think it is probably easier for those who have issues with namespaces. To be honest i have found people have issues not with the namespaces or prefixes, but how they are used in XPath, and more specifically how they qualify elements. This is so common that when there is a single namespace in an Xml document, i wonder whether an queries should just inherently be within the scope of that namespace, rather than an empty namespace - or at least provide this as an option. So in an Xml document with the namespace "http://tempuri.com" at the root, the XPath query "/items" should be the same as "/p:items" and "{http://tempuri.com}items". I would likely be murdered in the Xml community for saying this, but i have now seen more uses of "/*[local-name='items]" than i care to remember... defeating the purpose of the namespace anyway!

And again, in many cases, there IS only one namespace. People just don't get that things need to be qualified and i'm unure the XLinq syntax will make any difference in that sense. When it comes to multiple namespaces things get very interesting. Perhaps education and a simpler querying format is the way to make this work (i'm still early in the doc to see if/how this is addressed).

In any case, I'd like to see prefix support added in some manner. Why not allow this?

XNamespace ns = "http://mydomain.com";
ns.prefix = "p";

XDocument contactsDoc =
new XDocument(
new XDeclaration("1.0", "utf-8", "test"),
new XComment("XLinq Contacts XML Example"),
new XProcessingInstruction("MyApp", "123-44-4444"),
new XElement("p:contacts",
new XElement("p:contact", "steven")
)
);

... using a colon in a Xml Element name is invalid in any case and it would allow for shortcuts and the qualified name can easily be determed.

I like the XDocument.Parse() method - very useful. How will it resolve credentials and resources for URL's?

XDocument contactsDoc = XDocument.Parse(@"
<?xml:namespace prefix = p /><p:contacts p="">
<p:contact>steven</p:contact>
</p:contacts>");


In this case, i'd really need to be able to specify prefixes in the Xml doc and have these resolved to a namespace, especially when creating an instance from data that is read some elsewhere (say a database - sql's new Xml column type or web service and so on). So, in the following example:

XDocument contactsDoc = XDocument.Parse(@"

<p:contacts p="">
<p:contact>steven</p:contact>
</p:contacts>");

XName xname = "{http://mydomain.com}contact"; IEnumerable en = contactsDoc.Root.Descendants(xname);

foreach (XElement x in en)
{
Console.WriteLine(String.Concat("Name : ", x.Name));
Console.WriteLine(String.Concat("Value : ", x.Value));
Console.WriteLine(String.Concat("Xml : ", x.Xml));

}

... i'd like to be able to do this:

XDocument contactsDoc = XDocument.Parse(@"

<p:contacts p="">
<p:contact>steven</p:contact>
</p:contacts>");

XNamespace ns = "http://mydomain.com";
ns.Prefix = "p";

XName xname = "p:contact";
IEnumerable<xelement> en = contactsDoc.Root.Descendants(xname);

foreach (XElement x in en)
{
Console.WriteLine(String.Concat("Name : ", x.Name));
Console.WriteLine(String.Concat("Value : ", x.Value));
Console.WriteLine(String.Concat("Xml : ", x.Xml));

}

or ....

XDocument contactsDoc = XDocument.Parse(@"

<p:contacts p="">
<p:contact>steven</p:contact>
</p:contacts>");

XNamespace ns = "http://mydomain.com";
ns.Prefix = "p";

IEnumerable<xelement> en = contactsDoc.Root.Descendants(p:contact);

foreach (XElement x in en)
{
Console.WriteLine(String.Concat("Name : ", x.Name));
Console.WriteLine(String.Concat("Value : ", x.Value));
Console.WriteLine(String.Concat("Xml : ", x.Xml));

}

In complex cases putting the full namespace in each time would be a pain and i did notice there are some methods that actually let you get at the "hidden" prefix, so i was left wondering whether the prefix was something you want to hide or expose.

Oh, i just read the section "2.3.1.1 XML Prefixes and Output" and the method of associating a prefix with a namespace looks, erm, nasty. Is there a good reason for not just making it a property?

4. Text as value

Also, in terms of "2.1.1.4 Text as value", i often wonder whether the xsi:type attribute or Schema could be better used (say a switch on XDocument) to allow the type to be inferred from the schema. So xsi:type="string" is a .Net string type and so on, but this is just to get round explicit casts on Xml Schema defined primitive types which align pretty closely with the .Net types - or can be converted as so in many cases. I do like this ability though to go from Xml node to .Net type without too much work. [ Oh, i just read the Schema aware section - this looks REALLY cool!].

5. Remove/Delete

There has likely been much discussion around this, but could we not have Remove() and Delete() methods, the second of which would actually call the ToList() for you? It is education, but i do see many tripping over this. I'd like an "optimization" (Remove) and an "it works" (Delete) so those who get it can manage it, although one could aruge you can use the "for" statement to manage it yourself.

6. Ancestors/SelfAndAncestors and Descedants/SelfAndDescedants

It's just naming, but IMHO Ancestors/SelfAndAncestors and Descedants/SelfAndDescedants seems strange to me - using intellisense, i suspect the vast majority or people will use Ancestors/Descedants and it won't be obvious this doesn't include the current node (and even then there won't be an obvious way to find out what does). Even in XPath you have "descedents" and "descedents-or-self".

7. Typo

Small typo in section 3.1.3 - first code block in page 31. You have - select new XElement("phone", - but "phone" i believe is supposed to be "Phone".

[1] http://www.w3.org/TR/2004/REC-xml-20040204/#sec-rmd

steven
http://stevenR2.com

# posted by weblivz @ 7:09:00 am Comments: Post a Comment

<< Home