Query Languages for XML

[Paul Prescod]

Graydon Hoare wrote:
> If you run jade in sgml-to-sgml mode, you can make HTML out of arbitrary
> XML, but I don't think there are flow-objects representing forms. 

Sorry I was talking about XSL. As I understand it, XSL will allow you to
create any HTML element.

> What would it mean to take a form
> flow object and render it through a TeX backend? The "interactive" nature
> is gone. What happens to a combo-box? 

About the same as the printed rendition of a link or scroll flow object.
It would be completely useless. Stylesheets are tied to a particular
medium. Online stylesheets should have elements (link, input, scroll)
that allow interactivity and print-oriented stylesheet languages should
have elements that describe pages etc.

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

> It makes sense -- he's basically talking about getting
> full grove-manipulation into the query language so you can consider the
> grove a simple object database. OMDG OQL is probably worth looking over.

I can see that, but I don't think it necessarily has anything to do with
form input. 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.

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. 

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.

 Paul Prescod

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)