[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: XQuery -- Reinventing the Wheel?

  • From: Evan Lenz <elenz@x...>
  • To: Uche Ogbuji <uche.ogbuji@f...>, xml-dev@l...
  • Date: Wed, 21 Feb 2001 19:10:32 -0800

quoted xquery

Uche Ogbuji wrote:
> Evan Lenz:
>
> "This is correct, but XSLT already extends the XPath model to support
> non-well-formed source trees. Thus, the XQuery "ordered forest" is very
> much like the XSLT data model."
>
> Now I'm guessing at what Bob meant, but as I read that question, the
> simple answer is document() and not some minor arcana of the XSLT spec.

Yes, but, as I'm sure you understand, document() doesn't provide the same
functionality as querying a collection of documents without regard to
document names. I think it's still important to point out that XSLT can,
without disrupting the standard, model a collection of documents, though
perhaps with a few quirks. The reason I think this is important is to
emphasize how little might have to be changed or added in order to use XSLT
as a query language. We agree on this point.

>
> My talk of thin ice was precisely making the point that I hoped such
> minutiae were not the basis of the argument against XQuery's re-inventing
> the wheel.  As I think you, Evan and I all agree, the main point is that
> XSLT provides the general machinery for document query across documents.

Yes. I think the burden on me to show that XSLT is viable as a query
language is much smaller than the burden on the XML Query Working Group to
defend their proposal for an obvious XSLT clone. My primary aim is to
identify the problem, not to propose a specific solution.

> All I think would be needed in XQuery is a formalization of document
> collections and some unification of data models across the various facets
> of XML (XPath, DOM, SAX, XLink [note linkbases]), etc., where query proves
> useful.  And finally a few primitives based on XSLT extensions for
> specialized and efficient query calculus.

Yes, but I think these should probably be two different specifications, a la
the distinction between XQuery and DASL quoted in a previous post.
Ultimately, since our query language (XSLT) is based on the XPath data
model, something like the XPath data model should prevail, extended perhaps
with a referencing mechanism (XLink). (I believe this is one of the XML
Query requirements.) How instances of that data model are created should be
specified elsewhere; note that the W3C, as far as I know, is not directly
addressing this issue, which may portend opportunity for someone else...
But, ultimately, I'm interested in XSLT's viability as a query language, not
as much in how instances of its data model should be created, though I
recognize this is important. (And I recognize that these are not wholly
orthogonal.)

> XQuery could be a very small and very familiar spec.

I very much like the sound of this :)

Evan Lenz
XYZFind Corp.


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.