- From: Marcos Caceres <marcosc@opera.com>
- Date: Wed, 03 Feb 2010 10:12:09 +0100
- To: Doug Schepers <schepers@w3.org>
- CC: public-webapps <public-webapps@w3.org>
Hi Doug, Doug Schepers wrote: > Hi, Marcos- > > Marcos Caceres wrote (on 2/2/10 7:29 AM): >> >> I had a discussion with an implementer who was a bit confused about the >> concept of "null" in the specification. The problem is that I kinda >> wrote the spec as if it was to be implemented in Java or JavaScript. >> This has resulted in confusion wrt how "null" is to be interpreted in >> languages that don't have that concept/data type. >> >> So, in an effort to clarify that, I've added the following to Processing >> Rules section of P&C: >> >> [[ >> In the following algorithms, the concept of null is used as a special >> symbol to indicate that a variable has no data associated with it. For >> example, "let x be null" or "if y is empty, then return null". >> >> Note: Although ECMAScript and Java support null as a native value type, >> there are some programming languages that have no notion of null or >> where null is problematic (e.g. C++). For those languages, it is OK for >> an implementation to substitute the null for some other value or symbol >> (or for nothing at all). For example, it is ok to have the value 0 >> represent null for the height of a widget as the height of a widget is >> defined as a non-negative integer greater than 0. In such a case, 0 >> would behave as if it is null. >> ]] > > It seems strange to me to use language like "OK" in a spec, since it > seems overly casual and definitely not normative; I suggest you replace > all instances of "OK" with "awesome". heh, don't tempt me:) I'm a big advocate of the clarity that comes with the use of colloquialisms. Clarity above all else - specially at the expense of fancy words, long sentences, and excessive jargon. That's not to say I'm a good writer, but I try my best. > Failing that, maybe wording like this might better capture the interop > aspects? We want all the C++ implementations to behave the same, even if > they are crippled by their language. :P (I used to be a C++ > programmer... I thought it did have a NULL, but I guess that's only for > pointers.) I honestly don't know; I'm just going on what this says: http://www2.research.att.com/~bs/bs_faq2.html#null > [[ > In the following algorithms, the concept of null is used as a special > symbol to indicate that a variable has no data associated with it. For > example, "let x be null" or "if y is empty, then return null". > > Note: Although languages such as ECMAScript and Java support null as a > native value type, there are some programming languages that have no > notion of null or where null is problematic (e.g. C++). Implementations > in these languages should substitute a language-specific value or symbol > which is functionally equivalent to null, or if no equivalent exists, to > have no value at all. For example, the value 0 may represent null for > the height of a widget, since the height of a widget is defined as a > non-negative integer greater than 0. In such a case, 0 should be treated > as if it were null. > ]] I included your text into the spec. > I'm not satisfied by that wording either, to be frank... I think it > needs to be precise about the value for each language that's affected. I > also think we need to make a distinction between the implementation > language and the content language... the content should not get a '0', > right? It should get 'null', I'd think. I know what you mean, and as you can understand, it's a little bit more complicated than that: null sometimes plays the role of a flag, as is the case with widget@width being null which would trigger the user agent to use a "lacuna" value defined else where [1]. What I mean to say is that in most cases, null could be substituted for the word "banana" and the behavior of the spec would not change. Anyway, I don't think I want to spent much time on this because I think with the above text serving as an explanation this should all be OK and awesome. The proof that people are able to correctly interpret the spec is evident by the growing number of implementations that are claiming conformance. Of course, we are putting trust in individual implementers submitting their own results - but we are hopeful that we (the WG) will be able to independently verify that implementations really do conform before progressing this document to PR. [1] http://berjon.com/blog/2009/12/xmlbp-no-lacunae-values.html
Received on Wednesday, 3 February 2010 09:12:44 UTC