OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: Fw: XML query language

[ Lists Home | Date Index | Thread Index ]
  • From: Paul Prescod <paul@prescod.net>
  • To: XML List <xml-dev@ic.ac.uk>
  • Date: Tue, 30 Mar 1999 12:27:58 -0600

Oren Ben-Kiki wrote:
> 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. 

How about deletion? How about changes to the nodes? How about reports of
nodes that have changed?

> 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.

You are conflating implementation with language specification. XPointer is
a query language that can be used separately from XLink. Does that mean
that XLink implementations have taken a performance hit? No, because you
can choose to integrate XPointer and XLink in a loose way (xptr_filter |
xlink_filter ) or you can choose to implement them tightly. Your choice.

> 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? 

When you combine the query language with the report generation language
you end up with something very like XSL, yes. But you could use the two
separately. You could embed another query language into XSL (in a perfect
world) and use the query language in another style language or non-style

> Think of it another way. Suppose
> we agree to use:
> <xql:query match="XQL query pattern">
> Other <xql:*> tags for constructing the results...

Right. That's why XQL doesn't have tags for constructing the results. It
leaves that up to XSL, or Python or whatever it is embedded in.

> 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.

No, XQL has nothing to do with conversion. If I use it to locate nodes in
the tree before deleting them, where is the conversion? Imagine a command

XQL_locate database '/foo/bar["baz"]' | Node_Delete

The language passed between those two commands might be XML. It also might
not. Maybe it is just a list of UUIDs. Maybe it is the offset of the node
into the database store.
 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself

"Perpetually obsolescing and thus losing all data and programs every 10
years (the current pattern) is no way to run an information economy or
a civilization." - Stewart Brand, founder of the Whole Earth Catalog

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@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@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS