Re: Splitting up the spec

Toby A Inkster wrote:
>> 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?
> 
> I have never said that the parts may not normatively reference each other.

If they do this, it introduces a large amount of overhead into the 
mental model, significantly complicates the task of creating any 
implementation that has to deal with both parts, and significantly 
increases the risk of disagreements and things being underdefined.

Perhaps you view this as an acceptable, or even necessary cost, in view 
of some greater good that comes out of the split, but it's a cost that 
definitely needs to be kept in mind.

> Again these would be candidates for normative references between the 
> vocabulary and grammar.

And again, the number of "circular" normative references should be kept 
down to a minimum.  Heck, even the number of non-circular normative 
references should be as small as possible, for things to remain sane in 
terms of understanding how two specifications interact.

One approach to avoiding an explosion of integration points in this sort 
of situation is to develop the two specifications in lockstep, with 
minimal integration points provided, but that's not what some people in 
this thread are looking for (e.g. the ones who want to reuse arbitrary 
parts of the specification without reference to other parts for some 
other purpose).

>> I should further note that in practice when learning a language one 
>> doesn't learn it by learning the vocabulary, then the grammar, etc.
> 
> Indeed, but one learns a language from a tutorial-type book, not the 
> specification.

While true, one implements a system that "knows" a language from the 
specification.

> This goes for human languages as well as markup 
> languages, and programming languages too. You don't learn, say, C from 
> the EBNF syntax specification, but rather from a tutorial.

I would hope that a C compiler writer in fact learns C (the language the 
compiler must support, which is quite different from the language that 
any single person actually writes) from the EBNF.

>> How do you explain the meaning of parts of the markup language whose
>> only purpose is to affect the DOM in that setup?
> 
> I'm not so sure that there are any such parts.

The "target" attribute of <a> is only there to affect navigation.  The 
on* attributes are only present to trigger script execution.  The 
various attributes of <script> and <style> only exist to affect 
processing of the script or stylesheet.  The proposed <eventsource> 
element has no purpose other than to trigger DOM event dispatch.  The 
"reset" type of input and button has no purpose other than to trigger a 
certain operation on the page state.

That's off the top of my head and without thinking too hard.  An 
exhaustive list would be quiet a bit longer.  Note that with the 
exception of <eventsource> all of these are in HTML4.

> That autocomplete="off" indicates that an <input> element is either of a 
> particularly sensitive nature or is a value that is unlikely to ever be 
> reused. It indicates that the page author believes that the <input> 
> element cannot usefully be or should not be pre-filled by assistive 
> technology.

That presupposes existence of an assistive technology, and the 
editability of inputs, which is irrelevant to most conformance clases. 
There are many in this thread who would feel that such a definition 
would have no place in a "vocabulary" specification, and should instead 
be placed in a "processing" specification.

> I think in my last list of suggested splits I included the element and 
> attribute definitions, DOM and document object as all being included 
> within the HTML5 markup language specification.

OK.  That puts you a lot closer to my viewpoint than a number of other 
people in this thread are...

> but think that it should be structured so that each element is defined 
> without reference to the DOM, and the DOM is then defined in reference 
> to the element and its attributes.

I thought you advocated normative circular references between 
specifications.  Why not between sections?  In any case, I don't believe 
this is possible given the list of things above that are attributes or 
elements whose only purpose is to exert an influence on the DOM or on 
the navigation model.

I'm not saying this is a good thing, by the way.  Just that this is HTML 
as it's existed for almost 10 years now.

> This way, user agents that do not 
> build a DOM may still be able to implement some sort meaningful support 
> for the element.

I think that's possible as things stand.  Just ignore all the parts that 
talk about the DOM and the effect the element has on the DOM.

-Boris

Received on Monday, 24 November 2008 18:25:00 UTC