Joseph Kesselman wrote:

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."

Joseph,

I agree in principle with what you're saying, but in practice, if a
document is brought into an XML processor with a declaration of a
schema, and if *initially* that schema is provided, it seems to me
that the intention of both the author and the document "user" (at
that point) is for there to be a schema and that the document is
meant to go through whatever kinds of processing it does with that
schema attached, unless it is explicitly removed. The schema acts as
the very necessary guarantee that whatever processing occurs, the
output document still agrees with the schema. I.e., unless it has
been explicitly and deliberately removed or changed during the
processing.

So in this particular case, it isn't so much an issue as to whether
IDness should or should not persist -- it seems clear that is should
so long as the schema has not been explicitly removed -- but more
about what the heck happened to the schema. I mean, is it on holiday
in Jamaica or something? Where did it go? I think that's the problem
Elliote is up against. He seems to desire validation (or at least
ID constraints, which are a form of validation declared by a schema).

But I do agree that if one doesn't have a schema available, the
processor should make a big noise.

Murray

......................................................................
Murray Altheim                    http://kmi.open.ac.uk/people/murray/
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK               .

  The Rise of Pseudo Fascism -- David Neiwert
  Part 1: The Morphing of the Conservative Movement
    
http://dneiwert.blogspot.com/2004_09_19_dneiwert_archive.html#109028353137888956
  Part 2: The Architecture of Fascism
    
http://dneiwert.blogspot.com/2004_09_26_dneiwert_archive.html#109563628314780505
  Part 3: The Pseudo-Fascist Campaign
    
http://dneiwert.blogspot.com/2004_10_03_dneiwert_archive.html#109596147171278590
  Part 4: The Apocalyptic One-Party State
    
http://dneiwert.blogspot.com/2004_10_10_dneiwert_archive.html#109694976530359103
  Part 5: Warfare By Other Means
    
http://dneiwert.blogspot.com/2004_10_17_dneiwert_archive.html#109755467135245579

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to