Re: Splitting up the spec

Toby A Inkster wrote:

> A better analogy might be taking a "rulebook for using the English
> language" and splitting it up into separate books - the first
> providing just the vocabulary; the next explaining how grammar and
> punctuation work; another dealing with pronunciation; and another
> teaching essay writing.

That's an interesting thought experiment, because I think it has some of 
the same issues as we face here.  What is the dictionary definition of 
the words 'a' and 'the' and how are they to be defined without defining 
the grammar?  (Here I assume the "vocabulary" section will in fact 
include definitions rather than just being list of words.) Should the 
vocabulary section list parts of speech next to the word, and if so how 
is that done without reference to grammar?  If it won't list the part of 
speech, how will "lead (n)" and "lead (v)" be presented?

The fact is that while vocabulary and grammar seem orthogonal, in 
practice we have specialized vocabulary that only exists to influence 
the grammar in English.  Some other languages have a lot more of this, 
by the way.

Heck, consider the grammatical construction "would have been writing". 
Please describe to me the vocabulary sections for "would", "have", and 
"been"?

I should further note that in practice when learning a language one 
doesn't learn it by learning the vocabulary, then the grammar, etc.  One 
learns by an accretion process where one learns some basic vocabulary, 
then some basic grammar that can handle that vocabulary, and then keep 
layering like that, learning grammar and vocabulary in parallel.  This 
has more to do with the way languages work, in my opinion, than with the 
way human learning necessarily works.


> It's not a matter of separating out what's common and what's not
> common. It's a matter of separating out the markup language (HTML),
> its API (DOM) and scripting environment features (SQL, storage,
> history, etc).

How do you explain the meaning of parts of the markup language whose
only purpose is to affect the DOM in that setup?  Heck, how do you 
explain the meaning of parts of the markup language whose only purpose 
is to affect navigation (say the "autocomplete" attribute of <input>).

> Something like Javascript-accessible SQL has nothing to do with the 
> HTML5 markup language per se

I think everyone agrees that the SQL stuff needs to be split out at some 
point.  I challenge you to point to someone who argues against that. 
The bone of contention is element definitions, element DOM APIs 
(arguably an integral part of element definitions, though apparently not 
to you), and things like the Window and Document objects.

-Boris

Received on Monday, 24 November 2008 15:16:07 UTC