XHTML2 WG: XHTML 1.1 Issues Disposition of Comments

Editor: Steven Pemberton

Date: $Date: 2010/04/13 13:03:05 $


The intention of the PER transition request for XHTML 1.1 was to add XML Schemas to XHTML 1.1. To that end it wasn't the intention to make normative changes to the language, even though there were some outstanding issues. Some of those issues actually related to XHTML Modularization, which XHTML 1.1 references normatively, and so do not require a change to XHTML 1.1 but to the referenced spec.

Shortly after the PER was announced, an email was sent, not to the group, but to www-archive, complaining about perceived unaddressed issues in the XHTML 1.1 PER.

This document addresses those issues; although some editorial errors were indeed picked up (and would easily have been repaired if they had been sent to us), many of the issues raised were just wrong. It should also be noted that the email raised new issues that have never been raised before.

The issues were discussed over 4 meetings.

ISSUE 1: @name

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

Refers to XHTML 1.0; we agree it needs changing, and we were planning a 3rd edition. This was a PER just in order to update references. However, W3C has now decided not to reissue XHTML 1.0.

ISSUE 2: Informative references

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

These have been corrected or are addressed elsewhere in this document.

ISSUE 3: Fifth edition XML

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

This was quite deliberate. The changes introduced in XML 5th edition are potentially imcompatible, and the working group chose to freeze XHTML Modularization, and therefore markup languages derived from XHTML Modularization, at 4th edition. The group also chose to keep XHTML 1.0 (which is not derived from XHTML Modularization) at 4th edition for consistency. However, the W3C has decided to not update XHTML 1.0 so this is moot.


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

This was a typo (they are in Appendix A in the new document). Now fixed.

ISSUE 5: Appendix C

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

Appendix C has always been a non-normative set of guidelines intended to help authors with potential pit-falls of having to deal with legacy browsers. Therefore talking about 'accountability free' is missing the point. As the browser landscape changes these guidelines need to be kept up to date: that is ideal territory for a note rather than a spec, since you can make changes as needed to keep the guidelines current. One of the problems with having them in the spec is that it is much harder to update a spec (as this whole exercise amply demonstrates), and inattentive readers are mislead into thinking that they are normative. Removing the guidelines from Appendix C is one of the best changes that this edition made, since it makes it even clearer that these are not normative rules, but just ways that you can improve the potential acceptability of your documents.

ISSUE 6: 'Broken' links, and use of xml:lang

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/

Sorry about that. Note that they have the same anchors in their new location, so the only change needed is to change the URI of the base document, which is http://www.w3.org/TR/2009/NOTE-xhtml-media-types-20090116/

ISSUE 7: Lack of nesting rules

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.

The formal grammar used to define modules in XHTML Modularization uses exclusions to express the restrictions.

ISSUE 8: No nesting rules for Ruby

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

XHTML 1.1 references the Ruby spec which in turn calls out the nesting prohibitions.

ISSUE 9 (?): ?

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

This seems to be a repetition of issue 1 above.

ISSUE 10: References

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.


ISSUE 11: DOCTYPE optional

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

The working group were asked to make this change by Tim Berners-Lee. Upon further reflection the group has reverted this change because they agree that it is a bad idea.


Issue 11 was initially believed to be two issues. There is no issue 12.

ISSUE 13: @version

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

We don't require its use, but we do allow it. It is in HTML4 and XHTML 1.0 and deprecation isn't a problem - things can always be undeprecated (as has been done in the past). It is not clear what change would he like to make, if any.

ISSUE 14: Change not mentioned

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

Modularization widened the datatype of @version to CDATA, and in RDFa something 'more friendly' is used. We are not sure which change he is referring to.

ISSUE 15: Reintroduction of @lang

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

The email indicated is not the reason that @lang is being added. The motivation called out in the status is exactly the reason: we were asked to by the Accessibility groups since it would aid in the use of current assistive technology software.

ISSUE 16: @usemap

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

The group agrees that it is reasonable to repair this, but the repair needed to be done at the XHTML Modularization level. This has been completed in the XHTML Modularization PER.

ISSUE 17: DTD doesn't allow @lang

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

This is fixed.

ISSUE 18: No implementation report

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

A PER does not need an implementation report. It is not true that XHTML 1.1 requires application/xhtml, it says SHOULD.

ISSUE 19: Empty string in @lang

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

We are unable to locate any prohibition of the empty string for language codes in HTML4. lang and xml:lang accept the same values, and the definition of what lang means is taken from HTML4 and lang is allowed to be empty, and the definition of xml:lang is taken from XML, and is also allowed to be empty.

ISSUE 20(?): Inheritance from M12N

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

There were no substantive changes in Modularization 1.1, and it could perfectly well have been a PER. It just added Schemas to the mix. W3C decided it preferred to rename it, not the group. He mentions two dozen issues that were not addressed, but the group are not aware of which issues he is talking about. In any case, there are no unaddressed issues currently in the issue tracking system for XHTML Modularization.

ISSUE 21: @profile

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.

Fixed. XHTML Modularization says it is a space-separated list of URIs. Languages derived from XHTML Modularization inherit this definition, and the implementations provided match the definition.

ISSUE 22: bdo lacks event attributes

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

We believe all relevant open issues in [3] have been addressed. In HTML4 bdo did not have event attributes, nor did the previous version of XHTML 1.1, nor does this. It might be an interesting change to make, but someone would have to issue a request for this change, so that it became an issue.

ISSUE 23: No @version in XHTML Basic

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

XHTML Basic is deliberately a subset. It was produced by the mobile handset manufacturers, who did not require a version attribute. There are other features of XHTML that XHTML Basic does not have. There is no recorded issue against Basic not having @version.

ISSUE 24: DOCTYPE optional only in 1.1

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.

This is mostly a reiteration of issue 11 above. HTML constraints have never been fully defined by the DTDs, nor the schemas, because they can't be. DTDs and schemas also are able to describe different things, so there are some areas of no overlap. For instance, documents that conform to the DTD could fail with the schema because of schema's advanced datatype checking; however the document is still required to conform to the constraints, even if the DTD cannot check them. He is right that the different specs used different wording (they have now been harmonized); "and" is the correct wording.

ISSUE 25: @lang not in print, basic

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.

Print and Basic are for specific devices, and the parties who created those variants didn't require @lang, because they didn't require use of the appendix C guidelines. The XML references are updated to ensure they are consistent throughout the family.

ISSUE 26: consistency issues

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.

Print and Basic are designed for specific devices (mobile phones and printers) that have reduced possibilities, which includes not being able to override in the internal subset. So indeed, if you want to override, use XHTML 1.1, but be sure not to send it to the limited devices. We cover @target below.

ISSUE 27: @target

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

We were instructed that we couldn't add @target in a PER, so we didn't. There is general agreement that it should be there, but it can't be added to a PER, whose only purpose is to add Schemas to an existing spec.