Re: Level 3: Element.setIdAttribute*()

Philippe Le Hegaret writes:
 > attr and me will both be considered as ID. The notion of ID is in fact
 > not restricted to XML 1.0. This also permits a schema language to allow
 > aliases for ID.

Excellent!  This part of the DTD specification is one I've long had a
problem with, since it seems an arbitrary limitation.

 >  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?

 > > If the attribute node is replaced with another of the same name, does
 > > the new attribute node become an ID, is the original ID restored, or
 > > does the element end up with no ID?
 > 
 > It will loose its ID-ness (again, unless the implementation knows more
 > about the schema).

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 hope these questions make sense!
 > 
 > They do and the draft needs clarification. We spent lots of time last
 > week discussing setIdAttribute()/isId()...

I'm sure it was interesting!  ;-)

 > > 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?
 > 
 > No, but we will certainly consider this functionality.

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.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Zope Corporation

Received on Monday, 4 November 2002 14:33:05 UTC