Query Languages for XML

[Joe Lapp]

At 09:57 AM 11/14/1997 -0800, you wrote:
W. Eliot Kimber wrote: <eliot at isogen.com>
>[...] Any new language
>would, I think, mostly be an exercise in syntax definition, most of
>which is already inherent in the development of XSL (which is nothing
>more than a language for applying processes to the results of queries on
>XML groves).

The language would also consist of semantics -- a standard
interpretation of the syntax.  Some application will have to
make sense of the query based on its semantics.  The syntax
and the semantics of that syntax would have to be standardized
so that the applications that are developed to interpret the
queries all interpret the queries identically.

XSL may be thought of as a query-only tool or as a translation
tool.  As Richard Light explained, it doesn't provide a mechanism
for modifying the originally queried XML document.  XSL could be
used to convert portions (or all) of an XML document from one
XML representation to another, provided that flow object types
were available for all element types in the XML document.
However, there is no standard mechanism in place to update the
original XML document.  You might use XSL to create a replacement
document and then upload the replacement, but this is not
conducive to having many users concurrently querying and updating
the document (you'd have to lock the whole document).

>From another point of view, it's not possible to have *an* XML query
>language because there are too many different ways that you might want
>to access XML data: as nodes in groves ala SDQL, as full text using some
>full-text index, as semantic-specific objects using some domain-specific
>query mechanism, etc.

I agree that there will be many different ways to query a document
and that it is not possible to anticipate them all in advance.  One
(read-only) query might be analogous to XSL's pattern rules, which
queries based on the physical structure of the document.  Another
query might be analogous to an AltaVista-style word-based search.
Still another might operate by traversing XML's linking facilities
or by tranversing RDF's associations.

I think this is where XML's extensibility comes into play.  We
would define a standard query language for the most common querying
activities, such as those in XSL patterns (XSL patterns might be the
basis of the language).  If a user wishes to query an engine that
handles extensions, it is likely that the user will want to mix
standard query operations with the extended queries.  Each query
(even each extended query) is likely to return a result set that
takes the form of an XML document (a virtual one).  Such result sets
would be ameniable to additional querying via the XML-Query standard
(perhaps all within the same complex query statement).

Furthermore, every XML query engine would be able to parse every
query.  Each would be able to identify the constructs that are not
available to the engine.  There might be a way for the engine to
delegate the queries or operations associated with those constructs
to other (perhaps specialized) query engines.  If not, the engine
could return a meaningful error message to the user (e.g. "Element
type 'full-word-index' not supported.")

>A language like SDQL coupled with an XML property set (that is, the
>subset of the SGML property set needed to represent XML documents)
>provides a complete set of operations for querying XML documents
>represented as groves. [...]

I don't know a thing about SDQL, and I'm having trouble finding
useful material on the net.  Could someone please point me to
something that might be accessible to someone having no DSSSL
experience and having only a very rudimentary knowledge of LISP?

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