This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
When discussing float, double, and decimal, the Datatypes spec uses the term 'NaN' to denote the appropriately typed value notANumber. The descriptions of that usage for float and double, however, seem to misuse the term 'lexical mapping'; this should be corrected. Section 3.3.5.1 has Note: As explained below, the lexical mapping of the float value notANumber is 'NaN'. Accordingly, in English text we generally use 'NaN' to refer to that value. Section 3.3.6.1 similarly has Note: As explained below, the lexical mapping of the double value notANumber is 'NaN'. Accordingly, in English text we generally use 'NaN' to refer to that value. The lexical mapping of a type is a function from the lexical space to the value space; that term makes no sense in the sentences just given. What is meant is the pre-image of notANumber. Section 3.3.4.1 on decimal has a better wording: Note: As explained below, the lexical representation of the precisionDecimal value object whose numericalValue is notANumber is 'NaN'. Accordingly, in English text we use 'NaN' to refer to that value. Proposal: the editors should be instructed to align the sections on float and double with that on decimal, in this regard.
(In reply to comment #0) > Section 3.3.5.1 has > > Note: As explained below, the lexical mapping of the float > value notANumber is 'NaN'. Accordingly, in English text we > generally use 'NaN' to refer to that value. > The lexical mapping of a type is a function from the lexical > space to the value space; that term makes no sense in the > sentences just given. What is meant is the pre-image of > notANumber. Since the special value notANumber is in the value space of float and decimal, 'NaN' is in the lexical space, and the lexical mapping is a function which, among other things, maps 'NaN' to notANumber, I'd say the Note is correct as stated. > Section 3.3.4.1 on decimal has a better wording: > > Note: As explained below, the lexical representation of the > precisionDecimal value object whose numericalValue is > notANumber is 'NaN'. Accordingly, in English text we use > 'NaN' to refer to that value. In the case of precisionDecimal, the values in the value space are three-tuples with named coordinates; one of the coordinates is named "numericalValue". When the numericalValue coordinate has the value notANumber, the arithmeticPrecision and sign coordinates must both have the value absent. So the lexical mapping maps 'NaN' to that three-tuple. In the case of float and double, the constant is the value, rather than being one coordinate of a three-tuple value. In all three cases, the lexical mapping maps 'NaN' to the corresponding value in the value space.
(In reply to comment #1) > Since the special value notANumber is in the value space of float and decimal, Oops! For "float and decimal", read "float and double", of course.
(In reply to comment #0) > When discussing float, double, and decimal, the Datatypes spec > uses the term 'NaN' to denote the appropriately typed value > notANumber. The descriptions of that usage for float and double, > however, seem to misuse the term 'lexical mapping'; this should > be corrected. > > Section 3.3.5.1 has > > Note: As explained below, the lexical mapping of the float > value notANumber is 'NaN'. Accordingly, in English text we > generally use 'NaN' to refer to that value. Upon rereading, I believe I now understand what your complaint is. I believe the correct fix is to substitute 'lexical representation' for 'lexical mapping'. The original is arguably correct, but the fix is much easier to read correctly.
Approved by the WG; awaiting incorporation into the status quo document.
(removed the keyword "unclassified")
The change proposed above was approved by the WG in its call of 1 December 2006. It is now reflected in the status quo version of the Datatypes spec. Accordingly, I am setting the disposition of this issue to RESOLVED / FIXED. If the originator of the issue would examine the change and let us know whether it satisfactorily resolves the problem or not, we'd be grateful. To signal that the resolution is acceptable, change the status of the issue to CLOSED. Otherwise, to signal that it's NOT acceptable, change the status to REOPENED (and tell us what's wrong). If we don't hear from you in the next three weeks, we'll assume that silence betokens consent, and close the issue ourselves.