A weaker XSL?

[Tyler Baker]

Nathan Kurz wrote:

> 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?

Actually this is legal, just that when over you iterate over nodes, a Node needs to return the
expected data.  If you are reading things from a stream, then you obviously cannot just make
random accesses throughout the stream to lazily evaluate your data because streams are
inherently sequential.  For a DOM document that is merely an interface to a DBMS, this lazy
data model approach you suggest may indeed be the optimal solution for that particular
implementation.

> 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?

No.  Sorry if I confused you.

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


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