Re: XML:ID extension spec proposal to HTML5 documents

Robin Berjon, Tue, 04 Feb 2014 10:59:13 +0100:
> On 03/02/2014 23:48 , Leif Halvard Silli wrote:
>> Robin Berjon, Mon, 03 Feb 2014 12:25:28 +0100:
>>> The solution to the present problem
>>> is to have XInclude (and in general XML tool chains) recognise id as
>>> an ID in an HTML context.
>> 
>> I believe XInclude says nothing about *how* attributes are assigned the
>> ID type.
> 
> Naturally not, this has always been left open as something that could 
> be determined in more than one way. In this case XInclude relies on 
> XPointer, which in turn supports externally-determined IDs:
> 
>     http://www.w3.org/TR/2003/REC-xptr-framework-20030325/#term-xdi

> 
> Recognising @id as an ID in HTML context is an externally-determined 
> ID. Recognising xml:id is also an externally-determined ID.

Both attributes are indeed externally determined. HTML5 says that 
”Implementations must support DOM”. And it is the DOM that requires ID 
to be assigned to the id attribute, see 
http://www.w3.org/html/wg/drafts/html/master/single-page.html#concept-id

>> OK. I take it that you want me to add to the spec that, for documents
>> in the XHTML namespace, XML tools should just assign ID type to the id
>> attribute.
> 
> I don't see that this needs to be in any specification. HTML already 
> defines that @id is of type ID.

You are right. That detail need not be specified. The spec can just 
point to what HTML5 already says. I did not realize that this was so 
clear. I should definitely point this out in the spec and recommend XML 
tools to support HTML as specified.

>>> There is no need to add xml:id everywhere
>>> to support that.
>> 
>> But the fact is that there is a need, right now. For instance, Prince
>> XML, the HTML5-supporting PDF formatter for HTML/XML documents,
>> supports XInclude too, but does not assign ID type to HTML’s id
>> attribute.
> 
> That is a bug to file against Prince XML.

I think it just relies on a common XML library.

>> So the document must eventually describe both methods - the
>> future method and the current method, IMO. Unless there are some
>> stakeholders that are very tightly married to the xml:id way, it will
>> die out pretty quickly as soon as ID type assignment to the id
>> attribute has gotten traction.
> 
> There are only two cases to consider. Either:
> 
> A) The processor supports HTML. In that case it recognises @id. 
> Nothing further is required. This is the most desirable case since it 
> matches a few content instances out there.

Right.

> B) The processor does not support HTML, but you would like it to 
> process it anyway. Just transform the content to use xml:id. 
> Presumably if the processor does not support HTML the content is XML 
> anyway,

”Is XML anyway”??!! What a magical expression!

> so nothing prevents you from applying a transformation to add 
> xml:id. This does not require a specification, xml:id already does 
> that.

”Require” is a qualified word. I had to find out that I could use 
xml:id on my own. Spec are authored to help.

It is impractical to replace *all* ids with xml:id.  HTML is a format 
that is edited in multiple tools. Handing documents around that have 
replaced id with xml:id is *not* an option. 

An important task of specifications is to describe what works. But I 
will make sure that the spec also points to what HTML5 says about ID, 
so that the future direction is also covered.

> So I really don't see why an ES is required here. It adds nothing 
> that can't already be done.

I don’t follow this logic. For instance, DOCTYPE and DTD is already 
specified. But that does not prevent us from coming up with new DTDs - 
and add them to various new specs. I think it is useful to have a 
document that explains ”the ways to Rome”. 
-- 
leif halvard silli

Received on Tuesday, 4 February 2014 12:29:54 UTC