Subject: [vwrap] ECMA-262 and the Real LLSD type

From: "Hurliman, John" <[email-masked]>
Date: Thu, 6 May 2010 11:36:50 -0600

In draft-hamrick-llsd-00 "3.2. JSON Serialization" it states:

   Real  LLSD 'Real' values are represented by the JSON non-terminal 'number'.

Then later in "Appendix A. ABNF of Real Values" it lists a series of strings that can be converted into real values:

   negative-infinity =  %x2D.49.6E.66.69,6E.69.74.79   ; "-Infinity"
   negative-zero     =  %x2D.5A.65.72.6F               ; "-Zero"
   zero              =  %x30.2E.30                     ; "0.0"
   positive-zero     =  %x2B.5A.65.72.6F               ; "+Zero"
   positive-infinity =  %x2B.49.6E.66.69,6E.69.74.79   ; "+Infinity"
   signaling-nan       =  %4E.61.4E.53                   ; "NaNS"
   quiet-nan         =  %4E.61.4E.51                   ; "NaNQ"

Does this mean that an LLSD real type with a value of -Infinity needs to be converted to a JSON string, and would be decoded on the receiving side as an LLSD string with value "-Infinity" (that happens to have a valid conversion to an LLSD real)? ECMA-262 does not support Infinity, NaN, etc. for the JSON 'number' type so it looks like we need to transmit those values as strings.

John

---

From: Joshua Bell <[email-masked]>
Date: Thu, 6 May 2010 11:47:49 -0700

("from the floor")

On Thu, May 6, 2010 at 10:36 AM, Hurliman, John <[email-masked]>wrote:

> (snip)

> Does this mean that an LLSD real type with a value of -Infinity needs to be
> converted to a JSON string, and would be decoded on the receiving side as an
> LLSD string with value "-Infinity" (that happens to have a valid conversion
> to an LLSD real)? ECMA-262 does not support Infinity, NaN, etc. for the JSON
> 'number' type so it looks like we need to transmit those values as strings.
>

That looks like a reasonable interpretation/suggestion to me.

While we're nitpicking this part of the spec:

* The ABNF for non-special real numbers is pretty b0rked if I'm reading it
correctly. (The exponent is non-optional, negative numbers are not
productions, '0.00' is forbidden, etc) I've mentioned this to Mark Lentczner
off-list.

* are '+Zero' and '-Zero' really preferable over '0.0' and '-0.0' ? Who uses
them?

* should 'Infinity' (sans-+) be considered valid? how about 'NaN' (no 'S' or
'Q')?

* was this all just a conspiracy by the draft authors to get us talking
about their alter egos?

---

From: Meadhbh Hamrick <[email-masked]>
Date: Thu, 6 May 2010 11:48:46 -0700

blergh. i wrote that to aggressively support IEEE 754 which includes
several "exceptional" values like plus/minus infinity, signed zero,
NaN, etc. there ARE binary encodings for these numbers, so binary
serialization shouldn't be a problem.

i wonder if it makes sense to say that if you have to transmit an
exceptional IEEE 754 value, you send it as a string instead of a
JSON-number. that way when you do the equivalent of:

llsd_value.asReal();

it would "do the right thing" and convert the string to a real value.
this would require us to have a wrapper class to hang the asReal()
method off, which i know some on this list wanted to try to avoid.

also.. what do current JSON implementations do if you give it
something like a -Infinity? instead of a real?

-cheers
-meadhbh
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [email-masked]

On Thu, May 6, 2010 at 10:36 AM, Hurliman, John <[email-masked]> wrote:
> _______________________________________________
> vwrap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vwrap
>

---

From: Meadhbh Hamrick <[email-masked]>
Date: Thu, 6 May 2010 11:50:45 -0700

* i think we got the textual values from XDR.
* yes, i chuckled a bit at the thought of embedding my linden name in
a standard.
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [email-masked]

On Thu, May 6, 2010 at 11:47 AM, Joshua Bell <[email-masked]> wrote:
>> Does this mean that an LLSD real type with a value of -Infinity needs to
>> be converted to a JSON string, and would be decoded on the receiving side as
>> an LLSD string with value "-Infinity" (that happens to have a valid
>> conversion to an LLSD real)? ECMA-262 does not support Infinity, NaN, etc.
>> for the JSON 'number' type so it looks like we need to transmit those values
>> as strings.
>

---

From: Meadhbh Hamrick <[email-masked]>
Date: Thu, 6 May 2010 12:07:12 -0700

hmm... the ecmascript 5.0 spec seems to imply the string "-Infinity"
is a valid expression of a number, but note 4 on page 217 of the spec
implies that in JSON, you don't get exceptional values like Infinity
or NaN. or rather, both are represented as nulls.

it could be possible to encode all exceptional real values to null,
but when they're deserialized, there would be no way to tell which
exceptional value it was. so you could serialize a value that's
infinity, and deserialize something taht's NaN. but, in theory, this
should be copacetic for JSON parsers.

or... we could layer something on top of JSON to preserve the NaNs and
Infinities. we could come up with a standard way of representing these
values as strings or binaries. (if strings, then the simple strings
listed in the draft. if binaries, maybe the binary patterns in 754
that represent them.) but this will require asReal() and serialize()
methods in LLIDL libraries to understand the usage.

or we could punt and pretend negative infinities don't exist.

ideas? preferences? john, you're out in front as an implementer. what
works for you?

-cheers
-meadhbh

---

From: Meadhbh Hamrick <[email-masked]>
Date: Thu, 6 May 2010 12:37:43 -0700

k. so i pinged doug crockford about it. his response was that JSON
wants to be independent of any floating point standard, and thus only
represents finite numbers.

so... a) it's not a mistake or an oversight that you can't represent
NaNs as JSON-Numbers and b) even if it somehow worked in current
implementations, it's not the intent of the JSON designers, so, it may
not work in the future.

so do we know how important it is to represent each of the distinct
non-finite reals?

-cheers
-meadhbh

---

From: Joshua Bell <[email-masked]>
Date: Thu, 6 May 2010 13:48:23 -0700

I did some playing in an ECMAScript implementation of LLSD, following John's
suggestions of serializing NaN, +/- Infinity, and also negative zero, as
strings when serializing to JSON. Round-tripping works like a charm,
assuming of course that you're testing the results using an "asReal"
coercion that follows the same logic, which an LLSD implementation should
be.

Crockford's http://www.json.org/js.html page even hints at this approach at
the bottom, suggesting that non-finite values could be serialized to JSON as
strings.

On Thu, May 6, 2010 at 12:37 PM, Meadhbh Hamrick <[email-masked]>wrote:

> > Then later in "Appendix A. ABNF of Real Values" it lists a series of
> strings that can be converted into real values:
> >

---

From: "Hurliman, John" <[email-masked]>
Date: Thu, 6 May 2010 14:54:32 -0600

I’m fine with that approach.
John

From: [email-masked] [mailto:[email-masked]] On Behalf Of Joshua Bell
Sent: Thursday, May 06, 2010 1:48 PM
To: [email-masked]
Subject: Re: [vwrap] ECMA-262 and the Real LLSD type

I did some playing in an ECMAScript implementation of LLSD, following John's suggestions of serializing NaN, +/- Infinity, and also negative zero, as strings when serializing to JSON. Round-tripping works like a charm, assuming of course that you're testing the results using an "asReal" coercion that follows the same logic, which an LLSD implementation should be.

Crockford's http://www.json.org/js.html page even hints at this approach at the bottom, suggesting that non-finite values could be serialized to JSON as strings.

On Thu, May 6, 2010 at 12:37 PM, Meadhbh Hamrick <[email-masked]<mailto:[email-masked]>> wrote:
k. so i pinged doug crockford about it. his response was that JSON
wants to be independent of any floating point standard, and thus only
represents finite numbers.

-cheers
-meadhbh
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [email-masked]<mailto:[email-masked]>

On Thu, May 6, 2010 at 10:36 AM, Hurliman, John <[email-masked]<mailto:[email-masked]>> wrote:
> [email-masked]<mailto:[email-masked]>
_______________________________________________
vwrap mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/vwrap

---

From: David W Levine <[email-masked]>
Date: Thu, 6 May 2010 18:23:46 -0400

+1 on Joshua's approach. Document the expected asReal coercion and your 
bases are covered nicely I think. 

- David
~ Zha

From:
"Hurliman, John" <[email-masked]>
To:
Joshua Bell <[email-masked]>, "[email-masked]" <[email-masked]>
Date:
05/06/2010 04:55 PM
Subject:
Re: [vwrap] ECMA-262 and the Real LLSD type
Sent by:
[email-masked]

From: [email-masked] [mailto:[email-masked]] On Behalf Of 
Joshua Bell
Sent: Thursday, May 06, 2010 1:48 PM
To: [email-masked]
Subject: Re: [vwrap] ECMA-262 and the Real LLSD type
 
I did some playing in an ECMAScript implementation of LLSD, following 
John's suggestions of serializing NaN, +/- Infinity, and also negative 
zero, as strings when serializing to JSON. Round-tripping works like a 
charm, assuming of course that you're testing the results using an 
"asReal" coercion that follows the same logic, which an LLSD 
implementation should be.
 
Crockford's http://www.json.org/js.html page even hints at this approach 
at the bottom, suggesting that non-finite values could be serialized to 
JSON as strings.
 
On Thu, May 6, 2010 at 12:37 PM, Meadhbh Hamrick <[email-masked]> 
wrote:
k. so i pinged doug crockford about it. his response was that JSON
wants to be independent of any floating point standard, and thus only
represents finite numbers.

-cheers
-meadhbh

> Does this mean that an LLSD real type with a value of -Infinity needs to 
be converted to a JSON string, and would be decoded on the receiving side 
as an LLSD string with value "-Infinity" (that happens to have a valid 
conversion to an LLSD real)? ECMA-262 does not support Infinity, NaN, etc. 
for the JSON 'number' type so it looks like we need to transmit those 
values as strings.