Cart
[Home] [By Thread] [By Date] [Recent Entries]
Oren Ben-Kiki wrote: > > >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. Right. Pointers to, not copies of, the nodes. And the pointers should be in the most efficient "syntax" allowed by the system. In a Python program it is a PyObject reference. In C++ it is a DOMNode *. In a process-portable XML encoding it is an XPointer. Everybody is focused on this last case but it is only a special case. > >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. I didn't say that there should be no standard way. I said that the standard way is not something that the query language should specify. If there are 6 query languages (some standardized and some proprietary) and 6 result encoding syntaxes (some standardized and some proprietary) then you should be able to use any query language with any encoding syntax. > Both XML-QL and XQL have ways to construct results (CONSTRUCT and > <xql:result>). There is no such element type described in http://www.w3.org/TandS/QL/QL98/pp/xql.html > 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. Yes! > 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. Techically a good idea but I think that it is politically impossible to separate XSL and its matching language at this point. Maybe XSL 2.0 will depend on whatever XML QL is eventually standardized. > - 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? I agree with all of this but changes to CSS are unlikely in the short->medium term. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "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 http://www.wired.com/news/news/culture/story/10124.html 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...)
|
