W3C home > Mailing lists > Public > public-html@w3.org > August 2007

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

From: Robert Burns <rob@robburns.com>
Date: Thu, 2 Aug 2007 00:33:43 -0500
Message-Id: <2C8BE07D-E265-440A-9099-242850A3E6DA@robburns.com>
Cc: HTML WG <public-html@w3.org>
To: Henri Sivonen <hsivonen@iki.fi>

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,

[1]: <http://www.w3.org/TR/xml/#one-id-per-el)>
Received on Thursday, 2 August 2007 05:34:10 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:25 UTC