Re: After 5

2014-09-22 1:04, Sam Ruby wrote:
> On 09/21/2014 05:19 PM, Jukka K. Korpela wrote:
>> 2014-09-21 23:15, Sam Ruby wrote:
>>> I don't know what the "right" size is for a specification; but I'm
>>>  pretty sure it isn't the transitive closure of all of the
>>> normative references to the HTML5 specification.
>>
>> I don’t think anyone suggested making HTML5, or any specification,
>> the transitive closure of its normative references. So this looks
>> like a strawman argument, against something.
>
> It wasn't meant to be a strawman, but you have elided the context in
> which it was stated.  Restoring that context:
>
>> If there is a single spec, let it be 1,000 or 2,000 pages, you can
>> check any single thing there and get the ultimate answer.
>
> My claim is that the above is not correct in the general sense in the
> presence of strong normative references.
>

It is correct when we imply what we normally need to imply when talking 
about specifications. When reading specifications like HTML specs, you 
need to know the BNF syntax if formalized syntax is relevant to your 
purposes; you need to know XML if you intend to understand things based 
on XML; you need to know some English when reading specs written in 
English; and so on. And to the extend you don’t, you are expected to 
learn them from *their* specs or from tutorials.

Citing such specifications does not prevent a spec from being 
self-contained in a reasonable sense. It is *very* different from 
normatively citing a dozen other CSS specifications in a spec that 
defines a CSS “module”. Even more different from *not* citing other HTML 
extension specifications in an HTML extension specification, even though 
those other extensions may override or modify the rules presented.

The main problem with defining HTML in a reasonably self-contained (or 
“monolithic”, as some people would say) spec is with DOM specs. The 
various HTML5 drafts have a considerable amount of DOM stuff defined in 
them (as opposite to all previous versions of HTML, which were 
effectively DOM-ignorant), but it’s far from systematic. Some 
definitions are presented in great detail, whereas many other things are 
left up to normative references to other documents that are 
work-in-progress (working drafts or editor’s drafts). Now that the DOM 
is being defined in a reasonably self-contained document, it seems that 
there is a good basis for a single basic HTML specification, even though 
it will then imply that the reader knows the DOM spec.

Future development of HTML could then either define extensions to HTML, 
to be registered with a statement on their scope and purpose and with 
mutual conflicts kept track of, or modify (usually extend or clarify) 
the basic HTML specification. Then anyone could still check the single 
spec to see what’s in HTML; anything beyond it would be flagged as an 
extension to HTML (preferably named in a way that lets extensions to be 
conveniently referred to) or would constitute a proposal or draft.

I would expect most extensions to HTML then either remain in 
limited-scope use or simply fade away as they have been found wanting 
and either an idea was abandoned or replaced by an essentially different 
approach. But some of them would become widely used and supported and 
should then be incorporated into  “the” HTML specification at some point.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

Received on Monday, 22 September 2014 04:37:59 UTC