RE: [xml-dev] Re: determining ID-ness in XML

[Elliotte Rusty Harold <elharo@metalab.unc.edu>]

At 8:22 AM -0500 10/31/01, Champion, Mike wrote:
>> 
>>  xml:id and/or xml:idatts 
>> can be layered on top of XML 1.0 without changing anything 
>> about XML 1.0. 
>
>What does "without changing anything about XML 1.0" mean, exactly? 

Simply this: all existing tools continue to work on documents that contain xml:id attributes without any changes. They continue to do the same things they do with those documents they do today. 

>Could the
>xml+id processor be actually layered on top (or in front of) an  XML 1.0
>processor without changing the DTD validation logic?  

Absolutely. A valid document must declare xml:id, just like it has to declare xml:lang, xml:base, and xml:space. An invalid document doesn't have to declare these. 

>Does it mean that
>valid and  well-formed XML 1.0 documents will continue to be so in xml+ids?

Absolutely. 

>How about schema processors; will an "old" schema processor interoperate
>with an xml+ids XML processor? 
>

Certainly. It's the same story as with DTDs.  A schema-valid document must declare xml:id, just like it has to declare xml:lang, xml:base, and xml:space. An invalid document doesn't have to declare these. 

>One question (brought up by Michael Kay in an internal discussion): "is
>xml+id"  non-uniqueness a well-formedness error, or will it be some sort of
>low-level validation error? Presumably a well-formedness error, since
>non-validating parsers have no notion of "validation". 

This is the one tricky part. It is neither a well-formedness error nor a validity error. It is violation of the xml:id specification, but is in no way a violation of XML 1.0, Namespaces in XML, or Schemas. Parsers would not, at least by default, report such a violation unless a DTD or schema declared that xml:id had type ID, in which case it becomes a normal XML 1.0 or schemas validity error. 

It would be an error equivalent to xml:base="^^^^" or anything else that is not a legal URI. That is, it is not an XML 1.0 error. The XML parser will generally not flag this. A client application that was aware of the extra semantics attached to xml:id would catch the problem, much like an XLink processor would catch a problem with the above xml:base attribute but a normal XML parser would not. 

>BUT if there is a
>schema-defined ID and a XML+id-defined ID that clash, it is presumaby a
>validity error, because schemas only apply to well-formed XML documents ...
>andy anyway this implies that the schema processor knows about xml+id.  
>

Also tricky. I propose that xml:id defines its own ID space which is unique among other xml:id attributes but not necessarily among all ID type attributes. XPointers and other xml:id aware specs would define a rule for which type of ID wins in the event of a conflict. 

>These potential complications seem to suggest that doing any more than the
>bare minimum could start to get hairy. I'm inclined against adding ISO
>entities, multiple ids/element, namespace support, etc. in the first
>iteration.
>

I don't know. I agree that entities really aren't relevant here or a good idea because that would break XML 1.0. However, it seems that everything I've said here about xml:id works equally well for xml:idatts. 
-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+ 
|          The XML Bible, 2nd Edition (Hungry Minds, 2001)           |
|              http://www.ibiblio.org/xml/books/bible2/              |
|   http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      | 
|  Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/     |
+----------------------------------+---------------------------------+