Fw: XML query language

[Oren Ben-Kiki]

Paul Prescod <paul at prescod.net> wrote:

>I wrote:
>> Well, them, what other way is to return a list of XPointers then to store
>> each in an "element"?
>
>You don't need an element. You just need a nodelist. Look at the DOM's
>brutally named "getElementsByTagName" method.


You mean the NodeList contains the matched nodes directly, and not XPointers
which point to them. Presumably these nodes can be used to either access to
tree in the vicinity of the match, or to obtain other data regarding the
node (such as a fast ID for direct access to a DB record or whatever). That
does makes more sense then Paul Jenssens' proposal (returning XPointers).

>If you are asking me what is the syntax for a nodelist then I'll say it
>has no syntax. It is an abstraction like the record set returned by a
>database. If you have to move the query result between machines then you
>can choose an encoding (quite likely XML) but that's outside of the realm
>of the query language itself -- it is akin to report writing.


No standard way to represent a query result as text? I find this strange.
But if the result is a nodes list, wouldn't fragments somehow resolve this?
After all each node is a fragment...

>If you aren't moving data between processes then you shouldn't be forced
>to encode it in XML (even a DOM). This is just a general principle that
>applies here.


The output of an XSL processor is also not forced to be encoded in XML (it
might be a DOM or even a display on the screen), but it is very helpful to
have a standard XML encoding for it (witness the current XSL
implementations). Shouldn't the same hold for XQL?

And in a separate message:


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

Both XML-QL and XQL have ways to construct results (CONSTRUCT and
<xql:result>). I feel that _if_ XML is to be constructed as a result of an
XML query then XSL is the language to do so; there's no need to invent a new
construction language. Can we agree on this?

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

OK, if what you are saying is:

- We have two languages:
  (i) matching of XML elements, which we'll call XQL for the moment, and is
basically the XSL match pattern language;
  (ii) constructing XML trees from other XML trees which we'll call XTL for
the moment and is basically the <xsl:*> tags.
- XSL is the combination of both (plus FO objects).
- XQL is usable in other contexts then XTL.
- There's no other standard XML construction syntax other then XTL.

Then we agree. I'd also add:

- We should have separate specs for XQL, XTL, and FOs. The XTL spec should
simply reference the XQL spec. The FO spec should be independent.
- XQL should be used wherever a set of XML elements needs to be selected
from an XML tree.
- So therefore CSS should allow using XQL in its selectors. For that matter,
CSS should allow an XML syntax :-)
- And also XPointers?

Actually, what is the difference between XPointer syntax and XQL (as defined
above)? Both allow matching elements according to the structure of the XML
tree and/or the value of attributes. The syntax is different and the set of
capabilities doesn't exactly match. Is it just due to historical reasons
that XSL isn't using (possibly enhanced) XPointers in its match patterns?

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)