Mike Champion has a blog post entitled Why
does the world need another XML API? where he writes
One basic question keeps coming up, something like: "We have SAX, DOM,
XmlReader/Writer APIs (and the Java people have a bunch more), we have XSLT, we have
XQuery ... why do you think we need Yet Another XML API?"
we believe that the overall LINQ story is going to have a pretty profound impact
on data programmability, and we want to make sure that LINQ has a good story for XML...For
XML users, I see a few really powerful implications:
XmlReader / XmlWriter can't go away because XLinq uses them to parse and serialize
between XLinq objects and XML text. Also, while we are making XLinq as streaming-friendly
as possible (see the XStreamingElement class in the CTP release for a taste of where
we are going), we're only aiming at hitting the 80/20 point...
DOM can't go away because there are important use cases for API-level interoperability,
most notably in the browser...DOM doesn't make code truly interoperable across implementations
(especially on other languages), but there is enough conceptual similarity that porting
is generally not terribly difficult...
XSLT definitely won't go away. The Microsoft XML team was promoting XQuery
as a "better XSLT than XSLT 2.0" a few years ago (before I came, don't hurt me!),
and got set straight by the large and vocal XSLT user community on why this is not
going to fly. While it may be true in some abstract way that XQuery or XLinq might
logically be able to do everything that XSLT does, as a practical matter it won't...
XQuery won't go away, at least for its original use case as a database query language.
Microsoft supports a draft of XQuery in SQL Server 2005, contributes to the work of
the XQuery working group at W3C, and will continue to invest in finalizing the XQuery
Recommendation and implementing it in our DBMS..
The ability to query data by declaraing the characterics of the result set rather
than imperatively navigating through and filtering out all the data...
The ability to join across diverse data sources, be they XML documents, objects,
or DBMS queries
The ability to "functionally" reshape data within the same language as the application
is written. XSLT pioneered the functional transformation approach to XML processing,
but it is difficult for many developers to learn and requires a processing pipeline
architecture to combine XSLT transforms with conventional application logic...
This brings back memories of my days on the XML team at Microsoft. We went back and
forth a lot about building the "perfect XML API", the one problem we had was that
there one too many diverse user bases which had different ideas of what was important
to expose in an API. We were always caught between a rock and a hard place when it
came to customer requests for fixing our APIs. To some people (e.g. Microsoft Office)
XML was a markup format for documents while to others (e.g. Windows Communications
Foundation aka Indigo) it was simply a serialization format for programming language
objects. Some of our customers were primarily interested in processing XML in a streaming
fashion (e.g. Biztalk) while others (e.g. Internet Explorer) always worked on in-memory
XML documents. Then there were the teams whose primarily interest was in strongly
typed XML (e.g. SQL Server, ADO.NET) since it would be stored in relational database
In trying to solve all of these problems with a single set of APIs, we went down the
road of prematurely declaring the death of certain XML APIs and technologies such
as the DOM (see Ode
to the XML DOM) and XSLT (see XSLT
2.0 Sir? or Why
You Won't See XSLT 2.0 or XPath 2.0 in the Next Version of the .NET Framework). At
the end of the day we saw the light and we eventually changed our tune by not deprecating
class and by reconsidering whether replacing XSLT with XQuery was the right way
When I was on the team there was a lot of infatuation with XQuery which
eventually turned to frustration. There were a number of technical and non-technical
reasons for this such as its dependence on W3C
XML Schema which significantly complicated its type system and how long the spec
was taking to become a standard (over
5 years and counting as I write this post). Since then a bunch of folks who were
were enamored with XQuery have taken some of its lessons (e.g. declaritiveness, simple
model for XML generation, etc) and integrated it into a mainstream programming environment
with the XLinq project. XML geeks everywhere should read Erik Meijer's paper, XLinq:
XML Programming Refactored (The Return Of The Monoids), it is a thing of
beauty if angle brackets are your thing. And even better, if you are one you are one
of those that chants rabid slogans like "XML
is the assembly language of Web 2.0", you'll still like XLinq because it
provides a easier and richer level of abstraction for working with XML.