Re: ID Characters (was: Re: 3.4. Global attributes)

On Aug 2, 2007, at 12:00 AM, Henri Sivonen wrote:

>
> On Aug 1, 2007, at 18:54, Robert Burns wrote:
>
>> On Aug 1, 2007, at 10:34 AM, Henri Sivonen wrote:
>>> I said that it is not of type ID as far as the XML Processor  
>>> (that is, the XML parser as defined by the XML 1.0 spec) is  
>>> concerned when there is no DTD declaring the attribute id to be  
>>> of type ID. Between the XML parser and later stages of  
>>> processing, you do want to assign IDness to id. I propose  
>>> acknowledging this explicitly in the spec and calling the  
>>> processing stage an "XHTML id Processor". This is analogous to  
>>> how xml:id gains its IDness after the XML Processor in the  
>>> DTDless case.
>>>
>>> (What I said above holds regardless of what lexical space is  
>>> allowed for the id attribute.)
>>
>> I think you're raising a completely different issue from what I'm  
>> trying to address.
>
> I said why id isn't subject to the constraints XML 1.0 places on  
> IDs *even if* it gains IDness between the XML parser and further  
> processing. This is pertinent to whether "XML compatibility" is a  
> real problem.

I really don't understand what you're saying. However, on Aug 1,  
2007, at 1:01 PM, Thomas Broyer wrote:

>
> 2007/8/1, Robert Burns:
>>
>> On Aug 1, 2007, at 10:57 AM, Thomas Broyer wrote:
>>>
>>> I think it's about documents with multiple namespaces, where  
>>> XHTML5 is
>>> an "embedded language" (e.g. an Atom feed). In this case, you'd like
>>> to be able to assemble XHTML fragments from different sources and
>>> don't have their @id's conflict.
>>> I think "subtree" here means "subtree rooted at the 'root element'",
>>> not "subtree rooted at the element bearing the id attribute".
>>> ...just my own understanding, because I couldn't think of any other
>>> meaning for this sentence.
>>
>> Given that and what you say in the next two blocks, are you then
>> saying that we make no assumptions that an @id is of type ID?
>
> Yes. @id is NOT of type ID.

Which says to me that @id will never gain IDness. If it did gain  
IDness at any time then I think we have XML 1.0 compatibility  
problems. Unless, you're saying at some point — "between the XML  
parser and further processing" —  the document will cease to be an  
XML 1.0 document, then we have a compatibility problem. As I said  
before a value of type ID in an XML document: "must match the Name  
production; …  must not appear more than once in an XML document as a  
value of this type;… and must uniquely identify the elements which  
bear them [throughout the XML 1.0 document]"[1].

Since I'm not understanding what you're saying, perhaps you could  
draw on the XML 1.- document to show me how something that happens  
between the XML parser and further processing negates these norms.

Take care,
Rob

[1]: <http://www.w3.org/TR/xml/#one-id-per-el)>

Received on Thursday, 2 August 2007 05:34:10 UTC