Announcements and Explanations about XQuery in .NET 2.0

XmlTeam's WebLog — Fri, 28 Jan 2005 18:01:00 GMT

re: More on "Status of XQuery in the .NET Framework 2.0"

Yak — Fri, 28 Jan 2005 21:53:00 GMT

I've been studying XQuery and planning to incorporate it into an application for months now. Our App translates XML datastores and web services into other sources (HTML, but also PowerPoint, Word, and Excel) using XPath queries in templates.

It's completely .NET developed and so far users love it. The only problem is that I'm finding myself righting plenty of custom code to add functionality as XPath statements just aren't powerful enough... My users want to have a PowerPoint template say {if (//pct_complete <50) then "Behind Schedule" else "On Schedule"}. I'm contnuously building in much of the major functionality of XQuery... painful as I'm hoping that I'm matching my syntax to what will be used in the future.

Is there any chance to have a seperate download for those that accept the risk of not exactly meeting the W3C standard?

re: More on "Status of XQuery in the .NET Framework 2.0"

Christian Romney — Fri, 28 Jan 2005 22:00:00 GMT

First let me say that I agree that pulling XQuery from the Framework for Whidbey was the right move. I also agree with the reasons for introducing it int SQL Server. I would also add that XML at the data storage tier is something that SQL2K tried to get in on, and while EXPLICIT mode let you do what you wanted, it was excrutiatingly painful to do so. Where I don't agree with your perspective is with respect to XQuery vs XSLT. XSLT is an excellent tool with very specific use cases. While it is true that in some regard the use cases for XQuery overlap with XSLT, there are many more uses for XQuery than simple transformations. What makes XQuery so exciting is that it is a general purpose DSL for xml akin to what SQL is for the relational model. I think C-Omega is an ugly Frankenstien solution that moves C# in the wrong direction and dilutes its focus. Adding a native xml type to C# is like adding a native table type to C#. Should we add SQL integration to C# on the level that XML integration has been added to it in C-Omega? C# should remain what it is - a great balance between C++ and VB. For me it hits the sweet spot in terms of general programming. But when I want to query (and subquery) xml datastructures I want a high-level specialized domain-specific language that has been specifically designed to work with this datatype and to support all of its idioms with the highest degree of fidelity. Long live C# and XQuery. Down with C-Omega. Lastly, it'd be so very cool if Microsoft would open-source its XQuery code from the BCL and let the community build on it.

re: More on "Status of XQuery in the .NET Framework 2.0"

Sean — Fri, 28 Jan 2005 22:27:00 GMT

I like that last idea of breaking XQuery (and perhaps other bits which are based on evolving standards) out of the BCL into seperate APIs -- similar to how the WSE is implemented -- so long as there is a solid way to deploy these other packages.

re: More on "Status of XQuery in the .NET Framework 2.0"

Mike Champion — Fri, 28 Jan 2005 22:29:00 GMT

> Should we add SQL integration to C# on the level that XML integration has been
> added to it in C-Omega?

I for one would like to see tuples and XML documents treated as first-class data objects in programming languages. I understand that this expands the scope of the languages, but it seems like a natural evolutionary step. Over the last 30 years, strings, data structures, and objects have gradually moved from application-level to language-level constructs; continuing that trend seems like a good idea to me, FWIW.

More on XQuery vs C-Omega

XML-BLOG — Fri, 28 Jan 2005 22:33:00 GMT

Mike Champion has a post on Microsoft's decision to cut XQuery from Whidbey (but leave a subset in SQL Server). I completely agree with their decision and rationale for pulling XQuery from the 2.0 version of the Framework class library, but I have to disagree with his assessment of XSLT...

re: More on "Status of XQuery in the .NET Framework 2.0"

Drew Marsh — Fri, 28 Jan 2005 23:19:00 GMT

You're making the right decision. No reason to set yourselves up to be burned by changes to the spec and years of hearing people complain "MS has proprietary XQuery!".

Ship it as a separate assembly or as part of a 2.x upgrade to System.Xml.dll.

re: More on "Status of XQuery in the .NET Framework 2.0"

Kent Tegels — Sat, 29 Jan 2005 07:51:00 GMT

"Are there any passionate admirers of XQuery as something other than an XML database query language who think that MS should be seriously considering client and middle-tier use cases for XQuery once XQuery is a Recommendation?"

I don't think that's right question at all. The question should be "why don't we do the best job providing a tool that we can and see what developers use it for?" I just can't imagine Hollerith had the XBOX in mind when started his work. But today, were on the same type of threshold when it comes to where "smart data" could go in future. That's not to say that XML and XQuery are the future of data, but rather, they influence what might be. When you decide to not invest in a technology "because there's no use cases for it today," it artificially constrains what contributions it could be making going forward. What's sad for me to read here is "I've given up on the idea of XQuery as an XML-aware general purpose programming language for real-world developers." Why? Because XQuery isn't just "SQL for XML." Its fundamentally different is that there is a real standard that many companies are likely to push for near complete adherence *because of* not *despite* market demands to do so. SQL just doesn't have that and saying that languages like Cω are a better choice is a step down the same path IMHO. XQuery isn't a general purpose PL either, nor should it be. It should be the best language for querying, reshaping and managing data expressed as XML and that's it. The power that MS brings to the table is building high quality yet easy to use tools for working with standards (well, at least those they chose to anyway) for developers. That's the mind set that you need to take with XQuery. Let us decide what to do with them. You'll be amazed at the results.

After all, look what we did the with the "stone knives and bear skins" of HTML, scripting languages and FrontPage...

Of OLUG, XQuery and mild suprises.

Enjoy Every Sandwich — Sat, 29 Jan 2005 07:59:00 GMT

Of OLUG, XQuery and mild suprises.

re: More on "Status of XQuery in the .NET Framework 2.0"

Kent Tegels — Sat, 29 Jan 2005 08:02:00 GMT

re: More on "Status of XQuery in the .NET Framework 2.0"

Mike Champion — Sat, 29 Jan 2005 19:12:00 GMT

Kent Tegels makes some very interesting points. First "why don't we do the best job providing a tool that we can and see what developers use it for" is exactly the right question, and exactly the question we discuss internally. All I'm saying here is that at one point it looked like the answer was "XQuery", and now it doesn't. More later on what we conclude that the answer is.)

Second, if XQuery does in fact become the "real standard" for querying, reshaping, and managing data represented as XML, what I'm saying here could change. Right now it looks like it will be the real standard for querying, it will compete (IMHO unsuccessfully) for mindshare/resources with XSLT as the real standard for reshaping, and could possibly (after 1.1 is a Recommendation in a few years) be a contender as the one true standard for managing XML data. So, we are betting on XQuery as a query language, investing more in XSLT as the reshaping standard for the time being, and keeping an open mind about data management/manipulation.

There seemed to be an implication in the post that maybe MS should cover all the good guesses about which XML technologies will find good uses and let the market sort it all out. That's how I used to think about MS anyway -- "they could easily afford to support [X, Y, Z] why don't they? From the inside it looks a bit different -- I see budget decisions driven by business case analyses, lots of people spending lots of energy maintaining / testing / securing code based on long-ago guesses about what might be useful, an *immense* list of immediate needs and good ideas competing for resources, and a need to make hard choices going forward. I'm pretty sure that the choices we make will enable all sorts of unforseen use cases better than investing our finite resources in XQuery on the client today would have.

Weekend Summary - XQuery, XQuery, XQuery - My "New Best Friend of the Day" award and other fun stuff from this weekend

Tue, 01 Feb 2005 01:13:00 GMT

I've spent a majority of this weekend whackin' at some code for the site as well as preparing for phase 2 of the project, integration into Saxon.NET. There are still some features to finish on the side in regards to...

re: More on "Status of XQuery in the .NET Framework 2.0"

Sean Ottey — Fri, 04 Feb 2005 02:17:00 GMT

In doing some <a href="http://www.wpclabs.org">research</a> for possible use of XQuery in a simple translation engine, I (possibly incidently :-) ) came to the same conclusion: In reviewing 5 or 6 XQuery client side implementations, MS is not "down the path" far enough just yet, and it would take a crystal ball to be sure of a final sulution [before the fact] that aligned with the final standard [after the fact].

Our system is a parser/processor which, on completion, needs to pass of the resultant data, in XML form, to a translator for final conversion to a legacy format. This could have been done a number of ways, but I was interested in trying to incorporate greater flexibility in the future and XQuery seems to present that promise.

The Saxon.NET engine has me chomping at the bit, but for now, we're using the Java Saxon with some proprietary interop stuff between that and our .NET listeners. Granted, it sounds like our purposes would have been met by the "partial solution", but the majority of early adopters are looking for comprehensive support to leverage in their next gen apps.

It would be nice if the Native .NET XQuery support were prepared in such a way that, once the W3C standard becomes gospel, release to market would be minimal...

microsoft visual studio sulution

microsoft visual studio sulution — Thu, 10 Jul 2008 16:26:10 GMT

PingBack from http://gisselle.onlinevidsdigestabout.info/microsoftvisualstudiosulution.html

mikechampion s weblog More on Status of XQuery in the NET Framework 2 0 | Portable Greenhouse

Wed, 03 Jun 2009 11:11:08 GMT

PingBack from http://portablegreenhousesite.info/story.php?id=25105