RE: XQuery -- Reinventing the Wheel?

[Charles Reitzel <creitzel@mediaone.net>]

I see XML query processing (lower case q) as occurring in four stages:

1) Identify the universe of documents that will be searched.
2) Apply query conditions to include/exclude each.
3) Add specified fragments of each document to intermediate results.
4) Present output.

XSLT does a good job on 2)-4) and an adequate job on 1).  Without some more
powerful notion of locating documents - within a larger file system
directory structure, meta-data query result set or other means - I don't see
the value add for XML Query.

I believe any of the XML database products available do provide such a
container scope.  This concept is roughly equivalent to the set of available
tables in SQL or a DIT in LDAP.  Do the the XML dbms'es have enough in
common to start defining a standard query language along the lines of SQL or
LDAP?  If so, what are the shortcomings of XSLT in this regard?  In addition
to closing data model loopholes, perhaps a better definition of search scope
semantics is called for.  In any case, I don't see why these things can't
fit into XSLT.

These are non-emergency issues, however.  Proprietary products are filling
current market needs.  There are simply higher priorities for
standardization.  Horse before cart.  Walking, then running.  etc.  etc.
Take a survey of XML dbms vendors.  Do they want XML Schema data types
(yesterday) or XML Query (sometime after MS delivers .NET)?  Do they want
equality and ordering rules for data types?  In C++, for example, these
operators are almost always defined with the data type.  More deployment
experience with the basics should guide standards at the container level.

take it easy,
Charles Reitzel


On Wed, 21 Feb 2001 Kimbro Staken <kstaken@dbxmlgroup.com>
>Uche Ogbuji wrote:
>> 
>> Not a problem as far as XSLT qua XSLT.  But once you rely on this
>> property for standardized  treatment of a grove (term loosely used),
>> which is what it seems your XSLT-base dproposal would do, I think 
>> you'd need to have strict prescription of the mapping from multiple
>> documents to XSLT source for this not to be problematic.  Maybe you
>> already do so in your paper, which would, I think, cover my concerns.
>
>I'd think this to be a minor point really. I believe Evan's major point
>is just that the majority of XQuery syntax can be easily mapped to XSL-T
>and that creating an entirely new syntax may not be the proper thing to
>do. Clearly XSLT as it stands now is not fully sufficient to act as a
>query language. It seems though, that the changes required would be
>minor compared to having to deal with an entirely new language or even
>worse two new languages once the XQuery XML mapping is added. I
>certainly don't see current XSLT implementations suddenly becoming query
>engines, performance just isn't good enough. However, a specialized XSLT
>engine that implements a slightly modified spec and has an optimizer to
>utilize indexes might be a much simpler way to go. Regardless it would
>certainly be able to leverage the vast majority of the work already put
>into XSLT vs. starting from scratch on XQuery implementations. The more
>I think about it the more I find it a compelling idea but I just have to
>wonder if it can be made to perform well enough. 
>