W3C home > Mailing lists > Public > www-dom@w3.org > July to September 1998

Re: Anybody for a server-DOM spec -> transferring nodes and listener model.

From: Claude Zervas <czervas@Adobe.COM>
Date: Tue, 18 Aug 1998 13:39:04 -0700
Message-Id: <3.0.5.32.19980818133904.0142cdb0@seattle>
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 GMT

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