Query Languages for XML

[Derek Denny-Brown]

At 06:38 PM 11/19/97 -0800, Lauren Wood wrote:
> The idea of the DOM is to standardize the object 
>model part of "dynamic HTML" (whatever that might mean; the definition
>seems to change with the application that supports it, the person talking 
>about it, and probably the phase of the moon as well). So what sort of
>extension to XSL do you mean? I also don't understand why the XML 
>would have an XSL-grove interface, and the "output" (what does 
>output mean?) would have a DOM interface, when the DOM should 
>be an interface to an XML document...

I am not neccessily saying that DOM = dynamic HTML, but rather it is my
expectaction that dynamic HTML will depend on the DOM model, which from
what little I have glimpsed (admission of a failure to properly look into
it on my part), is quite different from the SGML/XML Grove model.  I
envision that a number of the initial XSL implementations which use the
HTML/CSS flow objects, will be based on existing HTML display engines.
These engines, asuming they have any real "dynamic" HTML potential, will be
using javascript/jscript/vbscript and something at least DOMish to provide
the "dynamic" part of the dynamic HTML.  Thus I would expect that a XSL
implementation that did more than build a static page would need to work
with these engines using a DOMish interface.

This means in the case of some XSL document, that the 'input' is a XML
document (and a XSL stylesheet) and the output is the screen via this
HTML-based display engine which allows some "dynamic" behaviour via a
DOMish interface.  That means that the XSL stylesheet (assuming it is using
some XSL extensions to talk DOMishness with the display engine) is talking
Grove-speak to the original XML document (because that is how XSL was
defined, at least in how I read the spec) and DOMishness to the display
engine (beyond the initial flow-object creation).  Having only limited
experience with DSSSL, I really don't have a complete picture of how
XSL/DSSSL could work in an "dynamic" output media environment.

what I mean by "dynamic" in the above paragraphs is that the display engine
has some means to change the (existing) rendering, on the fly.  I click the
"Verify" button and all the text fields which have invalid entries become
some nuclear-neon pink, so that I know where my error are, as an example.
Or even better, I can insert some new flow-objects or remove existing flow
objects from the displayed flow-object stream.  My classic example of what
I want from a "dynamic" HTML rendering engine is that I can build a "tree"
using the builtin list/list-item flow-objects, where I can expand/collapse
portions of that tree at runtime, without reloading the document.

I hope this emplains a bit.  I realize my original post was a (wee-bit)
criptic, and I left out some of my in-between thought processes (as an
excercise to the reader of coarse. <grin>)

-derek



     Derek E. Denny-Brown II      ||   ddb at criinc.com
     "Reality is that which,      ||   Seattle, WA USA
  when you stop believing in it,  ||  WWW/SGML/HyTime/XML
 doesn't go away."  -- P. K. Dick || Java/Perl/Scheme/C/C++

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)