Home > Learn XML > Supported XML Technologies > The XQuery Zone: XQuery Tutorials and Resources > XQuery Activist Kit > "XQuery for All" Campaign FAQ

Frequently Asked Questions About "XQuery for All"

Presenting the most frequently asked questions about Stylus Studio's mission to support XQuery for All!

Is XQuery in trouble?

No. In fact, XQuery is thriving. Several recently released developer studies by Evans Data Corporation, DataDirect, and DevX, in addition to real-world use-cases all point to tremendous momentum behind the XQuery standard, from both vendors and end-users, all in anticipation of the official W3C XQuery recommendation, which is expected to be finalized soon.

Is Microsoft on board?

Yes they have been a staunch support of the W3C XQuery working group and have embedded XQuery support in their upcoming Yukon release - but they recently announced that they are dropping XQuery from the next release of their .NET Framework 2.0 (Whidbey). Furthermore, they haven't committed to ever supporting XQuery in .NET. Since .NET Frameworks ship only every 3 or so years, cutting XQuery from Whidbey means that the next opportunity for XQuery to find its way into the .NET core framework won't be until around 2009, and even then it’s far from a sure thing. That’s why it’s so important that we, the community of XQuery developers, make XQuery a priority for Microsoft.

Has Microsoft completely abandoned its support for XQuery?

No. Microsoft is a big company with many products. While they have decided to abandon XQuery support in the .NET Framework 2.0, they are a BIG supporter of XQuery in SQL Server 2005 (Yukon), and they play an essential role on the official W3C XQuery standards committee, along with other big software vendors like DataDirect, Oracle, BEA, and IBM.

In fact, Microsoft has been instrumental in the development of XQuery - but we believe that it has a much broader potential than merely as a database query language. XQuery belongs in the middle tier, with a dedicated XQuery API, XQuery processing components, tools, and so on. XQuery is more than just a niche market for XML geeks -– it is a core infrastructure component for all developers, one that provides easy integration of data from multiple, disparate sources and that simplifies Web services and SOA. If you agree with this vision and believe that XQuery shouldn't be shut out of the Microsoft .NET 2.0 Framework, sign our online petition today!

Why did Microsoft drop XQuery from the .NET Framework 2.0?

You can read their official explanation on MSDN.

What is the point of this online petition? What do you hope to accomplish?

This petition is fundamentally about application of XQuery as more then just a neat way to query databases, but also as an important data integration technology for the mid-tier. Overall, we think that XQuery is an incredibly powerful and productive language for implementing sorts of complex middleware applications like simplifying relational to XML data access, message transformation, complex report generation, Web Services and SOA, etc. This fact is well recognized by the Java community in JSR 225: An XQuery API for Java (think of it as a JDBC for XML), with companies like Oracle, IBM, DataDirect, BEA (etc.) all on board. In fact, XQJ implementations and XQuery components are already available in the Java community.

A final W3C recommendation is expected early in 2006 – less then a year from now. Instead of dropping XQuery from the Microsoft .NET framework altogether, we urge Microsoft and the Whidbey team to provide a partial XQuery implementation that addresses the more stable parts of the current XQuery Working Draft, and to follow-up with a service pack sometime in 2006. This strategy is employed by your own Microsoft SQL Server 2005 product team, which is also shipping a major product release this year. A second possibility would be to postpone XQuery support in .NET until such time as XQuery becomes an official W3C standard. Short of taking any concrete action in Whidbey, we urge Microsoft to at the very least commit to providing XQuery support in the .NET framework sometime in 2006 or beyond.

Why is Stylus Studio organizing this online petition?

We know from our customer surveys that a large percentage of the Stylus Studio XML developer community of a quarter-million registered users is currently working with XQuery, and that they develop on the Microsoft platform or use SQL Server or other Microsoft XML components. These users often ask about XQuery APIs and components for the .NET platform, so we were quite surprised to read about Microsoft's decision to drop XQuery from the .NET Framework 2.0. Obviously we believe strongly in the productivity, ease of use, and power that the XQuery language has to offer – as well as in the importance of supporting W3C XML standards for enhanced interoperability. Because of our belief in the promise of XQuery, we are using our leadership position in the XML tools industry to advocate on behalf of this important issue and hopefully to affect change in a positive manner.

I'm a Java developer. Why should I care if XQuery is dropped on the Microsoft .NET framework?

Microsoft .NET is simply too big a technology platform to not affect us all in some way, regardless of one’s technology camp. For example, imagine yourself sometime in the future basking in the glory of XQuery on the Java platform and reaping the many productivity benefits XQuery has to offer – life is good. In recognition of your talents, you are reassigned to lead a data integration project involving the Microsoft .NET platform – what will you do?! You will curse the day you didn’t help support XQuery for All, for the sake of developers worldwide, that’s what you’ll do!

Is there support for Java on the client/mid-tier? Why should I care?

Yes. Java community (Oracle, IBM, DataDirect, BEA, etc.) are currently working on JSR 225, an XQuery API for Java, and there is an active and growing market for XQuery processing components and APIs. The availability of such programming API's and components simplify XML data integration in so many ways including:

• Allowing for for better extensibility and customization of data integration applications
• Enabling seamless integration with existing legacy applications
• Simplifying the implementation of Web service applications
• Providing the means to develop custom Java middleware applications and test harnesses which invoked and process XQuery/XML similar to how JDBC is so commonly used server side java application

Microsoft Research is currently developing a declarative language called "C-Omega" for XML data access – Is this the real reason they dropped XQuery from the .NET Framework 2.0?

We have no idea.

Does Microsoft even care about my opinion?

What makes Microsoft such a great company is that they listen to their customers! Maybe not right away (not everyone can be as responsive as Stylus Studio), but in time they respond to significant customer demand. Let's speed up the clock! By signing the Stylus Studio Petition to Provide XQuery for All, you can send a clear message to Redmond that we think XQuery is too important a technology to be shut out from the Microsoft .NET framework.

Can I currently use XQuery in .NET?

Technically, yes. The Saxon.NET project at SourceForge is an ongoing effort to convert the existing Java-based code of the open-source Saxon processor to the .NET platform. However there many problems with this approach:

• Simply re-compiling Java files into .NET Assemblies is no substitute for an XQuery processor and API built from the ground up in C# and is a far cry from the level of engineering effort that went into optomizing and testing MSXML 4.0.
• Saxon is primarily an XSLT 1.0/2.0 processor whose approach to executing XQuery expressions is to implement a different parser as a front end and execute the query using the existing XSLT 2.0 processing infrastructure. This strategy is not optimized for joining data, or working with large data volumes, or doing many of the great things XQuery was intended to do, and will not work as the XQuery 1.0 and XSLT 2.0 specifications continue to diverge in the future.
• An XQuery processor is only one component of the XQuery architecture. An XQuery API (similar to ADO.NET for XQuery or JSR 225: "An XQuery API for Java") is also needed, for invoking XQuery expressions and handling the results within application code.
• The Saxon.NET packages are not a part of the core .NET Framework packages which means this technology is not available "out of the box". Furthermore these packages won't be supported by Microsoft in any official way.

So many engineers have benefited from Microsoft's past leadership efforts in providing XML processing components and APIs in MSXML and System.XML over the past five years. XQuery technologies represent the next big leap forward in XML technologies, and that same leadership role is Microsoft’s to claim today, and we urge Microsoft to take it. The Java community has embraced XQuery, and has been rewarded with a burgeoning market for XQuery components and API standardization efforts like an XML API for XQuery (XQJ – JSR 225). We thank Microsoft for the leading role you have played in supporting XML technologies in the past, and respectfully ask for continued leadership in the future of XQuery by renewing a commitment to supporting XQuery technologies in some future version of the .NET Framework

What can I do to help Support XQuery on the Microsoft .NET Framework?

We've compiled a short list of ten simple things you can do to help the cause, and there's as well free XQuery resources in the XQuery activist kit.

Microsoft says it's too late to support XQuery in the .NET Framework

Well, that's not really a question, but we understand Microsoft (as any product company) has a release schedule to keep. We still hope that Microsoft would commit to supporting XQuery in some in future point release of the .NET Framework in the next year or two.

How long will Stylus Studio keep this petition going?

There are some XQuery naysayers out there, but every day more and more developers are coming to rely on XQuery to solve complex XML data access and integration challenges. We won't win over the hearts and minds of all developers overnight, but if we are consistent and relentless with our XQuery message, then over time the critics will have to see reason. So we'll keep the petition going for as long as it takes. Patience is a virtue, and Rome wasn’t built in a day! Join us – E Pluribus XQuery!

Prev: "XQuery for All Signitories" Next: "Save XQuery on Microsoft .NET - 10 Ways to Help"