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

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.

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

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

> 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");

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

-- 
Thomas Broyer

Received on Wednesday, 1 August 2007 15:57:46 UTC