Fw: XML query language

[Oren Ben-Kiki]

Paul Janssens <paul.janssens at skynet.be> wrote:
>I wrote:
>> Nice separation of concerns, but I see several objections:
>>
>> - Efficiency. Suppose I'm querying a very large DB, and I'm getting a
list
>> of matches scattered all over the place. In the current approach, the DB
>> would both resolve the matches and extract the necessary data,
potentially
>> at the same pass using a lot of locality-of-reference optimizations. In
your
>> method a second tool would re-fetch the references in a second phase,
which
>> would probably double the cost of doing the query.
>
>That's an implementation issue. You can build a tool that has an input
>of both the query and the style description, and optimizes the DB acces.
>In other words
>
>xml report syntax = xml query syntax + xml style syntax
>
>does NOT imply
>
>xml report implementation = xml query implementation + xml style
>implementation


We are not talking about a "report tool". I think it would be a very rare
application which would do an XML query and would only be interested in
pointers to the result, without requiring any data from that pointer. If
what you call a "report tool" is integrated into the query tool, always, it
hardly makes sense to make the distinction; if it isn't, then "non-report"
application will get the performance penalty hit.

>> - Power. Assume that I hypnotize all the W3C members to adopt the XSL
>> transformational part as XQL version 1.0 :-) This is more powerful then
>> current ?QL proposals because it allows for an <xsl:template> to call
>> <xsl:apply-templates> - that is, to perform nested queries (and
therefore,
>> BTW, offers a natural way to do joins without variables, and solves other
>> ?QL problems). All this works because XSL has a rich language for
>> constructing the results. In your approach, you won't be able to do a lot
of
>> that; you'd end up adding special constructs for them, duplicating XSL's
>> capabilities in an incompatible language. Of course you'd be in good
>> company - that is what all the other ?QL language proposals do :-)
>
>I have no problem with recycling some XSL syntax into ?QL where
>applicable, in fact it would be a good idea. Just as you could recycle
>XPointer syntax where applicable.


If we agree that an XQL match pattern should be used to select elements in
the DB and that XSL syntax should be used to specify what the XML result
data should be, don't we end up with XSL? Think of it another way. Suppose
we agree to use:

<xql:query match="XQL query pattern">
Other <xql:*> tags for constructing the results...

Then what is the difference between <xql:query> and <xsl:template> and
<xql:*> and <xsl:*>? Why bother having both?

Maybe it would be clearer if we thought about it this way: what feature of
XQL isn't useful in the transformational part of XSL, or vice versa? I can't
think of any. IMVHO both are _applications_ of the general XML -> XML
conversion problem, and any feature relevant for this problem will be
relevant for both.

>> - Convenience. It is easier to specify a query as just "one thing"
instead
>> of two. Note that even if ?QL == XSL transformation, it still makes a lot
of
>> sense to filter its results through another XSL stylesheet for
presentation
>> in most cases. Even lazy users will do so - if, for example, they had
>> already available XSL sheets for displaying certain types of results.
>
>The report syntax will allow you to either link to a query and style, or
>describe them inline, e.g.
>
><report>
>   <query>...
>   </query>
>   <style>...
>   </style>
></report>


Not nearly as convenient. In the query part you'd specify match patterns for
the DB, which automatically generate a list of pointers. You'd then specify
in the style section match patterns for entries in this list, which somehow
dereference them, and then proceed to match on the resulting trees to
generate FO objects (or whatever). There's both extra complexity for the
query writer and for the implementation which needs to figure out how to do
this in one pass for efficiency.

Does this really have any benefit over matching elements in the DB and
directly specifying which "near-by" elements are of interest using normal
XSL syntax? You would have the option of integrating the transformation to
FOs (or CSS) into this XSL (useful for ad-hoc queries and specialized
applications) or feeding the results to another XSL stylesheet for display
(probably one independent of the query, and fitting a particular display
media or format).

Share & Enjoy,

    Oren Ben-Kiki


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)