A new version of json.js is available. It corrects a problem in
parseJSON where it was possible to have the contents of one of the
caller's variables included in the decoded value.

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

Here is the link
http://ketankhairnar.blogspot.com/2007/06/json-utility-using-asm-java-bytecode.h\
tml

let me know what you think...

I have been working on putting together a proposal for a JSON Schema. I
have been collaborating with some others, but I wanted to elicit
feedback, input, and suggestions from the JSON group. The current
proposal which is definitely still a work in progress is at:
http://www.json.com/json-schema-proposal/
and some questions/issues are at:
http://www.json.com/2007/10/02/json-schema-proposal-rfc/

JSON Schema is a specification for a JSON-based format for defining the
structure of JSON data. JSON Schema provides a contract for what JSON
data is required for a given application and how it can be modified,
much like what XML Schema provides for XML. JSON Schema is intended to
provide validation, documentation, and interaction control of JSON data.

I wanted to initiate some dialogue about JSON referencing conventions. I did
a write up at http://www.json.com/2007/10/09/json-referencing-schemes/ on a
number of the different proposed approaches to doing referencing (most are
for the the purpose of circular referencing), and I wanted to elicit
feedback on these approaches and hopefully be able to converge as community
on a consistent convention for referencing in JSON.
Thanks,
Kris


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

On Sep 22, 2007, at 8:27 PM, Douglas Crockford wrote:

>> Is the "JSONRequest" header
>> supposed to be there, in this response?
>>    ...
> I see what you mean. No, that isn't supposed to be there.
> I have corrected it. Thank you.


Thanks!  I have one more thought about the proposal.

The Firefox plugin chooses to send an "Accept: application/
jsonrequest" header with the request, and I agree with this idea.
The proposal says that if the request is application/jsonrequest,
then the response must also be application/jsonrequest; the Accept
header spells out this requirement plainly in HTTP.   In my opinion,
the header should be mandatory.


JD

A design error in Firefox could allow parseJSON to include an eval
function object in the resulting JSON object. This situation will now
raise an exception.

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

Hi,

I have a JSON object whose structure is like this:

The name of the object is 'Emp' and the attributes are:
name
age
sex
department
address

Later in my javascript code, I have to check if the JSON object's
value matches with my local value. For this I have to check

if (Emp.name == localvar.name) ...
if (Emp.age == localvar.age) ...

But the problem is I cannot know which of the attributes will come
first for comparison, as no predefined order is allowed.
So I have to first find out the current element of 'Emp' and
accordingly compare the local variable with it.
The problem is I cann't find the current element. Can someone pls
tell me a way.

Thanks.

Will this work?

Emp["localvar.name"]


To: json@...: mahesh_mission@...: Thu, 11 Oct 2007
05:19:55 +0000Subject: [json] Accessing a JSON element name (metadata)




Hi,I have a JSON object whose structure is like this:The name of the object is
'Emp' and the attributes are:nameagesexdepartmentaddressLater in my javascript
code, I have to check if the JSON object's value matches with my local value.
For this I have to checkif (Emp.name == localvar.name) ...if (Emp.age ==
localvar.age) ...But the problem is I cannot know which of the attributes will
come first for comparison, as no predefined order is allowed. So I have to first
find out the current element of 'Emp' and accordingly compare the local variable
with it.The problem is I cann't find the current element. Can someone pls tell
me a way.Thanks.






_________________________________________________________________
It's simple! Sell your car for just $30 at CarPoint.com.au
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fsecure%2Dau%2Eimrworldwide%2Ecom\
%2Fcgi%2Dbin%2Fa%2Fci%5F450304%2Fet%5F2%2Fcg%5F801459%2Fpi%5F1004813%2Fai%5F8596\
41&_t=762955845&_r=tig_OCT07&_m=EXT

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

--- In json@yahoogroups.com, John David Duncan <john.david.duncan@...>
wrote:

> The Firefox plugin chooses to send an "Accept: application/
> jsonrequest" header with the request, and I agree with this idea.
> The proposal says that if the request is application/jsonrequest,
> then the response must also be application/jsonrequest; the Accept
> header spells out this requirement plainly in HTTP.   In my opinion,
> the header should be mandatory.

You're right.

I'm the type of person that is pretty impatient, and given the past
history of browsers with regards to adopting standards, I'm curious on
anyone's feelings on implementing JSONRequest before the browser's
officially do (obviously FF has a plugin but it's gotta be in IE at a
miminum before anyone seriously begins to adopt--also I'd say Safari
and then Opera would be pretty important overall).

I tend to think that we should just keep pushing the envelope and not
wait on browsers--I mean, after all, AJAX is just a ton of hacks and
workarounds pushing the current envelope to it's limit, and look what
interest it's created.  And like with XMLHTTPRequest, it got used
first and then became a standard... why not with JSON?

In my mind, there are really three ways to do it:

1) Build and maintain plugin for every major browser.
2) Build JSON on top of Flash flash.net.socket
3) Build JSON on top of Java Applet

And pro/cons of each:

1)
* Pro: No requirement on another technology
* Con: Installation process must be extremely painless. Failure to do
so is failure for widespread adoption. (Ask applets about this)
* Con: Personally not sure if every browser offers a plugin model deep
enough to implement JSON.
* Con: Have to build & maintain multiple plugins for wildly different
plugin models.

2)
* Pro: Flash is most ubiquitous of plugins
* Pro: Build on
* Pro: No security prompt for cross-domain requests.  (instead policy
file at root of origin domain indicates which other domains are
acceptable).
* Con: flash.net.socket does not support SSL (no indication if or when
that I can see), but one could build HTTP transport with it
* Con: XmlHTTPRequest within Flash uses same mechanism of browser,
which bothers me a bit because of max of 2 concurrent requests per
domain by default in IE/FF.  I assume one can't control cookies or all
headers as well with XHR either so that's a problem.

3)
* Pro: Java Applet is extremely capable as a development
environment--most powerful/most flexible.
* Con: Cross-domain requests required signed jar which require use to
click YES when the applet loads to security prompt.
* Con: not as widely adopted compared to Flash


With the later two solutions, one would have to build a javascript
bridge from the context of the flash player or applet.


Anyway, does any one have strong feelings about any of these 3
approaches, has a different idea, or thinks we should just wait for
browsers?

Seth

JSON JavaScript Object NotationCisco, have you tried Subspace/CrossSafe
(http://www.xucia.com/page/CrossSafe)? It is a JS library that provides secure
cross-domain JSON requests using iframes and JSONP and implements part of the
JSONRequest spec, but defers to the plugin when it is available. You can add
that to your list of options.
Kris


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

Hi,

one thing I didn't get a answer yet about security: I expect that NTLM is
not working with JSONRequest, too, is that correct?

Some other questions while implementing a client plugin: must there be a
maximum timeout value? I think that it makes no sence to run requests longer
than 10 seconds. What about the user-agent string, will this be sent or not?
Why only send the domain, doesn't the complete Uri makes sence?

And one last question: does the JSON server need to support HTTP 1.0, or is
it mandatory to support HTTP 1.1 only?

Michael



On 10/11/07, Douglas Crockford <douglas@...> wrote:
>
>   --- In json@yahoogroups.com <json%40yahoogroups.com>, John David Duncan
> <john.david.duncan@...>
> wrote:
>
> > The Firefox plugin chooses to send an "Accept: application/
> > jsonrequest" header with the request, and I agree with this idea.
> > The proposal says that if the request is application/jsonrequest,
> > then the response must also be application/jsonrequest; the Accept
> > header spells out this requirement plainly in HTTP. In my opinion,
> > the header should be mandatory.
>
> You're right.
>
>
>



--
Best regards | Schöne Grüße
Michael

Microsoft MVP - Most Valuable Professional
Microsoft MCAD - Certified Application Developer

http://weblogs.asp.net/mschwarz/
http://www.ajaxpro.info/

Skype: callto:schwarz-interactive
MSN IM: passport@...


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

hi all

i am seeking an Java based of JSON that can convert JSON become URL,

this is called URLEncoder and URLDecoder,

anyone have it?

FransThamura
Indonesia

--- In json@yahoogroups.com, "Michael Schwarz" <michael.schwarz@...>
wrote:
> Some other questions while implementing a client plugin:

Can you tell us which platform you are developing a client plugin for?

> Why only send the domain, doesn't the complete Uri makes sence?

The browser's security policy isn't granular enough to separate URIs
into separate security contexts, so it would be easy for a site to
spoof any URI within the page's a given domain by injecting script
tags into other pages. Also, in Firefox (for example) there are many
scenarios where a page has URI that does not specify a domain
(about:blank, or a javascript: URI) yet the page does have a domain
according to the browser.

To make this header match the browser's security policy, it would be
possible to set a header of the form scheme://domain:port (with no
path included), but I'm not sure whether this is necessary.

Hi,

On 10/14/07, collin_jackson <yahoo@...> wrote:
> --- In json@yahoogroups.com, "Michael Schwarz" <michael.schwarz@...>
> wrote:
> > Some other questions while implementing a client plugin:
>
> Can you tell us which platform you are developing a client plugin for?

I write one for Mac and Windows, well, it is not a real plugin, but a
way to integrate it in you web pages.



> > Why only send the domain, doesn't the complete Uri makes sence?
>
> The browser's security policy isn't granular enough to separate URIs
> into separate security contexts, so it would be easy for a site to
> spoof any URI within the page's a given domain by injecting script
> tags into other pages. Also, in Firefox (for example) there are many
> scenarios where a page has URI that does not specify a domain
> (about:blank, or a javascript: URI) yet the page does have a domain
> according to the browser.
>

What I thought was pages like aol.com/users/xxxx or
t-online.de/home/xxxx. Where is the "domain" specified, I thought it
will use the Web browsers location always, which in my mind is not
speficic enough.

Michael



> To make this header match the browser's security policy, it would be
> possible to set a header of the form scheme://domain:port (with no
> path included), but I'm not sure whether this is necessary.
>
>



--
Best regards | Schöne Grüße
Michael

Microsoft MVP - Most Valuable Professional
Microsoft MCAD - Certified Application Developer

http://weblogs.asp.net/mschwarz/
http://www.ajaxpro.info/

Skype: callto:schwarz-interactive
MSN IM: passport@...

Hello all,

http://lloydforge.org/projects/yajl/

This is a fast, lightweight, portable JSON
parsing/generation/validation library.  It's design goals were to
provide fast stream based event driven parsing that is representation
agnostic.

The concrete problem that motivated it's creation was that often I'm
using JSON in network protocols, and in performance critical
situations it's suboptimal to A) wait for all the data to arrive
before we start parsing, and B) map everything into the data
representation that the parsing library provides, then re-map it into
the representation of the application that embeds the library.

Aside from these performance related edge cases, I hope it's something
that's generally applicable.  It also comes with a command line json
validator and json pretty printer/minimizer.

Finally, it's possible to write small libraries on top of yajl which
provide a convenient data representation.

I'm interested in hearing all bug reports, and know there are
currently a couple open issues (heard a complaint that the parser is
too lenient on accepting invalid UTF-8 inside strings).

Also, if anyone is interested in helping me build MacPorts/FreeBSD
ports/RPMs for this thing, please holler.  I'd love the help.

hope this is useful,
lloyd hilaiel

The original version of json.js had a JSON object containing stringify
and parse methods. When the opportunity to add JSON support to the
next proposed standard for ECMAScript, the methods changed to toString
and parseJSON.

In retrospect, I think the original form was better. I have posted
json2.js which has JSON.stringify (which looks for the presence of a
toJSON method in the objects it stringifies), and JSON.parse (which
can still accept a filter function).

http://www.JSON.org/json2.js

I've been using my C# JSON parser for about a year now as I've been
building out a larger end-to-end Ajax framework.  Last week, I released
the JSON parser which the framework is built upon.

The parser/serializer is written in C# and is intended to be as easy to
use as XML serialization in .NET.  It includes the option to control
serialization using attributes or implementing an interface.  It has
the ability to serialize and deserialize strongly-typed classes.

Until the entire framework is available, I encourage you to try out the
parser:

     http://jsonfx.net/BuildTools/

Thanks,
Stephen McKamey

I for one totally agree with the decision to revert to the original API.
While I know that defensive enumeration is good practice, I really
appreciate keeping an unpolluted Object.prototype and Array.prototype. Thank
you Douglas, I think that was a good decision!
Kris


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

Thank you for implmenting this.  this make the code so much cleaner.

Now if we can just get the Prototype library to stop overloading
Object....

--- In json@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
> The original version of json.js had a JSON object containing
stringify
> and parse methods. When the opportunity to add JSON support to the
> next proposed standard for ECMAScript, the methods changed to
toString
> and parseJSON.
>
> In retrospect, I think the original form was better. I have posted
> json2.js which has JSON.stringify (which looks for the presence of
a
> toJSON method in the objects it stringifies), and JSON.parse (which
> can still accept a filter function).
>
> http://www.JSON.org/json2.js
>

Great job, Douglas.

There is a typo in the initial multiline comment at line 57, it says
JON.parse

On 10/30/07, Ric Johnson <RicJohnsonIII@...> wrote:
>
>   Thank you for implmenting this. this make the code so much cleaner.
>
> Now if we can just get the Prototype library to stop overloading
> Object....
>
> --- In json@yahoogroups.com <json%40yahoogroups.com>, "Douglas Crockford"
> <douglas@...> wrote:
> >
> > The original version of json.js had a JSON object containing
> stringify
> > and parse methods. When the opportunity to add JSON support to the
> > next proposed standard for ECMAScript, the methods changed to
> toString
> > and parseJSON.
> >
> > In retrospect, I think the original form was better. I have posted
> > json2.js which has JSON.stringify (which looks for the presence of
> a
> > toJSON method in the objects it stringifies), and JSON.parse (which
> > can still accept a filter function).
> >
> > http://www.JSON.org/json2.js
> >
>
>
>



--
Blog: http://justavo.blogsome.com/


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

What would be the recommended way of converting the result of an
regexp.exec(str) method call to JSON? The result is an array but with
two extra properties; index and input.

http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Glob
al_Objects:RegExp:exec

If I use stringify then I just get the array elements and the index
and input properties are missing. Is there a way of tricking the
stringify function into treating this as an object rather than an
array so I can get all the elements/properties/values?

--- In json@yahoogroups.com, "Jim Fricker" <yahoo@...> wrote:
>
> What would be the recommended way of converting the result of an
> regexp.exec(str) method call to JSON? The result is an array but with
> two extra properties; index and input.
>
> If I use stringify then I just get the array elements and the index
> and input properties are missing. Is there a way of tricking the
> stringify function into treating this as an object rather than an
> array so I can get all the elements/properties/values?


myObject = {index: myArray.index, input: myArray.input, array: myArray};
jsontext = JSON.stringify(myObject);

Quick note: there is a new JSON processor (parser, generator, simpler
mapping tools) written in Java called Jackson.

It's available from:

http://www.cowtowncoder.com/hatchery/jackson/index.html

and dual-licensed under either ASL or LGPL.

I have also done some performance benchmarking using Japex performance
test suite, using other existing json implementations I was able to
find. If anyone is interested in those, this blog entry has links to
results and source code:

http://www.cowtowncoder.com/blog/archives/2007/10/entry_50.html

-+ Tatu +-

--- In json@yahoogroups.com, "Frans Thamura" <frans@...> wrote:
>
> hi all
>
> i am seeking an Java based of JSON that can convert JSON become URL,
>
> this is called URLEncoder and URLDecoder,
>
> anyone have it?

How would it do this? Using naming convention to map JSON elements
into URL query parameters? ( { "value" : { "a" : 1, "b" : "abc" } ->
http://...?value.a=1&value.b=abc ?)

If so, that'd be a useful mapping tool, and one not too difficult to
write.

-+ Tatu +-

In my search for a convenient way to represent XHTML DOM elements, I
assembled some ideas of how to apply the native JavaScript objects to
the W3C DOM objects.  I call this assembly of ideas JSoda.

JSoda is JSON compliant <http://jsoda.info/JSoda+and+JSON> , so that a
DOM element represented as a JSoda object can be stored or transmitted
as JSON and utilize existing JSON solutions.

The details are located at http://jsoda.info/ <http://jsoda.info/> .
The site also contains an MIT licensed script
<http://jsoda.info/Object.toDOM#script>  for parsing JSoda objects into
their DOM counterparts.  A simple (X)HTML to JSoda converter
<http://jsoda.info/DOM+to+JSoda>  is also provided.

JSON-related comments or suggestions can be made in reply to this post.
If you have any input that is not JSON related, such as problems with
the site or JSoda improvement suggestions, please send an email to
notalanguage at jsoda dot info.

Looking forward to your feedback!


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

Those interested in JSoda should also check out JsonML.  JsonML is a
more compact representation and is fast for converting any XML to JSON.

Example client scripts and XSLT are available at: http://jsonml.org

IBM developerWorks wrote an excellent tutorial:
http://www.ibm.com/developerworks/library/x-jsonml/

Coming soon is an Ajax framework which has native JsonML support for
ASP.NET: http://jsonfx.net/Architecture/

--- In json@yahoogroups.com, "Kyle Alan Hale" <kylealanhale@...> wrote:
>
> In my search for a convenient way to represent XHTML DOM elements, I
> assembled some ideas of how to apply the native JavaScript objects to
> the W3C DOM objects.  I call this assembly of ideas JSoda.

Indeed, JSoda and JsonML serve much the same purpose, but with
slightly different styles and goals.

> JsonML is a more compact representation

This is probably the best reason to choose Stephen's JsonML over
JSoda.  A JSoda object is much more verbose by design, which has some
readability and usability advantages over JsonML.. but it also takes
up more space/bandwidth.  There are several other reasons
<http://jsoda.info/JSoda+is#an+answer+to+jsonml> why I formulated
JSoda, rather than just using JsonML, but if those reasons aren't
issues for you, JsonML will save you some bandwidth.

On Nov 14, 2007 12:01 AM, Kyle Alan Hale <kylealanhale@...> wrote:
>
> In my search for a convenient way to represent XHTML DOM elements, I
>  assembled some ideas of how to apply the native JavaScript objects to
>  the W3C DOM objects. I call this assembly of ideas JSoda.
>
>  JSoda is JSON compliant <http://jsoda.info/JSoda+and+JSON> , so that a
>  DOM element represented as a JSoda object can be stored or transmitted
>  as JSON and utilize existing JSON solutions.

I may be bit slow, but I am not sure I understand why you would want
to wrap DOM within JSON?
Why not deal with xml via DOM as is? And when transferring, let
efficient xml generators/parsers take care of marshalling aspects?

I do understand the interoperability aspects sometimes require one to
use mappings to make things work (albeit inefficiently or awkwardly),
but are there some other benefits?

-+ Tatu +-

> I may be bit slow, but I am not sure I understand why you would want
> to wrap DOM within JSON?
> Why not deal with xml via DOM as is? And when transferring, let
> efficient xml generators/parsers take care of marshalling aspects?
>
> I do understand the interoperability aspects sometimes require one to
> use mappings to make things work (albeit inefficiently or awkwardly),
> but are there some other benefits?
>
> -+ Tatu +-
>

The DOM element objects themselves aren't being wrapped in JSON.  In
fact, JSoda isn't JSON at all, it's just nested JavaScript objects.
Each object type represents a different thing:

Object object -> DOM element
Array object -> DOM document fragment
String object -> DOM text node

However, it is JSON compliant, meaning that you can conveniently store
or transmit representations of DOM via, say, JSON RPC, or the proposed
JSONRequest, or any other method of transmitting textual information.
So, if you're using JSON anyway to transmit data, a JSoda object
could be embedded within the JSON text and not cause any problems with
JSON parsers... and not need an additional XML parser. In my case,
I'll be using it to transmit XHTML-based rich-text.. and I didn't want
to use a full fledged xml solution.  I may change my mind about that
as the project that I'm working on develops, but for now this is perfect.

I also use JSoda objects to build DOM elements, using the script
available on the site.  Sure, I could do everything in XHTML and
innerHTML it into my doc, but I'd rather be as ready for the future as
possible by implementing a wrapper around standards-based DOM methods.
Or, I could use XML and parse it, but the parsing overhead of a
native JavaScript object based solution is almost nonexistent,
compared to the intrinsically bulky XML parsers out there.

ha.. I didn't expect anyone to ask "Why not just use XML?" in the JSON
group.  If I were intending for this to be a markup language in
itself, then, you're right, XML would be more appropriate.  But JSoda
is just representing one language (XHTML) in terms of another
(JavaScript).  I like being able to think of DOM nodes as JavaScript
objects when working on JavaScript/AJAX based applications, but I
don't like the tedium of using the DOM functions on their own.  JSoda
meets both needs with a syntax that is analogous to DOM objects, but a
hell of a lot easier to build.