We want our XQuery

We want our XQuery

Summary: While XQuery has gained a lot of support and interest over the past two years, Microsoft has apparently bailed on the standard. In January, the Redmond software giant announced that it was dropping XQuery from the next release of its .


While XQuery has gained a lot of support and interest over the past two years, Microsoft has apparently bailed on the standard. In January, the Redmond software giant announced that it was dropping XQuery from the next release of its .NET Framework (version 2.0, or Whidbey).  The folks at Stylus Studio -- and ostensibly, about 120 other Microsoft partners -- are not happy about this development.

Stylus Studio, a provider of XML development tools, has posted a petition to Redmond demanding that XQuery be added to Whidbey. According to the petition, "Since major updates to the .NET Frameworks only ship every 3 or so years (more or less), cutting XQuery from this release means that the next window of opportunity for XQuery to find its way into the .NET core framework won't be until around the 2009 timeframe, and possibly never if we, the community of XQuery developers don't make it a priority for them."

XQuery For All

XQuery promises to do for XML data what SQL did for relational data — that is, make it possible to write a standardized query that will pull the right data out of any database, regardless of vendor or format. Surveys show XQuery to be a popular standard among database developers. Surveys I have worked on with Evans Data have found that at least half of database developers are ready to work with XQuery, especially with large volumes of XML-based data sweeping across enterprises. Another survey of 550 XML developers by DataDirect Technologies earlier this year finds that 52% already started working with XQuery, and another 33% have plans to start using XQuery this year.

For its part, Microsoft states in a message on its Website that it pulled XQuery because a final version has not yet been approved by the World Wide Web Consortium (W3C). "This means that we will have to finalize the code before XQuery becomes a W3C recommendation, making it impossible for us to guarantee forward compatibility between any XQuery support in .NET 2.0 and the eventual XQuery 1.0 recommendation."  Also, Microsoft does include XQuery support in SQL Server 2005.

Topic: Software Development

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Don't worry

    Microsoft won't leave developers stranded. At this very moment they're cranking out their own functional equivalent which will make XQuery irrelevant.
    Yagotta B. Kidding
    • Why "functional equivalent"

      Why not support the official W3C XQuery standard (when it becomes a standard) for the sake of interoperability instead of creating a "functional equivalent". Makes it easier for data integation folks everywhere.
      • The great thing about standards ...

        ... is that there are so many of them to choose from, as the ancient joke says. There a bunch of "functional equivalents" of XQuery on the client side, especially XSLT. Supporting all of them is not a practical business proposition even for MS, so we have to pick the ones that are the right tool for a specific job. For .NET 2.0 XSLT is at the sweet spot of functionality, mindshare, and real industry support, so that's where effort was concentrated. In the future, who knows? *Maybe* XQuery will be the basis for real interoperability in the future, but it's a huge, complicated spec and we will just have to see if it turns out to be more truly interoperable than, say SQL 3 is.

        XML itself is the most suitable basis for *data* interoperability, and that's why MS focuses its efforts on building the most conformant, scalable, and secure implementations of the XML and XML Schema specs.
        • XSLT sweeter spot than Xquery? wake up MS!

          It's hard to believe that MS thinks XSLT is the "sweet spot" over XQuery. I think developers view the two languages as completely different from a code approach.

          After working with both languages, IMHO Xquery has a simpler, more "top-down" feel than XSLT. I don't think even features in XSLT 2.0 will change developers minds about that.

          To me, Xquery seems much more SQL-like in it's simplicity, with easier grouping and looping. The bottom line is that I can solve a typical data integration problem much more quickly with Xquery.

          It's confusing to me why MS isn't on board with this. As usual, it looks like they are waiting for some other vendor to succeed with Xquery before jumping in...typical of MS.
          • XQuery is not a standard

            As was pointed out in the article, XQuery is not a standard. MS has learned that too early of support costs them with people complaining when the final standard doesn't match their pre-release. In this case, MS decided to wait until the standard is finalized so that they can actually have a standard to work towards.

            Frankly, the W3C is becoming less relevant in my opinion. Simply put, they're too slow. I'm still waiting for them to finalize CSS-3 with behaviors. Or for that matter Mozilla to support them.
  • You get your XQuery ......In SQL Server 2005.

    Please note that Microsoft *does* support XQuery in SQL Server 2005. This is described in http://www.stylusstudio.com/michael_rys.html

    The reasoning for removing XQuery support from .NET 2.0 is given in http://msdn.microsoft.com/xml/xquerystatus/default.aspx and updated in http://blogs.msdn.com/arpande/archive/2005/04/29/413347.aspx . The "enterprising people" supporting XQuery in .NET are the developers of the open source Saxon.NET effort http://weblog.saxondotnet.org/
    • saxon.net is nice but no substitute for offical support

      Saxon .NET is a re-compile of Saxon's open source Java files into .NET classes. According to an interview with Saxon founder, Michael Kay, the XQuery support in Saxon is enabled by: "using the Saxon XSLT run-time, just by implementing a different parser as a front end" (http://www.stylusstudio.com/michael_kay.html). Does anyone really think that Saxon.NET is scalable for heavy-duty XQuery processing? If this is the extent of XQuery support in .NET count me out.
      • saxon.net is fine for now

        My guess is that if his client implementation is not sufficiently "scalable for heavy-duty XQuery processing" in some application, the app should have been built on a DBMS in the first place.

        For heavy-duty processing, most would recommend a DBMS-based approach, and that's what MS supports in 2005. If XQuery gets actual mindshare and traction on the mid-tier so there is real demand for heavy-duty XQuery support in .NET, MS will very likely meet that demand in the future. For now, there are several other XML technologies that address heavy-duty XML processing on the client/mid-tier including XSLT, and streaming APIs, DOM-like APIs, and so on. It is not clear that XQuery will be a contender on the client/mid-tier, even though it is the undisputed champion of XML querying from a database.

        The key point is that XQuery is still a working draft. As Michael Kay has said, his great advantage over big companies is that he write what he wants whether or not it is a "standard", without promising to support it for a decade, whether or not he can make a strong business case, etc. More power to him! MS can't, and shouldn't operate that way, however. Michael has the best client-side implementation of the XSLT2 and XQuery drafts at this point, and anyone needing those technologies should definitely not ignore the .NET port of his stuff.