xml-dev - Re: Query Languages for XML

[Joe Lapp <jlapp@acm.org>]

At 04:20 PM 11/15/1997 -0500, you wrote:
>[...]
>> I think the question being asked is whether you could make an input-text
>> flow object which had a clearly defined semantics in altering your XML
>> grove, not your flow object tree. For this, you would need an abstraction
>> for the form submission/editing cycle, and such SDQL primitives as richard
>> was mentionning. 
>
>Only if you take the approach that DSSSL code must manage the form
>interactivity process. I don't see why it must. It seems simplest to
>methat it should do the moral equivalent of "put a button here" and
>leave the processing of the button click to JavaScript, Java or C++.

A standard, platform-independent query language has its merits:

(1) Many people use SQL without knowing a thing about programming.  It's
easier to learn a tiny language than to have to learn a big language in
order to make use of a tiny library.  SQL is very useful as a filter-
specification language.  This allows database administrators to manage
a database by specifying complex filters that the database tool uses
to select the elements to process.  The user does not have to know the
language in which processes are defined.  Imagine trying to manage a
database by having to write a different program (or plug-in) for each
query operation you wished to perform.

(2) If the query language were defined as APIs (interfaces or IDLs) for
use in an existing programming language, a person versed in manipulating
a database from one language may find his skills of less value when he's
asked to manipulate a database in a language he does not yet know.  An
administrator's skills (or DB developer's skills) are much more valuable
if they are directly usable in many different environments.

(3) If a query must be expressed in a particular programming language,
that query will not be directly usable in other programming languages
or other environments.  It is very likely that the query would have to
be embedded in a plug-in module (or COM component or JavaBean), and
that module will not be directly usable in any other environment --
perhaps not even outside the original application for which it was
intended.  If a standard language were used, applications could share
queries, queries could be stored away for future retrieval, and users
could share each other's queries just by handing each other files.

>[...] The SQL model (I'm not familiar with OQL) is that a host
>language (COBOL, PowerScript, JavaScript, Java, whatever) handles the
>interactivity and issues data model update instructions. SQL does not
>handle the user interface itself.

OQL looks very much like SQL, except that it has extensions for
accessing object-oriented databases, and except that it throws out
the non-object-oriented update mechanisms of SQL.  It still uses the
SELECT ... FROM ... WHERE syntax.  However, both SELECT statements
and object methods can return result sets that can be further
operated on.  OQL does not have the UPDATE or INSERT statements.
To perform equivalent actions you must use methods on objects.  Such
objects might be individuals or the objects in collections retrieved
via the query semantics.

>In other words, the vast majority of forms will have nothing to do with
>the document grove itself. They may be forms designed to talk to
>relational databases or object databases or CGI or whatever. We can
>create these forms immediately, without touching SDQL. Yes, it would be
>cool if SDQL allowed grove updates, and of course we expect that if it
>did, you would be able to call it from the code that handles your
>button, just as you could call SQL or OQL etc. 

I think there is a whole class of applications that could arise from
being able to manage XML documents from clients.  Consider knowledge
repositories that retain data in a semantic form (in XML).  Users
could perform semantic-based queries and updates and all participate
together in generating a semantic model and information warehouse.
It may be that existing applications won't have much use for the
kind of query language I'm proposing -- I'm looking toward the future.

>Anyhow, I think that the DOM allows updates, so if you use DOM functions
>as your "query language" and the DOM model as your grove, then you will
>have a read/write document query language.

This is a very significant point.  I expect that DOM will define
query operations on its objects, so that via IDLs, programs will be
able to remotely manage persistent XML databases.  However, for
reasons I've given in other posts, I think an XML-based query
language is necessary.  The form of that query language might
mirror the form defined by DOM, but the query language will
necessarily provide constructs not named by DOM.  DOM assumes the
existence of a Turing-complete programming language.  Just as SQL
has, we would need to have mechanisms for piping filters through
each other and for performing operations on the result sets.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)