xml-dev - Re: A weaker XSL?

[Nathan Kurz <nate@valleytel.net>]

Clark Evans wrote:
> DOM requires the entire stream be read before the
> the document object is returned and processing can begin.
> Not only does this chew significant memory for very large
> streams, but it causes significant delay before output
> could be generated.  In the worst case, it turns a
> perfectly simple problem into an "impossible" one
> where the memory requirements and time delay make
> the solution useless.

Tyler Baker wrote:
> In this case of XSL the spec enforces constraints which make it
> impossible to be able to properly process an XML document unless it
> has been fully parsed into an in-memory tree structure (for most
> people this will be the DOM).

I apologize for jumping into this so late, but these two statements
have me a bit worried.  Are the both true?  I'm still in the XML
fiddling around stage, but I've read both of the specs and didn't draw
the same conclusions.  I was hoping these specs allowed for more
wriggle room than this.

The first statement regarding the DOM model seems true word by word,
but seems a bit misleading.  First, couldn't a bit of judicious
preprocessing allow some of those very large streams to be made into
very small streams before the DOM model is built?  The spec says that
the DOM structure model is 'structurally isomorphic' to the document,
but surely this document doesn't have to be a pre-existing XML file?

Also, while the entire stream has to have been read, does it have to
have already been processed?  The way I was interpretting the spec,
the DOM model didn't exclude a lazy processing method.  So long as an
implementation provides a compliant interface, can't it do anything it
wants with the data, even so far as to put off processing information
until it is requested?

I had hoped for an extremely lazy DOM implementation that would
maintain information about all but the root level nodes in a 'flat'
unprocessed state a request for that information is made.  For many
cases (well, at least the ones I'm envisioning) such an implemention
would be much more efficient than an entirely pre-processed one.  Is
this sort of implemention just right out of the question?

As for the second statement (regarding XSL), could these constraints
be more explicitly laid out?  While I can see that arbitrary XSL might
require a fully constructed tree, couldn't one come up with many cases
where a partially constructed tree would be sufficient?  For example,
what if your style sheet had only the following template:

     <xsl:template match="/match">
     Found a match!
     </xsl:template>

Would one still have to fully construct your tree ahead of time?

Hoping I'm not too far off base but half-expecting that I must be,

nathan kurz
nate@valleytel.net

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/ and on CD-ROM/ISBN 981-02-3594-1
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)