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 17:35:51 -0500
Message-Id: <9FC9A54A-70AD-4E6D-B1DD-2BFFD6AA5992@robburns.com>
Cc: HTML WG <public-html@w3.org>
To: Smylers <Smylers@stripey.com>


On Jul 15, 2007, at 4:58 PM, Smylers wrote:

>
> Robert Burns writes:
>
>> 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.
>
> Thanks.  But I'd still appreciate an example of an element/attribute/
> whatever which could meet your definition of being invalid but not a
> "must not".

I could provide an example like that, but its not relevant so let's  
pretend I can't. Its more important for you to realize that the more  
important issue is that we need to use the full vocabulary available  
to us as the writers of this recommendation. That involves  
requirements, <em>and</em>  recommendations, <em>and</em> options.  
And we have those for both document conformance and UA conformance.

>> HTML5 is moving away from simple validation.
>
> Why?

I don't know all of the reasons, but I suspect it is partially  
because the spec is not written in terms of just requirements and  
prohibitions. There is more to conformance than that.  To tell  
authors only whether a document is valid or not keeps other  
information for authors about the document and its relation to the  
recommendation.

> For previous versions of HTML the W3C has provided a validator which
> gives a 'yes' or 'no' answer -- and in the case of 'yes' provides a  
> logo
> authors may display to indicate that their HTML is valid.  Are you
> saying that this will not be the case with HTML5?

Someone could produce that (including the W3C). However, I believe  
members of the WG are already working on richer conformance checkers.

> Na´vely I would have thought it very important to authors that they be
> able to tell whether their documents meet the spec.

Flagging only prohibitions and requirements only does that partially.

>> 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.
>
> Sure.  But if we have optional criteria, or criteria that we would  
> only
> like authors to respect but which we concede they don't absolutely  
> have
> to, then a document which doesn't meet those criteria still  
> conforms to
> our specification.

Yes. But again that's back to the false binary: conformance / non- 
conformance or validity / invalidity. We can and should provide  
authors with more information about a document's relation to the  
spec. Also we should be aware as we craft this recommendation that we  
have these options. For example, using the <img>fallback</img> idea  
that spawned this discussion, we could say "Authors should ensure  
<img> elements are empty when using a xml serialization and must  
ensure <img> elements are empty in the text/html serialization of  
HTML5." If we did this, an <img> elment in an xml serialized HTML5  
document could have contents and be a conforming document. Ideally,  
the conformance checker would let the author know that they were  
doing something they should not do.

>> Forget about valid and invalid.
>
> "Valid" or "invalid" are the output states of a validator.  Authors  
> will
> continue to use those terms.

However, we're moving to conformance checker. We may still use those  
terms there, but the output state (even in todays validators) is much  
richer than simply 0 or 1.

> It's also a term you used in the sentence I've been struggling with:
>
>   However even it ifs invalid it can still be may not/should not/must
>   not.
>

I'm not sure what you're asking here.

Take care,
Rob
Received on Sunday, 15 July 2007 22:36:09 GMT

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