- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Mon, 3 Feb 2014 23:48:25 +0100
- To: Robin Berjon <robin@w3.org>
- Cc: Jirka Kosek <jirka@kosek.cz>, "public-html@w3.org" <public-html@w3.org>, Paul Cotton <Paul.Cotton@microsoft.com>, Sam Ruby (rubys@intertwingly.net) <rubys@intertwingly.net>, Maciej Stachowiak <mjs@apple.com>
Robin Berjon, Mon, 03 Feb 2014 12:25:28 +0100: > On 31/01/2014 23:48 , Leif Halvard Silli wrote: >> But as of right now, I am unaware of tools that have taken that >> approach. > > But the fact is that they could. I continue to agree. > 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. 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. Unless I misunderstood something, I will do so ASAP. (I hope hat the SVG 2.0 has made progress in this field so I can steal something from them.) > 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. 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. -- leif halvard silli
Received on Monday, 3 February 2014 22:48:56 UTC