W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2000

Re: TreeWalker.whatToShow

From: <keshlam@us.ibm.com>
Date: Sun, 27 Feb 2000 22:58:11 -0500
cc: www-dom@w3.org
Message-ID: <85256893.00551351.00@D51MTA03.pok.ibm.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:47 GMT