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 wid...@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
