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

Joshua Bell <josh@lindenlab.com> Thu, 06 May 2010 20:51 UTC

Return-Path: <josh@lindenlab.com>
X-Original-To: vwrap@core3.amsl.com
Delivered-To: vwrap@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D9ED3A6C2B for <vwrap@core3.amsl.com>; Thu, 6 May 2010 13:51:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.118
X-Spam-Level:
X-Spam-Status: No, score=0.118 tagged_above=-999 required=5 tests=[AWL=0.605, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2D6+FOzEtJ2 for <vwrap@core3.amsl.com>; Thu, 6 May 2010 13:51:10 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 2005E3A6C5F for <vwrap@ietf.org>; Thu, 6 May 2010 13:48:39 -0700 (PDT)
Received: by vws9 with SMTP id 9so416767vws.31 for <vwrap@ietf.org>; Thu, 06 May 2010 13:48:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.108.7 with SMTP id d7mr1234447vcp.161.1273178903486; Thu, 06 May 2010 13:48:23 -0700 (PDT)
Received: by 10.220.73.13 with HTTP; Thu, 6 May 2010 13:48:23 -0700 (PDT)
In-Reply-To: <z2jb325928b1005061237q9c08d062v25e43996c964839f@mail.gmail.com>
References: <62BFE5680C037E4DA0B0A08946C0933DCE425A2C@rrsmsx506.amr.corp.intel.com> <z2jb325928b1005061237q9c08d062v25e43996c964839f@mail.gmail.com>
Date: Thu, 6 May 2010 13:48:23 -0700
Message-ID: <m2xf72742de1005061348h5f0a246doad547c752272fe5@mail.gmail.com>
From: Joshua Bell <josh@lindenlab.com>
To: "vwrap@ietf.org" <vwrap@ietf.org>
Content-Type: multipart/alternative; boundary=00c09f971b8b4722140485f3107e
Subject: Re: [vwrap] ECMA-262 and the Real LLSD type
X-BeenThere: vwrap@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual World Region Agent Protocol - IETF working group <vwrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vwrap>, <mailto:vwrap-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vwrap>
List-Post: <mailto:vwrap@ietf.org>
List-Help: <mailto:vwrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vwrap>, <mailto:vwrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 May 2010 20:51:12 -0000

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 <ohmeadhbh@gmail.com>wrote;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.
>
> 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
> --
> 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
> >
> _______________________________________________
> vwrap mailing list
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap
>