Re: Is appendChild/insertBefore() supposed to raise exceptions for attributes?

> In some implementations I am aware of, for example, a single
> representation of common nodes are shared between parents/owners,

Isn't this a whole different graph? Is this a case where something like
Object declare is working?
Are there other standardized cases in the DOM where a child may have
mulitple parents?

Thank You and Best Regards,
Joe

----- Original Message ----- 
From: "Ray Whitmer" <ray@xmission.com>
To: "Frans Englich" <frans.englich@telia.com>
Cc: <www-dom@w3.org>
Sent: Friday, December 22, 2006 5:01 AM
Subject: Re: Is appendChild/insertBefore() supposed to raise exceptions for 
attributes?


>
> On Fri, 22 Dec 2006, Frans Englich wrote:
>
>> On Friday 22 December 2006 12:37, you wrote:
>>> Hi everyone,
>>>
>>> Me and my co-developer were discussing how attributes are to be treated
>>> within DOM.
>>>
>>> For interface Attr, this paragraph can be found:
>>>
>>> "Attr objects inherit the Node interface, but since they are not 
>>> actually
>>> child nodes of the element they describe, the DOM does not consider them
>>> part of the document tree. Thus, the Node attributes parentNode,
>>> previousSibling, and nextSibling have a null value for Attr objects. "
>>
>> Also, how should one set ownerElement of the Attr when calling
>> setAttributeNode? Should setAttributeNode do it? The spec doesn't say 
>> that,
>> as far as I can tell.
>
> ownerElement works for attributes just like parentNode works for children.
> An attribute is not a child, so it never has a non-null parentNode. 
> Instead
> ownerElement is set to indicate the element it has been set on.
>
> "ownerElement of type Element, readonly, introduced in DOM Level 2
> The Element node this attribute is attached to or null if this attribute 
> is not in use."
>
> That is pretty clear to me.  The specification also does not say that an 
> implementer
> has to set parentNode when you call insertBefore, but it seems to make 
> sense to
> do so since it now has a parent.  I am not telling you to call 
> insertBefore on
> an attribute node but only making a comparison.  If you can figure out a 
> way
> to have the ownerElement correct all the time without setting it in this 
> case,
> go for it.  In some implementations I am aware of, for example, a single
> representation of common nodes are shared between parents/owners, meaning 
> that a
> scaffolding tracking the parent ancestry is built as you navigate to a 
> location
> so a child never has a pointer to its parent and an attribute never has a
> pointer to its owner element internally.  It is the implementation, so you
> are free to do whatever you like as long as the results are right, i.e. 
> the
> ownerElement provides the correct information at a particular time if the
> attribute in question is on the element in question.
>
> Ray
>

Received on Saturday, 24 February 2007 18:03:53 UTC