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

On Aug 2, 2007, at 2:21 AM, Henri Sivonen wrote:

>
> On Aug 2, 2007, at 08:33, Robert Burns wrote:
>
>> 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.
>
> I'm saying that an XML processor as defined by XML 1.0 does what it  
> is defined to do. It reports data to the application. The data  
> reported to the application says that the attribute id is of type  
> CDATA. XHTML5 doesn't change that.
>
> However, the application may put in a filter that changes things so  
> that to further parts of the application the type of id is reported  
> as ID. This is what an xml:id Processor does for the xml:id  
> attribute. This is also implementable. (I have implemented an  
> "XHTML id Processor" for SAX. It works.)
>
> Changing the type of the attribute id to ID *after* the XML  
> processor stage is desirable in order to be able to define #  
> selectors, the XPath id() function, document.getElementById() and  
> the HTML attributes that have IDREF-like semantics in terms of IDness.

I think you're reading these recommendations in a way too  
compartmentalized fashion. An xml:id processing application is still  
and xml processing application. It doesn't start out as an xml  
processing application then die and become reborn as an xml:id  
processing application. It starts as xml and become xml and xml:id.  
The norms build upon the previous norms:

xml -> xml namespace -> xml:id -> HTML5.

We can make our @id attribute a XSD:string data type (or whatever).  
But if we make it data type ID and it doesn't conform to the XML  
requirements for ID then HTML5 is a non-conforming application of  
XML. Whether this has any practical consequences is another story. I  
don't know. But it certainly breaks the norms of XML.

>
>> However, on Aug 1, 2007, at 1:01 PM, Thomas Broyer wrote:
>>
>>> Yes. @id is NOT of type ID.
>>
>> Which says to me that @id will never gain IDness.
>
> It is a statement of fact when it is scoped to what happens *in the  
> XML processor*. This WG mustn't change the definition of what an  
> XML processor does. However, this WG can define a processing stage  
> that makes id gain IDness after the XML processor if this WG so  
> chooses. The xml:id spec is precedent.

Again, whatever processing state this workgroup defines it's still a  
processing state occuring within an XML processor when the @id value  
achieves IDness.

>
>> If it did gain IDness at any time then I think we have XML 1.0  
>> compatibility problems.
>
> Does the XSD spec create XML 1.0 compatibility problems by defining  
> the PSVI, in your opinion? (I'm not suggesting that the PSVI is  
> good or nice. I'm merely suggesting that it is layered on top of  
> XML 1.0 and is not "incompatible" with XML 1.0.)

I'm not familiar with that.

>
> Does the xml:id spec create XML 1.0 compatibility problems, in your  
> opinion?

No, I don't think so. I don't see anything in the xml:id spec that  
doesn't conform to the requirements of XML for ID.

>> 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.
>
> The XML 1.0 spec doesn't define further processing it is entirely  
> up to the application. That's the crux of the matter why XHTML5  
> doesn't need to inherit arbitrary restrictions from XML 1.0 when  
> those restrictions don't concern the XML processor.

If XHTML5 intends to be an XML application (that is processed by XML  
processors) then it does need to conform to the XML 1.0 norms. It  
needs to in the sense that if it doesn't then XHTML5 is a non- 
conforming XML application (with whatever consequences that brings,  
if any). We can also change the code point assignments of Unicode in  
a later processing stage, but still claim to be a Unicode  
application. We will then be a non-conforming Unicode application  
(with some pretty serious consequences; i.e., our glyphs will not  
match the characters as expected by authors).

> I reiterate my drawing on the xml:id spec instead:
> "The xml:id processor performs ID type assignment on all xml:id  
> attributes, even those that do not satisfy the constraints."
> http://www.w3.org/TR/xml-id/#processing

 From the part you cite: "An xml:id error occurs for any xml:id  
attribute that does not satisfy the constraints" and later regarding  
errors: "A violation of the constraints in this specification results  
in an xml:id error. Such errors are not fatal, but should be reported  
by the xml:id processor. In the interest of interoperability, it is  
strongly recommended that xml:id errors not be silently ignored."

> No doom or gloom occurs when ID type assignment is done on an  
> attribute whose value isn't an NCName.

Perhaps not, but that recommendation doesn't go out of its way to  
encourage authors to produce non-NCName IDs.

> As for precedent for changing the lexical space (and the value  
> space) of IDs, I point to XSD that makes the lexical space of  
> xsd:ID different from XML 1.0 DTD ID (albeit in the opposite  
> direction than XHTML5).

Do you mean stricter rather than looser? Then that's not a precedent.  
Of course an XML conforming application can make anything stricter  
without violating the XML 1.0 norms. It's making it looser that  
violates the XML recommendation.

The conversation is getting way too academic here. To try to bring it  
back down to Earth, I don't really think we'll be doing authors a  
favor by giving them a few more characters to use in their ID values.  
These are opaque values anyway, as the draft already says. Authors  
already have tens of thousands of characters available (nearly  
100,000 if we permit XML 1.1). Do they really need a few more?

Take care,
Rob

Received on Thursday, 2 August 2007 07:51:46 UTC