Lists Home |
Date Index |
- From: Tyler Baker <email@example.com>
- To: Nathan Kurz <firstname.lastname@example.org>
- Date: Thu, 04 Feb 1999 13:54:37 -0500
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
> 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!
> 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
> xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
> To (un)subscribe, mailto:firstname.lastname@example.org the following message;
> (un)subscribe xml-dev
> To subscribe to the digests, mailto:email@example.com the following message;
> subscribe xml-dev-digest
> List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)