For those interested, JSON Schema has been submitted as an Internet
Draft to the IETF:
http://tools.ietf.org/html/draft-zyp-json-schema-01

-- Kris Zyp SitePen (503) 806-1841 http://sitepen.com

Hi all,

The latest version of jswoof has finally gone live. But its far from an update
its a complete rewrite. enabling it to acheive speeds 3x faster than previous
builds.

It is also important to note for those of you switching from version 1.10 that
the getLastError() function has been removed. As errors are now handled using
exceptions. So with that in mind you can just plug the library in as normal no
biggie and remove and calls to getLastError.

As usual you can get the latest version of jswoof from:

http://www.waynemike.co.uk/jswoof

Regards
Wayne IV Mike.

The server at JSON.org is getting hammered. It turns out that there are some
sites that are linking directly to json2.js instead of dispensing it from their
own servers. By far the heaviest impact is from onlinebootycall.com. My
intention was to provide the world with a free implementation, but the world can
buy its own bandwidth.

So I have added this line as the first line in the json2.js file:

alert('IMPORTANT: Remove this line from json2.js before deployment.');

It will not break anything, but it should help get a message to the
onlinebootycalls that you should not load code from strange third party servers.
It is not safe.

Any interest in moving your code to an account on Github? Might also help with
people's desire for versioned-versions of your various code currently hosted
directly on json.org. You could simply link to the project itself, or even the
raw file.
You could even go so far as to use embedded Gists (with syntax highlighting and
all) for your code samples.
Anyway, just a thought.

-Brian Lopez (author of yajl-ruby)

--- In json@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
> The server at JSON.org is getting hammered. It turns out that there are some
sites that are linking directly to json2.js instead of dispensing it from their
own servers. By far the heaviest impact is from onlinebootycall.com. My
intention was to provide the world with a free implementation, but the world can
buy its own bandwidth.
>
> So I have added this line as the first line in the json2.js file:
>
> alert('IMPORTANT: Remove this line from json2.js before deployment.');
>
> It will not break anything, but it should help get a message to the
onlinebootycalls that you should not load code from strange third party servers.
It is not safe.
>

There is more information at
http://www.stevesouders.com/blog/2009/12/10/crockford-alert/ and
http://ajaxian.com/archives/doug-crockford-and-the-online-booty-call-saga

Hi All,

Jswoof tiny has now been re-built using the new jswoof v1.12 core library.

As usual you can get the jswoof from http://www.waynemike.co.uk/jswoof

Regards
Wayne IV Mike.

Douglas, I think this move was brilliant, but as I have twitted, I wonder
how many devs wrote a:

window.alert = function(){};

before including external resources, rather than get the real/original
message (also because alert is something only RyanAir and few others could
still use "in 2010")

In any case, specially for a problematic subject as JSON evaluation is, I
guess you should be proud about the fact that many people simply trust your
implementation.
Moreover, as somebody already said, I think it's more about having an
automatically updated version, rather than grab your server bandwidth.

I think your JSON implementation should be hosted with a "Donate" button in
some place able to use pre-gzipped/deflated/plain version via ETag, 304, and
every possible technique able to make it safer and usable everywhere, with
clear benefits provided by common browsers cache.

Best Regards

On Sun, Dec 13, 2009 at 1:00 AM, Douglas Crockford <douglas@...>wrote:

>
>
> There is more information at
> http://www.stevesouders.com/blog/2009/12/10/crockford-alert/ and
> http://ajaxian.com/archives/doug-crockford-and-the-online-booty-call-saga
>
>
>


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

--- In json@yahoogroups.com, Andrea Giammarchi <andrea.giammarchi@...> wrote:
>
> Douglas, I think this move was brilliant, but as I have twitted, I
> wonder how many devs wrote a:
>
> window.alert = function(){};
>
> before including external resources, rather than get the real/original
> message

The point I was making was that if you care about reliability, security, and
performance, then you shouldn't load scripts directly from third party servers.
Are you suggesting that it is ok if you stub out alert first?

2009/12/14 Douglas Crockford <douglas@...>
>
> --- In json@yahoogroups.com, Andrea Giammarchi <andrea.giammarchi@...> wrote:
> >
> > Douglas, I think this move was brilliant, but as I have twitted, I
> > wonder how many devs wrote a:
> >
> > window.alert = function(){};
> >
> > before including external resources, rather than get the real/original
> > message
>
> The point I was making was that if you care about reliability, security, and
performance, then you shouldn't load scripts directly from third party servers.
Are you suggesting that it is ok if you stub out alert first?

I think he's suggesting that the people who need to get the point may
not actually get it - they'll just work around it with no idea why you
put it in there.

Just to underline another thing:

On Sun, Dec 13, 2009 at 6:38 PM, Douglas Crockford <douglas@...>wrote:

>
> The point I was making was that if you care about reliability, security,
> and performance
>
>
reliability ... they are including the de facto official JSON library for
JavaScript
security ... they trust your implementation and they trust the fact you keep
updating it
performances ... they are using a potentially "common used external
resource" so if the browser cached already that version performances will be
better for every website that includes it plus they are saving bandwidth.

As you can see somebody could think that your points ARE the reason they
included JSON via the direct source, rather than their local copy
potentially non updated and served even if almost every browser has stored
somewhere exactly the same library.

So, finally, I would think about a proper specific server or an official
repository Github style so that people than use the raw minified and gzipped
version with the 304 response, but if you think nobody should ever include
external scripts, you should tell us why we all have YUI configurator
scripts, google adsense/analytic files, etc etc.

Regards


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

If you go in YUI 3 Configurator the Result page provides a script to copy
and paste to include remotely the library.
http://developer.yahoo.com/yui/3/configurator/

If you go in Google Ajax libraries you will find external URIs to use third
part hosts as trusted safe and secure host with updated libraries.
http://code.google.com/apis/ajaxlibs/documentation/#AjaxLibraries

If you are using dojo library you probably know about AOL:
http://dev.aol.com/dojo

What am I saying is that we are not everybody under https and we trust, for
whatever reason, some external domain.
Not everybody could have followed the "alert story", I can already imagine
developers called 6am in the morning about an alert in the website that does
not use alerts at all.
These devs could have quickly solved the problem nullifying the alert
without caring about why the alert was there and, in the worst case
scenario, blaming you to have forgot an alert inside your library and
feeling cool to have solved an unexpected alert problem forever (so try with
prompt or confirm ...)

Since the message as is could sound more like you were testing something and
you forgot an alert, I would rather change the alert message with a link
that points WHY there is an alert.

I totally agree with you and it could often be about developers laziness (in
YUI case they did not use the php loader, etc etc) but at the same time:

  1 - every website could benefit about common external resources thanks to
distributed cache for common libaries
  2 - this message is not perfectly clear since somebody, YUI! itself, is
suggesting external resources while you, a Yahoo! engineer, are saying that
this is so bad that anybody should avoid this technique

Do you see what I mean?

Regards


On Sun, Dec 13, 2009 at 6:38 PM, Douglas Crockford <douglas@...>wrote:

>
>
> --- In json@yahoogroups.com <json%40yahoogroups.com>, Andrea Giammarchi
> <andrea.giammarchi@...> wrote:
> >
> > Douglas, I think this move was brilliant, but as I have twitted, I
> > wonder how many devs wrote a:
> >
> > window.alert = function(){};
> >
> > before including external resources, rather than get the real/original
> > message
>
> The point I was making was that if you care about reliability, security,
> and performance, then you shouldn't load scripts directly from third party
> servers. Are you suggesting that it is ok if you stub out alert first?
>
>
>


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

On 12/13/2009 09:34 PM, Andrea Giammarchi wrote:
>
> Just to underline another thing:
>
> On Sun, Dec 13, 2009 at 6:38 PM, Douglas Crockford
> <douglas@... <mailto:douglas%40crockford.com>>wrote:
>
> >
> > The point I was making was that if you care about reliability, security,
> > and performance
> >
> >
> reliability ... they are including the de facto official JSON library for
> JavaScript
> security ... they trust your implementation and they trust the fact
> you keep
> updating it
> performances ... they are using a potentially "common used external
> resource" so if the browser cached already that version performances
> will be
> better for every website that includes it plus they are saving bandwidth.
>
> As you can see somebody could think that your points ARE the reason they
> included JSON via the direct source, rather than their local copy
> potentially non updated and served even if almost every browser has stored
> somewhere exactly the same library.
>

Hi Andrea,

I think you are forgetting that the (current) json.org website is
probably just a shared-hosting
account.

So that probably means it's not as reliable as something Google or Yahoo
might do for some of the js-libraries.

Performance-wise it would be really bad if everyone started hotlinking
to just that one (or maybe 2 or 3) server(s) as well.

Security-wise, something like the CDN-like setup Google and Yahoo are
doing have a lot of save-gaurds,
like monitoring tools and employees for file-changes. Seperate dedicated
datacenters or atleast 'cages' of
dedicated 19"-racks of servers. And not to forget procedures.

While I do think getting automatic updates of json[2].js would be really
interresting, because it's a very
security-sensitive library.

So in the current situation, it's a really bad idea.

>
> So, finally, I would think about a proper specific server or an official
> repository Github style so that people than use the raw minified and
> gzipped
> version with the 304 response, but if you think nobody should ever include
> external scripts, you should tell us why we all have YUI configurator
> scripts, google adsense/analytic files, etc etc.
>

Yes, I think some people would love to see Yahoo add json[2].js to their
list of js-libraries
they are already hosting on their own CDN (I think Google has a whole
list of libraries).

But maybe Mr. Crockford does not want his personal project to be tied to
his (current)
employer or Google. I don't know their, could be many reasons.

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

i noticed that this works with the native JSON object in FF3.5.5

  JSON.parse(["true"])

but with the json2.js this throws an error.

which one is the intended behaviour?

greetings
  simon

I guess that json2.js is supposed to work on Json-Text and not java arrays with
json-text.

You could do this instead:

JSON.parse('["true"]');


--- In json@yahoogroups.com, "nostalgiker" <nostalgiker@...> wrote:
>
> i noticed that this works with the native JSON object in FF3.5.5
>
>  JSON.parse(["true"])
>
> but with the json2.js this throws an error.
>
> which one is the intended behaviour?
>
> greetings
>  simon
>

okay, i figured that out ;) bwt it's a plain javascript array, not java.

but i was actually wondering why IE8 and FF3.5+ allow this with their native
JSON objects - passing an array with one element to parse()

so does the jquery.json pluggin - which is unmaintained. that is why i switched
to json2... where i noticed that it doesnt support this, but everybody else
seems to.

JavaScript provides automatic type conversions on a lot of action

So if you do

var foo = ["bar"] + " baz";

["bar"] will be converted into "bar" and you'll have foo === "bar baz"

you can also see that in JavaScript ["foo"] == "foo"

and String["foo"]) === "foo"

Then when you send an array to a function expecting a string, and this function
doesn't check the type of the parameter ( or force it to string), you'll have
what you get


Le 17 déc. 2009 à 11:45, nostalgiker a écrit :



okay, i figured that out ;) bwt it's a plain javascript array, not java.

but i was actually wondering why IE8 and FF3.5+ allow this with their native
JSON objects - passing an array with one element to parse()

so does the jquery.json pluggin - which is unmaintained. that is why i switched
to json2... where i noticed that it doesnt support this, but everybody else
seems to.






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

Jansson v1.1.3 is out. This is a bug fix release in the 1.1 release
series.

Changes since v1.1.2:

* Encode reals correctly, so that first encoding and then decoding a
   real always produces the same value
* Don't export private symbols in libjansson.so

Download source: http://www.digip.org/jansson/releases/jansson-1.1.3.tar.gz
View documentation: http://www.digip.org/jansson/doc/1.1/
Changelog: http://www.digip.org/jansson/releases/CHANGES


What is Jansson?

Jansson is a C library for encoding, decoding and manipulating JSON data.
It features:

* Simple and intuitive API and data model
* Comprehensive documentation
* No dependencies on other libraries
* Full Unicode support (UTF-8)
* Extensive test suite

Jansson is licensed under the MIT license.

For more details, see http://www.digip.org/jansson/.


Petri Lehtinen
petri@...

Hi JSON fans

I'm currently creating a project where I need a JSON parser in Java. There's no
lack of Java JSON-parsers at json.org, in fact there's 18 different
implementations available. Rather than browse through the entire source-code of
these projects, I ask you to recommend an implementation that suit my needs.

My needs are the following:
  - open source (not GPL)
  - complete (no subset of JSON)
  - correctness in parsing (well-tested)
  - few files (less than 50 - it's not brain surgery)

I would prefer that:
  - It's easy to navigate in the resulting AST. E.g. obj.get('a.b[2]')
  - It's Java 1.4.2 compatible (but I can edit the source if it's Java 5+)

Dont cares about:
  - Speed
  - Encoding capabilities

I hope you will tell me about pros and cons in your favourite JSON (Java) API.

/Jonas

BTW: I would be great if there was some sort of a comparison sheet available on
json.org or here.

Hi all,
The first port of jswoof has now been uploaded. You can now get jswoof
for c#.

You can download the beta from:

http://www.waynemike.co.uk/jswoof/csharp

Happy Xmas.

Regards
Wayne IV Mike.

I just found an interesting json validator

"Orderly is a textual format for describing JSON. Orderly can be compiled
into JSONSchema.
It is designed to be easy to read and write".

http://orderly-json.org/


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

Hi all,
The jswoof website has now been updated to reflect all changes that
have recently been made to the library. Work is also under on the C#
version of the website.

http://www.waynemike.co.uk/jswoof
http://www.waynemike.co.uk/jswoof/csharp

Kind Regards
Wayne IV Mike.

Hi all.
Jswoof version 1.13 is ready for download. Its contains a new clause in the
parseObject function that throws an exception if no key is present.

as usual you can get the latest versions of jswoof from:

www.waynemike.co.uk/jswoof
www.waynemike.co.uk/jswoof/csharp

Regards
Wayne IV Mike.

> JavaScript provides automatic type conversions on a lot of action

thx for the replies, but i'm not talking about a js function. it's the NATIVE
firefox JSON object:

  > JSON.parse(["true"])

i realize this is mailinglist is about json2.js. but i was wondering why firefox
allows passing an array and json2.js not. and which one is the "correct"
behaviour?

According to this page: http://www.west-wind.com/weblog/posts/729630.aspx, the
native implementation is based upon the interface of json2.js. In fact you
should always include json2.js, because quote: "The JSON2 implementation
includes checks to see if a JSON  object exists already and if not leaves it in
place so the native version is used." and you don't want to exclude browsers
with no native json implementation.

If the function that takes a javascript-array with json-text is very important
to you, then you should write a wrapper function that calls JSON2 for every
element in your array.

I don't know if it is a bug or according to some specs. that native firefox json
accepts a javascript-array, but you could try to see if IE8 does the same.


--- In json@yahoogroups.com, "nostalgiker" <nostalgiker@...> wrote:
>
>
> > JavaScript provides automatic type conversions on a lot of action
>
> thx for the replies, but i'm not talking about a js function. it's the NATIVE
firefox JSON object:
>
>  > JSON.parse(["true"])
>
> i realize this is mailinglist is about json2.js. but i was wondering why
firefox allows passing an array and json2.js not. and which one is the "correct"
behaviour?
>

Neither are correct.

The ECMAScript 5 spec states the first step of JSON.parse is to call ToString(
text ).  That means JSON.parse(["true"]); should be equivalent to
JSON.parse("true"); -- barring Array.proto.toString clobbering.  FF3.5 and IE8
are in violation of the spec.  json2.js also does not perform this step,
resulting in a thrown error during the regex scouring because it assumes the
input has the 'replace' method.

--- In json@yahoogroups.com, "nostalgiker" <nostalgiker@...> wrote:
>
>
> > JavaScript provides automatic type conversions on a lot of action
>
> thx for the replies, but i'm not talking about a js function. it's the NATIVE
firefox JSON object:
>
>  > JSON.parse(["true"])
>
> i realize this is mailinglist is about json2.js. but i was wondering why
firefox allows passing an array and json2.js not. and which one is the "correct"
behaviour?
>

> Neither are correct.
>
> The ECMAScript 5 spec states the first step of JSON.parse is
> to call ToString( text ).

thank you, that was the answer is was looking for. should have checked the
spec...

is mr.crockford reading this list? imo this is then a bug in json2.js since
JSON.parse(['true']) fails in his implementation but it should behave like
ecma5's native JSON.

greetings
  simon

--- In json@yahoogroups.com, "nostalgiker" <nostalgiker@...> wrote:

> is mr.crockford reading this list? imo this is then a bug in json2.js since
JSON.parse(['true']) fails in his implementation but it should behave like
ecma5's native JSON.


JSON.parse wants to be called with a string. If you call it with anything else,
you get what you deserve. I don't recommend reliance on the edge cases. That is
where systems are the least portable.

I believe that the EMCAScript standard should be changed.
On page 212 in http://www.ecmascript.org/docs/tc39-2009-043.pdf
ECMA specifies the JSON-grammar, but does not do so by the specification given
by Crockford. http://tools.ietf.org/html/rfc4627
He specifies (page 2) that:

"A JSON text is a serialized object or array.
  JSON-text = object / array"

ECMA says that JSONText is JSONValue, which is too liberal as it would also mean
that JSONString, JSONNumber, etc. is JSONText.

Doing it the ECMA standard way would (as previously said) convert ["text"] it
into 'text' or '"text"' - which isen't JSONText, but that what the ECMAstandard
tells you to do.

The Native parser is actually a valid JSON parser. The spec says so:
"A JSON parser MUST accept all texts that conform to the JSON grammar. A JSON
parser MAY accept non-JSON forms or extensions."

bummer.

But it would be interesting to see if JSON.stringify is outputting JSONText
according to the spec given by D.Crockford or the self-invented JSON grammar by
ECMA.

Anyway - It's always sane to feed a parser text, because a parser works on text
(http://en.wikipedia.org/wiki/Parsing) - that's why json2.js should not be
changed and ECMAScript 5 should be modified.

What you should do, is to encode your javascript-array into json before parsing
it:

var a = ["text"];
var json_a = JSON.stringify(a); //gives you '["text"]'
var a_array = JSON.parse(json_a);

(I haven't tested this code - might not be bug free)

--- In json@yahoogroups.com, "nostalgiker" <nostalgiker@...> wrote:
>
> > Neither are correct.
> >
> > The ECMAScript 5 spec states the first step of JSON.parse is
> > to call ToString( text ).
>
> thank you, that was the answer is was looking for. should have checked the
spec...
>

Wait a minute - ignore my last advice.
That would probably give you escaped characters instead of what you want. Just
dont feed parsers anything but plain text.

--- In json@yahoogroups.com, "Fredag_d13" <jonas@...> wrote:
>
>
>
> I believe that the EMCAScript standard should be changed.
> On page 212 in http://www.ecmascript.org/docs/tc39-2009-043.pdf
> ECMA specifies the JSON-grammar, but does not do so by the specification given
by Crockford. http://tools.ietf.org/html/rfc4627
> He specifies (page 2) that:
>
> "A JSON text is a serialized object or array.
>  JSON-text = object / array"
>
> ECMA says that JSONText is JSONValue, which is too liberal as it would also
mean that JSONString, JSONNumber, etc. is JSONText.
>
> Doing it the ECMA standard way would (as previously said) convert ["text"] it
into 'text' or '"text"' - which isen't JSONText, but that what the ECMAstandard
tells you to do.
>
> The Native parser is actually a valid JSON parser. The spec says so:
> "A JSON parser MUST accept all texts that conform to the JSON grammar. A JSON
parser MAY accept non-JSON forms or extensions."
>
> bummer.
>
> But it would be interesting to see if JSON.stringify is outputting JSONText
according to the spec given by D.Crockford or the self-invented JSON grammar by
ECMA.
>
> Anyway - It's always sane to feed a parser text, because a parser works on
text (http://en.wikipedia.org/wiki/Parsing) - that's why json2.js should not be
changed and ECMAScript 5 should be modified.
>
> What you should do, is to encode your javascript-array into json before
parsing it:
>
> var a = ["text"];
> var json_a = JSON.stringify(a); //gives you '["text"]'
> var a_array = JSON.parse(json_a);
>
> (I haven't tested this code - might not be bug free)
>
> --- In json@yahoogroups.com, "nostalgiker" <nostalgiker@> wrote:
> >
> > > Neither are correct.
> > >
> > > The ECMAScript 5 spec states the first step of JSON.parse is
> > > to call ToString( text ).
> >
> > thank you, that was the answer is was looking for. should have checked the
spec...
> >
>