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

"Hurliman, John" <john.hurliman@intel.com> Thu, 06 May 2010 20:55 UTC

Return-Path: <john.hurliman@intel.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 9D10A3A6A98 for <vwrap@core3.amsl.com>; Thu, 6 May 2010 13:55:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.099
X-Spam-Level:
X-Spam-Status: No, score=-7.099 tagged_above=-999 required=5 tests=[AWL=-0.501, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 JkPjMNxSuexP for <vwrap@core3.amsl.com>; Thu, 6 May 2010 13:55:01 -0700 (PDT)
Received: from mga14.intel.com (mga14.intel.com [143.182.124.37]) by core3.amsl.com (Postfix) with ESMTP id EFBE83A6A08 for <vwrap@ietf.org>; Thu, 6 May 2010 13:54:57 -0700 (PDT)
Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 06 May 2010 13:54:44 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos; i="4.52,343,1270450800"; d="scan'208,217"; a="274229269"
Received: from rrsmsx602.amr.corp.intel.com ([10.31.0.33]) by azsmga001.ch.intel.com with ESMTP; 06 May 2010 13:54:34 -0700
Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx602.amr.corp.intel.com ([10.31.0.33]) with mapi; Thu, 6 May 2010 14:54:34 -0600
From: "Hurliman, John" <john.hurliman@intel.com>
To: Joshua Bell <josh@lindenlab.com>, "vwrap@ietf.org" <vwrap@ietf.org>
Date: Thu, 6 May 2010 14:54:32 -0600
Thread-Topic: [vwrap] ECMA-262 and the Real LLSD type
Thread-Index: AcrtXdlUCAyn0uXRSVCLCAuabFFbFQAAGzJQ
Message-ID: <62BFE5680C037E4DA0B0A08946C0933DCE425C2A@rrsmsx506.amr.corp.intel.com>
References: <62BFE5680C037E4DA0B0A08946C0933DCE425A2C@rrsmsx506.amr.corp.intel.com> <z2jb325928b1005061237q9c08d062v25e43996c964839f@mail.gmail.com> <m2xf72742de1005061348h5f0a246doad547c752272fe5@mail.gmail.com>
In-Reply-To: <m2xf72742de1005061348h5f0a246doad547c752272fe5@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_62BFE5680C037E4DA0B0A08946C0933DCE425C2Arrsmsx506amrcor_"
MIME-Version: 1.0
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:55:02 -0000

I’m fine with that approach.
John

From: vwrap-bounces@ietf.org [mailto:vwrap-bounces@ietf.org] On Behalf Of Joshua Bell
Sent: Thursday, May 06, 2010 1:48 PM
To: vwrap@ietf.org
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 <ohmeadhbh@gmail.com<mailto:ohmeadhbh@gmail.com>> 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<mailto:OhMeadhbh@gmail.com>



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