W3C home > Mailing lists > Public > public-html@w3.org > July 2007

Re: Validity & Must Not/Should Not/May Not

From: Robert Burns <rob@robburns.com>
Date: Sun, 15 Jul 2007 16:21:24 -0500
Message-Id: <BE220C99-E117-493F-9FC8-0525AEE43276@robburns.com>
Cc: HTML WG <public-html@w3.org>
To: Smylers <Smylers@stripey.com>


On Jul 15, 2007, at 2:53 PM, Smylers wrote:

>
> Robert Burns writes:
>
>> On Jul 13, 2007, at 2:18 PM, Smylers wrote:
>>
>>> Robert Burns writes
>>>
>>>> However even it ifs invalid it can still be may not/ should not /
>>>> must not.
>>
>>> Oh, I had't thought of that, sorry.  What things are we classifying
>>> as invalid yet still only telling authors that they "may not" or
>>> "should not", rather than "must not"?
>
> Sorry to repeat the question, but I'm still struggling with this and
> think it would be clearer with an example.  Please can you give an
> example of something which would be invalid yet not a "must not" item.

I answered that question. HTML5 is moving away from simple  
validation. Its not about just letting an author know what violated  
the must not and what hasn't fulfilled the must. It should be about  
all of the conformance criteria. Why take the time to write other  
conformance criteria if we don't want he conformance checker to let  
the author know.

>>> What do those states represent?
>>
>> I'm suggesting its not as simple as saying something is valid or
>> invalid. We have a much bigger toolbox than that and we should make
>> use of it. Let's not always use the hammer. In other words, we do not
>> have to insist that conformance checkers flag [whatever] as invalid.
>> We can ask the question, how  should the conformance checker respond
>> ...? It can tell the author there is an error (i.e., "must  not"...).
>> The conformance checker could issue a warning (i.e., should not). Or
>> there could be some sort of comment ("may") ...
>
> If the spec has a list of things that an author must not do then  
> surely
> it's invalid for an author to do any of those things?  And that the
> point of a conformance checker is to check that the author conforms  
> with
> the requirements, to fail a document that does invalid things?
>
> Or, to put it the other way round, if something is only a "should not"
> then it's permitted to do it, so how can it be invalid?

Forget about valid and invalid. A decent conformance checker should  
let an author know about any conformance issue: whether its a must,  
should, may, may not, should not , or must not. Leaving out  
everything but must and must not says to me this is an inadequate  
conformance checker. Notice this can all be discussed without the  
words valid and invalid which turn a rich conformance specification  
into a false binary.

>> Its a lot to keep track of all of the options for conformance  
>> criteria
>> (must not, should not, may not, may, should, must) and the different
>> conformance audiences such as authors, and all sorts of UAs, general
>> UAs, authoring UAs,  conformance checking UAs, conversion UAs,  
>> visual,
>> aural, tactile, etc.  However, these options  also  provide us   
>> with a
>> lot of fine-grained control over our  recommendations. We should make
>> use of that power.
>
> Yes.  Though I suspect that in many situations it isn't necessary to
> consider so many categories of user-agents:

In many situations yes: all the categories will share the same  
conformance criteria. However, there is all sorts of room to address  
conformance criteria for a diverse array of UAs.

> * Programs that generate HTML are bound by the author requirements for
>   HTML they generate.  That applies whether the content is being
>   provided by a human or a document in some other format is being
>   converted.

Yes, but that still leaves room for variation. It may be a good idea  
for our recommendations to address that wiggle room: to tell  
converters (for just one example), how they may (or should or must)  
convert implied elements from text/html to xml.

> * Conformance checkers are checking that HTML meets the authoring
>   requirements, so obviously that's what they need to implement.

No, conformance checkers are not  checking just authoring  
requirements.  They are checking authoring conformance (i.e.,  
document conformance). So in that sense we want conformance checkers  
to check whether the document meets the requirement of HTML5 and also  
how the document does on the HTML5 <em>document recommendations</em>  
and <em>document options</em>. Its not just about validation anymore.

Take care,
Rob
Received on Sunday, 15 July 2007 21:21:35 GMT

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