W3C home > Mailing lists > Public > public-html@w3.org > May 2008

Deterministic Conformance Requirments [was: Re: HTML Action Item 54 - ...draft text for HTML 5 spec to require producers/authors to include @alt on img elements.]

From: James Graham <jg307@cam.ac.uk>
Date: Mon, 12 May 2008 23:51:46 +0100
Message-ID: <4828CA02.1080104@cam.ac.uk>
To: Dan Connolly <connolly@w3.org>
CC: Dave Singer <singer@apple.com>, "public-html@w3.org" <public-html@w3.org>, W3C WAI-XTECH <wai-xtech@w3.org>, wai-liaison@w3.org, Chris Wilson <Chris.Wilson@microsoft.com>, "Michael(tm) Smith" <mike@w3.org>

Dan Connolly wrote:
> On the other hand, I don't think that the most useful definition
> of conformance for HTML 5 documents is limited to accessible documents.
> 
> As I said a while back, I do think the most useful definition
> of conformance is objective...
> 
>   keep conformance objective (detailed review of section 1.
> Introduction)
>   http://lists.w3.org/Archives/Public/public-html/2007Aug/1187.html
> 
> I'm still getting my head around the notion of conformance
> in the current HTML 5 draft. Making conformance depend
> on whether markup is used per semantics of <h1> and such
> seems like making grammatical correctness of English
> sentences depend on whether they're true or not. I suppose
> there's some value in it, but it's so different from what
> I'm used that I have trouble making sense of the discussion.

I don't think making a big deal of the distinction between machine 
checkable and non-machine checkable conformance requirements is very 
useful in the context of HTML.

Since HTML parsers are error-recovering and HTML 5 specifies that error 
recovery, there is no such thing as input that will not lead to some 
defined behavior in UAs. This means that conformance is not needed to 
ensure that the document functions much less that it functions as expected.

Given this, two reasons for setting conformance requirements in HTML 
come to mind:

a) QA assistance for authors. By making only a subset of all possible 
ways of achieving a particular DOM legal, and even by making certain 
DOMs illegal, we can help authors to identify likely errors in their 
documents that will lead to unexpected behavior.

b) Exerting social pressure on authors to construct their documents in a 
way that is beneficial to consumers, even if it is not of immediate 
benefit to the authors themselves.

Neither a nor b is helped exclusively by requiring that all conformance 
requirements be machine checkable.

For the QA case (a), non-machine checkable requirements are still likely 
to make it into textbooks and tutorials, so authors are more likely to 
be aware of the requirement and are therefore more likely to avoid the 
issue in the first place. If they hit the issue, they are more likely to 
find a solution quickly.

However case (b) — social pressure ­— is the really interesting case. By 
phrasing certain things as conformance requirements, there is presumably 
an increase in the number of people who will conform with that 
requirement compared with the case where there is no conformance 
requirement but some sort of implicit suggestion. This can be good for 
all sorts of reasons. For example if there are a large class of users 
who are known to suffer in some situation — when tables are used for 
layout, for example — then making it a conformance requirement to not do 
that can be helpful to those users.

Promoting certain behavior also helps certain classes of UA. For example 
making it conformance requirement that only headings appear in heading 
elements and all headings appear in heading elements increases the 
probability that a UA with a navigate-by-headers function will work 
acceptably well on the web.

By their nature this type of scenario tends to lead to 
non-machine-checkable conformance requirements. But trying to remove 
such requirements just because they are not machine checkable not only 
means that we have to give up the benefits they bring but also adds 
temptation to proxy fundamentally non-machine-checkable requirements 
with beguilingly similar-looking machine checkable requirements. Doing 
so is likely to be bad as people optimize for the proxy rather than the 
underlying requirement; a phenomenon that can be observed in many fields 
e.g. education where teachers (and pupils) often optimize for passing 
exams rather than for learning.

(as an aside, my understanding is that modern linguistics is generally 
not able to machine check for grammatical correctness but instead uses 
value judgments provided by a human being to assess whether sentences 
are grammatical or not. If a sentence is deemed grammatical by a human 
but cannot be derived from the supposed formal grammar of the language 
that merely indicates that the formal grammar is incomplete.)

-- 
"Mixed up signals
Bullet train
People snuffed out in the brutal rain"
--Conner Oberst
Received on Monday, 12 May 2008 22:52:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:17 GMT