Re: Should we Publish a Language Specification?

On Nov 19, 2008, at 9:42 AM, Julian Reschke wrote:

>
> Maciej Stachowiak wrote:
>> I think it would be pretty bad to have multiple normative specs for  
>> the syntax of HTML. I would be strongly opposed to publishing  
>> Mike's document as Working Draft or later unless its status is  
>> changed to informative. Already it is out of sync with the main  
>> HTML5 spec on such basic things as the set of elements in the  
>> language.
>> ...
>
> I agree that the language HTML5 should have a singular normative  
> definition. I'd prefer it not to be the same document that describes  
> all the rest.

1) Why is this important for HTML, but not for SVG or MathML or XForms  
or SMIL, where one document defines what you consider "the language"  
as well as "all the rest"? Why is this the only W3C language where  
implementation conformance requirements, DOM interfaces and error  
handling should be left out of the main spec?

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 would be  
disastrous if conformance checkers flagged errors in a manner that is  
inconsistent with Mike's document. It would be similarly disastrous if  
user agents parsed content in a way that had unexpected results for  
correct syntax. Both of these things are very hard to verify with a  
separate spec and would create serious problems if the specs disagree.

3) Mike's document seems to have the implied premise that content  
producers, unlike consumers, won't be interested in the 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. So it seems to me it is  
not even very useful as an authoring guide.

Therefore I am strongly in favor of following the standard W3C  
approach, with a single spec that defines syntax, vocabulary, DOM  
interfaces and error handling. I strongly object to doing otherwise  
solely because of some vocal complainers who cannot articulate a  
principled reason why they demand this for the HTML spec but not any  
other W3C markup language.

I do agree that many scripting interfaces in the current HTML5 spec  
are not HTML-specific and it would in theory be beneficial to break  
them out. But trying to split the core parts of the spec courts  
disaster.

Regards,
Maciej

Received on Thursday, 20 November 2008 01:45:57 UTC