Re: Level 3: Element.setIdAttribute*()

On Mon, 2002-11-04 at 14:32, Fred L. Drake, Jr. wrote:
>  >  The ID-ness is an association between the attr node and the element
>  > node. If the attr node is removed, it will loose its ID-ness. If
>  > re-attached to the document element, it may get back its ID-ness if the
>  > implementation is "schema-awared" or if you use normalizeDocument.
>  > Consequently, renaming a Node will not affect isId() as currently
>  > defined.
> Ok, I kind of like that renaming a node doesn't destroy it's ID-ness.
> Should ID-ness created by setIdAttribute*() be maintained across
> adoption, cloning, and importing?

A general approach could be: if the  Attr node does not have an
ownerElement, then isId() returns false.

> Ok, here's another detail implementors need to know:  If I have an
> attribute on an element that gets ID-ness because of a
> setIdAttribute() call (and the schema doesn't cause it to be an ID),
> and then call setAttribute() on the element to change the value of
> that node, should it remain an ID or not?

I can't think of a reason why changing the value of the attribute should
remove its ID-ness so I'd say that it remain an ID.

>  > > A simpler question, also related to IDs:  Is there any expectation
>  > > that an attribute or method will be added that allows an application
>  > > to get the ID of an element without having to loop over the attribute
>  > > nodes and check the isId attribute?
> Sounds good.  I guess it would need to return an array of DOMString
> instances, since multiple ID attributes are being supported.  I'd
> suggest that this be a non-live thing; that seems to be one of the
> most controversial aspects of the getElementsByTagName*() methods.
> The value of live-ness here is even lower.

After reading this, I'm more inclined to think that maybe we should not
add this functionality... ;-)


Received on Monday, 4 November 2002 15:31:28 UTC