Lists Home |
Date Index |
- From: David Brownell <firstname.lastname@example.org>
- To: Lauren Wood <email@example.com>
- Date: Thu, 11 Nov 1999 01:44:03 -0800
Lauren Wood wrote:
> On 10 Nov 99, at 14:48, David Brownell wrote:
> > Having just been suffering through a DOM implementation
> > that actually exposes EntityReference nodes, with no way
> > to turn them off and no utilities to get rid of them,
> > I'd quite gladly abolish them from DOM ... ;-)
> Well, you can always implement TreeWalker (part of the Level 2
> Traversal module), which has as its first use case how to navigate
> the tree without seeing entity reference nodes. Not that I disagree
> that tripping over them can be a pain, but there is now a DOM way
> of not doing so.
I was thinking of that as I wrote, in fact. But the TreeWalker
is still a "look but don't touch" model ... the children of
an entity ref are still going to be readonly, even if the walker
masks the EntityReference from your sight. Solutions addressing
the "I need to touch it!" aspect can't use just TreeWalker.
Perhaps the general issue is that whenever DOM starts to offer
APIs for populating a DOM Document, there need to be options
about what features should be exposed. For my usage, things
like EntityReference and CDATASection (vs normal Text) would
hardly ever be used.
Or perhaps there should be variants of Element.normalize() that
give you other options for getting rid of extra tree nodes.
"No adjacent text nodes" is covered. How about flags for cases
like "don't use EntityReference", "don't use CDATASection",
and "don't use Comment"?
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)