- --- In email@example.com, Martin Cooper <mfncooper@g...> wrote:
> One other point: I'm beginning to be concerned about the stability
> JSON as a spec. Many people are implementing it now, but it appearsto
> be a moving target.OK, this is earlier than I wanted to "announce" this, but I've been
concerned with the above, plus there are things I want to do that JSON
gets me close to but not quite.
I promise this will be the only and only time I will bring it up on
this group, if you want to contact me, feel free to whois my domain
and email me. Please also bear in mind I am really trying to be low
key about this, embedding it in a reply to an existing message, rather
than starting a new thread. In particular, suggestions for different
names are encourage; I've additionally thought of jsdeclare or jsrules
To my point:
Object Expressions" or JSON eXtended, whichever way you see it. The
best way to illustrate it is with a file I would like to see
1) optional identifying clause
2) unquoted strings including identifiers, function definitions, and
regular expressions, allowed as values; functions and regular
expressions can provide "hints" to parsers, but don't necessarily need
to be implemented
3) multiple expressions per file creating a namespace in which it can
be attempted to resolve identifiers
4) reference implementation
5) multi-person steering committee
6) backward compatible with JSON
7) not "yet another (data interchange) markup language" but rather, in
addition to that, a format suitable for client-server interoperable
By the way take the jsox.html off the URL above and descend into the
com and org directories under jsox/ and you will find my extension of
Mr Crockford's Java implementation of JSON. The only change made to
the org.json code was to make one attribute protected instead of
private. All I've done so far is allow an optional identifier and
regular expressions, albeit poorly in my estimation.
- Funny thing is, YAML was designed for human consumption as much as a
more in the LISP camp than the C camp , i.e., designed for expressive
power rather than bit-munging.
Programmers spend half their time looking at code. Ergonomics matter.
If line speed is a premium, why allow insignificant whitespace at all?
If line speed was a premium (and human consumption irrelevant), I'd be
using ASN.1 anyway; it is well established in the telecom world, and
there are tons of software and utilities that will help you with the
Think of comments as something that belong to a separate namespace. The
JSON parser should have no other business with comments than ignoring
them. If ECMAScript syntax for comments is too loose for easy parsing,
The alternative is an informal standard for comment properties that in
effect turns me into a carbon-based compiler and requires applications
to share a notation for comments anyway.
Atif Aziz wrote:
>>I think the real crux...
> As I said, I have a sneaking hunch that the real issue stems from tying
> JSON to YAML. With the comments debate generating some traffic, I feel
> less daring at this point to open up the disappearing of single-quoted
> strings gone as well as unquoted member names (at least on the decoding
> end). I am hoping Douglas will provide some insight so everyone can
> build a better understanding of the decisions that lead to several
> cutbacks in the specs. I think focusing the discussion too much on
> comments is really just avoiding a more fundamental issue. Does anyone
> agree or am I just rambling here?
> -----Original Message-----
> From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of
> Sent: Tuesday, January 03, 2006 8:03 PM
> To: firstname.lastname@example.org
> Subject: Re: [json] Re: Comments
> I think the real crux of this is simply, you cannot create a json
> format string through encoding from existing data that would contain
> comments (IIRC). It is only from people creating a json format string
> by hand.
> It is a fairly weak argument that the standard should support
> something that is not going to be used by the majority of people and
> probably not in production, from an early version of the standard,
> especially given that there are other ways get the same information
> across using the current standard.
> If you want to block out sections of json for ease of testing, then
> comment out the properties of the objects you are encoding, not /**/
> in some hand edited string.
> If you want to include comments about an object, include it in a
> property of the object.
> If you feel a need to include very detailed breakdowns, write a spec
> for the object your passing, it shouldn't be in the data stream.
> Your suggestion on wording is really avoiding the issue of why it
> should remain when there are other workable alternatives, and
> suggesting that it remain part of the standard just because it was
> once thought to be useful.
> Yahoo! Groups Links
> Yahoo! Groups Links