Working Group Decision on ISSUE-56 urls-webarch

The decision follows.  The chairs made an effort to explicitly address
all arguments presented in the Change Proposal on this topic in
addition to the arguments posted as objections in response to the call
for closure based on Amicable Resolution.

*** Question before the Working Group ***

There is a basic disagreement in the group as to whether or not the
content attribute of the meta element should allow multiple languages,
or even if a Content-Language pragma should be treated as conforming at
all.  The result was an issue, three change proposals, and a survey:

== Uncontested observations:

The following observations were made by participants and seemed to
enjoy consensus:

  * it would be nice if http-equiv actually had the same effect as the
    HTTP header. However, this isn't possible in this case for
    compatibility reasons.

  * All 3 proposals agree that UAs MUST ignore pragmas with multiple
    languages inside

  * Any restrictions on the use of Content-Language interferes with the
    original intended use of this markup.

  * The use of html@lang cancels any effects that HTTP and http-equiv
    might have, in HTML5 parsers and (in the average cases) in legacy
    parsers as well.

  * We are faced with a situation where the choices either involve
    producing error messages for situations which are harmless, or to
    pick a more complicated solutions that authors may not universally

None of these were decisive.  There were people who supported one of
the change proposals even after taking these facts into consideration.
The fact that they were acknowledged up front was appreciated.

It generally is difficult to evaluate consensus when there are more
than two proposals.  In this case, the way we proceeded was simply to
evaluate each in turn.

=== Objections to allowing multiple languages

Weakest objections include: confusing/complicated, and
redundant/unnecessary.  That's not to say that such objections are not
valid, just that there may be circumstances where it may be necessary
to ignore such requirements once the full implications are are
understood and carefully weighed.  In both of these cases, exactly such
an argument was made.

Strong objections include: does not match the HTML model where each
node in a document can have its language computed to at most one
language tag, nor does it exactly match the HTTP header model, no
demonstration that content language tools actually need/use this
feature, multiple language values are not interoperably supported, and
evidence that this feature is more often than not unused or misused.

=== Objections to making only multiple languages non-conforming

Weakest objections include producing errors in situations where the
markup is harmless, and redundancy.  Again, that's not to say that
these objections are not valid, just that there were arguments put
forward which indicate that there are valid reasons for an exception to
be made in this case.

Strong objections include changing the syntax in a way that makes HTML
and HTTP incompatible.

== Objections to making Content-Language non-conforming

Weakest objections include producing errors in situations where the
markup is harmless, the proposal is a layer violation, and that this
proposal will interfere with the intended use case for this function.

There were no uncontested strong objections to this proposal.  Again,
what that means is that while there were valid objections against this
proposal, we found that for each objection there were valid reasons put
forward why such an objection should not be considered strong.

For completeness, we now review each of the objection to the "making
Content-Language non-conforming" proposal:

It is uncontested that this proposal will cause validators to produce
errors in situations that are, in fact, harmless.  In each such case,
there is a preferred way for the language to be expressed.  One of the
alternate proposals would have produced the same number of messages,
just as warnings not as errors.  The other proposed not producing
messages in cases which will neither be interoperably implemented nor
compatible with the HTTP definition, and both of these conditions were
considered undesirable.

It is also uncontested that this is a layering violation.  The I18N
Working Group provided a clear statement as to why specific
circumstances merits an exception:

   It really is a requirement that HTML5 clearly specify if (and if so,
   how the) HTTP Content-Language and/or the Content-Language pragma is
   assigned to html@lang when html@lang is itself not present. The I18N
   WG could accept language specifying the assignment of the
   (unmodified) Content-Language syntax header/pragma to html@lang, as
   long as such an assignment were completely unambiguous, although we
   really would prefer that no such linkage is created.

Additionally, this layering concern applies in differing degrees to
both of the other Change Proposals as each proposes conformance
criteria and/or behavior which differs from the HTTP definition.

Finally, it is asserted that this will interfere with the intended use
case for this function.  While the assertion itself is not contested,
what is contested is that there has been any demonstration that there
is any need or desire on the behalf of authoring tools to communicate
this information in this manner. This leads to a strong objection to
premature standardization absence this evidence.

*** Decision of the Working Group ***

Therefore, the HTML Working Group hereby adopts the Change Proposal to
make Content-Language non-conforming.  Of the Change Proposals before
us, this one has drawn the weaker objections.

== Next Steps ==

Bug 8552 is to be REOPENED and marked as WGDecision.

Since the prevailing Change Proposal does call for a spec change, the
editor is hereby directed to make the changes in accordance to the
change proposal.  Once those changes are made, ISSUE-88 is to be marked

== Appealing this Decision ==

If anyone strongly disagrees with the content of the decision and would
like to raise a Formal Objection, they may do so at this time. Formal
Objections are reviewed by the Director in consultation with the Team.
Ordinarily, Formal Objections are only reviewed as part of a transition

== Revisiting this Issue ==

This issue can be reopened if new information come up.  An example of
possible relevant new information include:

* Clear evidence that there are either authoring tools or servers which
   depend specifically on the Content-Language pragma to behave per the
   original intended use for this function.

== Arguments not considered

The following arguments expressed in the survey were not considered for
the reason specified:

   Additionally, it is asserted that this proposal contains "unjustified
   changes, inconsistencies, unimplementable requirements and is overall
   inappropriate for use in the specification."

This argument is entirely lacking in specifics.

   We would prefer that the CP be modified... this, of course, is an
   argument against the main raison d'Ítre of this CP.

We only evaluate change proposals that actually were submitted.  This
is particularly true when the changes proposed are "against the main
raison d'Ítre" of the proposal in question.

Received on Saturday, 19 March 2011 14:11:00 UTC