PROPOSAL:

   For the HTML syntax, allow xml:id="foo" inside elements of any
   namespace, provided its value matchs an id="foo" attribute on same
   element.

   Alternatively, write an extension spec which permits xml:id.  If the
   editors don't want to include it in HTML5.x, I offer to write the
   spec.

JUSTIFICATION:

1) In XHTML 1.0 and XHTML 1.1, the @id attribut is, technically (due the
DTD), a tokenized XML attribute of type "ID".  As result, XPointer and
spec’s that implements XPointer, can be applied to XHTML 1.0 and XHTML
1.1 documents, provided that the XML tool chain supports DTDs.

2) HTML5 documents should have the same opportunity. For instance, the
XInclude 1.1. spec has just reached CR and it makes use of XPointer,
including the element(FOO) syntax, where FOO refers to an element of
ID-value 'FOO'. and XInclude. But, unless one uses one of the obsolete
but conforming DOCTYPE declarations that HTML5 permits, the @id attribut
does note work for xpointer usage.

(For XInclude 1.1, see
http://www.w3.org/TR/2013/CR-xinclude-11-20131008/ )

EFFECTS OF ALLOWING:

* xml:id (or more correctly, the ID content type, see XML 1.0
http://www.w3.org/TR/REC-xml/#id) is more restricted than the HTML5 @id
attribute with regard to content, since the xml:id attribute has some
validity constraints. Thus, when used, xml:id will impact on what is
poermitted inside @id (due to the requirement that xml:id and @id are
identical)

* The legacy XHTML 1.0 and XHTML 1.1 doctyps *cannot* be used, whenever
xml:id is used or else one would end up with documents where an element
could contain two attributes of type "ID".

NOT AFFECTED:

* Text/html browsers would not be affected as they do not support the
xml:id attribute. And even if they had supported it (like some legacy
Web browsers do when it comes to XML), it ought not to matter as long as
xml:id and @id are identical.

SUBOPTIMAL, ALTERNATIVE SOLUTIONS:

1) Instead of the most intutive variant of the element(FOO)
syntax, one can use another variant of its syntax. E.g. for
XInclude, one might to xpointer="element(/1/2/2)" - as opposed
to the more stable and more semantic xpointer="element(SemanticIDValue)". 

2) Or, instead of adding xml:lang="id", the author could somehow make
sure that the docs were consumed with a legacy DOCTYPE in place. But
this works against the trend of deprecating DOCTYPE declarations etc.

A USE CASE:

   ]]
   An author with a Web site which follows polyglot markup wants
to create a PDF output or some other single document output of all
the pages of the site. By the use of an XML toolchain that supports
XInclude, this is very simple. Just create a "parent" document which,
using the the <include> element of the XInclude specification, points to
all the documents that should be includled in the final output.

However, the author stumbles upon one problem: Since the HTML5 based
site contains navigation content etc on each page, he would like to use
XInclude’s XPointer support in order to point to the fragments which
should be included:

<include href="http://site.example.com/about.html"
xpointer="element(SectionFOO)" />

Alas, this does not work for the reasons described above. But there is
a simple solution: If the author, as needed, duplicates the current @id
attributes with an xml:id attribute, it would work: Just convert <foo
id="bar"> to <foo id="bar" xml:id="bar"> through out the document.
   [[