Re: Efficient read-only cloning?

Steve Savitzky wrote:
>as far as I can tell, nothing in the specification says that the
>parent of these ``virtual children'' has to be the EntityReference node.

I tried very hard to interpret the spec that way, but I think I did find
words that kept me from being able to do so. I should recheck that. For
interoperability's sake, the DOM spec should probably either say that
they're real children or explicitly say they aren't required to be so.

>As far as I can tell the only other alternative is to
>(perhaps lazily) copy the children.

That's my current solution. As I said in the other note, if you want to
allow editing the DocumentType you also have to track that and refresh the
EntityReference at appropriate times. (Definition of "appropriate" is open
to debate, admittedly.)

>I note in passing that Node does not appear to have a ``readonly''
>attribute

I get the impression that readonly was something of a last-minute
addition... Note that there's not only no getter method, there's no setter
either. I've addressed that by having EntityReference set the readonly flag
when it builds its kids, just to avoid adding yet another non-DOM public
method.

>In my opinion, having Node.getParentNode in the spec is a serious mistake,
>since it rules out implementations that share structure.  But nobody asked
>me.  Maybe it can be made optional in Level 2.

This is supposedly why Attributes no longer have parents. Of course, as
discussed in the past, INUSE_ATTRIBUTE_ERR makes taking advantage of that
difficult.

It _is_ convenient to be able to ask a node for its parent. As one example,
it allows the user to walk the tree without maintaining a parent stack
(either manually or via recursion). And most nodes really don't need shared
parentage; one can argue that anything which is being shared should
probably have been an Entity to begin with.

If I Were King, rather than removing Node.getParentNode, I'd redefine
EntityReference so it is _only_ a reference and ask applications to
understand that they need to look at the Entity if they want to know what
it contains.

As far as optional features go: Please don't. Much as I'd like to see some
things in Level 1 redone (the deep version of NodeList in particular), I
think it's as important -- or more important -- to have Level 2 be a direct
superset of Level 1's funcationality. The right answer if there's a problem
in Level 1 is to fix Level 1's spec... but as I understand the process, at
this point only harmless changes or complete showstoppers are being
accepted, and this falls somewhere in the middle.

______________________________________
Joe Kesselman  / IBM Research
Unless stated otherwise, all opinions are solely those of the author.

Received on Wednesday, 23 September 1998 13:41:42 UTC