Re: A few questions

On Tue, 19 May 1998, Mike Champion wrote:

> >This is what I thought also until I realized that it could cause problems if
> >an Attribute is shared among multiple element (this could happen if the
> >attribute is FIXED or is inherited as DEFAULT value).
> 
> That's a really good point; I'm pretty sure that one SHOULD have separate
> attribute objects in this scenario, but we should clarify it ...

        What happens if I create an Attribute and call 
Element.setAttributeNode(Attribute newAttr); with it, on multiple 
Elements?  Does it throw an exception?
	I think that you have to be carefull not to try and do to much.
Leave the intelligence to the user.  I think the DOM elements should be as
dumb and simple as possible for version 1.  Let users set Attribute/Node
parents manually.  I think these same arguments go for the whole
NodeIterator thing, it just seems to get so messy after a while when you
start to add intelligence.  I think navigating the tree should be left to
the user.  Attributes and Children should be normal simple two way linked
lists, with the head of the list being the Node itself, and if you insert
or delete something, it's your job to synchronize the state of your
application, this should be outside the scope of DOM.  Everyone
understands the behavior of a two way linked list, why can't DOM be that
simple?  getParent finds the head of the list, setAttribute replaces or
appends, etc.  Forget NodeIterators, just have 
Element.getFirstAttribute/Child(), and
Attribute/Node.getNextAttribute/Child(). I guess I just don't see the
problems with this.
	As a user, I prefer clean and simple, with less functionality,
over convoluted and complex with more functionality.  But then again, one 
could argue, what do I know?  Just nailing down the objects involved
seems like enough of an accomplishment to me, without all these other
issues.  Just my three cents.

---
Chris Hubick
mailto:chris@hubick.com
http://www.hubick.com/

Received on Wednesday, 20 May 1998 04:02:55 UTC