Re: AuthConfReq: Presentational Markup

Hi Larry,

Your line of thinking is interesting. Some comments below:

On Mar 30, 2010, at 3:59 PM, Larry Masinter wrote:

> This is a little terse, so please don't take too much out
> of context, but I've been thinking about how to deal with some
> of the authoring/document conformance issues:
>
>
> What I'd suggest is a clearer separation of conformance
> classes, which seem to me to be mixed in this spec (and, for
> what it is worth, in other web specs too.)
>
> (a) document conformance: defining what is or isn't a "valid"  
> document,
>   with some features added, some features changed, some
>   "deprecated", and some "removed" compared to HTML4.
>
> (b) authoring conformance: defining expected, preferable, best  
> practices
>  for authoring tools or author behavior
>
> (c) validator conformance: defining expected, preferable, best  
> practices
>  for tools that might be used for evaluating (a)
>
> as well as being clearer about the distinction between:
>
> (d) document processor conformance: defining expected, preferable,  
> best
>   practices  for any component that reads, scans, interpreters  
> documents
>
> (e) user agent conformance: defining expected, preferable, best  
> practices
>  for document processors that are interacting with a user
>
> (f) browser conformance: defining expected, perferable, best practices
>  for user agents whose primary purpose is to browse the (primarily
>  HTTP-based) web.

The spec actually already defines a bunch of implementation  
conformance classes. However, rather than marking up conformance  
requirements or groups thereof to say what classes they apply to, it  
mostly leaves things to the definitions of the conformance classes. In  
particular, the conformance class definitions give exemptions from  
broad classes of requirements. See here:

<http://dev.w3.org/html5/spec/Overview.html#conformance-requirements>

I would be interested in your thoughts on ways to make this more crisp.

Specifically, the list there covers your classes (b), (c), (d), (e)  
and (f), although I think the spec a bit more fine-grained than that  
(scripting is an orthogonal dimension to your categories). There is  
also a class of conforming documents, though it is less visibly called  
out in the conformance section.

>
> Some opinions (to be turned into more concrete edits or bug
> reports, if anyone agrees with these):
>
> (a) I would argue against making any previously valid content invalid
> unless
> (1) it was never implemented as specified
> (2) there is demonstrable harm to others that making the feature
>  invalid will repair.
>
> For "interoperability", documents (a) need to be accepted by
> all document processors (d).  Conforming documents should be
> conservative (robustness principle) even though document processors
> are liberal.
>
> I would argue that presentational markup don't meet these criteria.



> (b) I think there should be few conformance requirements
> on authoring tools, with exceptions made when justified for
> general good of issues around security, privacy, internationalization,
> accessibility. There are such a wide variety of authoring and
> creation tools and content management system generation of HTML
> that "authoring" requirements that are generally applicable
> will be rare.

I believe this is already the case - most authoring tool requirements  
are implicit in requirements on documents. The key requirement for  
authoring tools is the sentence, "Authoring tools and markup  
generators must generate conforming documents."

> (c) I think way too much empahsis has been put on validators.
> There are many kinds of validation and tools and checkers that
> implement not only determining "valid" content as far as this
> specification, but also deal with legacy systems, text-only
> systems, screen readers, etc. and each delivery context probably
> requires a different validator. I'm not sure there should be
> any conformance requirements on validators per se -- they should
> most likely be requirements on (a).

I think the vast majority of requirements on conformance checkers (aka  
validators) are in fact implicit as conformance requirements on  
documents. The key requirement for conformance checkers is the  
sentence, "Conformance checkers must verify that a document conforms  
to the applicable conformance criteria described in this specification."

Conformance checkers are also subject to the parsing requirements that  
otherwise apply to your categories (d), (e) and (f).

As far as I can tell, there are only ten MUST-level requirements in  
the whole spec that are explicitly on conformance checkers, of which  
three are in the definition of the "conformance checker" conformance  
class.

>
> (d) I think far too many of the requirements currently actually
> only apply to (f) but the spec is written as if they apply to
> (d).

The spec's style is to just state requirements, and let the  
definitions of conformance classes control which applies to which  
class, except where it would be otherwise unclear. I am sure other  
approaches are possible, though I am not sure this way is entirely  
without precedent.

> I think way too many things that should be "best practices"
> and at best a MAY are instead couched as mandatory for (d).

I'm not sure couching "best practices" as a MAY is the best approach.  
For the category of "best practices" to make sense, it must be a  
subset of what documents MAY do. In the case of the implementation  
conformance classes, the spec often uses "are encouraged to" language  
to make strong suggestions that do not even rise to the level of SHOULD.

Incidentally and just to be clear, my intent is not to dismiss your  
analysis, but rather to help clarify how the spec currently structures  
conformance classes.

Regards,
Maciej