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

HI Thomas,

I'm still trying to understand this.

On Aug 1, 2007, at 10:57 AM, Thomas Broyer wrote:

>
> 2007/8/1, Robert Burns:
>>
>> On the issue of the @id attribute and compatibility, I'm not sure
>> what we're trying to accomplish here. Henri says[1] that the
>> attribute is of type CDATA and not of type ID
>
> Yes, because only a DTD can tell an XML (validating) parser the
> attribute is of type ID. An XML Schema could eventually also tell a
> validator an attribute is of type xsd:ID (which share the same
> syntactic constraint as the DTD's ID attribute type; I don't think it
> shares its uniqueness constraint though).
>
>> The current draft[2][3] says:
>>
>> "The value must be unique in the subtree within which the element
>> finds itself and must contain at least one character."
>>
>> I'm not sure I understand what this means, but it sounds to me like
>> @id attributes need only be unique within a particular node (or
>> within a depth traversal of a node)? Again, I don't really understand
>> what the current draft means by that.
>
> 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? This  
may be similar to me getting my head around the no versioning idea,  
but I sense you're saying HTML5 has some kind of weak typing. Is that  
correct? That would explain why there's little mention of data types.  
So if the HTML5 @id attribute is not of type ID but rather simply a  
string, we can deploy whatever uniqueness rules we want (even in XML).

>
>>  From HTML4[4] the @id attribute has to be unique throughout an
>> entire document and the attribute takes a value of type ID[5].
>
> Actually, the value has to be unique throughout the entire document
> *because* the attribute is of type ID (which also restricts the
> attribute "value space").

Understood.

>
>> In XML the @id attribute must be unique in the document,
>
> In XML, an attribute named "id" has no specific type other than the
> one given by a DTD (or other schemas if don't stick to the XML spec).
>
>> there must only be one ID per element[6].
>
> Yes (though your pointer was incorrect: http://www.w3.org/TR/xml/ 
> #one-id-per-el)

Sorry.

>
>> The current draft also says[2][3]:
>>
>> "This specification doesn't preclude an element having multiple IDs,
>> if other mechanisms (e.g. DOM Core methods) can set an element's ID
>> in a way that doesn't conflict with the id attribute."
>>
>> Again, I don't really understand what this paragraph is saying. Is
>> this multiple attributes with different names all taking a value of
>> type ID? or is this one @id attribute with multiple whitespace or
>> comma delimited values? Or is this just multiple values of @id or
>> multiple type IDs within the DOM?
>>
>> Also, what are the use-cases this is trying to address. Why would we
>> need to have multiple @id attributes on the same element? I can
>> understand this node-unique ID, but it's hard to decipher what
>> multiple IDs on the same element would be used for?
>
> I think this is trying to address the problem of @id and @xml:id with
> conflicting values. The following element in an XHTML document would
> have two identifiers:
>     <span id="foo" xml:id="bar">blah blah blah</span>
> and thus would be matched by those two CSS selectors:
>     #foo, #bar
> and could be found with these two script statements:
>     document.getElementById("foo");
>     document.getElementById("bar");

I really don't think that's something we should encourage. Unless we  
want to define @id to be unrelated too dat type ID. If it would avoid  
compatibility problems I would love to see @id in HTML be unique only  
within a node (like in a hierarchical file system). I think that  
fosters more persistence in @id values and easily avoids name  
collisions.

>> The concerns I'm raising here pertain to document conformance and not
>> to UA conformance. Obviously UAs can be as lenient as possible on
>> this. However, what are we gaining by encouraging authors to use id
>> values that could cause problems down the road. In some sense I think
>> we want IDs to be as persistent as possible because ever time IDs
>> have to change they run the risk of breaking things (hence the idea
>> of a node-unique id). So this suggests to me that we should stick
>> with the HTML4 and XML notion of an ID. If we want to add another
>> unique identifier it could have a different name (such as @key).
>
> Given that valid HTML4 and XHTML 1.0 documents would still be valid
> (X)HTML5 documents, I don't see the problem.

Well my concern would be that an HTML4 UA might have taken this  
portion of the HTML4 recommendation seriously and the compatibility  
would be broken (if testing has already indicated that's not the  
case, then I'm satisfied on that). The other concern would be if we  
are to specify @id as type ID and thus break XML conformance. Will we  
not have an XML schema of any kind (DTD, XSD or otherwise)? Should we  
include something in this subsection explaining that an @id is not of  
type ID?

Take care,
Rob

Received on Wednesday, 1 August 2007 16:13:45 UTC