DataSet.ReadXml() is still hot - here "hot" does not mean any good, especially confronting upcoming beta1 release.
In the comment to my blog post, I was asked if we can provide XmlDocument-less DataSet.ReadXml(). I have been developing anothe implementation , but I had no certain answer about that question. However, I found one problematic design in MS.NET.
MS.NET infers a data columns in a certain order. It infers:
This instance will assert my inference above.
Then, there is a problem. Because
So if the column order is their "design", then Microsoft's ReadXml() implementation is bound to DOM.
Then what shuold we do? Two ideas occured to me: A) ignore such column orders (or addint column order replacement internally), or B) separate inference engine and data loading engine. My current implementation is A) but I think B) would be better since it won't be complicated. Moreover, there are many System.Data hackers so that I don't want to impact on the basic class changes
except for xml support stuff. However, I have no idea if we have enough time to develop B)... I have many things that should be fixed such as ReadXmlSchema(), TypedDataSetGenerator, XmlDataDocument, SqlTypes etc.
B) sounds more elegant, no doubt about it. Although referencing columns by index instead of name isn't a good habit, imho, the column order is important. I hope you have time to implement B), but it's of no big importance to me. It'll do just fine with XmlDocument, and then you're also in sync with the .NET implementation (which probably is a good thing, after all).
Posted by: Asbjørn Ulsberg on April 29, 2004 06:33 PM