W3C home > Mailing lists > Public > public-html@w3.org > November 2008

Re: Should we Publish a Language Specification?

From: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 20 Nov 2008 02:03:46 -0800
To: Julian Reschke <julian.reschke@gmx.de>
Cc: "public-html@w3.org" <public-html@w3.org>
Message-id: <4ECAFA61-8119-47DA-8637-FE51B6B22B07@apple.com>

On Nov 19, 2008, at 6:18 PM, Julian Reschke wrote:

> Maciej Stachowiak wrote:
>> 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?
> It may be important for the others as well.

Are you aware of any practical problems, complaints from implementors,  
or complaints from authors as a result of the way those other specs  
include all the relevant information in one document? I am not. Thus I  
presume there is no real problem other than a desire for theoretical  
purity, unless it can be shown that HTML is materially different from  
these other languages in some relevant way.

>> 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.
> Yes, that's why the syntax should be defined in a single spec.

Great. We already have one. Let's not make a second one.

>> 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.
> Total disagreement. The elements you mention may be important for  
> the browser platform, but are totally meaningless for HTML5 as a  
> document markup language. Thus they should be defined in optional  
> modules.

You don't want "the language spec" to actually define the whole  
vocabulary of language? Why don't we just title it "The Parts of HTML5  
That Julian Reschke Likes".

>> 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'm making recommendations for the specs the WG I'm member of works  
> on. That doesn't mean that I wouldn't make the same recommendations  
> if I'd by in one of the WGs that produce these specs.

In each case the responsible working groups accept public comments  
from non-members, much as the HTML WG has accepted many comments from  
non-members on this issue.

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

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:39 UTC