I’ve posted numerous times before about my feelings on Xml parsing
(and not just as it relates to .Net, but Xml in general), so I won’t
rehash my feelings on the subject here except for one sentence: I
love Xml, but I abhor querying/parsing/handling it. It’s great in
principle, but in practice there is a lot to be desired (IMO). It
is getting better though with XQuery support in 2.0, but it’s not quite
there yet.
So, I found myself with some free time this weekend to work on a small project I’ve wanted to do for a while now, ever since Ray pointed out that our favorite online music streaming company publishes an Xml file of their playlists;
build a WinForms gui that wraps up this playlist and offers more
functionality than their website (which is *painfully* slow I might
add). The structure of the Xml file is pretty straightforward,
but I’m always hesitant to parse Xml files due to the reasons mentioned
above, and lack of strong typing (I really don’t like seeing a lot of
strings in my code, it’s error-prone and I usually end up
anti-debugging methods that deal with Xml parsing).
I initially set out to consume the file in a dataset, then realized
that setting up all the relationships manually was going to be tedious
at best and would end up taking more time than just XPath’ing the
document. I don’t know why I didn’t think of this before, but it
hit me that I should be able to create a strongly typed dataset based
on the schema of the file. I’ve worked with typed datasets
before, but it’s always been with RDBMS structured data, never with
Xml. It turned out the be quite simple actually…in short I was
blown away with how simple it was.
- Create a new System.Data.Dataset.
- Create a new XmlTextReader and point it towards the Xml file
to write the schema for (in this case, the Xml file published by DI).
- Load the file into the dataset by calling ds.ReadXml, passing in the XmlTextReader as a parameter.
- Call ds.WriteXmlSchema and specify the path for the resulting .xsd file.
- Open a .Net command window and run xsd <path\name of file>.xsd /d to create the C# class file.
- Add the resulting class file to your project.
- Instantiate the new class, and read in the original Xml file via the steps mentioned above.
I was a little
skeptical if this would work as DI’s file has no schema information in
it, but through the magic of WriteXmlSchema it was all inferred.
What you now have is a fully typed container for your Xml data…no messy
XPath navigation, traversing nodes…and did I mention it’s fully typed?
No more f5’ing just to see if your XPath statements do indeed return
the results you need (well, in my case at least…I highly doubt someone
of say, Dino Esposito’s stature
would ever doubt their own code). It may be a bit of an overkill
for a file as simple as DI’s (the resulting class file from xsd.exe is
close to 3000 lines of code), but why not leverage the built-in
functionality of the runtime wherever possible (plus I’m partial to
typed datasets, for WinForms at least). What would have taken me
who knows how many lines of XPath to parse/navigate the document took
me only a dozen lines (and virtually no rebuilding…since it’s typed you
know that it will “just work”). All of the relationships are
built in, so finding child rows is easy as this (where ChannelInfo is my typed dataset and ContentSection is a homegrown user control to house the data retrieved).
That’s it. Minimal code, minimal testing. As for
performance, I don’t have any raw data in front of to see if it’s
actually faster than the comparable XPath…my guess is that it would be
though. As far as the application I’m writing to wrap up the
DI playlists, it’s a secret for now…but I plan on building some pretty
cool stuff into it. I have the shell built which mimics DI’s
interface, but I plan on adding a lot to it (basically just a utility
that sits in your systray, will enable full control of streaming media
from any site, will be completely pluggable/extensible/the usual
stuff…plus features like pinging you when a specific track comes on,
etc…lots of ideas, so little time to code).
I’ve been a web guy for as long as I can remember, haven’t really
worked on any WinForms stuff on any scale…I’m pretty impressed with
what I’ve seen thusfar. This is gonna be a fun hobby project!