OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: XQuery - The truth comes out!



Title: RE: XQuery - The truth comes out!


> -----Original Message-----
> From: Evan Lenz [mailto:elenz@xyzfind.com]
> Sent: Saturday, February 24, 2001 11:34 PM
> To: Jonathan Robie
> Cc: xml-dev@lists.xml.org
> Subject: Re: XQuery - The truth comes out!
>
>
> Of course, I make a bigger claim as well, that not only is
> virtually any XSLT query algorithmically convertible to XQuery at
> compile-time, but that many of them, in particular those that only use
> "down-reference pull" are not only trivial to convert, but the conversion
> is obvious to  the user.

Hi Evan,

I'll let you and Jonathan duke it out over whether this is true.  But even IF it is true, does that mean that XQuery should not go forward?  I see XQuery as a single language within which to do all of what XPath does, some of what XSLT does, some of what SQL does, with some scripting and DOM-like functionality as well ... all within a common data model and processing paradigm.   I see this as a "good thing" even if it is not absolutely needed given the existence of all this other stuff.

More philosophically, we need to be wary of carving existing practice in stone; there has to be room for evolution/markets to select the best practices.  If XQuery moves that forward significantly, I personally find the cost in confusion to be tolerable.  

So, I'd be more interested in hearing people's opinions on whether XQuery would meet their business needs more conveniently than the existing specs.  Existing practice seems like an RDBMS world in which SQL has nothing but a SELECT ... WHERE clause, and you have to use a report writer if you want to reformat the output, some procedural code whenever you want to deal with multiple tables, and so on.  XQuery gives the XML world roughly the functionality of SQL -- to incorporate a reasonable set of querying, processing, transforming, and updating tools in a single language.  That seems like a "good thing", and a nicer world to live in than one in which people have to warp XSLT to do things it wasn't designed to do, simply because it logically can do them. 

What am I missing here?