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

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.

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

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

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

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

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

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

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

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Thursday, 2 August 2007 07:22:26 UTC