Two changes to the reference implementation.
JSONObject will keep a LinkedHashMap, so that new JSONObject(new
LinkedHashMap()) can be used to make ordered objects. Thanks, Jonathan
Hefner.
A JSONTokener can now be a reader. Thanks, Til Schneider.
json2.js and JSONObject.java use different definitions of
"control-character". json.org seems to leave the term undefined.
What's the real answer and why isn't it written on the json.org
homepage?
Thanks,
--Tyler
On Tue, Jul 1, 2008 at 1:50 PM, Douglas Crockford <douglas@...> wrote:
> Two changes to the reference implementation.
>
> JSONObject will keep a LinkedHashMap, so that new JSONObject(new
> LinkedHashMap()) can be used to make ordered objects. Thanks, Jonathan
> Hefner.
>
> A JSONTokener can now be a reader. Thanks, Til Schneider.
>
>
--- In json@yahoogroups.com, "Tyler Close" <tyler.close@...> wrote:
>
> json2.js and JSONObject.java use different definitions of
> "control-character". json.org seems to leave the term undefined.
> What's the real answer and why isn't it written on the json.org
> homepage?
The RFC says: All Unicode characters may be placed within the
quotation marks except for the characters that must be escaped:
quotation mark, reverse solidus, and the control characters (U+0000
through U+001F).
It turns out that some implementations of JavaScript's eval function
delete some characters before evaluation. (I hope to correct this in
the next edition of the ECMAScript Standard.)
On Wed, Jul 2, 2008 at 9:08 AM, Douglas Crockford <douglas@...> wrote:
> It turns out that some implementations of JavaScript's eval function
> delete some characters before evaluation. (I hope to correct this in
> the next edition of the ECMAScript Standard.)
In the meantime, does the json2.js definition of control character
cover all the potentially dangerous characters? Shouldn't all JSON
emitters be escaping these characters, since the output might be
consumed by a Javascript eval() function. Since following the RFC
currently results in potentially unsafe JSON output, putting the
control character definition on the json.org homepage seems wise.
I wonder how many different definitions of control character are used
in the collection of implementations at the bottom of the JSON.org
homepage.
--Tyler
--- In json@yahoogroups.com, "Tyler Close" <tyler.close@...> wrote:
>
> On Wed, Jul 2, 2008 at 9:08 AM, Douglas Crockford <douglas@...> wrote:
> > It turns out that some implementations of JavaScript's eval function
> > delete some characters before evaluation. (I hope to correct this in
> > the next edition of the ECMAScript Standard.)
>
> In the meantime, does the json2.js definition of control character
> cover all the potentially dangerous characters?
Yes.
> Shouldn't all JSON
> emitters be escaping these characters, since the output might be
> consumed by a JavaScript eval() function. Since following the RFC
> currently results in potentially unsafe JSON output, putting the
> control character definition on the json.org homepage seems wise.
>
> I wonder how many different definitions of control character are used
> in the collection of implementations at the bottom of the JSON.org
> homepage.
So far this hasn't appeared to be a problem. I haven't seen
applications flinging around a lot of the Cf characters that get
deleted by Firefox before eval.
For applications that need Cf characters in strings that don't want to
have to escape them, a non-eval parser should be used, such as
http://www.json.org/json_parse.js or
http://www.json.org/json_parse_state.js.
On Thu, Jul 3, 2008 at 8:31 AM, Douglas Crockford <douglas@...> wrote:
> So far this hasn't appeared to be a problem. I haven't seen
> applications flinging around a lot of the Cf characters that get
> deleted by Firefox before eval.
I'd be more worried about web apps that accept user input and so could
be made to traffic in Cf characters without having thought about it. A
tricky user might then be able to exploit the fact that strings
silently change value when being passed back and forth by the
application.
--Tyler
--- In json@yahoogroups.com, "Tyler Close" <tyler.close@...> wrote:
>
> On Thu, Jul 3, 2008 at 8:31 AM, Douglas Crockford <douglas@...> wrote:
> > So far this hasn't appeared to be a problem. I haven't seen
> > applications flinging around a lot of the Cf characters that get
> > deleted by Firefox before eval.
>
> I'd be more worried about web apps that accept user input and so could
> be made to traffic in Cf characters without having thought about it. A
> tricky user might then be able to exploit the fact that strings
> silently change value when being passed back and forth by the
> application.
That is a serious problem when using a naked eval. So json.js contains
this step:
text = text.replace(cx, function (a) {
return '\\u' + ('0000' +
(+(a.charCodeAt(0))).toString(16)).slice(-4);
});
It converts the flimsy characters to escape sequences before eval so
that they are preserved.
Maybe I'm just going crazy, but in a previous version of json.js (or
maybe json2.js) did the .toISOString function wrap an extra set of ""
(double quotes) around the converted date string?
Was this removed at some point? just wondering why. Although, it never
really made sense to me to begin with, so +1 for removing them. I'm
just trying to get a confirmation on what is considered "correct" now.
I apologize if this has already been discussed. I could not find
anything on topic.
Mr. Crockford,
In your "Recommendations for the Fourth Edition of the ECMAScript
Programming Language Specification"
(http://www.crockford.com/javascript/recommend.html) post you mention
two additions to the Date object...
1. date.toJSONString()
2. date.toISOString()
Can you elaborate on the what you see as the return difference between
the two? Would toISOString use UTC and toJSONString use local time?
Any insight you can provide would be helpful.
--- In json@yahoogroups.com, "geoffrey.mcgill" <geoff@...> wrote:
>
> Maybe I'm just going crazy, but in a previous version of json.js (or
> maybe json2.js) did the .toISOString function wrap an extra set of ""
> (double quotes) around the converted date string?
I think you are confusing toJSON with toJSONString. The toJSON method
(which is supported by json2.js and is likely to be included in the
next ECMAScript standard) allows an object to specify a value that
will be serialized. The toJSONString method (which is no longer
recommended) allows an object to return its own serialization string.
I would be interested in both attending and presenting.
Best,
Mark
P6R. Inc
On Mon, 07 Jul 2008 19:15:10 -0000
"Douglas Crockford" <douglas@...> wrote:
> Would you be interested in attending and possibly
>presenting at a JSON
> Conference? Is there broad enough interest in JSON to
>justify an event?
>
-------------------------
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
On Mon, Jul 7, 2008 at 12:15 PM, Douglas Crockford
<douglas@...> wrote:
> Would you be interested in attending and possibly presenting at a JSON
> Conference? Is there broad enough interest in JSON to justify an event?
How about if we broaden the agenda to "Safe subsets of JavaScript"? In
addition to JSON itself, there are quite a lot of language experiments
currently attempting to define safe subsets: ADsafe, Caja/Cajita,
FBJS, Jacaranda, Capsol/dojox.secure.
--
Cheers,
--MarkM
Yes!
(I implemented server-side support for JSON and JSONRequest in mod_ndb, and I'd
especially
like the chance to talk with people working on the browser and client side...)
--- In json@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
> Would you be interested in attending and possibly presenting at a JSON
> Conference? Is there broad enough interest in JSON to justify an event?
>
Oh, I think there's plenty of interest in JSON. What I wonder is if there's
enough material, without the conference devolving into a set of use case
presentations (nothing wrong with use cases, but a conference full of them
wouldn't be interesting to me) and / or presentations on a never-ending
series of "me too" JSON implementations.
If a JSON conference was to materialise, though, I would hope that everyone
would do their best to disabuse attendees of the notion that it has any
serious ties to JavaScript (in contrast to an earlier post suggesting that
the conference be expanded to include other subsets of JavaScript), since,
if anything is holding back adoption, it's the assumption that it's tied to
the JavaScript language.
--
Martin Cooper
On Mon, Jul 7, 2008 at 12:15 PM, Douglas Crockford <douglas@...>
wrote:
> Would you be interested in attending and possibly presenting at a JSON
> Conference? Is there broad enough interest in JSON to justify an event?
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
[Non-text portions of this message have been removed]
> If a JSON conference was to materialise, though, I would
>hope that everyone
> would do their best to disabuse attendees of the notion
>that it has any
> serious ties to JavaScript (in contrast to an earlier
>post suggesting that
> the conference be expanded to include other subsets of
>JavaScript), since,
> if anything is holding back adoption, it's the
>assumption that it's tied to
> the JavaScript language.
>
I agree with this. JSON has lots of other applications
than just Javascript. Our customers want support for
JSON in C++ applications.
Best,
-------------------------
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
Yes. It's really important to JSON.
--- Douglas Crockford <douglas@...>:
> Would you be interested in attending and possibly
> presenting at a JSON
> Conference? Is there broad enough interest in JSON
> to justify an event?
>
>
--
JSON: Action in AJAX!
JSON - http://www.json.org
JSON.simple - http://www.json.org/java/simple.txt
___________________________________________________________
ÑÅ»¢ÓÊÏ䣬ÄúµÄÖÕÉúÓÊÏ䣡
http://cn.mail.yahoo.com/
Yes, I would be interested in attending.
An about some comments regarding endless repetition of use cases, I believe
the problem could be solved by someone (presumably you Douglas) presenting
an agenda of possible topics where people interested in exposing their job
could apply for each topic.
By proceeding in this way, if no one applies for most of the topics, may be
there is not enough material as to celebrate the conference. If there are
too many people for the same topic, some filtering could be required (as
evaluation of a written version of the presentation by a small team leadered
by you). In both cases you could keep conference content complete enough as
to be interesting for anybody related with the technology and avoid
monotonous repetition on the same subject.
Regards,
2008/7/7 Douglas Crockford <douglas@...>:
> Would you be interested in attending and possibly presenting at a JSON
> Conference? Is there broad enough interest in JSON to justify an event?
>
>
>
[Non-text portions of this message have been removed]
I think there would be enough interest, and I would try to attend.
A lot of us are using JSON in production today, so I think you would have to
find interesting presentations on the topic to garner attendants. The
downside of it being so simple to use, is that we are already using it in
all sorts of places. It would really have to be about good usage examples
and interesting roles for it. An online show case might serve the same goal,
minus the face to face...
--
Matthew P. C. Morley
[Non-text portions of this message have been removed]
I would be very interested. I love hearing about new applications and
tools of JSON since it's my data transportation/storage of choice.
--- In json@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
> Would you be interested in attending and possibly presenting at a JSON
> Conference? Is there broad enough interest in JSON to justify an event?
>
It appears there's enough support for a conference. If it materializes I'll do
my best to attend. Good usage examples would be very useful.
-------------- Original message from "Matthew Morley" <WickedLogic@...>:
--------------
I think there would be enough interest, and I would try to attend.
A lot of us are using JSON in production today, so I think you would have to
find interesting presentations on the topic to garner attendants. The
downside of it being so simple to use, is that we are already using it in
all sorts of places. It would really have to be about good usage examples
and interesting roles for it. An online show case might serve the same goal,
minus the face to face...
--
Matthew P. C. Morley
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
I'd be interested in both attending and possibly presenting.
--- In json@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
> Would you be interested in attending and possibly presenting at a JSON
> Conference? Is there broad enough interest in JSON to justify an event?
>
hi john,
your server side implementation of JSONRequest combined with a js
library that wrapped client side technologies (browserplus, gears,
flash, etc) could perhaps make JSONRequest a reality in the short
term... meet you at the conference?
lloyd
--- In json@yahoogroups.com, "jddefn" <john.david.duncan@...> wrote:
>
> Yes!
>
> (I implemented server-side support for JSON and JSONRequest in
mod_ndb, and I'd especially
> like the chance to talk with people working on the browser and
client side...)
>
>
> --- In json@yahoogroups.com, "Douglas Crockford" <douglas@> wrote:
> >
> > Would you be interested in attending and possibly presenting at a JSON
> > Conference? Is there broad enough interest in JSON to justify an
event?
> >
>
--- In json@yahoogroups.com, "Phil Gibbs" <randomnoise@...> wrote:
> It appears there's enough support for a conference.
Yes, there is interest. I am thinking to hold the conference in
California, perhaps in San Francisco or San Jose.
So the planning begins. What is your estimate of the number of people
who will attend?
On Jul 8, 2008, at 10:37, Douglas Crockford wrote:
> So the planning begins. What is your estimate of the number of people
> who will attend?
It really depends on more details of what sort of talks will be there.
JSON itself is boring. Novel ways to use it are interesting.
- ask
--
http://develooper.com/ - http://askask.com/
Anything non-east coast mostly kills it for me, especially with the on going
issues of air travel. But I know I'm in the minority here.
Hopefully if something comes about, it'll be recorded and put online for
those who cannot make it. : )
--
Matthew P. C. Morley
[Non-text portions of this message have been removed]
I added toJSON methods to Boolean, Number, and String. This makes
simple type wrappers work correctly, so
JSON.stringify(new String('string'))
produce "string". If you don't use the type wrappers (and it is best
that you don't) then you can delete those methods.
Anybody had any luck using these two together?
Specifically, if the payload of the request and or response is json,
then is the payload required to be wrapped in a soap envelope?