Re: Should we Publish a Language Specification?

Ian Hickson wrote:
>> It makes sense for the *set* of specifications defining it to treat it 
>> as such. That doesn't imply it necessarily needs to be a single spec.
> 
> Then by the same argument, the argument you were making (that features 
> should be in or out based on whether they are part of a document mmarkup 
> language) similarly doesn't imply that the spec necessarily needs to be 
> more than a single spec.

Not sure what exact point you're trying to make.

Of course good structuring of a single spec can help as well, but I 
think the ability to progress several specs at different speeds, or to 
revise them independently, is something you won't get with a single 
document.

>>>> I think the state of the web really doesn't affect that distinction, 
>>>> and it's still a useful distinction to have.
>>> I disagree. Is the HTML5 spec a document or an application?
>> <http://www.w3.org/TR/2008/WD-html5-20080610/single-page/> appears to be 
>> a document to me.
> 
> And this is an application?:
> 
>    http://www.whatwg.org/specs/web-apps/current-work/

Assuming it contains scripts that are *needed* to use it: no.

If they are truly optional: perhaps.

>>> You didn't reply to my question. How do you draw the line between 
>>> "document" and "application"?
>> I've stated several times that I do agree that where to draw the line 
>> exactly is tricky, and that different people will have different 
>> preferences. That doesn't man that it doesn't make sense to draw the 
>> line somewhere.
>>
>> Without having thought about it a lot, I would expect a document not to 
>> require anything that wouldn't "work" when served from the local file 
>> system, with scripting in the UA being disabled.
> 
> "work" how, in a Web browser? Do you mean indistinguishable behavior when 
> compared to serving the same files to the same browser using http: with 
> scripting enabled instead of file: with scripting disabled?

Yes.

> So is your proposal that we have one specification A that defines features 
> that would work the same in a Web browser when served over file: with 
> scripting disabled as when served over http: with scripting enabled, and 
> one specification B for everything else? 

Potentially. At least that is a line that could be drawn that came to 
mind first.

> So for example would you want your A spec to include the definition of the 
> browsing context, and the navigation algorithm, and the bulk of the 
> parser, as well as the form controls, but your B spec to include the 
> Window object, small parts of the parser that change under scripting, the 
> DOM parts of elements, and form submission?

I'm not sure why A would need to define those (for instance, it would 
need to define just serializations that are valid, but not handling of 
invalid documents).

> ...

BR, Julian

Received on Monday, 24 November 2008 22:28:39 UTC