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

Re: XQuery -- Reinventing the Wheel?

• From: Uche Ogbuji <uche.ogbuji@f...>
• To: Gerd Mueller <gerd@s...>
• Date: Mon, 26 Feb 2001 07:35:25 -0700 (MST)

> > Please resist.  Having an XML syntax has made XSLT very ugly
> > and cumbersome to use.

I should note that I think XSLT implementation will mature so that a lot
of the endless typing currently necessary is no longer so.  Ranging from
synthesis from simple expression to full XSLT (a la XSLT-based Schematron)
to Oo-wee gooey XSLT editors (Stylus?), and passing through such one-off
tools as Oliver Becker's loop converter, hopefully the problem of XSLT
verbosity will waer off.

Of course this is what was hoped for XML itself and I still do my XML
editing using emacs.

> Maybe, but on the other hand an XML syntax gives us the possibility
> to create and process queries with 'common' XML tools. And it don't
> have to be ugly and cumbersome. E.g. http://www.xmldb.org/xupdate
> specifies and update language for XML documents and the syntax is
> quite clear and easy to use.
>
> IMHO, the current XQuery spec. tries to much: it wants to select
> _and_ transform, although selection would be enough. If I like to
> transform the query results I use XSLT. This way XSLT and XQuery
> would have a clear scope: One for transformation and the other for
> selection.

This is, I think, an important take on the discussion.  I think most of
the pro-XQuery arguments (excepting the syntactical arguments, which I
think are s much less important) point to efficiency of selection.

So would there be anyproblem with making XQuery a super-selector for XSLT?
That way the result-tree mechanism could be re-used, and there could be
crucial clarity in exactly how XQuery builds on XPath.

If XSLT got, in addition to its current path selection, the ability to
crunch cartesian products of information element containers, along with a
lazy-evaluation scheme that allowed for efficient handling of interim
results, wouldn't this address both camps' concerns?

BTW, thanks to Jonathan Robie for his reasoned and patient arguments.
I've not come all his way yet, but I've learned much and amended some of
my views on the matter.


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@f...               +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

• Prev by Date: Re: Why not reinvent the wheel?
• Next by Date: RE: Data Model(s) for XML 1.0 / XML Devcon / DOM / XSL / Query
• Previous by thread: RE: XQuery -- Reinventing the Wheel?
• Next by thread: No Subject
• Index(es):
  • Date
  • Thread