W3C home > Mailing lists > Public > public-html@w3.org > January 2014

XML:ID extension spec proposal to HTML5 documents

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Fri, 31 Jan 2014 08:09:27 +0100
To: "public-html@w3.org" <public-html@w3.org>
Cc: Paul Cotton <Paul.Cotton@microsoft.com>, Sam Ruby (rubys@intertwingly.net) <rubys@intertwingly.net>, Maciej Stachowiak <mjs@apple.com>
Message-ID: <20140131080927231577.7ac2358c@xn--mlform-iua.no>
Hi!

I am hereby presenting to the HTML Working Group the first version of a 
specification for the optional use of the xml:id attribute in HTML5 
documents - XHTML or HTML. I am looking forward to your feedback, on 
this list.

Please find the draft snapshot as an attachment to this very message.

The extension spec addresses the issue that the new doctype that was 
introduced by HTML5, removed (classic) XML ID-type assignment from HTML 
documents consumed as XML. As a result, XML tools relying on that kind 
of assignment are unable to locate resources of XML ID type in HTML5 
documents. XHTML1 documents do not have this issue (as long at their 
DOCTYPE is included).

One use case for the xml:id attribute is XML Inclusions, last updated 
in October 2013, see http://www.w3.org/TR/xinclude-11/. The XML 
Inclusions spec specifies an <include> element in the XInclude 
namespace. <include> and  can be viewed as an alternative to “includes” 
of various languages (every scripting language seems to have them), but 
a nice thing with XML Inclusions is that it can not only include entire 
files, but can also include specific nodes of an XML document. And for 
this, the parser must be able to identify idrefs. Which is where xml:id 
comes to rescue. And btw, XML Inclusions is designed to work on both 
HTML and XML, since one can specify per <include> element how to parse 
the referred file (which of course must be well-formed, though). It is 
the <include> element’s xpointer attribute that keeps the idref. And 
while can refer to other things than idrefs, using them for idrefs is 
simplest (to authors) and also with best support in (legacy) tools.

The intent intent is not change the current HTML specification in any 
way. The intent is only to offer an extension spec.

The NU validator is not compatible with the proposed extension. On last 
check, before Christmas, I identified two incompatibilities: 1) For 
HTML, NU validator does not permit the xml:id attribute. 2) For XHTML, 
it does allow xml:id, but not if xml:id and id are specified on the 
same element - which is exactly the use that the extension spec 
proposes. (The spec text proposes usage similar to that of xml:lang.) 
May be it would be a good idea if NU validator stopped performing XML 
ID-type assignment on the xml:id attribute. Or may be it could simply 
accept what the spec proposes. That being said, since xml:id is meant 
to duplicate the id attribute, it is simple to add/remove it 
before/after running validation.

Web browsers should be compatible with this spec. ”Modern” browsers do 
not implement xml:id. Some old browser do, but they are not hampered, 
AFAIK. In writing the spec, I have tried to consider whether the 
documents authored according to the spec could stumble upon issues in 
the future. I believe not. The possible issues are now or in the past. 
I also tried to understand the SVG issue - as SVG has a history of 
xml:id and (de)implementation of it.

The goal of this extension spec is to be reviewed on its own. After a 
week or so, from now, my hope is to ask the Co-Chairs for a ”CfC for 
First Public Working Draft”.

Implementations basically already exists, namely in the (XML) authoring 
field. With this specification, hope is to bring awareness to the 
subject amongst authors and in the specification community. Outside the 
HTML working group, I hope that it will be met with interest from the 
XML community in particular.

The attached specification proposal is issued under the new dual 
CC-BY/W3C license.

Your feedback is very much welcome! 
-- 
Leif Halvard Silli


Received on Friday, 31 January 2014 07:09:58 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:40 UTC