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

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/ * OhMeadhbh@gmail.com

On Thu, May 6, 2010 at 10:36 AM, Hurliman, John <john.hurliman@intel.com> wrote:
> 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
> _______________________________________________
> vwrap mailing list
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap
>