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

At 05:38 PM 8/18/98 -0400, keshlam@us.ibm.com wrote:
>Re deprecating the next/previous sibling attributes: I would actually
>expect my user set to use them more than the item() accessor. I grant that
>this may just reflect my own programming practices, but I'd still be Real
>Unhappy to see them go away. "Aren't very useful" depends on how the
>application wants to handle the document. (And "aren't very efficient",
>which is my problem with item() and getSize(), probably depends on how the
>implementation is storing the document.)

I guess either next/previousSibling or NodelList.item() can be efficient
but usually not both. The best way to solve this would be to introduce
iterators. I am advocating the deprecation of next/previousSibling
only if they are replaced with iterators (and only for the "server-DOM").

>In fact, these accessors seem to be the one place where mixing
>implementations gets into the worst trouble, since it's a place where
>non-DOM-specified optimizations (such as "has this changed since I last
>looked at it" flags for the "live" behavior) may not know how to talk with
>each other. Maybe the answer there is for Level 2 to actually define those
>support channels, if this can be done in a sufficiently general way that it
>isn't bound to specific implementations, so mixing node types doesn't break
>that connection. But that may not belong in the base DOM; it's more code
>and I'm sure some folks are going to want to put DOM-based code into
>palmtops and smaller, where 10KB still makes a real difference.

Your right, and thats why it would be nice to perhaps split the
DOM into two or more "packages". One for small client-side scripting
applications and one more in tune with distributed server-side
applications where resources such as storage are a little cheaper.

>... If all the distributed
>fragments independently honor the DOM API, this looks to be basically the
>same question as mixed implementations -- a mechanism is needed to allow
>crossing DOM boundaries -- plus the issue of dealing with a node which may
>be in more than one document and hence doesn't have a "parent" except in
>the context of a particular set of operations. (Which may be a point in
>favor of making the accessors be a separate interface, which could maintain
>this higher-level connectivity information.)

It should be possible to mix implementations and still restrict nodes
to having just one parent. But it would be nice to have the option
of sharing nodes among several parent trees. Perhaps there could be
orphan nodes that do not belong to a particular document and have
no explicit parents. Something akin to a DocumentFragment but without
the flattening semantics when added to a new parent.

It seems like quite a few people are totally against the idea
of mixing implementations. I'm not quite sure why since it seems
pretty useful. Especially for highly dynamic documents whose structure
is maintained by more than one generator.
It would be nice to have a public API that supports this since
sharing implementations sort of depends on it.

Perhaps a seperate "heterogenous-mixing-server-DOM" spec could be defined? ;)

- Claude Zervas

Received on Tuesday, 18 August 1998 18:19:39 UTC