Re: Should we Publish a Language Specification?

Maciej Stachowiak <mjs@apple.com>, 2008-11-19 17:45 -0800:

>  2) Mike's document is explicitly only for producers. But a conformance 
>  checker is a content consumer. Currently the main HTML5 spec includes 
>  conformance requirements for conformance checkers. It can't do this without 
>  defining what is a document conformance error and which are mandatory for a 
>  conformance checker to diagnose.

It's conceivable that it (or another spec) could in fact define
requirements for conformance checkers while normatively
referencing another spec that normatively defines what a
conformant document is (and so what a document conformance error is).

>  3) Mike's document seems to have the implied premise that content producers, 
>  unlike consumers, won't be interested in the scripting interfaces.

It's certainly not meant to imply that. The only reason it
currently doesn't explicitly discuss scripting interfaces is
because it seems like they are completely orthogonal to what the
definition of what a conformant document instance is -- and
because it's not clear that it's necessary for content producers
to know anything about them at all in the case where their only
needs is to be able to check whether a particular document matches
the definition of what a conformant document is, or to know what
the rules are for putting a document together in such a way that
it matches the definition of what a conformant document is.

It also does not seem necessary for an implementor of an HTML5
conformance-checking tool to know anything about the associated
scripting interfaces, nor to have their applications do any kind
of conformance checking related to scripting interfaces.

>  But a 
>  large proportion of Web content, especially content on the most popular 
>  sites, includes some script, and correctness of that content depends on 
>  scripting behavior. Some elements, such as <canvas>, <event-source>, or to a 
>  lesser extend <video>, don't even make sense without their scripting 
>  interfaces.

It's clear that <canvas> isn't actually useful to anybody in
practice without some associated scripting. But among the needs
that someone writing a canvas application has is simply to know
things like what attributes <canvas> can and cannot have, and to
know, say, that the "hieght" attribute they tried to use on canvas
is not conformant, and the conformant way to write it is "height".

>  So it seems to me it is not even very useful as an authoring 
>  guide.

To be clear, it's not meant to be useful on its own as an
authoring guide. In the context we're discussing now, it's meant
just to be a definition of what the document-conformance rules
are, not a guide to how to best follow the rules. At the risk
of making a simple-minded analogy, I guess I could compare it to
the difference between the set of rules that are printed on the
inside cover of a board game, and third-party strategy guide that
tells you how to win the game.

The draft just attempts to be the most succinct possible
definition of what a conformant document is, along with defining
the semantics of each of the elements and attributes.

  --Mike

-- 
Michael(tm) Smith
http://people.w3.org/mike/

Received on Thursday, 20 November 2008 08:10:27 UTC