Re: Language specification vs. user agent specification

On May 24, 2009, at 1:26 PM, Larry Masinter wrote:

> In the discussion around the document title (and process issues
> around that), there is at least some actual technical content.
>
> (1) "traditional language"
>
> In reply to my suggestion:
>>> It might be possible to create a more traditional language  
>>> definition
>>> using the bulk of the material, but expressed in less operational  
>>> terms.
>
> Ian asked:
>> What do you mean by "a more traditional language definition" and  
>> why would
>> this be desireable?
>
> I think it is traditional to define a language and its semantics
> first -- what does an utterance in the language *mean* and separately
> and independently (even if the same document) define conformance
> requirements for processors of that language. The current document
> frequently does not do that, but defines the processing requirements
> and then infers the language semantics from that.

If there is indeed such a tradition, it seems that it is rarely  
respected. Here are some examples of language specifications that  
clearly state conformance requirements for processors of the language  
before or mixed up with any definition of semantics, or in some cases  
do not explain the semantics at all other than as informal operational  
semantics:

SVG Tiny 1.2: http://www.w3.org/TR/SVGTiny12/
ECMAScript 3ed: http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf
C99: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf
XForms 1.1: http://www.w3.org/TR/xforms11/
Java, third edition: http://java.sun.com/docs/books/jls/third_edition/html/j3TOC.html

The only example of a language spec I can think of that follows the  
tradition you named is HTML 4.01, and it does so largely by omitting  
most of the conformance requirements for processors.

Besides defining a language, HTML5 defines APIs. For APIs, it is  
nearly universal to define APIs by what they do (i.e. the requirements  
on the implementation) and what constraints there are on calling them  
(requirements on what clients of the API), rather than abstract  
semantics.

> I think this is why there are persistent discussions of it as a  
> "browser spec"
> despite the attempts to define other conformance requirements.
>
> Defining things as language-first is more useful and easier
> to read than the current editorial style, especially for end-users
> and authors of HTML documents, whose priority over implementers is
> a stated design goal. Further, it allows clearer evaluation of
> whether the design "goes too far" in locking down implementation
> behavior unnecessarily, because, even though testable, in practice
> the implementation conformance requirement is unnecessary.

Implementors have many times suggested various HTML5 conformance  
requirements as unnecessary and overly constraining of the  
implementation (myself included).

> I took as an example (randomly selected) image.width and image.height
> defined in terms an algorithm for determining them based on whether
> the image was "available", and that "available" wasn't well defined,
> and that I would have to guess whether an image defined with "data:"
> was or wasn't available.

image.width and image.height are APIs, so it's traditional to define  
them in operational terms.

I think you have what may be a valid technical objection to the  
specific definition of image.width and image.height, I will comment on  
that in a separate email if that seems appropriate after reviewing it.

Regards,
Maciej

Received on Sunday, 24 May 2009 23:55:18 UTC