Lists Home |
Date Index |
- From: Tyler Baker <email@example.com>
- To: Don Park <firstname.lastname@example.org>
- Date: Thu, 11 Feb 1999 00:16:16 -0500
Don Park wrote:
> I am in complete agreement without regarding the use of DOM documents as
> input to XSL processors.
> However, I think we should revisit what the conflicts are specifically.
> Could you point out what aspect of the XSL or the namespace spec forces DOM
> tree to be rebuilt over and over?
As far as the source tree is concerned, since there is no native namespace support, any
mutation of the DOM tree in effect invalidates the rest of the tree in terms of managing
namespace scoping. This would not be a problem if the DOM did all of this internally and as
in the case with Oracle's DOM namespace specific types that extend the Element and Attribute
interfaces (NSElement and NSAttribute). Each node manages its "namespace" internally. If the
tree is mutated, then the necessary internal changes to managing prefixes, namespaces, etc.
However, if you rely on the standard DOM, you never know what the scoping rules are (since
they can always change if the tree is mutated only slightly). This forces you to interate the
entire source tree to build up the necessary Node -> namespace mappings or else lazily
evaluate namespaces for each node being processed or evaluated in a select or match pattern.
LotusXSL does this and it is horribly inefficient. XT on the other hand does not use the DOM
at all so all of the namespaces are resolved as the source tree is being built.
There are lots of other issues, but basically you are left with either using the DOM which is
the only standard object model and have performance issues to handle namespaces, or else you
don't support any standard object model at all and make everyone use your proprietary source
If you get rid of namespaces as they are currently defined in XSL, you can have your cake and
eat it too.
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)