[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Fw: XML query language
Paul Janssens <paul.janssens@s...> 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@i... 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@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|