Re: TreeWalker.whatToShow

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.

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.

That's a legitimate, and not infrequently cited, use case for filtered
views of the document. If you don't have an interest in that particular
filtered view, fine; there are others which want the same behavior.

Obviously, the use cases we considered treated whatToShow as a
skip/don't-skip pre-filter, since that's the behavior we created. If folks
have strong cases for reject/don't-reject as an alternative/additional
mechanism, I think that's worth further study. But given that all the
desired behaviors can be achieved with the current design, I'm still
inclined to defer the cost/benefit analysis of that enhancement to DOM
Level 3. I _think_ the cost could be kept fairly low, but I really want a
bit more time to think about the implications.

______________________________________
Joe Kesselman  / IBM Research

Received on Monday, 28 February 2000 13:02:07 UTC