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 -- Reinventing the Wheel?



> 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.

Ah.  I see now.  I would prefer that this was dealt with by adding
container primitives to XSLT rather than relying on arcane wording in XSLT
1.0.  Michael Rys was also talking about document()'s scalability, and my
guess now is that he actually meant its convenience.

With containers, a subject, BTW, which Kimbro, others and I have been
discussing in the XML::DB group, all of this can be addressed quite
simply.  We could start with the WebDAV model and improve from there.

> 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.

Yes.

> > 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.

This is a very important point.  I do think that the XQuery group should
go to great pains to explain the redundancies.  It may be that we're
missing somethig, but it can't just be taken for granted that "something
else" is needed.


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python