RE: Attr nodes

In a previous message, you mentioned that you are implementing the DOM
specification.  The first question you have to ask yourself is why.  Is
there a specific reason that one of the existing implementations is not
appropriate or could not be customized to fit your application?  If not,
then the easiest path is to adopt one of the many existing implementations.

If there is a clear reason that you must do your own implementation, then
you can learn a lot by referencing the existing implementations.  Many are
open-source and you can benefit from the experience of the many users of
those implementations.  I'd download a couple to have as ready references
whenever you have an implementation issue.  When after looking at the
existing references and the recommendation and things still are unclear,
then ask here.

The DOM recommendation is totally about outward appearances, not
implementation details.  All it says is that setting .nodeValue, .value and
manipulating the childNodes should all appear to do the same thing.  However
nothing forces you to create a child node until someone asks for one.

If you are doing an implementation, you may benefit from the DOM test suite
work (http://www.w3.org/DOM/Test) or earlier work done with testing of C++
implementations at http://xmlconf.sourceforge.net


> -----Original Message-----
> From: Mark Hellegers [mailto:M.H.Hellegers@stud.tue.nl] 
> Sent: Thursday, February 14, 2002 2:06 PM
> To: www-dom@w3.org
> Subject: Re: Attr nodes
> 
> 
> > Don't confuse IDL attributes with implementation fields. An IDL 
> >attribute is just a value you can read or set. Where it's 
> stored is a 
> >completely separate issue, and is up to the implementation.
> >
> >The DOM API says that the Attr node's value is always equal to the 
> >concatenation of the values of its Text descendents, and 
> that when you 
> >set this node's value that's taken as a request to replace those 
> >descendents with a single Text node containing the new 
> value. I don't 
> >think we actually said whether it will be a new Text node, 
> or whether 
> >one of the existing Text children of the Attr (if any) will 
> be reused 
> >by having the new value assigned to it. I believe either is 
> acceptable.
> 
> I'm sorry, but I can't find where it is stated that the Attr 
> node's value is constructed that way. Now I read it again, I 
> can see that the value is not primarily the value of 
> nodeValue, but it is not made really clear what it is.
> 
> Thanks,
> 
> 	Mark Hellegers
>

Received on Thursday, 14 February 2002 16:41:10 UTC