Fw: XML query language
Paul Prescod <paul@p...> 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@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