Re: XML:ID extension spec proposal to HTML5 documents

David Carlisle, Tue, 04 Feb 2014 21:10:59 +0000:

> That is not automatic, it is up to the designer of any specific
> vocabulary whether to include xml:id.

Even if xml:id is not defined by XML 1.0, its relationship to XHTML5 is 
analogous with that of xml:lang in that it has to be *defined* as 
conforming in order to *be* conforming. In this, they ought to be equal.

    […]
>>> As specified that simply makes documents invalid, and it's best to
>>> leave it that way, ie not have an extension specification that
>>> makes it valid.
  […]
> XHTML is less of an issue. Your draft extension would make xml:id valid
> in text/html parsing which would be an unfortunate change. [ ... ]

Why?

The discussion has made clear one issue that actually does concern me: 
With the solution in the proposal (namely to duplicate id with xml:id), 
we would end up with xml:id being conforming in text/html documents but 
always causing ID-clashes if conforming XHTML5 parsers parsed a such 
XHTML5 document (unless the tool stopped supporting xml:id). The only 
way around *that* would be to take the opposite solution, namely to 
require that xml:id and id *never* are used on the same element.

… I need to think this over …

Btw: If instead of a xml:id, one made a XHTML5 DTD that took care of 
the ID type assignment, then we would avoid becoming valid in HTML (on 
one side), yet still be back-compatible with legacy XML tools (on the 
other side).

>> The spec proposal already says that if both xml:id and id are
>> assigned ID type, the XML tool will issue an (non-fatal) error
>> message. But I will make bring the legacy aspect of the spec proposal
>> much clearer in the next update.
>> 
> If it is a validating  parser it is (or could be) a fatal error.

The more fatal, the less of a ”danger” should xml:id be. 
-- 
leif halvard silli

Received on Wednesday, 5 February 2014 06:37:19 UTC