Live nodelists: That's the example always cited. I think everyone
understands that there were honest diffrences of opinion on this design.
Committees compromise; that's the nature of the beast. Since it's now in
the REC, it's rather late to revisit it. Put whatever caveats you feel are
required into your implementation's Javadoc, and let it go. If experience
really does establish that it's more trouble than it's worth, it can always
be deprecated in some future version of the DOM, after alternatives (such
as iterators) are in place.
Re EntityReference: I don't see that as being aimed at a specific audience.
I think it was simply intended to simplify the conceptual document model by
allowing a simple tree-walk -- and in particular, an iterative tree-walk,
which requires that the parent links mirror the child links -- to fully
explore the document's contents, without special-casing for
EntityReference.
My own preference _would_ have been to special-case that, since I am
thinking in terms of editors which may want to alter an Entity and have
that change immediately reflected into the document, and in terms of
embedded contexts where replicating the child nodes burns more storage than
the "reference is only a reference" solution would.
But I'm not completely convinced that my preferred version would have been
sufficiently better for a sufficiently large percentage of the user
population... and that should be the test when writing a standard. So I'm
willing to simply say "it's not what I would have implemented, but it works
adequately well" and let this one go as well.
>I have little confidence
De gustibus non disputandum est, and that applies to confidence too. We'll
find out whether pessimism is justified or not when the WG shows us what
the next version may look like. Can we table it until then? It's more fun
to argue about a design when there's a concrete proposal to throw darts
at... and more useful, I think.
Alternatively, if you want to do something useful: Draw up a "use case" or
three that demonstrates what you want to use iterators for, and provide
that as input to the WG. That might help them ensure that whatever they
come up with will in fact meet your needs... or at worst that they've given
your concerns serious consideration and have Good Reasons for any
divergence from them. (Don't overdo the design details; the goal is to
drive functionality and performace, and the specifics of how that function
is expressed are going to have to be made to mesh with all the other use
cases.)
______________________________________
Joe Kesselman / IBM Research
Unless stated otherwise, all opinions are solely those of the author.