- From: <bugzilla@jessica.w3.org>
- Date: Thu, 10 Oct 2013 14:52:36 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23480 Bug ID: 23480 Summary: Allow xml:id="Foo" (on the same conditions that xml:lang="Foo") Product: HTML WG Version: unspecified Hardware: PC URL: http://htmlwg.org/heartbeat/WD-html5-20121011/syntax.h tml#syntax OS: All Status: NEW Severity: normal Priority: P2 Component: HTML5 spec Assignee: dave.null@w3.org Reporter: xn--mlform-iua@xn--mlform-iua.no QA Contact: public-html-bugzilla@w3.org CC: mike@w3.org, public-html-admin@w3.org, public-html-wg-issue-tracking@w3.org 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. [[ -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Thursday, 10 October 2013 14:52:39 UTC