- 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
Attachments
- text/html attachment: xmlid.html
Received on Friday, 31 January 2014 07:09:58 UTC