- From: Claude Zervas <czervas@Adobe.COM>
- Date: Tue, 18 Aug 1998 13:39:04 -0700
- To: www-dom@w3.org
At 10:06 AM 8/18/98 -0600, you wrote: >Claude Zervas wrote: > >> Hmmm, according to the latest spec Node.next/previousSibling are read-only. >> How do you set these without casting to an implementation that has >> set methods for these attributes if there are none in the interface ? >> >> I think maybe you thought there was Node.setNext/PreviousSibling() >> methods defined somewhere. This, as I understand, was a typo in the old spec. >> If not, then the latest spec isn't quite fully cooked. > >No. I was arguing that the primary target of an OO operation does not need to >be upcasting, but I didn't read carefully that the example you gave was an >argument to a method, not the primary object of the operation, which does indeed >require upcasting. > >...>My own implementation does not store previous/nest sibling pointers at all, and >cannot represent the invalid states that could be created if the user were free >to set these in inconsistent ways, nor could I produce as efficient an >implementation if the user were free to do this. My implementation uses a child >alias's knowledge of its position in the parent's child list to return the >previous or next sibling when it is requested. > >The fully-linked direct representation of the DOM previous/next pointers is not >powerful enough for my server or client uses. Ok, I agree. Personally I think the next/previousSibling attributes should be deprecated or optional since they aren't very useful. My own implementation uses the same method as yours to determine these attributes... And, its true, casting isn't all that expensive, I was just getting a little shrill. My whole argument stems from a desire to not have to depend on the implementation. I'm still convinced that it should be possible to mix implementations. It should be possible to accept a foreign node and insert it into a local tree without making any assumptions besides the public interfaces. Say you have a document whose nodes are distributed over several physical locations and one of these locations decides to upgrade its software. To maintain a consistent state all of the locations would have to do the same. To avoid this kind of thing now you'd have to clone node trees fairly often to maintain consistency. Cloning a remote tree also presents problems when the original tree is modified. The copy would have to be notified of these changes and update itself accordingly. >As I stated before, if your alternative suggestion is to eliminate every freedom >of the implementation underneath by dictating every detail, and exposing every >primative so that the user is free to create inconsistent states that do not map >well onto powerful engines, then I oppose that strongly, whatever the setting >the DOM is intended for. No, this is not my intention. There are currently very few places where you need to make assumptions about the implementation. I think the only thing that is required is to make the Node.parent attribute writable. Granted, it would place some restrictions on the implementation but none that would be too onerous. Perhaps it would be possible to query a node to find out if it supports a heterogenous implementation environment and, if not, then clone it... I really don't want to start a firestorm here, I just would like to put the idea of mixing implementations on the table. I feel it is an important issue if documents are eventually a truly shared resource and not just copied around networks. I'm not just trying to save network bandwidth, since iterating over a remote node tree is probably as expensive as cloning it. - Claude Zervas
Received on Tuesday, 18 August 1998 16:38:58 UTC