RE: XQuery -- Reinventing the Wheel?

[Ray Whitmer <ray@xmission.com>]

On Thu, 22 Feb 2001 Jonathan.Robie@SoftwareAG-USA.com wrote:

> Brian Miller wrote:
> 
> > Jonathan.Robie@SoftwareAG-USA.com wrote:
> > > 
> > > "An entirely new syntax" seems to be a bit of an
> > > exaggeration.  In fact, XPath 2.0 will become that 
> > > common semantic and syntactic core for both 
> > > languages [XSLT and XQuery].
> >
> > How awkward that XPath (the "common semantic and 
> > syntactic core" of our pending XML revolution) is 
> > itself not expressed as XML.
> 
> Actually, I do not see this as awkward. In SQL, the query language is not
> expressed in tables and rows. In XQuery, the query language is not expressed
> in XML. Why is this a problem?
> 
> I have played with several syntaxes for expressing XPath with XML syntax,
> and it makes expressions *much* harder to read, write, and modify. However,
> it's quite easy to generate these representations automatically using an
> XPath parser, and they can be easier to use for programmatic manipulation.
> But I don't want to write them by hand.
> 
> Historical note: XSLT once *did* use an XML syntax for path expressions. The
> XSL Working Group found this awkward, and adopted a string-based expression
> language for the convenience of stylesheet authors.
> 
> Jonathan

There are significant use cases for which having a readily-available object
and processing model are quite useful.  This doesn't mean that it should be
the only syntax.

It is easy to represent XPaths as XML, but the people who developed XPath
were apparently thinking of file-system- (or URL-) like paths and their
syntax caters to people who are used to that type of representation, which 
many people think is a good thing.

I personally highly value what an XML representation would bring with it,
such as a DOM that makes it easier to construct complex expressions,
an infoset, the ability to access every element of the expression as part
of an XSL or other transform, etc.

But I have understood from very early days when this was being discussed
that an XML alternative syntax would be a possibility.  Someone on this
list not too long ago suggested, I believe, an XPath cross parser, which
took an XPath and produced the DOM of an XML equivalent syntax.  I think
it might be useful to more-seriously explore XML equivalences for micro
syntaxes used in XML such as XPath or parts of SVG which seem to be
quite profitably mapped into XML.  It might be nice to have these things
optionally brought into the infoset through equivalence mappings so that
the general XML facilities could operate on them, too, rather than making
impenetrable black boxes out of them, especially where there are use
cases for both syntaxes.

Ray Whitmer
ray@xmission.com