Re: Splitting up the spec

Ian Hickson wrote:

> So where would you put the requirements currently in the "4.4.10.1
> Creating an outline" section?

Personally, I don't think they belong as part of the spec at all.  
Don't get me wrong: it's a brilliant algorithm, and I've found it  
invaluable - far better than my own attempts before it was pointed  
out to me. But it doesn't need to be included in the spec. A separate  
W3C note would suffice; or possibly as an informative appendix to the  
HTML5 markup spec.

Here's my current thoughts on how I think the HTML5 spec should be  
split:

1. _HTML5 and DOM5_: Define the language syntax, the elements and  
their content models, the attributes, and the DOM (i.e. the  
"document" object in Javascript, but no other part of the document  
object). The parsing algorithm should be included. The outline  
algorithm could be an informative appendix or a separate note.  
Effectively chapters 1-3,8 of the current spec.

2. _Storage for Javascript_: the Storage interface, sessionStorage,  
localStorage, the storage event. Section 4.11.2 of the current spec,  
and some other parts of 4.11.1.

3. _SQL for Javascript_: database storage. This would include the  
scripting interface to the database, plus the minimal conforming  
subset of SQL. Section 4.11.2 of the current spec, and some other  
parts of 4.11.

4. _Server-Sent Events for Javascript_: Chapter 6 of the current spec.

5. _Offline Web Applications_: Section 4.7 of the current spec.

6. _HTML Link Vocabulary_: possibly not a spec, but a formal  
registry. This would start off as 4.12.3 of the current spec, but  
would probably expand.

7. _The HTML5 Browser_: this would normatively reference all of the  
above specifications, plus CSS 2.1, ECMAScript, XHR and Workers. Also  
a lot of the non-"document.*" Javascripty bits from the current HTML5  
spec should be included: Window, History, Location, UndoManager, the  
draggable stuff, the contentEditable stuff, etc. Same origin; content- 
type sniffing. Much of chapter 4 and all of chapter 5 from the  
current spec. Also, included should be instructions for how user- 
agents should interpret any obsolete elements which they may  
encounter - you know, the really horrible ones that we don't want to  
be part of the markup spec, but browsers must still know how to deal  
with: <xmp>, <font>, etc.

It has been mentioned by some people in this discussion that there is  
a lot of subtle interplay between these different parts, but actually  
I think that's even better justification for splitting them. It will  
allow us to see the ties between them because they will need to be  
made explicit by including normative references between the  
specifications.

Once we can see these dependencies we can look at them one by one,  
and decide how they should be resolved: by keeping the normative  
reference, or perhaps redefining something in a different way to  
avoid the dependency. An example might be that server-sent events  
rely on the <event-source/> element. When we saw that dependency  
between _Server-Sent Events for Javascript_ and _HTML5 and DOM5_ we  
might think: why is <event-source/> needed? Perhaps an event source  
could be established entirely via script?

> Splitting up the specs to help make progress faster, measured  
> either as
> reaching CR faster, decoupling dependencies that might reach REC  
> faster,
> getting specification text written faster, or, most importantly,  
> getting
> interoperable implementations faster, is interesting. IMHO,  
> splitting up
> the specs for no reason other than editorial preference is not

Splitting up the spec can serve several useful purposes:

A. It allows parts of the spec to be finalised before other parts. As  
I pointed out as an example before, a full and useful definition of  
SQL for Javascript is still a long way off. Splitting the spec would  
allow other important parts such as the markup language and DOM to  
enter the recommendation track without being held up by less complete  
parts.

B. It makes it easier for other markup languages to incorporate  
components. For example, MathML, XHTML2 or SVG might like to  
incorporate Javascript storage, or server-sent events; OpenDocument  
might use the link vocab. This is a lot more practical if they are  
their own separate components.

C. The aforementioned additional clarity regarding how the different  
parts are related.

D. Going forward, past 2022, allowing new versions of each component  
spec to be worked on independently. e.g. a _SQL for Javascript 2.0_  
spec (allowing, I don't know, transactions and triggers or something)  
could be developed without having to rethink everything else.

Splitting the spec up wouldn't need to lead to the components  
diverging. The same working group could continue to work on the  
collection.

People writing HTML5 browsers would still have a definitive spec to  
aim for: _The HTML5 Browser_.

-- 
Toby A Inkster
<mailto:mail@tobyinkster.co.uk>
<http://tobyinkster.co.uk>

Received on Saturday, 22 November 2008 00:33:39 UTC