Re: The DOM is not a model, it is a library!

On 11 Oct 1999, Stephen R. Savitzky wrote:

>Actually, in some cases you might _want_ to be able to change the default
>value.  Changing the value associated with a single element would be done
>only via setAttribute or setAttributeNode, which would always create a local
>Attr attached to the Element. 
>
>In Level 2 there's no way to change the default value which, as I said,
>could be useful in some cases.

But PLEASE not by getting an attribute from the element and mutating it.
That would be a disasterous model, would break level 1, and so on.

>I don't think so -- unless otherwise noted it would be assumed that, for
>example, previousSibling on the returned node would work.  Lazy loading
>doesn't do you any good if you want to stream through a huge document and
>throw away the nodes you're no longer interested in.  Admittedly, my
>requirements are slightly bizarre. 

You just have to make your code bi-directional, so that it can stream in 
either direction.  That makes the forward direction not significantly less 
efficient -- the forward direction can be the optimized one.  Every lazy-
loading application I can think of requires the ability to go backwards.  
There are lots of solutions that would allow it to work efficiently.

>> I don't see the need to make the thing unidirectional -- I think that most
>> constraints can be addressed in other ways.  I fully plan on having a lazy-
>> loading DOM that works well for palm pilots.  This is easy with the current
>> API.  And it doesn't rely on TreeWalker.  I'd be happy to discuss a variety 
>> of techniques...
>
>Again, this only works if you keep the whole tree around _somewhere_.  In
>my case I want to be able to guarantee that I never have to keep it at all;
>documents just stream through. 

XML is largely symmetrical, and it is not hard to make most things work
bidirectionally, but if you want a model that only ever goes forward, it 
should have been immediately apparent that DOM was the wrong API for you.  
I written lots of lazily-loaded / lazily-saved / lazily thrown-out-of-memory 
apps, but never one that would work under those constraints.  I think the 
implementation is undully constraining the application in this case, or you 
are writing a single-application DOM.

>Correct me if I'm wrong, but I thought that the implicit use case has always
>been that an application is handed a document, grovels over it for a while,
>and exits (or gets handed another document); I don't think the DOM was ever
>intended as a model for persistent storage or even for multi-threaded
>applications.  Which is not to say that persistent tree storage with
>persistent metadata wouldn't be good to have.

That is a very simple use case that should be handled.  But often there
are other sets of functionality, views, or libraries coming in to play that 
need to operate without collision.

>Nice.  So leaf nodes are shared, and only the Element nodes are actually
>linked into the tree?  Or do you share Element nodes as well?  In either
>case I can see why == doesn't work in your system. 

Actually, all nodes are shared.  My core data model has no parent or sibling
pointers.  Only parents know the children and their order.  If someone is
traversing the hierarchy and needs a full-fledged node, then I create a chain
of unshared objects that keep the state so that parents and siblings can be
efficiently computed and so that if mods are made the shared node is not
mutated, but rather a new one is substituted, which can later be garbage
collected and the mutations eventually reflected in shared data again.

I have a half-strength proprietary DOM interface I can use that omits all
the methods that make DOM objects unsharable such as getParentNode, 
getNextSibling, setNodeValue, insertNode, removeNode, etc. which I use for
code that doesn't have to work on other DOMs which works extremely fast
awnd efficiently without creating the unshared proxies.

It makes cloning and hierarchy difference comparisons very easy, and that is
extremely important to me using DOM for server-side purposes.

Just to really confuse you, I'll tell you that "==" does work in _my_
implementation currently.  But I think I may rewrite a version where it does 
not that doesn't have to do as much work.

I hope after mulling these things over, some of your obstacles look smaller.
But with some of the constraints you are putting on the system, I find it
quite likely that you want something besides DOM.  But don't be suprised
when full DOMs come out that lazily load/save/discard on Palm and still
efficiently support the full DOM function set.

Also, you said that the tree has to be loaded SOMEWHERE.  While IMO it 
doesn't have to be, it makes even better lazy loading models possible.
Have the server do the hard work and let the Palm version use CORBA to have 
much better lazy loading because you can access an encyclopedia-sized
document and random access to the pieces you want to visit and change and
save, without much waiting on a slow modem.  You only have to load the objects
of the screen you are currently viewing.  I know there are problems to solve,
but they are solvable (I solved them without too much work), and the end 
result is great.

Best regards,

Ray Whitmer
ray@imall.com

Received on Monday, 11 October 1999 14:42:58 UTC