Re: HTML 5 and conformance checkers

On Jun 14, 2007, at 09:22, Karl Dubost wrote:

> Le 14 juin 2007 à 14:16, Henri Sivonen a écrit :
>> The applicable conformance criteria are [machine-checkable]  
>> criteria for document conformance both in the spec itself and in  
>> normatively referenced other specs.
> Yes on the same line here. My trouble is what is [machine-checkable].
> I see possible discussion on people argueing on what is  
> automatically checkable or not. It is why I said an objective list  
> of criterias to include or exclude would make it easier.

Easier for whom? Not for the spec editors, that's sure. As a  
conformance checker implementor, I have so far found determining the  
machine-checkability of requirements sufficiently easy.

> What about
>     "An HTML 5 conformance checker must implement all the machine
>     checkable criteria of this specification.
>      Note: There are criteria that can only be checked by a human
>     and then do not affect an HTML5 conformance checker. Some of
>     the machine criteria can't be expressed by the current schema
>     languages. You should not rely only on schema languages to
>     create an HTML5 conformance checker."

Looks ok.

> Let's try with a concrete example: q element for quotes.
>     The q element represents a part of a paragraph quoted
>     from another source.
> Does that mean q is contained in a paragraph (address, aside, navm  
> footer, li, dd, figure, and p.)?

That's depends on whether the q is a descendant of at address, aside,  
navm footer, li, dd, figure, or p.

> Does that mean that the content of q element is a part of a paragraph?


> If it's the former, it means div > q fails.

div > p depends on the document tree regardless of conformance.

More to the point, any definitional problem here arises from <div>-- 
not <q>.

>      If the cite attribute is present, it must be a URI
>     (or IRI).
> checkable. It means that the HTML5 conformance has to check that is  
> it a valid URI or IRI


As a side note: For extra usefulness, a checker can have knowledge  
about particular URI scheme-specific requirements. Different choices  
here cause a theoretical problem. If we want to remove the  
theoretical problem, the spec could enumerate a closed list of URI  
schemes that conformance checkers must know about. (Forbidding the  
application of knowledge about common schemes like http, https and  
mailto would be silly.)

> Here it is tricky. the association of
>     <p><q cite="urn:isbn:2-07010-579-2">Plus vague et
>        plus soluble dans l'air,</q>
>        est un vers de l'<cite>Art Poétique,
>        Œuvres poétiques complètes, Paul
>        Verlaine.</cite></p>
> Here a tool can extract
>     "Plus vague et soluble dans l'air,"
>     Art poétique, Œuvres poétiques complètes, Paul Verlaine
>     urn:isbn:2-07010-579-2
> I can have a process which uses only machines and tries to match  
> the isbn and the title and/or the author. It will be only done by  
> machine. Using for example services like http:// 
> Even easier in the  
> case of HTTP URIs. All of that can be done by machine only.

A machine-checkable criterion should probably be defined to be a  
criterion the conformance to which is a decidable problem (in the  
computer science sense) given a document (Content-Type and finite  
byte stream) and the knowledge embodied in the spec and the normative  

That is, the program computing whether a given document conforms to a  
criterion should not be required to consult outside resources and  
should not embody arbitrary knowledge that isn't part of the spec  
(with normative references).

>>>          Conformance checkers must check that the input
>>>         document conforms when scripting is disabled, and
>>>         should also check that the input document conforms
>>>         when scripting is enabled. (This is only a "SHOULD"
>>>         and not a "MUST" requirement because it has been
>>>         proven to be impossible. [HALTINGPROBLEM])
>>> Is the intented purpose of this is to define two levels of  
>>> Conformance?
>> What would the other level of conformance be? If it involves  
>> executing scripts, would it be OK for conformance to the other  
>> level to be undecidable be machine in a general case?
> # must and should
> * Conformance checkers must check all the must and should.
> * Conformance checkers must check all the must only.

IIRC, there were one or two SHOULDs applying to do documents that  
could use guidance on what conformance checkers are to do. I can't  
remember what those were, but I'm pretty sure I have notified Hixie.

> If the script is not executed and because it is a should,

That's a SHOULD applying to the checker itself--not to the document.

> the Conformance checker silently ignores it and says conforms?


> Then *another* conformance checker (more performant) had success  
> running scripts and sees that the document does not conform, what  
> does it say?

It has been proven (in 1937) that such a conformance checker cannot  
exist for the general case.

A checker that runs scripts with some implementation-specific  
limitations but that doesn't cover the general case could be useful  

> Once the document is conformant and once it is not.

Yes. With scripts, document conformance is possible to check only for  
a given snapshot in time. Obviously, the result can be different with  
different snapshots.

It is impossible to check (in the general case) that a document with  
a script executing on it keeps conforming from t_0 to t_infinity.

>> A snapshot of the DOM in a browser at a user-chosen point in time  
>> could be checked for conformance, though. This would, again, not  
>> involve executing scripts during the conformance checking process.
> user-chosen point in time? No human interaction, we said above.

Well, someone or something has to choose the input document the  
conformance checking process. That is, a user invokes a conformance  
checker: "check the document (bytes) at this URI" or "check the  
document (DOM) currently loaded in this browser window".

Henri Sivonen

Received on Thursday, 14 June 2007 07:39:52 UTC