Check with the DOM WG to be sure, but I don't _think_ this is broken.
Copying/cloning/importing attribute nodes in the DOM may lose ID-ness,
since the attribute may not be an ID in the new location. Some DOMs may be
able to check and reassert this, if they have the DTD/schema information
available to them. In DOM Level 3, I think you'll be able to revalidate the
document to re-establish this binding.
As it says in the definition of getElementByID, "Note: The DOM
implementation must have information that says which attributes are of type
ID. [...] Implementations that do not know whether attributes are of type
ID or not are expected to return null. " After moving things around, the
DOM may no longer be sure whether the attribute is an ID, since that
depends on the context in which the attribute appears and the DTD/schema
which that document is validated under Some DOMs may be able to check and
reassert this; some may not. In DOM Level 3, I think you'll be able to
revalidate the document to re-establish this binding.
As to whether IDness _should_ persist once established... I'm not
convinced. If you don't have a schema, all you really know is that you
don't know. A bogus true could be as misleading as a bogus false. And
consider the case where your doc recombination has created two elements
with the same ID -- validation would complain about that, but it isn't
clear you want to get into doing that check every time you alter the
document. "The shortest distance between two valid docs is often through an
invalid doc."
______________________________________
Joe Kesselman, IBM Next-Generation Web Technologies: XML, XSL and more.
"The world changed profoundly and unpredictably the day Tim Berners Lee
got bitten by a radioactive spider." -- Rafe Culpin, in r.m.filk
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
