[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Fw: XML query language and another OS/XML suggestion

• From: "Stephen D. Williams" <sdw@l...>
• To: Oren Ben-Kiki <oren@c...>
• Date: Tue, 30 Mar 1999 13:56:31 -0500

I don't have a strong opinion yet on xml query languages and results, however:

Maybe the results could be the XLink/XPointer AND the contents that it points to.  That way
you have a canonical reference but also get the contents for efficiency.

Offhand, for many situations, especially database queries, I think that it will be difficult
to Always generate a reasonable XLink/XPointer.  With SQL for instance, it is quite common to
create result strings from multiple fields and transformations.  Additionally, results will
often be ephemeral snapshots of something  (stats, processes, connections from /dev/proc/xml
for instance) that have no future reference.  Maybe this can be solved by just having a
'dead-end' link value to communicate these situations as meta-data.

A note on the /dev/proc/xml mention: I've been thinking for a while that EVERY data/meta-data
interface to a typical OS (such as Linux/Unix) should have an XML form.  Maybe add or override
-X  or --XML to all commands where it could possibly make sense.  ps, netstat, lsof, ifconfig,
df, egrep, ls, etc. are all good candidates.  Add simple tree/value extraction to bash and
you'd have more portability for a lot of things.

sdw

Oren Ben-Kiki wrote:

> Paul Janssens <paul.janssens@s...> wrote:
> >In my opinion, an xml query language should only describe a set of
> >equations, an xml query language implementation should only solve these
> >equations, and whatever is done with the result is NO business of the
> >query language.
>
> Just to make sure I follow: you'd prefer that there would be a standard
> <xql:result> DTD, so that results would always be created in an XML format
> containing references to the matched XML elements (XLink/XPointer?). The
> user would then filter this through XSL or whatever to display the results.
>
> 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.
>
> - 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 :-)
>
> - 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.
>
> So all in all I prefer my approach: XQL = XSL - FO.
>
> 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...)

--
OptimaLogic - Finding Optimal Solutions     Web/Crypto/OO/Unix/Comm/Video/DBMS
sdw@l...   Stephen D. Williams  Senior Consultant/Architect   http://sdw.st
43392 Wayside Cir,Ashburn,VA 20147-4622 703-724-0118W 703-995-0407Fax 5Jan1999



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

• References:
  • Fw: XML query language
    • From: "Oren Ben-Kiki" <oren@c...>

• Prev by Date: Fw: XML query language
• Next by Date: XML query language and another OS/XML suggestion
• Previous by thread: Re: XML query language
• Next by thread: XML query language
• Index(es):
  • Date
  • Thread