Lists Home |
Date Index |
- From: Paul Janssens <email@example.com>
- To: firstname.lastname@example.org
- Date: Tue, 30 Mar 1999 18:37:26 +0200
Oren Ben-Kiki wrote:
> Paul Janssens <email@example.com> wrote:
> >In my opinion, an xml query language should only describe a set of
> >equations, an xml query language implementation should only solve these
> >equations, and whatever is done with the result is NO business of the
> >query language.
> Just to make sure I follow: you'd prefer that there would be a standard
> <xql:result> DTD, so that results would always be created in an XML format
> containing references to the matched XML elements (XLink/XPointer?). The
> user would then filter this through XSL or whatever to display the results.
> 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
> - 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.
> - 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.
Paul Janssens - firstname.lastname@example.org
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)