JSON is not able to directly represent cyclical structures. However,
with some simple transformation, it can. This is demonstrated by two
JavaScript functions, decycle(value) and retrocycle(value).

decycle produces a deep copy of a value, except that recurrences are
replaced with JSPON notations. retrocycle modifies an object by
replacing JSPON notations, restoring cycles. The result of decycle can
be given to an encoder (such as JSON.stringify). The result of a JSON
decoder (such as JSON.parse) can be given to retrocycle.

These functions use a subset of Kris Zyp's JSPON, which uses a subset
of Stefan Goessner's JSONPath.

See http://www.JSON.org/cycle.js

This is great to see, obviously I am pleased to see further adoption of
reference-capable JSON. I did want to make a few comments:

While I had originally specified "$" as the reference to the root of
current JSON document following the lead of JSONPath, I have since began
to think that "#" is be a better choice. The reason for this is because
full JSON referencing (formerly known as JSPON, JSPON was an earlier
attempt at full CRUD protocol, but now it essentially superseded by HTTP
+ JSON + JSON referencing) is intended to be exactly analogous to the
semantics of hyperlinks, with resolution following the rules of relative
URIs, essentially allowing JSON to act as RESTful hypermedia with JSON
referencing is applied. Path-based referencing is intended to define the
referencing targets based upon position in the current JSON document and
integrates well with the relative URL, forming a subset that is purely
internal. Path-based referencing is the subset of JSON referencing that
Crockford has implemented in cycle.js. However, in the context of
considering path-based referencing as a proper subset of full relative
URI based hyperlinking, it is actually more semantically correct to
prefix a path-based reference with "#". The "#" symbol is specifically
designated to have the purpose of referencing parts of the currently
loaded document. Just as we use the hash part of URLs in HTML to
navigate to different parts of a page, this is analogous to
resolving/dereferencing different parts of the current JSON
document/object graph. By using the "#" symbol to refer to the root of
the JSON document, this path-based referencing can act as an exact
subset of relative URI referencing, where the references implicitly
indicate that their targets are internal, and referencing
implementations like cycle.js can act on this exact subset without any
further relative URI knowledge while implementations that are integrated
with URI resolving and retrieval capabilities can act on the full set of
JSON references without incompability.

For further information on JSON referencing (with path and id-based
referencing), I originally described it here:
http://www.json.com/2007/10/19/json-referencing-proposal-and-library/,
with some more examples here:
http://www.sitepen.com/blog/2008/06/17/json-referencing-in-dojo/. This
is all with the original "$" notation for the root. The impetus for
using "#" came from recent discussions with the RESTful JSON group
(http://groups.google.com/group/restful-json, and cc'ing them on this
email), and my resultant proposal for RESTful JSON interaction
(http://www.json.com/specifications/json-resources/). I haven't updated
these blog posts nor http://jspon.org with the "#" because these
discussions were quite recent, and actually I would love to get feedback
from this group for the best approach. Right now Dojo's implementation
of JSON referencing uses the "#" notation. However, I would certainly be
willing to change it per the consensus of the community.

Also, I am certainly not asking for a change in names, but I have been
hesitant to use the term cycle/circular only because I think multiple
referencing is every bit as valuable circular referencing. Multiple
referencing is covered by cycle.js as well; cycles are subset of the
referencing dependent data structures that are enabled by cycle.js. For
example:

var b= {foo:"bar"};
var c={d:b,e:b};
JSON.stringify(decycle(c)) ->
"{"d":{"foo":"bar"},"e":{"$ref":"$[\"d\"]"}}"
And
var newC = retrocycle(decycle(c));
newC.d === new.e // -> true (identity is preserved)

Just didn't want you to sell yourself on the capabilities of this
library, it does more than it's name suggests.

Anyway, once again, I think this library looks great, it is exciting to
see the growing potential for ubiquitous interchange of rich data
structures with a common technique for referencing implemented by this
library, Dojo, Persevere, and hopefully others.
Thanks,
Kris

Douglas Crockford wrote:
>
> JSON is not able to directly represent cyclical structures. However,
> with some simple transformation, it can. This is demonstrated by two
> JavaScript functions, decycle(value) and retrocycle(value).
>
> decycle produces a deep copy of a value, except that recurrences are
> replaced with JSPON notations. retrocycle modifies an object by
> replacing JSPON notations, restoring cycles. The result of decycle can
> be given to an encoder (such as JSON.stringify). The result of a JSON
> decoder (such as JSON.parse) can be given to retrocycle.
>
> These functions use a subset of Kris Zyp's JSPON, which uses a subset
> of Stefan Goessner's JSONPath.
>
> See http://www.JSON.org/cycle.js <http://www.JSON.org/cycle.js>
>
>


[Non-text portions of this message have been removed]

I made RJSON about a year ago to handle cycles and types.  It uses function
call forms, as used by cyclic JSON, but instead of a JSON path it uses
integers or strings ids to encode references.  This way you can transmit
object graphs that reference objects that have already been sent, cannot be
sent, etc. by referencing a non-local id.

If you can read lisp, this example should be obvious:

(rjson:encode-rjson
  (let* ((a (list "one" "two" "three"))
         (b a)
         (fruit (make-instance 'fruit :calories 55)))
    (push a a)
    (list a b fruit))
  *standard-output*)

->
{"header":{
"allocs":[rjalloc(2,"json:array")],
"inits":[rjinit(2,["one","two","three"])]
},"content":
[ [rjref(2),"one","two","three"], // a
  rjref(2), //b
rjconstruct("fruit",{"calories":55})] // fruit
  }

The four Javascript functions required to implement this are rjalloc,
rjinit, rjref, and the auxiliary rjconstruct.  Allocation occurs first to
assign an ID to cross-referenced objects; these objects are then initialized
with some piece of data; the objects may then be cross-referenced with
rjref.   Assuming these functions are implemented, you decode an RJSON
string in Javascript with eval( rjsonString ).content

This does not cover all cases for transmitting graphs efficiently, but I
have found it a sufficiient JSON++ for my needs.

See
http://common-lisp.net/project/suave/

or the implementation
http://common-lisp.net/project/suave/darcs/rjson/lisp-src/rjson-encode.lisp

Best,
Red Daly

On Mon, Oct 27, 2008 at 9:34 PM, Kris Zyp <kriszyp@...> wrote:

>   This is great to see, obviously I am pleased to see further adoption of
> reference-capable JSON. I did want to make a few comments:
>
> While I had originally specified "$" as the reference to the root of
> current JSON document following the lead of JSONPath, I have since began
> to think that "#" is be a better choice. The reason for this is because
> full JSON referencing (formerly known as JSPON, JSPON was an earlier
> attempt at full CRUD protocol, but now it essentially superseded by HTTP
> + JSON + JSON referencing) is intended to be exactly analogous to the
> semantics of hyperlinks, with resolution following the rules of relative
> URIs, essentially allowing JSON to act as RESTful hypermedia with JSON
> referencing is applied. Path-based referencing is intended to define the
> referencing targets based upon position in the current JSON document and
> integrates well with the relative URL, forming a subset that is purely
> internal. Path-based referencing is the subset of JSON referencing that
> Crockford has implemented in cycle.js. However, in the context of
> considering path-based referencing as a proper subset of full relative
> URI based hyperlinking, it is actually more semantically correct to
> prefix a path-based reference with "#". The "#" symbol is specifically
> designated to have the purpose of referencing parts of the currently
> loaded document. Just as we use the hash part of URLs in HTML to
> navigate to different parts of a page, this is analogous to
> resolving/dereferencing different parts of the current JSON
> document/object graph. By using the "#" symbol to refer to the root of
> the JSON document, this path-based referencing can act as an exact
> subset of relative URI referencing, where the references implicitly
> indicate that their targets are internal, and referencing
> implementations like cycle.js can act on this exact subset without any
> further relative URI knowledge while implementations that are integrated
> with URI resolving and retrieval capabilities can act on the full set of
> JSON references without incompability.
>
> For further information on JSON referencing (with path and id-based
> referencing), I originally described it here:
> http://www.json.com/2007/10/19/json-referencing-proposal-and-library/,
> with some more examples here:
> http://www.sitepen.com/blog/2008/06/17/json-referencing-in-dojo/. This
> is all with the original "$" notation for the root. The impetus for
> using "#" came from recent discussions with the RESTful JSON group
> (http://groups.google.com/group/restful-json, and cc'ing them on this
> email), and my resultant proposal for RESTful JSON interaction
> (http://www.json.com/specifications/json-resources/). I haven't updated
> these blog posts nor http://jspon.org with the "#" because these
> discussions were quite recent, and actually I would love to get feedback
> from this group for the best approach. Right now Dojo's implementation
> of JSON referencing uses the "#" notation. However, I would certainly be
> willing to change it per the consensus of the community.
>
> Also, I am certainly not asking for a change in names, but I have been
> hesitant to use the term cycle/circular only because I think multiple
> referencing is every bit as valuable circular referencing. Multiple
> referencing is covered by cycle.js as well; cycles are subset of the
> referencing dependent data structures that are enabled by cycle.js. For
> example:
>
> var b= {foo:"bar"};
> var c={d:b,e:b};
> JSON.stringify(decycle(c)) ->
> "{"d":{"foo":"bar"},"e":{"$ref":"$[\"d\"]"}}"
> And
> var newC = retrocycle(decycle(c));
> newC.d === new.e // -> true (identity is preserved)
>
> Just didn't want you to sell yourself on the capabilities of this
> library, it does more than it's name suggests.
>
> Anyway, once again, I think this library looks great, it is exciting to
> see the growing potential for ubiquitous interchange of rich data
> structures with a common technique for referencing implemented by this
> library, Dojo, Persevere, and hopefully others.
> Thanks,
> Kris
>
>
> Douglas Crockford wrote:
> >
> > JSON is not able to directly represent cyclical structures. However,
> > with some simple transformation, it can. This is demonstrated by two
> > JavaScript functions, decycle(value) and retrocycle(value).
> >
> > decycle produces a deep copy of a value, except that recurrences are
> > replaced with JSPON notations. retrocycle modifies an object by
> > replacing JSPON notations, restoring cycles. The result of decycle can
> > be given to an encoder (such as JSON.stringify). The result of a JSON
> > decoder (such as JSON.parse) can be given to retrocycle.
> >
> > These functions use a subset of Kris Zyp's JSPON, which uses a subset
> > of Stefan Goessner's JSONPath.
> >
> > See http://www.JSON.org/cycle.js <http://www.JSON.org/cycle.js>
> >
> >
>
> [Non-text portions of this message have been removed]
>
>
>


[Non-text portions of this message have been removed]

JSON allows, but does not require escaping of the / character.
Generally, it is best to not escape the slash. The JSON strings "/"
and "\/" must produce exactly the same result.

JSON tolerates \/ for the benefit in HTML. In HTML, </ is not allowed
in string literals, so JSON permits <\/.

I have a slower version of json2 that explicitly detects and rejects
cycles. The results are always the same, but stringify will fail
faster in the presence of a cycle.

http://www.json.org/json2_no_cycle.js

(putting json@yahoogroups.com back on the cc in case anyone is
interested over there)
Manuel Simoni wrote:
> On Wed, Oct 29, 2008 at 6:53 PM, Kris Zyp <kriszyp@...> wrote:
>
>>> So, by simply copying HTML's prior art, a *complete strawman* proposal
>>> could look like this:
>>>
>>> 1. Everywhere a $ref member occurs it's value must be a URL.
>>> { "$ref": "http://example.com/some-doc#foo" }
>>>
>>>
>>>
>> Yes, that is exactly how JSON referencing works.
>>
>>> 2. Everywhere a $id member occurs its value must be a ID token.
>>> { "$id": "foo" }
>>>
>>>
>> That is the general idea. However, while I have also thought it would be
>> great to have one standard identity property (I had proposed "id", just
>> a little different spelling than your "$id"), but in order to facilitate
>> adoption and utilize existing JSON data with minimal modification, I
>> think it advantageous to support user-defined identity attribute.
>>
>
> What if the "IDs" used for targetting elements were decoupled from the
> user-defined IDs for "business objects"? IOW, people would add "$id"
> (for making nested objects targettable) in addition to whatever
> identifying scheme they were already employing (including none).
>
> I think this would avoid a whole can of worms. (For example, imagine
> the complexity if HTML's <a name> anchors had to work with arbitrary
> attributes besides @name.)
>
My point is that if a user already has a scheme for identifying
sub-objects why should we force them to add yet more properties to their
JSON to make it referenceable if it is already referenceable? If a user
already has URI referenceable subobjects, we can leverage that by simply
understanding the mapping (by knowing the identity property), rather
than creating new targetting schemes. I want to minimize the complexity
that we hoist on users. Adding properties is costly as well, encroaching
in the domain of available properties for user purposes.


>> [...]
>> Also, I think it is beneficial to define the identity as a real
>> URI location (same resolution rules as $ref) rather than a fragment
>> target, so that sub-objects can be treated as their own resources, which
>> is important for efficient updating. Therefore it would be more
>> analogous to the HTML<base> tage than <a name> tag.
>>
>
> As I said before, I believe that for a JSON referencing effort to be
> successful, it has to be of utmost simplicity and follow HTML's
> footsteps. I am not entirely sure of this, but for now it's my working
> assumption.
>
>
Of course I agree, with the caveat that HTML is structurally different
than JSON. I certainly want to follow HTML hyperlinking's steps as far
as they make sense in JSON, but not where JSON lends itself to a
different approach.
> What you are trying to achieve with clearly identifyable subresources
> I see as a separate, orthogonal effort to a referencing solution. Once
> a referencing solution were in place (and subelements of a JSON
> structure could be targetted), only then can one think further about
> clearly identifyable subresources, which are very much a separate
> topic from "mere" referencing in my opinion. (They are more of an
> "object model"/media type thing, imho).
>
I certainly want to separate orthogonal concerns, but understanding how
to identify targets so they can be referenced is critical to
referencing. Not thinking about the future is definitely a poor way to
design systems, so we need to think about how to keep consistent designs
for the future so as to minimize complexity for users.
> IOW, I don't think there's a case for deviating from HTML's prior art
> and requiring "<a name>" = "$id" anchors be full URIs. The <a name>
> and $id IDs should be mere identifiers used for selecting a
> subresource *included in another resource's representation* (exactly
> the same as say, a list of microformatted hcard entries inside a HTML
> web page). The $ids only need to make sense in the context of the
> larger document they are embedded in.
>
>
Yes, I understand, this is certainly a reasonable idea, but once again
it does nothing to address the issues I mentioned. How do you reference
an array or a primitive? This is where HTML-JSON analogy falls apart.
Also, JSON users don't like mixing in extra properties into their JSON
data, whereas this doesn't tend to as much of an issue with HTML because
it is actually written into the format.

>>> I think demanding more complex processing from agents (e.g. a path
>>> expression language) would strongly hinder the adoption of any JSON
>>> hyperlinking proposal.
>>>
>>>
>> That's a reasonable concern, but I believe path-based
>> linking/referencing is important because it is critical for describing
>> arbitrary object topologies (like cycles) and can be less intrusive. For
>> example, if you had an array with a circular reference, this would be
>> impossible to describe with id-based referencing since an array can't
>> define an identity in JSON:
>> {"myArrayWithACycle":[{"$ref":"#myArrayWithACycle"}]}
>> This can not be described with id-based referencing.
>>
>
> Right, but serializing object graphs is an issue that again I see
> orthogonal to Web-scale hyperlinking. Sure, being able to serialize
> arbitrary object graphs is a nice and much needed facility, but it is
> much less widely applicable than general hyperlinking, and again I
> think adding it to a generic JSON referencing proposal would hinder
> its adoption (e.g. many people have never thought before about
> serializing object graphs with cycles.)
>
They are both fundamentally about linking to other entities, whether
they be internal or external. Hyperlinks in HTML do not differentiate
between internal and external links; you actually lose a lot if you
don't keep these consistent, because then you can't link to
fragments/subobjects inside other resources (URI with fragments).
Inconsistent design won't help users here.
I am also curious how you quantified that internal references (like
cycles) are less important than hyperlinking. In my experience working
with the JSON community, circular references have received more
attention and effort. IMO, they are both important.

>
>> Also from my
>> experience, there are a lot of people that have expressed a preference
>> to path-based referencing so that don't have to assign ids to all
>> objects (and sub-objects) that might be targets of references. Also, one
>> could actually use path-based referencing to refer to primitive values
>> (like strings), which could have space-saving implications. Finally, the
>> implementation I have done in JavaScript (available in Dojo in
>> dojox.json.ref) probably only has a few hundred bytes of extra code to
>> handle paths, so it really isn't that painful.
>>
>
> Of course it would be nice if we could select HTML page subelements
> with XPath expressions after #. But I speculate that putting that into
> the HTML spec would have led to troubles:
>
> Even if the library for evaluating such expressions is small, it still
> has to be implemented by *every* participating agent, and without such
> a library, the references are essentially *undecipherable*. This means
> that if I want to whip up a spider for downloading a web of JSON
> documents in programming language X, which doesn't have such a
> library, I will first need to spend time on the library.
>
> Compare this to a HTML-like hyperlinking solution, without path
> expressions, where you only need to implement a URL resolution
> mechanism (with some kind of "<base>" support) which you need anyway.
> And for having to assign $id to all elements that should targettable,
> I think that's a price that we simply may have to pay for making them
> addressable.
>
> (It's obvious that we are looking from different angles at the
> problem, and I hope I am not boring you with my repeated references to
> HTML. Anyways, thanks for the interesting discussion!)
>
>
I certainly appreciate the HTML angle, the application of hyperlinking
to JSON is exactly what I am after as well, and HTML provides valuable
lessons. I just want to make we apply it in a way that matches the
structure of JSON (fundamentally much different than HTML/XML). Thank
you too for the great discussion and suggestions!

Thanks,
Kris

Hi all,

We've just released Restlet 1.1 with full JSON support. See complete
announce here:
http://blog.noelios.com/2008/10/28/restlet-110-released/

We have also added support for JSON in our new Restlet-GWT module, a
port of our client API to GWT 1.5. With this, you can work with JSON
both in the browser and in the server using a RESTful design and the
same Restlet API.

See our regular JSON extension (based on library from JSON.org):
http://www.restlet.org/documentation/1.1/ext/index.html?org/restlet/ext/json/pac\
kage-summary.html

For our Restlet-GWT module, the relevant page in the User Guide is here:
http://wiki.restlet.org/docs_1.1/13-restlet/144-restlet/190-restlet.html

Best regards,
J閞鬽e Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com

Article title:  <xsl:output method='json'/>
http://www.p6r.com/articles/2008/11/02/xsloutput-methodjson/

How we support output of JSON documents in our XSLT 2.0
and DOM parser object.


Best,
Mark Joseph, Ph.D.
P6R, Inc

The EcmaScript 3.1 draft standard is rapidly congealing towards an official
standard. The Kona version at <
http://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_draft>
is the important one -- details aside, the only remaining significant
unsettled controversy is whether Decimal remains or is pulled from ES3.1.

If you see any significant issues with the Kona version that need fixing,
please give us your feedback now, or post to the es*-discuss lists. After
the Nov 19/20 meeting, we are hoping to change only typos, bugs, and
problems revealed by implementation efforts.

We are quite proud of this draft. Given the maze of bizarre legacy
compatibility constraints, I'm amazed at how well we've been able to improve
on ES3. The JavaScript language is about to get a lot better.


---------- Forwarded message ----------
From: Pratap Lakshman (VJ#SDK) <pratapl@...>
Date: 2008/11/6
Subject: ES3.1 Draft: 07 Nov 2008 "Kona" version available
To: "es3.x-discuss@..." <es3.x-discuss@...>, "
es-discuss@..." <es-discuss@...>
Cc: "e-TC39@..." <e-TC39@...>


   I have uploaded to the wiki
(link<http://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_draft>\
)
the 07 Nov 2008 draft of the specification for ES3.1. This is in the form of
in-place edits and markups to the ES3 specification. Revision history is at
the end of the document.



This shall be the document to use for review at the upcoming TC39 meeting
(19/20 Nov, Kona, Hawaii). If there are any updates or revisions prior to
the meeting, we will post them on the wiki as well as on the discuss lists.



pratap

_______________________________________________
Es-discuss mailing list
Es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss




--
    Cheers,
    --MarkM


[Non-text portions of this message have been removed]

On Thu, Nov 6, 2008 at 2:33 PM, Mark S. Miller <erights@...> wrote:
> The EcmaScript 3.1 draft standard is rapidly congealing towards an official
> standard. The Kona version at <
> http://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_draft>
> is the important one -- details aside, the only remaining significant
> unsettled controversy is whether Decimal remains or is pulled from ES3.1.
>
> If you see any significant issues with the Kona version that need fixing,
> please give us your feedback now, or post to the es*-discuss lists. After
> the Nov 19/20 meeting, we are hoping to change only typos, bugs, and
> problems revealed by implementation efforts.
>
> We are quite proud of this draft. Given the maze of bizarre legacy
> compatibility constraints, I'm amazed at how well we've been able to improve
> on ES3. The JavaScript language is about to get a lot better.

Hear, hear!

Peter

Mark S. Miller scripsit:

> If you see any significant issues with the Kona version that need fixing,
> please give us your feedback now, or post to the es*-discuss lists.

Two versions are given, PDF and DOC.  Only the PDF is useful to me
because of the revision marks in the margin.  But it's full of red print,
which is damnably hard to read.  When I printed it on a b/w printer, it
became dim gray, which combined with the font was even harder to read,
if possible.  Please print a true b/w PDF version, and have mercy on
these 50-year-old eyes.

--
John Cowan  cowan@...  http://ccil.org/~cowan
If I have not seen as far as others, it is because giants were standing
on my shoulders.
         --Hal Abelson

Mark S. Miller scripsit:

> If you see any significant issues with the Kona version that need fixing,
> please give us your feedback now, or post to the es*-discuss lists. After
> the Nov 19/20 meeting, we are hoping to change only typos, bugs, and
> problems revealed by implementation efforts.

Postfix ++ and -- are defined identically the same way as prefix --
and ++; they all are said to return the incremented (decremented) value.

Since it is said that multiplication is not associative, the use of the
YACC-style left-recursive syntax rule implies that it is left-associative,
but it would be as well to say so.  And is the same not true of addition?

References to Unicode 2.0 (there's one at the end of 11.9.3, and may be
others) should be updated.


--
John Cowan                                   cowan@...
         "You need a change: try Canada"  "You need a change: try China"
                 --fortune cookies opened by a couple that I know

I changed the stringify method's array test from

    if (typeof value.length === 'number' &&
             !value.propertyIsEnumerable('length')) {

to the more reliable Miller device

    if (Object.prototype.toString.apply(value) === '[object Array]') {

See http://blog.360.yahoo.com/douglascrockford?p=916

It appears that versions of http://json.org/json2.js starting around
May 2008 have issues in Opera.  I've verified this in Opera 9.52 and
Opera 9.27.

The issue appears in the RegExp on line 190 of the 2008-11-19 version.
My guess is that Opera does not like escaped unicode in literal
RegExp?  It throws a syntax error which causes the rest of the script
to not load.

Does anyone know of a fix or work-around for this?

Thanks in advance,
smm

--- on Sat May 3, 2008 7:42 am, "Douglas Crockford" <douglas@...>
wrote:
>
> There are several Unicode characters that JavaScript mishandles,
> either by silent deletion, or by treating them as line ending
characters.
>
> json2.js now escapes those characters when it parses and when it
> minifies, so they can now be used correctly in JSON applications.
>
> http://www.JSON.org/json.js

On Tue, Dec 16, 2008 at 01:43:48AM -0000, Stephen M. McKamey wrote:
> It appears that versions of http://json.org/json2.js starting around
> May 2008 have issues in Opera.  I've verified this in Opera 9.52 and
> Opera 9.27.
>
> The issue appears in the RegExp on line 190 of the 2008-11-19 version.
> My guess is that Opera does not like escaped unicode in literal
> RegExp?  It throws a syntax error which causes the rest of the script
> to not load.
>
> Does anyone know of a fix or work-around for this?
>

Hi,

My college and me at work noticed this as well, we made a patch for
it at the time. It seems we forgot to report it. It's fixed in newer
versions of Opera.

--- json.js 2008/05/28 10:12:29 1.3
+++ json.js 2008/06/13 07:04:16 1.4
@@ -177,8 +177,8 @@
                   f(this.getUTCSeconds())   + 'Z';
          };

-        var cx =
/[\u0000\u00ad\u0600-\u0604\u070f\u17b4\u17b5\u200c-\u200f\u2028-\u202f\u2060-\u\
206f\ufeff\ufff0-\uffff]/g,
-            escapeable =
/[\\\"\x00-\x1f\x7f-\x9f\u00ad\u0600-\u0604\u070f\u17b4\u17b5\u200c-\u200f\u2028\
-\u202f\u2060-\u206f\ufeff\ufff0-\uffff]/g,
+        var cx = new
RegExp("[\u0000\u00ad\u0600-\u0604\u070f\u17b4\u17b5\u200c-\u200f\u2028-\u202f\u\
2060-\u206f\ufeff\ufff0-\uffff]", "g"),
+            escapeable = new
RegExp("[\\\"\x00-\x1f\x7f-\x9f\u00ad\u0600-\u0604\u070f\u17b4\u17b5\u200c-\u200\
f\u2028-\u202f\u2060-\u206f\ufeff\ufff0-\uffff]","g"),
              gap,
              indent,
              meta = {    // table of character substitutions

> Thanks in advance,
> smm
>
> --- on Sat May 3, 2008 7:42 am, "Douglas Crockford" <douglas@...>
> wrote:
> >
> > There are several Unicode characters that JavaScript mishandles,
> > either by silent deletion, or by treating them as line ending
> characters.
> >
> > json2.js now escapes those characters when it parses and when it
> > minifies, so they can now be used correctly in JSON applications.
> >
> > http://www.JSON.org/json.js
>
_____________________________________
New things are always on the horizon.

Ahh, thanks!  I tried that but thought it didn't work because this
whole thing was masking a different Opera issue.  Your post made me go
back and look more closely.  Seems to do the trick.

Douglas, can you update json2.js to use the RegExp constructor syntax
instead of RegExp literals?

Thanks,
smm

--- In json@yahoogroups.com, Leen Besselink <leen@...> wrote:
>
> On Tue, Dec 16, 2008 at 01:43:48AM -0000, Stephen M. McKamey wrote:
> > It appears that versions of http://json.org/json2.js starting
around
> > May 2008 have issues in Opera.  I've verified this in Opera 9.52
and
> > Opera 9.27.
> >
> > The issue appears in the RegExp on line 190 of the 2008-11-19
version.
> > My guess is that Opera does not like escaped unicode in literal
> > RegExp?  It throws a syntax error which causes the rest of the
script
> > to not load.
> >
> > Does anyone know of a fix or work-around for this?
> >
>
> Hi,
>
> My college and me at work noticed this as well, we made a patch for
> it at the time. It seems we forgot to report it. It's fixed in newer
> versions of Opera.
>
> --- json.js 2008/05/28 10:12:29 1.3
> +++ json.js 2008/06/13 07:04:16 1.4
> @@ -177,8 +177,8 @@
>                   f(this.getUTCSeconds())   + 'Z';
>          };
>
> -        var cx = /[\u0000\u00ad\u0600-
\u0604\u070f\u17b4\u17b5\u200c-\u200f\u2028-\u202f\u2060-
\u206f\ufeff\ufff0-\uffff]/g,
> -            escapeable = /[\\\"\x00-\x1f\x7f-\x9f\u00ad\u0600-
\u0604\u070f\u17b4\u17b5\u200c-\u200f\u2028-\u202f\u2060-
\u206f\ufeff\ufff0-\uffff]/g,
> +        var cx = new RegExp("[\u0000\u00ad\u0600-
\u0604\u070f\u17b4\u17b5\u200c-\u200f\u2028-\u202f\u2060-
\u206f\ufeff\ufff0-\uffff]", "g"),
> +            escapeable = new RegExp("[\\\"\x00-\x1f\x7f-
\x9f\u00ad\u0600-\u0604\u070f\u17b4\u17b5\u200c-\u200f\u2028-
\u202f\u2060-\u206f\ufeff\ufff0-\uffff]","g"),
>              gap,
>              indent,
>              meta = {    // table of character substitutions
>
> > Thanks in advance,
> > smm
> >
> > --- on Sat May 3, 2008 7:42 am, "Douglas Crockford" <douglas@>
> > wrote:
> > >
> > > There are several Unicode characters that JavaScript mishandles,
> > > either by silent deletion, or by treating them as line ending
> > characters.
> > >
> > > json2.js now escapes those characters when it parses and when it
> > > minifies, so they can now be used correctly in JSON
applications.
> > >
> > > http://www.JSON.org/json.js
> >
> _____________________________________
> New things are always on the horizon.
>

http://code.google.com/p/json-simple/

--
JSON: Action in AJAX!

JSON - http://www.json.org
JSON.simple - http://code.google.com/p/json-simple/


       ___________________________________________________________
   好玩贺卡等你发，邮箱贺卡全新上线！
http://card.mail.cn.yahoo.com/

2009/1/6 Fang Yidong <fangyidong@...>:
>
> http://code.google.com/p/json-simple/

Quick question: home page suggests that one benefit of the library is
high performance. How is this determined, i.e. how has it been tested,
and against which libraries? For Java there are at least half a dozen
alternatives parsers, so it should be easy to find things to benchmark
against, I just didn't see a link that shows the details of testing
done.

-+ Tatu +-

It's base on some internal testing and聽 testing of an independent author in
some complex scenarios.

The result show that the encoding of JSON.simple is as fast as Douglas's
implementation. The decoding is close to Douglas's implementation and faster
than some of the implementations, but slower than one or two of them.

The testing may not cover all scenarios and may not be completely fair, but
provides some basic information.

Hope there will be a public third party testing.

--

JSON: Action in AJAX!



JSON - http://www.json.org

JSON.simple - http://code.google.com/p/json-simple/














             2009/1/6 Fang Yidong <fangyidong@yahoo. com.cn>:

>

> http://code. google.com/ p/json-simple/



Quick question: home page suggests that one benefit of the library is

high performance. How is this determined, i.e. how has it been tested,

and against which libraries? For Java there are at least half a dozen

alternatives parsers, so it should be easy to find things to benchmark

against, I just didn't see a link that shows the details of testing

done.



-+ Tatu +-

























       ___________________________________________________________
   濂界帺璐哄崱绛変綘鍙戯紝閭璐哄崱鍏ㄦ柊涓婄嚎锛�
http://card.mail.cn.yahoo.com/

[Non-text portions of this message have been removed]

On Thu, Jan 8, 2009 at 12:57 AM, Fang Yidong <fangyidong@...> wrote:
> It's base on some internal testing and  testing of an independent author in
some complex scenarios.
>
> The result show that the encoding of JSON.simple is as fast as Douglas's
implementation. The decoding is close to Douglas's implementation and faster
than some of the implementations, but slower than one or two of them.
>
> The testing may not cover all scenarios and may not be completely fair, but
provides some basic information.
>
> Hope there will be a public third party testing.

Thank you for quick answer! Would it be maybe possible to publish
results of these internal tests? And/or maybe just cut'n paste your
explanation -- it helps a lot in understanding what has been measured.
For what it's worth, json.org's reference implementation is not among
the fastest parsers, but I guess it is a reasonable baseline to
compare against.

I can probably help with testing, too, since I do have a test suite I
have used previously (but not with json.simple since I didn't know of
its existence).

-+ Tatu +-

It will be great if you can add JSON.simple (latest version 1.0.2) in your test
suite and let me know the results.

I'll publish the testing source codes and results if appropriate, later.
聽
Thanks.
聽
--
JSON: Action in AJAX!

JSON - http://www.json.org
JSON.simple - http://code.google.com/p/json-simple/

---






On Thu, Jan 8, 2009 at 12:57 AM, Fang Yidong <fangyidong@yahoo. com.cn> wrote:
> It's base on some internal testing and testing of an independent author in
some complex scenarios.
>
> The result show that the encoding of JSON.simple is as fast as Douglas's
implementation. The decoding is close to Douglas's implementation and faster
than some of the implementations, but slower than one or two of them.
>
> The testing may not cover all scenarios and may not be completely fair, but
provides some basic information.
>
> Hope there will be a public third party testing.

Thank you for quick answer! Would it be maybe possible to publish
results of these internal tests? And/or maybe just cut'n paste your
explanation -- it helps a lot in understanding what has been measured.
For what it's worth, json.org's reference implementation is not among
the fastest parsers, but I guess it is a reasonable baseline to
compare against.

I can probably help with testing, too, since I do have a test suite I
have used previously (but not with json.simple since I didn't know of
its existence).

-+ Tatu +-















       ___________________________________________________________
   濂界帺璐哄崱绛変綘鍙戯紝閭璐哄崱鍏ㄦ柊涓婄嚎锛�
http://card.mail.cn.yahoo.com/

[Non-text portions of this message have been removed]

Doug, I realized that I hadn't sent you note about Jackson json
processor moving to Codehaus.
Could you update the link at json.org to point to:

http://jackson.codehaus.org

(the old page is still there and will redirect, so it's not a huge
deal, but eventually it'll move over completely)

Also: on a related note, would it make sense to start
classifying/grouping projects more on that page? Or adding some
tagging to indicate rough functionality. Right now level of json
functionality for Java libs varies a lot, for example: some libraries
are for xml processing but also expose interoperability functionality
for json; whereas others are json parsers, data binding packages and
so on.

-+ Tatu +-

--- In json@yahoogroups.com, Tatu Saloranta <tsaloranta@...> wrote:
>
> Doug, I realized that I hadn't sent you note about Jackson json
> processor moving to Codehaus.
> Could you update the link at json.org to point to:
>
> http://jackson.codehaus.org

Updated. Thanks.

> Also: on a related note, would it make sense to start
> classifying/grouping projects more on that page? Or adding some
> tagging to indicate rough functionality. Right now level of json
> functionality for Java libs varies a lot, for example: some libraries
> are for xml processing but also expose interoperability functionality
> for json; whereas others are json parsers, data binding packages and
> so on.

Would you like to propose something?

The Python community was able to converge on a single library. The
Java community has not yet, as far as I can tell, shown any intention
to converge.

On Fri, Jan 16, 2009 at 1:26 PM, Douglas Crockford
<douglas@...> wrote:
> --- In json@yahoogroups.com, Tatu Saloranta <tsaloranta@...> wrote:
>>
>> Doug, I realized that I hadn't sent you note about Jackson json
>> processor moving to Codehaus.
>> Could you update the link at json.org to point to:
>>
>> http://jackson.codehaus.org
>
> Updated. Thanks.

Thank you.

>> Also: on a related note, would it make sense to start
>> classifying/grouping projects more on that page? Or adding some
>
> Would you like to propose something?
>
> The Python community was able to converge on a single library. The
> Java community has not yet, as far as I can tell, shown any intention
> to converge.

I think convergence will happen via sort of natural selection over
time... although it might not be bad to have one or more APIs similar
to SAX/Stax. So for now it's ok to let all flowers bloom. :)

My suggestion would be more modest: to try to indicate what kind of
things libs are capable of, to help users more easily find what they
are looking for.
This is partly due to high number of json processing tools available
on java platform.

-+ Tatu +-

The JSON.stringify function builds a JSON text using the own
properties of the objects it is given. If you want the text to also
include the inherited properties, then you can provide a replacer
function parameter that causes all of the members to be included. For
example,

JSON.stringify(n, function replacer(key, value) {
     var i, new_value;

     switch (typeof value) {
     case 'function':
     case 'undefined':
         return;
     case 'object':
         if (value &&
                 Object.prototype.toString.apply(value) !==
                      '[object Array]') {
             new_value = {};
             for (i in value) {
                 new_value[i] = value[i];
             }
             return new_value;
         }
         return value;
     default:
         return value;
     }
} , 4)

Please check out my new C++ JSON interface library at:

http://cajun-jsonapi.sourceforge.net/

What makes it better than the others already available? A major goal
of the library was a powerful interface but a short learning curve.
The C++ Standard Template Library served as an inspiration for the
interface, and so should be immediately intuitive to anyone familiar
with the language. See the release notes for lots more information:

http://sourceforge.net/project/shownotes.php?
group_id=251569&release_id=658013


Cheers,
Terry

Does this interface allow the JSON data to be streamed in?

Thanks,
Mark
P6R, Inc


On Tue, 03 Feb 2009 12:26:31 -0000
   "terry_caton" <lc840c@...> wrote:
> Please check out my new C++ JSON interface library at:
>
> http://cajun-jsonapi.sourceforge.net/
>
> What makes it better than the others already available?
>A major goal
> of the library was a powerful interface but a short
>learning curve.
> The C++ Standard Template Library served as an
>inspiration for the
> interface, and so should be immediately intuitive to
>anyone familiar
> with the language. See the release notes for lots more
>information:
>
> http://sourceforge.net/project/shownotes.php?
> group_id=251569&release_id=658013
>
>
> Cheers,
> Terry
>
>

-------------------------
Mark Joseph, Ph.D.
President and Secretary
P6R, Inc.
http://www.p6r.com
408-205-0361
Fax: 831-476-7490
Skype: markjoseph_sc
IM: (Yahoo) mjoseph8888
      (AIM) mjoseph8888

JSON.simple introduces a simplified and stoppable SAX-like content handler to
process JSON text stream. Please take a look if you are interested in it:

http://code.google.com/p/json-simple/wiki/DecodingExamples#Example_5_-_Stoppable\
_SAX-like_content_handler


--
JSON: Action in AJAX!

JSON - http://www.json.org
JSON.simple - http://code.google.com/p/json-simple/


       ___________________________________________________________
   好玩贺卡等你发，邮箱贺卡全新上线！
http://card.mail.cn.yahoo.com/

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the json
group.

   File        : /json-lib-1_0_2.zip
   Uploaded by : shawnsilverman <shawn@...>
   Description : A Java library for processing JSON data.

You can access this file at the URL:
http://groups.yahoo.com/group/json/files/json-lib-1_0_2.zip

To learn more about file sharing for your group, please visit:
http://help.yahoo.com/l/us/yahoo/groups/original/members/web/index.htmlfiles

Regards,

shawnsilverman <shawn@...>

--- In json@yahoogroups.com, "Mark Joseph" <mark@...> wrote:
>
> Does this interface allow the JSON data to be streamed in?
>

Yes it does. In fact, the library's built-in
input/output capability is based on the standard
istream & ostream classes, so any C++ stream-based
file/network/console interface should work automagically.
Furthermore, this stream-based serialization is
implemented "externally" via the visitor pattern,
which facilitates the straighforward implementation of
additional operations (graph rendering, document
validation, custom network streaming, etc).