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

Meadhbh Hamrick <ohmeadhbh@gmail.com> Thu, 06 May 2010 19:07 UTC

Return-Path: <ohmeadhbh@gmail.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 CE0873A697C for <vwrap@core3.amsl.com>; Thu, 6 May 2010 12:07:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.226
X-Spam-Level:
X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599]
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 8jo0ddqXMz6C for <vwrap@core3.amsl.com>; Thu, 6 May 2010 12:07:50 -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 590343A6902 for <vwrap@ietf.org>; Thu, 6 May 2010 12:07:50 -0700 (PDT)
Received: by vws9 with SMTP id 9so308561vws.31 for <vwrap@ietf.org>; Thu, 06 May 2010 12:07:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=GOA7t0HUUgyD6KW9ZvnaoaSHdnMIfQKuADMFZnK3G78=; b=piWnuS16UDUCEBCMsqx/I0HD7Fz0VOyEhHKkL/50txmDpHzpndaGn03zvrtzjESLxN rS1IMhl1dioDNf1+VoYckgTIIBSWtapGNL+EsvTsH86XLPgyise0fGC0xCk0c8kr9Pnc 6RZz8oRhUO+mUsbA9k9hw3VNxB6ZYNiI1nI7g=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=bpvMqV4ZXfZ5ljXw1xCCZtN+RFkZJS7BjG2tS5858udlTCRQ3iZvX0vIjdaIkClxAi 8391ErScvxFiWTEn70CVJocMMGom41mZt+SGcgDKHIW9KL0RMZVWibwye5x6xWCOnXHK refyEZ+0wbQOnYTavRtyWA7TKUL5zztANob0w=
Received: by 10.229.28.137 with SMTP id m9mr5744802qcc.21.1273172855501; Thu, 06 May 2010 12:07:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.24.142 with HTTP; Thu, 6 May 2010 12:07:12 -0700 (PDT)
In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933DCE425A2C@rrsmsx506.amr.corp.intel.com>
References: <62BFE5680C037E4DA0B0A08946C0933DCE425A2C@rrsmsx506.amr.corp.intel.com>
From: Meadhbh Hamrick <ohmeadhbh@gmail.com>
Date: Thu, 6 May 2010 12:07:12 -0700
Message-ID: <n2ob325928b1005061207l186eec38w90cf2ad343c13c6b@mail.gmail.com>
To: "Hurliman, John" <john.hurliman@intel.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "vwrap@ietf.org" <vwrap@ietf.org>
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 19:07:52 -0000

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
--
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
>