Lists Home |
Date Index |
- From: Derek Denny-Brown <email@example.com>
- To: firstname.lastname@example.org
- Date: Thu, 20 Nov 1997 09:58:47 -0800
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
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 E. Denny-Brown II || email@example.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:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)