XHTML2 WG: XHTML 1.1 Issues Disposition of Comments

Applies to XHTML 1.0

HTML 4.0 did not include the name attribute for the form and img elements; HTML 4.01 changed that [4] adding it to all document types. XHTML 1.0 is supposedly based on HTML 4.01 and it does include the attribute in the Frameset and Transitional variants, but not in the Strict variant, but does not account for this difference in the specification.
[4] http://www.w3.org/TR/html4/appendix/changes.html#19991224

The appropriate way to address this issue would affect conformance, and as such this is a substantive issue. The group has been aware of this problem for six years now [5] and even though it would take minutes to fully address it, the group has taken no action on it, and did not note this failure as required either.
[5] http://htmlwg.mn.aptest.com/cgi-bin/voyager-issues/XHTML-1.0?id=6504

The proposed document in fact pretty much claims the opposite [6], that the document reflects corrections based on community feedback. It is very rare that the group responds to community feedback at all, but even issues where they promised swift action six years ago remain unchanged.
[6] http://www.w3.org/TR/2009/PER-xhtml1-20090507/#status

Applies to XHTML 1.1

The current specification marks all references as informative. Clearly that is incorrect as acknowledged by the group [7] and in addition to being quite embarassing makes reasoning about the specification difficult. The proposed document has the same flaw [8].
[7] http://htmlwg.mn.aptest.com/cgi-bin/voyager-issues/XHTML-1.0?id=6674
[8] http://www.w3.org/TR/2009/PER-xhtml1-20090507/#refs

The References section is in fact rather curious as pretty much none of them have been updated, even though that was the stated purpose of the publication [9]. It lists RFC 2396 which has been obsoleted by 3986, the first edition of Namespaces in XML, and quite importantly the second edition of XML 1.0.
[9] http://lists.w3.org/Archives/Public/public-xhtml2/2009Mar/0087.html

Applies to all XHTML Family Specifications

The fifth edition changed what characters are allowed inside Names which affects what is allowed, say, in ID attributes. With an unupdated specification it would be reasonable to assume XHTML 1.0 would inherit those changes.

But with an updated specification that references an outdated specification, we cannot make such an assumption. Perhaps there is some subtle reason beyond the imagination of the uninitiated that caused them to intentionally not update it, which would ultimately cause speculation and argument in places such as the www-validator mailing list.

For the Validator this update would have been particularily helpful, as then the SGML declaration for XML 1.0 as included in the specifications would have been updated, saving the Validator developers the trouble of creating their own unofficial version, which I take it has yet to happen [A].
[A] http://dev.w3.org/cvsweb/validator/htdocs/sgml-lib/xml.dcl

Applies to XHTML 1.0

Editorially we need not look further than the SotD section [6] to know how much care was put into drafting the document. According to it, the only change of note is an update to Appendix A. Now Appendix A has not been changed at all, it enumerates the document type definitions and entity sets which have been left unchanged, including still listing the INRIA as W3C host.
[6] http://www.w3.org/TR/2009/PER-xhtml1-20090507/#status

Applies to XHTML 1.0

The change is actually to the controversial Appendix C. The idea is to move the content into the accountability free realm of Working Group Notes [B]. Needless to say that in drafting said Note, the group did not find reason to address issues with the text collected in their own issue tracking system, or much of the newly reported ones, with the usual complaints about that [C].
[B] http://www.w3.org/TR/2009/NOTE-xhtml-media-types-20090116/
[C] http://lists.w3.org/Archives/Public/public-xhtml2/2009Feb/0032.html

Applies to XHTML 1.0

The group also proposes to needlessly break all links into the section, as tools such as my own Appendix C validator [D] would generate them. Of course, the document does not actually follow said guidelines: they did manage to use only xml:lang instead of xml:lang and lang for one of the Chairs' affiliation; the other documents have similar problems.
[D] http://qa-dev.w3.org/~bjoern/appendix-c/validator/

Applies to XHTML 1.1 and XHTML Modularization

Let's move on to XHTML 1.1. Procedurally it is important to note that unlike the new version of XHTML 1.0 it did not pop out of nowhere, it had a preceding Working Draft [E]. Of course this PER has much of the same issues as the XHTML 1.0 PER.
[E] http://www.w3.org/TR/2007/WD-xhtml11-20070216/

Let's take for example the matter of unaddressed substantive issues. To pick one, there are certain nesting rules that cannot be expressed in the formal languages used to describe the format. XHTML 1.0 calls those out explicitly, XHTML 1.1 and XHTML Modularization on which the latter is based do not.

Applies to XHTML 1.1

One may imagine that the rules from XHTML 1.0 are inherited, but XHTML 1.1 also includes elements from Ruby annotation [F] and does not call out nesting prohibitions for those elements. Again addressing this will affect conformance and the issue has been known for half a decade [G] but remains unchanged.
[F] http://www.w3.org/TR/ruby/
[G] http://htmlwg.mn.aptest.com/cgi-bin/voyager-issues/XHTML-1.1-DTDs?id=8840

Applies to XHTML 1.1

For actually acknowledged issues you can also go back as many as eight years like with [H] which somewhat ironically is quite related to the issue [5].
[5] http://htmlwg.mn.aptest.com/cgi-bin/voyager-issues/XHTML-1.0?id=6504
[H] http://htmlwg.mn.aptest.com/cgi-bin/voyager-issues/XHTML-1.1-text?id=480

Applies to XHTML 1.1

The References section naturally has similar issues as XHTML 1.0 has, though this time they manage to reference the slightly less outdated Fourth Edition of XML 1.0, for example. One may wonder though why XHTML 1.0 is a normative reference even if it is referenced only in informative sections, and, say, Namespaces in XML informative, even though it is referenced in normative text.

Applies to XHTML 1.1

Moving on, we can have a look at the changes. The news piece [1] and the Status section [I] inform us there is a couple of corrections and clarifications. Nothing could be further from the truth, we actually have the greatest paradigm shift since the event of XHTML: DOCTYPE declarations are now optional.
[I] http://www.w3.org/TR/2009/PER-xhtml11-20090507/#status

That is gross violation of the W3C Process. Given that the document was a Working Draft beforehand, at least one of [J] and [K] applies, and of course [L] and again [2].
[2] http://www.w3.org/2005/10/Process-20051014/process.html#cfr-edited
[J] http://www.w3.org/2005/10/Process-20051014/process.html#return-to-wg
[K] http://www.w3.org/2005/10/Process-20051014/process.html#correction-classes
[L] http://www.w3.org/2005/10/Process-20051014/process.html#DocumentStatus

Applies to XHTML 1.1

The new way to specify the dialect you are using now seems to be the version attribute. The version attribute is a long dead relict from the 1990s; being redundant it's been deprecated in HTML 4 and never made it into its Strict variant, or XHTML 1.0 for that matter. If you have some XHTML 1.1 and do not explicitly specify the version attribute, it quite probably is non-conforming now. One has to wonder though whether adding it would change that, given its deprecated nature [M].
[M] http://www.w3.org/TR/html4/struct/global.html#adef-version

Applies to XHTML 1.1

One thing to say in their favour though is that they realized, more by accident, that the version attribute must contain a formal public identifier per XHTML Modularization 1.1. They failed to realize that when creating another dialect [N]. Naturally this change from XHTML 1.0 is not mentioned in the document.
[N] http://www.w3.org/TR/2008/REC-rdfa-syntax-20081014/#docconf

Applies to XHTML 1.1

The other change, the re-addition of the lang attribute, is called out in the status section, but otherwise quite similar. Of course, the motivation mentioned in the status section, compatibility with user agents and assistive technologies is not the actual motiviation that called for this change [O].
[O] http://lists.w3.org/Archives/Public/public-xhtml2/2009Jan/0049.html

The reasoning is rather ludicrous, if you want to use the attribute you can use XHTML 1.0 unless you also want to use Ruby. If there is a need to use legacy attributes from a decade ago alongside Ruby and you want to have the result validate against some W3C approved document type, then a new document type could easily be made. As noted in the abstract the purpose [P] of XHTML 1.1 is a different one.
[P] http://www.w3.org/TR/2009/PER-xhtml11-20090507/xhtml11.html#abstract

Applies principally to XHTML Modularization; has effect on specifications using @usemap

Clearly if compatibility is a concern all of the sudden, one might expect that they would re-evaluate other compatibility concerns previously rejected. One such issue is the definition of the usemap attribute. It's been changed in XHTML 1.1 in a way that causes compatibility problems. Despite a number of promises to reevaluate and change it [Q] [R], there is no change at all. But perhaps nobody noticed? [S] [T] are suggestive.
[Q] http://lists.w3.org/Archives/Public/www-validator/2002Apr/0019.html
[R] http://ln.hixie.ch/?start=1172653243&count=1
[S] http://www.google.com/search?q=usemap+%22XHTML+1.1%22
[T] https://bugzilla.mozilla.org/show_bug.cgi?id=109445

Applies to XHTML 1.1

Of course, the new XHTML 1.1 DTD does not actually allow using the lang attribute. They tried to allow it by defining the lang.attrib parameter entity in the document model module, but when that is read the entity is already defined, and the first declaration always wins [U]. It's telling that they cannot even use their own framework for making such changes.
[U] http://www.w3.org/TR/xml/#sec-entity-decl

Applies to XHTML 1.1

Needless to say that [2] requires the group to demonstrate that support for the lang attribute and doctype-less documents has been implemented, and that consequently there is no implementation report whatsoever. Last time [V] they figured checking for DTD support in XML processors would suffice, if they had bothered to check a document with a lang attribute they might just have noticed this issue.
[2] http://www.w3.org/2005/10/Process-20051014/process.html#cfr-edited
[V] http://web.archive.org/*/http://www.w3.org/MarkUp/2006/m12n-11-implementation.html

The idea that motivated this change [O], that you can now use text/html for XHTML 1.1, is also hardly accomodated by this change, as the XHTML 1.1 specification requires to use application/xhtml+xml for documents.
[O] http://lists.w3.org/Archives/Public/public-xhtml2/2009Jan/0049.html

Applies to XHTML 1.1

If they wanted to do something good for language declarations in XHTML, they might at least have brought XHTML 1.0 in line with the now rather outdated second edition of XML 1.0 which they reference and allow the empty string in xml:lang attributes as per [W]. Or at least not refer to HTML 4 for the definition of the lang attribute in XHTML 1.1 [X] as HTML 4 prohibits using the empty string as value for it [Y].
[W] http://www.w3.org/XML/xml-V10-2e-errata#E41
[X] http://www.w3.org/TR/2009/PER-xhtml11-20090507/xhtml11.html#s_doctype
[Y] http://www.w3.org/TR/html4/struct/dirlang.html#langcodes

Applies to XHTML Modularization

Now XHTML 1.1 is based on XHTML Modularization 1.1 and so inherits all the issues with that document. That Recommendation is a successor of [Z] the 2004 Modularization of XHTML 1.0 Second Edition draft. In 2005 the group, or rather its predecessor, wanted to have it advanced to PER status, but there were too many changes [a] [b] to proceed thus.
[Z] http://www.w3.org/TR/2004/WD-xhtml-modularization-20040218/
[a] http://www.w3.org/mid/42A99B2E.6020808%40w3.org
[b] http://www.w3.org/mid/op.sxtcfwl4smjzpq%40r600.lan

So the group renamed the draft XHTML Modularization 1.1 and had it published as Proposed Recommendation in 2006 [c]. Now, a problem with that was that reviewers filed about two dozens of issues with the 2004 draft, most of which were not addressed, as is mandatory to enter PR status.
[c] http://www.w3.org/TR/2006/PR-xhtml-modularization-20060213/

Unusually the Team investigated complaints resulting from this, and found there were no procedural problems, except that the Disposition of Comments [d] was not properly linked from the document. Now, that DoC is not even for the document that was advanced, but rather for its predecessor; except perhaps if you want to believe that the group discarded the 2004 draft, started over, came up with materially the same document, and had that published instead, replacing the first edition of XHTML Modularization 1.0, as the second edition would have.
[d] http://htmlwg.mn.aptest.com/htmlwg/xhtml-m12n-schema-lc-doc-20050907.html

Applies to XHTML Modularization

Be that as it may, an issue of particular import, raised quite a number of times, was the definition of the profile attribute. It kinda takes one or more URIs that identify meta data profiles, but the draft allowed only a single URI. When the PR was published, there was no record of a group decision on the matter. Alerted by process complaints, one got added in haste [e], saying that this was a change made on purpose to use the attribute for something else entirely, to identify compound document profiles.
[e] http://lists.w3.org/Archives/Public/www-html/2006Feb/0087.html

Couple of weeks later this was actually found to be an inadvertent editorial error that will be corrected [f]. Given the attention the issue received, surely this error has been corrected in the Recommendation?
[f] http://www.w3.org/mid/44634B86.8080805%40w3.org

Well as it turns out, not really. Both DTD and Schema in XHTML Modularization [g] [h] allow only a single URI, or in case of Schema, associate incorrect semantics with the attribute value. Helpfully the DTD version notes the profile attribute is reserved for future use with document profiles. So much for an inadvertent editorial error.
[g] http://www.w3.org/TR/xhtml-modularization/xhtml-modularization.html#a_modules_basicmods_2
[h] http://www.w3.org/TR/xhtml-modularization/xhtml-modularization.html#a_modules_basicmods

Worse, the DTD defines a default value to the attribute, in case of XHTML 1.1 that is the empty string. The implication of that is that the default meta data profile of each XHTML 1.1 document is the document itself, which is almost always incorrect.

Applies to XHTML 1.1

We can course effortlessly find as yet unreported issues simply using a little script [i] and our favourite diff tool to compare the proposed XHTML 1.1 DTD with the previous one, and find, for example, that the bdo element suddenly lacks event attributes. And [3] has plenty unfixed old issues.
[3] http://htmlwg.mn.aptest.com/cgi-bin/voyager-issues
[i] http://lists.w3.org/Archives/Public/www-archive/2005Feb/0029.html

Applies to XHTML Basic

Moving on we have XHTML Basic 1.1 and XHTML Print Second Edition. Shall we have a look at how they deal with the issues we discussed before? So, take the version attribute for example. Recall it is forbidden in XHTML 1.0, recommended in XHTML 1.1. In XHTML Print it's not applicable since it was deprecated all the way back in HTML 4 [j]. XHTML Basic 1.1 does not mention it.
[j] http://www.w3.org/TR/2009/PER-xhtml-print-20090507/#s3.2

Applies to XHTML 1.1

How about DOCTYPEs? Well they are required in XHTML 1.0, optional in the proposed XHTML 1.1 version, and in Basic 1.1 and Print they are required again. Also of note is that in XHTML 1.1 documents must somehow conform to the Schema *and* the DTD, while in Basic 1.1 and Print one or the other is sufficient.

Applies to XHTML Print and XHTML Basic

The lang attribute? It's not in Print, but it's in Basic, except that it is not really there, thanks to the group modifying the DTD incorrectly. XHTML Print then thankfully references the third edition of XML 1.0, so we have a nice set with the 2nd, 3rd, and 4th, missing only the current and first edition.

Applies to XHTML Modularization

Oh, as we are talking about it, do not override parameter entities in the internal subset when using XHTML Print or XHTML Basic 1.1, that's not allowed in there. Use XHTML 1.1 instead. Always remember the rules: if you need to open documents in a new tab, specify list item values, or input modes, use XHTML Basic; if you need Ruby, use XHTML 1.1. If you need both, you're screwed.

Applies to XHTML Modularization

Actually this is kinda funny, because XHTML 1.1 is actually supposed to have the target attribute [k], and it was in the 2007 Working Draft but only in the DTD, not the schema [l]. That issue appears to be fixed now: now it is in the schema but not in the specification prose or the DTD; except in the flat version, as that one has not been updated since the 2007 draft, and is not in fact a DTD at all. If that change had been noted in the draft as required, perhaps someone might have spotted the mistake.
[k] http://www.w3.org/mid/op.sxtcfwl4smjzpq%40r600.lan
[l] http://htmlwg.mn.aptest.com/cgi-bin/voyager-issues/Modularization-Schemas?id=9721