On Tue, Jun 2, 2009 at 10:56 PM, Allen Wirfs-Brock
allen.wirfs-br...@microsoft.com wrote:
My inclination would be to require ES5 implementation to exactly conform
the whatever JSON grammar we provide and to throw syntax errors if the input
doesn't exactly conform to the grammar. (in other
On Jun 2, 2009, at 11:09 PM, Rob Sayre wrote:
On 6/3/09 1:56 AM, Allen Wirfs-Brock wrote:
My inclination would be to require ES5 implementation to exactly
conform the whatever JSON grammar we provide and to throw syntax
errors if the input doesn't exactly conform to the grammar. (in
On Jun 3, 2009, at 11:12 AM, Oliver Hunt wrote:
1.) leading zeros are parsed as decimal numbers (octal seems like a
bug no matter what, per MarkM)
IE8 and V8's JSON implementation, and json2.js at json.org all
interpret 010, as octal (eg. 8), and 009 as 9
Those look like bugs ;-).
The
On Jun 3, 2009, at 11:18 AM, Rob Sayre wrote:
On 6/3/09 2:12 PM, Oliver Hunt wrote:
1.) leading zeros are parsed as decimal numbers (octal seems like
a bug no matter what, per MarkM)
IE8 and V8's JSON implementation, and json2.js at json.org all
interpret 010, as octal (eg. 8), and 009
See below
-Original Message-
From: Oliver Hunt [mailto:oli...@apple.com]
...
On Jun 2, 2009, at 11:09 PM, Rob Sayre wrote:
On 6/3/09 1:56 AM, Allen Wirfs-Brock wrote:
...
1.) leading zeros are parsed as decimal numbers (octal seems like a
bug no matter what, per MarkM)
IE8 and V8's
Allen Wirfs-Brock wrote:
JSON.parse([010])
should be an error, per spec. Nobody follows the spec though...
As I read them neither the RFC or the current ES5 JSON grammar recognize [010] as a
valid JSON form, so according to the ES5 spec. a syntax error should be thrown. If we really want
I want to bring this discussion around to focus on concrete points that we need
to make decisions on.
1) There is a bug in the ES5 candidate spec. in that it says that:
JSONSourceCharacter ::
SourceCharacter but not U+ thru U+001F
This is pretty clearly bogus as it means that tabs and
2) Do we want to permit conforming implementations to extend the JSON
grammar that they recognize?
No. An implementation has the license to support other formats (such as an
XML object or a SuperJSON object). But the JSON object should recognize only
the JSON forms described by ES5. There
The JSON RFC, by including the escape clause A JSON parser MAY accept
non-JSON forms or extensions, admits non-validating parsers. The
table at http://code.google.com/p/json-sans-eval/ gives us some good
terminology. The reason we need JSON to be provided by platforms
rather than libraries is that
Mark S. Miller wrote:
Crock, is your position that ES5 should specify a validating JSON
parse exactly equivalent to the parse specified in the RFC (i.e.,
waiving the escape clause), but with JSON value as the start symbol?
If so, then I agree.
Yes.
Mark S. Miller wrote:
Crock, is your position that ES5 should specify a validating JSON
parse exactly equivalent to the parse specified in the RFC (i.e.,
waiving the escape clause), but with JSON value as the start symbol?
If so, then I agree.
Yes. Then we are in agreement.
On Wed, Jun 3, 2009 at 4:59 PM, Douglas Crockford doug...@crockford.com wrote:
Mark S. Miller wrote:
Crock, is your position that ES5 should specify a validating JSON
parse exactly equivalent to the parse specified in the RFC (i.e.,
waiving the escape clause), but with JSON value as the start
On Jun 3, 2009, at 2:15 PM, Mark S. Miller wrote:
On Wed, Jun 3, 2009 at 2:10 PM, Robert Sayre say...@gmail.com wrote:
OK, so, all such deviations will be considered bugs by
implementations
that purport to conform. Right?
Yes.
Awesome.
--Oliver
Waldemar Horwat wrote:
Here are my views on this.
2) Do we want to permit conforming implementations to extend the JSON
grammar that they recognize? This probably could be done by extending
the syntax error extension allowance in section 16 to include the JSON
grammar. If we allow this
Douglas Crockford wrote:
Waldemar Horwat wrote:
2) Do we want to permit conforming implementations to extend the JSON
grammar that they recognize? This probably could be done by
extending the syntax error extension allowance in section 16 to
include the JSON grammar. If we allow this then
-Original Message-
From: Waldemar Horwat [mailto:walde...@google.com]
OK, so we need not discuss any new numeric types any further in
committee because it would be impossible to round-trip them through
JSON. Do we have agreement on that?
I think that's reality. Languages with multiple
Waldemar Horwat wrote:
Douglas Crockford wrote:
Waldemar Horwat wrote:
2) Do we want to permit conforming implementations to extend the
JSON grammar that they recognize? This probably could be done by
extending the syntax error extension allowance in section 16 to
include the JSON grammar.
Douglas Crockford wrote:
Waldemar Horwat wrote:
OK, so we need not discuss any new numeric types any further in
committee because it would be impossible to round-trip them through
JSON. Do we have agreement on that?
Not necessarily. What we can agree on is that new numeric types cannot
18 matches
Mail list logo
