Re: algorithmic normative conformance requirements, design principles, etc.

On Mon, 25 May 2009, Larry Masinter wrote:
>
> Missing design principle: avoid MUST conformance requirements unless it 
> is necessary for interoperability.
>
> Missing editorial policy: all technical terms must be defined precisely.

I agree with these two concepts, but I'm not sure I'd characterise them as 
design principles or editorial policies, so much as basic specification 
writing skills that apply to any technical specification.


> Missing design principle: the temporal relationship between states must 
> either be defined precisely or made explicitly flexible.

I don't understand what this means.


> Because conformance requirements are given in terms of algorithms, 
> otherwise reasonable implementations of the semantics are disallowed, 
> even when they would be compliant with conformance requirements stated 
> in semantic rather than algorithmic terms.

If the conformance requirements would be different by rephrasing them from 
"algorithmic" to "semantic", then the change would be more than just a 
rephrasing. Thus the proposal would be more than just an editorial 
request. If there are indeed cases where you think that the requirements 
should be different, then please raise them in Bugzilla. This is 
independent of how the requirements are phrased, though.


> I'll pick on a single issue, image width and height.
> 
> You might claim that this is a single issue and "please fill out a bug 
> report in the bugzilla database", but I claim that this issue is 
> endemic, that the instances of it are numerous, and it results from 
> choosing an editorial style of specifying conformance by giving 
> algorithms which MUST be followed.  In fact, it's hard to find a part of 
> the specification which doesn't have this problem somewhere.

Please do list them, so I can fix them.


> My question was whether image width and image height MUST simultaneously 
> be known -- whether a script can assume, that if image.width is non-zero 
> that the height also must be non-zero, or whether height could be zero 
> at one point in time and later be non-zero, asynchronously.

They must both be known simultaneously, yes. I've tried to clarify this.


> There is an algorithmic definition of how to compute the DOM attributes 
> width and height, as part of a conformance requirement.  Although the 
> conformance requirement is written in prose, it's really a little 
> program, so I will indent it:
> 
> "The DOM attributes width and height 
>   MUST return 
>    the rendered width and height of the image, in CSS pixels, 
>    if the image is being rendered,
>             and is being rendered to a visual medium; 
> 
> or else
>    the intrinsic width and height of the image, in CSS pixels, 
>   if the image is available 
>                   but not being rendered to a visual medium; 
> 
> or else 0, 
>    if the image is not available or its dimensions
>    are not known."
> 
> The word "must" is used, so I presume that this is a normative 
> requirement. I interpret -- is there any other interpretation of this? 
> -- that any implementation must have a binary state for an image, 
> 'available?' and an image at any point in time is either 'available' or 
> 'not available'.

Correct.


> There is no provision in this algorithm for an image which is partly 
> available and partly not available.

Correct.


> However, the definition of "available" does seem to allow for partial 
> download:
> 
>   If the image was successfully obtained, with no network
>   errors, and the image's type is a supported image type,
>   and the image is a valid image of that type, then the
>   image is said to be available. If this is true before the
>   image is completely downloaded, each task that is queued
>   by the networking task source while the image is being
>   fetched must update the presentation of the image
>   appropriately.

Correct; 'available' is a binary state and is not predicated on the full 
image being downloaded yet. (Indeed some images are infinite and can never 
be completely downloaded, e.g. streaming JPEGs.)


> This is the closest I can find to the definition of "available" -- is it 
> defined more formally elsewhere?

No; what is missing in this definition that you would like made more 
formal?


> So I *think* that a conforming implementation MUST use, for deciding 
> whether or not "width" and "height" are known and thus non-zero, this 
> single state. I think it is not allowed -- by these conformance 
> requirements -- to have "width" known and "height" not known.

Correct.


> This seems to be an unfortunate tradeoff of precision -- defining 
> behavior precisely -- over extensibility and what is usually an 
> important design goal of most standards: only require MUST, only make 
> conformance requirements, for those requirements that are needed for 
> interoperability, for things to work together correctly.

It is necessary for the DOM to behave predictably and identically in all 
user agents if we are to have a coherent application development platform.


> Perhaps none of the current implementations of WebKit, Mozilla, Opera 
> and IE implement anything other than this algorithm, though? Maybe they 
> all have implemented "width" and "height" according to the algorithm 
> given.

As far as I am aware, this is the case.


> But is this the *right* requirement?

Right in what sense? It is the way things are.


> Does the current specification development method, in which requirements 
> are vetted by checking them against three or four implementations, bring 
> sufficient review of whether the normative requirements are TOO 
> stringent?

I try my best to avoid making requirements that are too stringent, but I'm 
sure I make mistakes. Please raise bugs if you find any.


> I think writers of Javascript programs should NOT assume that if 
> image.height is non-zero, that image.width is subsequently non-zero

Whether they _should_ or not is somewhat academic; they do.


> and the spec should NOT require simultaneous availability of these 
> values.

I disagree.


> Doing so is unnecessary, and precludes otherwise legitimate 
> implementations.

I disagree.


> There is another design principle, widely used, which seems to have been 
> not followed: standards should only REQUIRE (only MUST) behavior with 
> sufficient precision to support reasonable interoperability.

Making sure that DOM APIs return consistent state is required to support 
reasonable interoperability.


> The current HTML 5 document goes MUCH TOO FAR to "nail down" behavior 
> (including "error" behavior)--

I disagree.


> to the point where it stifles any future innovation in implementation 
> methods -- reify a processing model which is inappropriate for many 
> otherwise legitimate contexts.

Could you elaborate on this? Examples would be good. If there are specific 
cases that should be made more flexible without sacrificing the need for 
interoperability, I definitely want to make them so.


> This difficulty is a direct result of the attempt to specify the 
> conformance requirements of a "Language" in algorithmic terms.

There is no such attempt; in fact quite the contrary. I try to define 
everything in semantic (declarative) terms, and only fall back on 
algorithms where this makes the requirements easier to understand. The 
unfortunate state of affairs is that the Web's requirements are often far 
too complex to describe in a non-algorithmic fashion.


> Alas, while "precise" has been a goal, the definition of terms is, in 
> fact, not "precise" in many instances.  To take the case here, I asked 
> about the definition of "available", and asked
> 
> > If I know the image width and height, but not whether it is of a 
> > supported type, is it "available"?
> 
> and the reply was:
> 
> > How can you know the dimensions if you don't support it?
> 
> If the term "supported" is defined somewhere, I can't find
> the definition--

I've now added a definition of the word "supported" to the terminology 
section. It had not occurred to me that its meaning was unclear.


> (the document's liberal use of terms without formal definition in formal 
> conformance requirements is itself an problem)--

If you have other examples of this please let me know so I can fix them.


> but the usage seems to indicate that the decision of whether a 
> particular image is "supported" depends only on the image "type", and 
> the examples given of "supported types" doesn't seem to allow for some 
> image types (image/png, image/tiff, image/jpeg) to have profiles or 
> options.

I've attempted to fix this; please let me know if the new text is clearer 
on this front.


> In general, by specifying things in terms of algorithms for 
> implementation, the functional specification tends to require a temporal 
> relationship between factors that are not temporally aligned. So in one 
> place "available" and "supported" are assumed to be static, binary 
> values, but at least in the sense of "available" there is some allusion 
> to the temporal nature of the process, that downloads can be partial and 
> additional information available asynchronously.

This is very much a dynamic state of affairs, yes. I have attempted to use 
phraseology that doesn't imply static behaviour; please let me know if I 
have failed in this in any specific sentences.

HTH,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 25 May 2009 23:18:30 UTC