A weaker XSL?
Tyler Baker
tyler at infinet.com
Thu Feb 4 18:57:42 GMT 1999
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)
More information about the Xml-dev
mailing list