Re: TreeWalker.whatToShow

keshlam@us.ibm.com wrote:
> 
> Quoth David Brownell <david-b@pacbell.net>:
> >
> > Let's see ... why else would a node be readonly, except that our
> > current node has an EntityReference ancestor?
> >
> > Not at all hidable -- you always know when they're around.
> 
> You're taking me overly literally. Obviously a TreeWalker won't turn
> read-only nodes read-write; filtering can't suppress that distinction
> entirely, and isn't intended to.

The reason I pointed out that issue:  When I've previously commented
on various problems with EntityReference nodes, one response I'd get
back is "use a filter" ... giving me to understand that supressing
that distinction really _was_ one of the goals.  Of course, it can not
achieve such a goal.


> However, if it's set to skip EntityReference nodes (either in whatToShow or
> in user-defined filtering), the _read_ appearance of the tree is equivalent
> to that of having the Entity Reference expanded in-line. In some cases
> that's a better answer than processor-time expansion of Entity References,
> which the DOM also supports.

DOM doesn't have any APIs for XML processing, so I don't think it's at
all accurate to say it "supports" such behaviors.  At best it doesn't
get in the way of certain implementation-specific behaviors.  And I
consider implementation-specific behaviors a problem when they come
up in such a visible circumstance.

- Dave

Received on Monday, 28 February 2000 15:24:51 UTC