Hi,

I'm developing a web front-end to our student database and I'd like to
let the users specify what fields they want in their view and be able to
filter and sort the data.

After some thinking I figured out that this all can be expressed by an
SQL query -- and it will end up generating an SQL query on the server.

So I made a JSON syntax like this:
{
"fields":["std_id","code","lastname","firstname"],
"filters":[{"prog":["200A0","200A1"]},{"decision":["A%"]}],
"sort":[{"cote_mix":"desc"}]
}
which would generate an SQL query like this:
SELECT std_id, code, lastname, firstname FROM students
WHERE prog IN ('200A0','200A1') AND decision LIKE 'A%'
ORDER BY cote_mix DESC

But I feel like I'm re-inventing the wheel here...
Is there already a specification for expressing an SQL query in JSON?

Thanks,
GFK's
--
Guillaume Filion
http://guillaume.filion.org/



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

I a new at JSON but have been doing stuff like this for 27 years.  (JSON is
just another form of data transportation as when EDI was king over XML 10-25
years ago.)



You should only give your user's the options on a screen of what fields to
choose, not have them write out the fields names themselves. (Is that what
you are doing?)  You would face a big inject attack if you let them write
the SQL fields themselves.



Gene











From: json@yahoogroups.com [mailto:json@yahoogroups.com] On Behalf Of
Guillaume Filion
Sent: Wednesday, April 29, 2009 3:21 PM
To: json@yahoogroups.com
Subject: [json] Expressing SQL queries in JSON








Hi,

I'm developing a web front-end to our student database and I'd like to
let the users specify what fields they want in their view and be able to
filter and sort the data.

After some thinking I figured out that this all can be expressed by an
SQL query -- and it will end up generating an SQL query on the server.

So I made a JSON syntax like this:
{
"fields":["std_id","code","lastname","firstname"],
"filters":[{"prog":["200A0","200A1"]},{"decision":["A%"]}],
"sort":[{"cote_mix":"desc"}]
}
which would generate an SQL query like this:
SELECT std_id, code, lastname, firstname FROM students
WHERE prog IN ('200A0','200A1') AND decision LIKE 'A%'
ORDER BY cote_mix DESC

But I feel like I'm re-inventing the wheel here...
Is there already a specification for expressing an SQL query in JSON?

Thanks,
GFK's
--
Guillaume Filion
http://guillaume.filion.org/

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





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

Hey everyone,

Just wanted to announce my new ruby C bindings to Yajl creatively called:
yajl-ruby ;)

The sources are up on Github for now at http://github.com/brianmario/yajl-ruby
although I might put it up on RubyForge soon too. Instructions on how to install
and use are in the README.rdoc file.

To my knowledge this is only the second C-based JSON parser for Ruby aside from
the JSON gem that's existed for a while.

In my preliminary parsing benchmarks, yajl-ruby performed on-par (in terms of
time to completion) with the JSON gem on small-medium sized JSON strings (385
bytes to around 25k) but performs significantly better on larger files (100k+).
But as far as memory usage is concerned - it's much more efficient. For example:
parsing a 2.4MB JSON string, ruby was using around 30MB of RAM for yajl-ruby and
almost 80MB for the JSON gem. Using the OSX Instruments development tool, doing
the same operation was showing 13MB compared to 42MB of allocations
respectively.

Parsing as a stream opens up a whole new realm of possibilities for using JSON
to transfer large amounts of data. I have some examples, including
Yajl::HttpStream.get(uri) which will parse the JSON response body *directly off
the socket* for the highest possible efficiency. Or even directly from a
compressed Gzip or Bzip2 stream without the need to decompress to a buffer, then
parse. I have tons of feature ideas around Http and Socket communication in
general. But I'd love to hear yours!

My next big API addition will be streaming JSON string creation using Yajl. Then
I'll work on some examples of using yajl-ruby on both sides of a stream.

Please check it out and give me any/all improvement suggestions and/or feature
requests you might have.

The web_send library provides a concise and expressive API for
interacting with arbitrary JSON resources from the web browser. When
used from the Firebug console, it acts like a command line for your
web server; a great help during development of server-side code. The
same API is also convenient for creating an AJAX user interface to
JSON resources; so code born on the interactive command line migrates
smoothly into application code. This tutorial also links to a live web
page <http://waterken.sourceforge.net/bang/> where you can try out the
library against a simple server-side counter object.

SOME QUICK INTRODUCTORY EXAMPLES

For example, say you've got a brand new server-side object sitting at
a URL like: <https://example.com/myApp/obj123>. All you want to do is
invoke one of its methods, to see what happens. Using the web_send
library from the Firebug console, you could write:

factory = lib.web.getLocation();    // grab the window.location URL
drum = lib.Q.post(factory, 'makeDrum', []);

That code generates the following HTTP request:

POST /myApp/obj123?q=makeDrum HTTP/1.1
Host: example.com
Content-Type: text/plain; charset=UTF-8
Content-Length: 2

[]

The arguments to Q.post() are:

    1. remote reference for the target object
    2. optional argument to add to the query string
    3. optional JSON value for the request body

The makeDrum() method didn't take any arguments. Here's one that does:

lib.Q.post(drum, 'bang', [ 1 ]);

Causing the HTTP request:

POST /myApp/obj456?q=bang HTTP/1.1
Host: example.com
Content-Type: text/plain; charset=UTF-8
Content-Length: 5

[ 1 ]

The target URL in the above request was taken from the HTTP response
to the previous request. For this to work, the web_send library
introduces some conventions for HTTP requests and responses. These
conventions are the least restrictive they can be, while still
supporting the client-side remote reference API. This document
explains these conventions and shows how to use legacy JSON resources
that don't follow the conventions.

... (continue reading at <http://waterken.sourceforge.net/web_send/>)

--
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html

This looks really cool. Have you tried it with existing servers to see
how compatible it is with current implementations of HTTP/JSON servers?
This data interaction aspect of this looks similar to the functionality
in Dojo's JsonRestStore, which can interact with CouchDB and Persevere.
It'd be curious if your browser shell works with Persevere, as Persevere
follows RFC 2616 pretty closely as well as some of the RESTful JSON
conventions discussed here, such as JSON referencing:
http://groups.google.com/group/restful-json
Kris

Tyler Close wrote:
>
>
> The web_send library provides a concise and expressive API for
> interacting with arbitrary JSON resources from the web browser. When
> used from the Firebug console, it acts like a command line for your
> web server; a great help during development of server-side code. The
> same API is also convenient for creating an AJAX user interface to
> JSON resources; so code born on the interactive command line migrates
> smoothly into application code. This tutorial also links to a live web
> page <http://waterken.sourceforge.net/bang/
> <http://waterken.sourceforge.net/bang/>> where you can try out the
> library against a simple server-side counter object.
>
> SOME QUICK INTRODUCTORY EXAMPLES
>
> For example, say you've got a brand new server-side object sitting at
> a URL like: <https://example.com/myApp/obj123
> <https://example.com/myApp/obj123>>. All you want to do is
> invoke one of its methods, to see what happens. Using the web_send
> library from the Firebug console, you could write:
>
> factory = lib.web.getLocation(); // grab the window.location URL
> drum = lib.Q.post(factory, 'makeDrum', []);
>
> That code generates the following HTTP request:
>
> POST /myApp/obj123?q=makeDrum HTTP/1.1
> Host: example.com
> Content-Type: text/plain; charset=UTF-8
> Content-Length: 2
>
> []
>
> The arguments to Q.post() are:
>
> 1. remote reference for the target object
> 2. optional argument to add to the query string
> 3. optional JSON value for the request body
>
> The makeDrum() method didn't take any arguments. Here's one that does:
>
> lib.Q.post(drum, 'bang', [ 1 ]);
>
> Causing the HTTP request:
>
> POST /myApp/obj456?q=bang HTTP/1.1
> Host: example.com
> Content-Type: text/plain; charset=UTF-8
> Content-Length: 5
>
> [ 1 ]
>
> The target URL in the above request was taken from the HTTP response
> to the previous request. For this to work, the web_send library
> introduces some conventions for HTTP requests and responses. These
> conventions are the least restrictive they can be, while still
> supporting the client-side remote reference API. This document
> explains these conventions and shows how to use legacy JSON resources
> that don't follow the conventions.
>
> ... (continue reading at <http://waterken.sourceforge.net/web_send/
> <http://waterken.sourceforge.net/web_send/>>)
>
> --
> "Waterken News: Capability security on the Web"
> http://waterken.sourceforge.net/recent.html
> <http://waterken.sourceforge.net/recent.html>
>
>

Gene Berger a écrit :
> You should only give your user's the options on a screen of what fields to
> choose, not have them write out the fields names themselves. (Is that what
> you are doing?)  You would face a big inject attack if you let them write
> the SQL fields themselves.

Yes the user would have a nice graphical interface to specify which
fields he wants. Also, I would validate the fields names on the backend
before creating the SQL query.

Cheers,
GFK's
--
Guillaume Filion
http://guillaume.filion.org/



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

On Thu, May 7, 2009 at 10:51 AM, Kris Zyp <kriszyp@...> wrote:
> This looks really cool.

Thanks!

>  Have you tried it with existing servers to see
> how compatible it is with current implementations of HTTP/JSON servers?
> This data interaction aspect of this looks similar to the functionality
> in Dojo's JsonRestStore, which can interact with CouchDB and Persevere.
> It'd be curious if your browser shell works with Persevere, as Persevere
> follows RFC 2616 pretty closely as well as some of the RESTful JSON
> conventions discussed here, such as JSON referencing:
> http://groups.google.com/group/restful-json

The implementation currently supports GET and POST to an arbitrary URL
with an arbitrary JSON request entity and an arbitrary JSON response
entity. Non-success HTTP response codes trigger the provided failure
callback.

Is there some aspect of Persevere's implementation of RFC 2616 that
could be problematic for a client implemented on the browser's
XMLHttpRequest object?

All JSON encoding/decoding is done using whatever JSON object is in
the global scope. It looks like you could use your JSON referencing
code by importing it instead of json2.js.

--Tyler

--
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html

I'm proud to announce that MJSON v1.1 has been released!

MJSON is Maciel's JSON parser, a small light-weight library that
handles documents written in the JSON markup language. It's written in
ISO C, which means that it may run wherever there is a C compiler.

This release focuses on stability and offers a hand full of bug fixes.


MJSON and jsonindent can be found at:
http://sourceforge.net/projects/mjson


Rui Maciel

--- In json@yahoogroups.com, Guillaume Filion <gfk@...> wrote:
> which would generate an SQL query like this:
> SELECT std_id, code, lastname, firstname FROM students
> WHERE prog IN ('200A0','200A1') AND decision LIKE 'A%'
> ORDER BY cote_mix DESC
>
> But I feel like I'm re-inventing the wheel here...
> Is there already a specification for expressing an SQL query in JSON?

The most similar technology is LINQ, which for JavaScript translates as JSLINQ
(http://jslinq.codeplex.com/).

But you may take a look to myPatterns.free.fr, too, which complements LINQ with
JSON patterns.

Regards,
Nic.

Hi,

I am pleased to announce you the availability of a novel free library for
JavaScript, called myPatterns/JS, implementing pattern matching in JSON and
other custom notations.

With myPatterns/JS, you can match native JavaScript objects with JSON patterns
such as:

  "{name:{firstname:%f, lastname:"Smith"}, children:[%elder | %_]}"

which both checks if an objects matches the pattern and if yes, returns a
resulting substitution, such as: {f:"John", elder:{name: "Bob"}}.
You can use such patterns for filtering data sequences, too.

Other, customized notations can be defined with a few lines of JavaScript code.
No grammar/parser needed.

You can try the library online at:

http://mypatterns.free.fr/

Any feedback is greatly appreciated!

Enjoy,
Nic.

I guess yajl-ruby hasn't been announced on this list, so here goes...

Brian Lopez has been feverishly working on ruby bindings for yajl, and has
reported some very favorable performance numbers for the resultant parser.

You can get the code and learn more about Brian's work here:
http://github.com/brianmario/yajl-ruby/tree/master

And you can get a little overview of the marriage of yajl and ruby here:
http://trickyco.de/2009/05/parse-json-in-ruby-in-14-the-time-of-yaml/

best,
lloyd

(it was a direct message, I have copied and pasted here as well)
Good afternoon Mr Douglas Crockford,
I wonder if you have seen already my latest JSON related project, called
JSON.hpack,
an Homogeneous Collection Packer.

As summary, hpack transform a JSON list of objects, usually a database
resultSet
[{name:value},{name:value},{name:value}]
into an array only collection with columns info in the special index 0

[[name],[value],[value],[value]]

With 4 different compression levels, it is able to cut down number of
characters from 75Kb to 9Kb ( no gzip ) and to make big client side
elaborated resultSets send via Ajax possible without having gzip/deflate
compression on client side. The JSON.hunpack method is extremely fast and
compatible with every chosed compression level.

I hope it will find a place into json.org and I'd love to read a comment
about it as soon as you have some free minute (... even if I know it is
something hard to find in IT).

Blog Entry:
http://webreflection.blogspot.com/2009/05/re-introduction-to-jsonhpack.html

Github Project:
http://github.com/WebReflection/json.hpack/tree/master

Here is a live demo page:
http://www.3site.eu/examples/json.hpack/test/

Best Regards,
Andrea Giammarchi


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

What level of difference is there between raw database result set name
value paired that has been gzipped and hunpack'ed data that has been
gzipped? I know that gzipping also finds redundancies and reduces them,
so I am curious how well this works if you are compressing all your data
with gzip already. Anyway, good work.
Thanks,
Kris

Andrea Giammarchi wrote:
>
>
> (it was a direct message, I have copied and pasted here as well)
> Good afternoon Mr Douglas Crockford,
> I wonder if you have seen already my latest JSON related project, called
> JSON.hpack,
> an Homogeneous Collection Packer.
>
> As summary, hpack transform a JSON list of objects, usually a database
> resultSet
> [{name:value},{name:value},{name:value}]
> into an array only collection with columns info in the special index 0
>
> [[name],[value],[value],[value]]
>
> With 4 different compression levels, it is able to cut down number of
> characters from 75Kb to 9Kb ( no gzip ) and to make big client side
> elaborated resultSets send via Ajax possible without having gzip/deflate
> compression on client side. The JSON.hunpack method is extremely fast and
> compatible with every chosed compression level.
>
> I hope it will find a place into json.org and I'd love to read a comment
> about it as soon as you have some free minute (... even if I know it is
> something hard to find in IT).
>
> Blog Entry:
>
http://webreflection.blogspot.com/2009/05/re-introduction-to-jsonhpack.html
>
> Github Project:
> http://github.com/WebReflection/json.hpack/tree/master
>
> Here is a live demo page:
> http://www.3site.eu/examples/json.hpack/test/
>
> Best Regards,
> Andrea Giammarchi
>
> [Non-text portions of this message have been removed]
>
>

Kris, hope I got your question.
Basically, as you said gzip is able to reduce drastically redundant words (in
JSON case, every collection repeated key)

This simply means that while JSON vs JSON.hpack difference could be up to 80%
less characters for the hpack best option, gzipped JSON.hpack against gzipped
JSON will be not that consistent at all (0.85~0.15:1.0) so in this case we have
different benefits:

  1. JSON.hpack could make runtime gzip usage a plus, rather than a must

  2. JSON.hpack make faster, and in some case "just possible" Client TO Server
interaction over homogeneous collection. While gzip is a common practice on the
server, in the client side we have almost nothing, except the in-core request
inflate/gunzip. In previous posted example, my host does not support more than
50Kb of posted data. This means that is not possible to send back in JSON format
the retrieved, and eventually elaborated, big result set, while as soon as the
test uses JSON.hpack, the client can quickly send back everything in a shot (
rather than a call for each updated row/field, can you see my point? )

  3. except for Internet Explorer 8, where JSON.parse/stringify are native,
JSON.hpack make the entire "create JSON, send, receive and convert to native"
faster in every other browser. The reason is simply, Big D did a great job with
json2.js but more big is the object or more long is the string, more time it
will take to convert, or convert back. You can simply tests results with
FireFox2, 3, Opera, Safari beta, or Chrome.

Accordingly, JSON.hpack best environment is in the client side, where it could
significally make the difference but since its JSON.hunpack method is "that
simple", there is no reason to do not have at least that one on the whatever
server side language, in order to be able to retrieve JSON.hpack data. As
summary, potentially faster in the server (with cached results and no gzip
runtime compression), always preferable in the client side (still performances
over thousands of objects plus "one/shot" client to server possibility reducing
delay up to 80%).

Did I reply to your concerns? Regards.

--- In json@yahoogroups.com, Kris Zyp <kriszyp@...> wrote:
>
> What level of difference is there between raw database result set name
> value paired that has been gzipped and hunpack'ed data that has been
> gzipped? I know that gzipping also finds redundancies and reduces them,
> so I am curious how well this works if you are compressing all your data
> with gzip already. Anyway, good work.
> Thanks,
> Kris
>
> Andrea Giammarchi wrote:
> >
> >
> > (it was a direct message, I have copied and pasted here as well)
> > Good afternoon Mr Douglas Crockford,
> > I wonder if you have seen already my latest JSON related project, called
> > JSON.hpack,
> > an Homogeneous Collection Packer.
> >
> > As summary, hpack transform a JSON list of objects, usually a database
> > resultSet
> > [{name:value},{name:value},{name:value}]
> > into an array only collection with columns info in the special index 0
> >
> > [[name],[value],[value],[value]]
> >
> > With 4 different compression levels, it is able to cut down number of
> > characters from 75Kb to 9Kb ( no gzip ) and to make big client side
> > elaborated resultSets send via Ajax possible without having gzip/deflate
> > compression on client side. The JSON.hunpack method is extremely fast and
> > compatible with every chosed compression level.
> >
> > I hope it will find a place into json.org and I'd love to read a comment
> > about it as soon as you have some free minute (... even if I know it is
> > something hard to find in IT).
> >
> > Blog Entry:
> >
> http://webreflection.blogspot.com/2009/05/re-introduction-to-jsonhpack.html
> >
> > Github Project:
> > http://github.com/WebReflection/json.hpack/tree/master
> >
> > Here is a live demo page:
> > http://www.3site.eu/examples/json.hpack/test/
> >
> > Best Regards,
> > Andrea Giammarchi
> >
> > [Non-text portions of this message have been removed]
> >
> >
>

On Wed, May 27, 2009 at 6:27 AM, Andrea Giammarchi
<andrea.giammarchi@...> wrote:
> (it was a direct message, I have copied and pasted here as well)
> Good afternoon Mr Douglas Crockford,
> I wonder if you have seen already my latest JSON related project, called
> JSON.hpack,
> an Homogeneous Collection Packer.
>
> As summary, hpack transform a JSON list of objects, usually a database
> resultSet
> [{name:value},{name:value},{name:value}]
> into an array only collection with columns info in the special index 0

This seems like a simple and possibly sensible convention.
But in addition to having an implementation, it would seem most
interesting to specify the convention. This would allow
implementations for other languages: verbosity of textual data formats
matters for many use cases, and json is being used a lot on
server-to-server communication too.

Wrt compression: I am sure gzip would yield more additional
compression, since it would not only eliminate redundancy wrt. names
(which compress very well obviously) but also for values. It can
definitely be added as a separate layer.
But given how CPU hungry gzip is (see
[http://www.cowtowncoder.com/blog/archives/2009/05/entry_263.html] for
example;  for java json, overhead is 3x - 5x basic processing),
conventions can help a lot, so the two can be complementary; even if
plain gzip would probably compress things more if size reduction was
the only goal.

-+ Tatu +-

Tatu, gzip works faster in any case over JSON.hpack(ed) stuff for the same
reason JSON.stringify / parse is faster over JSON.hpacked stuff, less characters
to work over (you gzip a string smaller up to 80%)

It could be a separated layer in any case, but even over, will be faster. The C#
implementation of both hpack and hunpack are extremely fast, I need time to
create a Python version and I was planning to create a PHP extension in C as
well but only one Java guy told me he will try to create a parser ... I mean, C#
version is not that different, I guess a porting will take a couple of hours and
nothing else.

Anyway, I miss your point about specify the convention ... do you mean proper
specs? I could write something more than I already wrote on github homepage, let
me know.

Regards

--- In json@yahoogroups.com, Tatu Saloranta <tsaloranta@...> wrote:
>
> On Wed, May 27, 2009 at 6:27 AM, Andrea Giammarchi
> <andrea.giammarchi@...> wrote:
> > (it was a direct message, I have copied and pasted here as well)
> > Good afternoon Mr Douglas Crockford,
> > I wonder if you have seen already my latest JSON related project, called
> > JSON.hpack,
> > an Homogeneous Collection Packer.
> >
> > As summary, hpack transform a JSON list of objects, usually a database
> > resultSet
> > [{name:value},{name:value},{name:value}]
> > into an array only collection with columns info in the special index 0
>
> This seems like a simple and possibly sensible convention.
> But in addition to having an implementation, it would seem most
> interesting to specify the convention. This would allow
> implementations for other languages: verbosity of textual data formats
> matters for many use cases, and json is being used a lot on
> server-to-server communication too.
>
> Wrt compression: I am sure gzip would yield more additional
> compression, since it would not only eliminate redundancy wrt. names
> (which compress very well obviously) but also for values. It can
> definitely be added as a separate layer.
> But given how CPU hungry gzip is (see
> [http://www.cowtowncoder.com/blog/archives/2009/05/entry_263.html] for
> example;  for java json, overhead is 3x - 5x basic processing),
> conventions can help a lot, so the two can be complementary; even if
> plain gzip would probably compress things more if size reduction was
> the only goal.
>
> -+ Tatu +-
>

On Thu, May 28, 2009 at 1:25 AM, an_red@...
<andrea.giammarchi@...> wrote:
> Tatu, gzip works faster in any case over JSON.hpack(ed) stuff for the same
reason JSON.stringify / parse is faster over JSON.hpacked stuff, less characters
to work over (you gzip a string smaller up to 80%)

Yes, certainly, not arguing with that, wrt. speed.

> It could be a separated layer in any case, but even over, will be faster. The
C# implementation of both hpack and hunpack are extremely fast, I need time to
create a Python version and I was planning to create a PHP

No doubt, it should be a fairly simple transformation on other
languages as well.

> extension in C as well but only one Java guy told me he will try to create a
parser ... I mean, C# version is not that different, I guess a porting will take
a

There are many good fast Java parsers, so I would recommend using one
of those, and add transformation layer on top. No need to write a
parser (IMO -- but I have written mine so I may be biased).

> Anyway, I miss your point about specify the convention ... do you mean
> proper specs? I could write something more than I already wrote on github
homepage, let me know.

Yeah, specification of this convention (or transformation),
documenting how it should behave. This is necessary (or at least
useful) to ensure interoperability. Given how many people want to
write their own json parsers (... just a random example...), because
they don't like what is available, I'm sure there'll be many who'd
want to reimplement this mapping as well.
But at least implementations would be interoperable.

So yes, need not be anything too heavy-weight, but somewhat formal
notation helps in my opinion.

Thanks!

-+ Tatu +-

Is something like this enough?
http://wiki.github.com/WebReflection/json.hpack/specs-details

Best Regards.

Andrea Giammarchi

--- In json@yahoogroups.com, Tatu Saloranta <tsaloranta@...> wrote:
>
> On Thu, May 28, 2009 at 1:25 AM, an_red@...
> <andrea.giammarchi@...> wrote:
> > Tatu, gzip works faster in any case over JSON.hpack(ed) stuff for the same
reason JSON.stringify / parse is faster over JSON.hpacked stuff, less characters
to work over (you gzip a string smaller up to 80%)
>
> Yes, certainly, not arguing with that, wrt. speed.
>
> > It could be a separated layer in any case, but even over, will be faster.
The C# implementation of both hpack and hunpack are extremely fast, I need time
to create a Python version and I was planning to create a PHP
>
> No doubt, it should be a fairly simple transformation on other
> languages as well.
>
> > extension in C as well but only one Java guy told me he will try to create a
parser ... I mean, C# version is not that different, I guess a porting will take
a
>
> There are many good fast Java parsers, so I would recommend using one
> of those, and add transformation layer on top. No need to write a
> parser (IMO -- but I have written mine so I may be biased).
>
> > Anyway, I miss your point about specify the convention ... do you mean
> > proper specs? I could write something more than I already wrote on github
homepage, let me know.
>
> Yeah, specification of this convention (or transformation),
> documenting how it should behave. This is necessary (or at least
> useful) to ensure interoperability. Given how many people want to
> write their own json parsers (... just a random example...), because
> they don't like what is available, I'm sure there'll be many who'd
> want to reimplement this mapping as well.
> But at least implementations would be interoperable.
>
> So yes, need not be anything too heavy-weight, but somewhat formal
> notation helps in my opinion.
>
> Thanks!
>
> -+ Tatu +-
>

On Fri, May 29, 2009 at 3:29 AM, an_red@...
<andrea.giammarchi@...> wrote:
> Is something like this enough?
> http://wiki.github.com/WebReflection/json.hpack/specs-details

I think so (didn't read in detail) -- and if there are questions, it's
easy to contact you and suggest clarifications.

Thanks!

-+ Tatu +-

jswoof version 1.04 has been released. providing more speed improvements. some
minor bug fixes and updated documentation.
as usual you can get the latest version from:
http://www.waynemike.co.uk/jswoof

Last month, I announced the web_send library on this list:
http://tech.groups.yahoo.com/group/json/message/1250

When hosted by your server, the web_send library turns your Firebug
console into a command line for your server-side application. The same
code can also be run by the Windows Script Host, a standard part of
all Windows releases since Windows 98. Doing so has two big
advantages:

     * no files need to be uploaded to your web server
     * you are not restricted by the Same Origin Policy

As a result, you have a command line for all JSON resources on the
Web. The world is at your fingertips!

This page explains how to use the JSON shell, with examples from
Google, Yahoo!, Twitter and Flickr.

Continue reading at:
http://waterken.sourceforge.net/web_send/wsh/

--Tyler

--
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html

We have been having a heck of a time with an issue in IE8's implementation of
JSON.stringify(). It appears that IE8 *sometimes* encodes an empty string as the
string "null". If anyone has a clean work-around for this, or at least an
explanation I'd be really interested. Am I missing something?

Here is the repro:

var good = ""; // good === ""
var bad = document.createElement("input").value; // bad === ""

if (good === bad) {
	 // this is the path followed
	 alert("Strings: good === bad");
} else {
	 alert("Strings: good !== bad");
}

good = JSON.stringify(good); // good === '""' here
bad = JSON.stringify(bad); // bad === "null" here

if (good === bad) {
	 alert("JSON.stringify: good === bad");
} else {
	 // this is the path followed
	 alert("JSON.stringify: good !== bad");
}

IE may have a REFERENCE to the origianl object.

In your first example, when coerced into a string from th LEFT, they are
equivilant

The stringify method may convert t an OBJECT as null, since the element value is
not actually set.


--- In json@yahoogroups.com, "Stephen M. McKamey" <stephen@...> wrote:
>
> We have been having a heck of a time with an issue in IE8's implementation of
JSON.stringify(). It appears that IE8 *sometimes* encodes an empty string as the
string "null". If anyone has a clean work-around for this, or at least an
explanation I'd be really interested. Am I missing something?
>
> Here is the repro:
>
> var good = ""; // good === ""
> var bad = document.createElement("input").value; // bad === ""
>
> if (good === bad) {
>  // this is the path followed
>  alert("Strings: good === bad");
> } else {
>  alert("Strings: good !== bad");
> }
>
> good = JSON.stringify(good); // good === '""' here
> bad = JSON.stringify(bad); // bad === "null" here
>
> if (good === bad) {
>  alert("JSON.stringify: good === bad");
> } else {
>  // this is the path followed
>  alert("JSON.stringify: good !== bad");
> }
>

The triple-equals shouldn't be coercing the arguments before comparison. 
Reversing the order of the test to (bad === good) still results in true.  To top
that off, typeof returns "string" for both.

The other thing that is odd is that even if it were treating the value as a null
object, it should serialize as "null" but instead it actually serializes as the
escaped string '"null"'. There was a typo in the repro, it should have read:

    bad = JSON.stringify(bad); // bad === '"null"' here

What is scary about this, is that unless you fix it at the time of gathering the
data off the input element, you have no way of differentiating between a real
string and this bogus string which acts as if the user typed the word "null"
into the input.

--- In json@yahoogroups.com, "Stephen M. McKamey" <stephen@...> wrote:
>
> We have been having a heck of a time with an issue in IE8's implementation of
JSON.stringify(). It appears that IE8 *sometimes* encodes an empty string as the
string "null". If anyone has a clean work-around for this, or at least an
explanation I'd be really interested. Am I missing something?
>
> Here is the repro:
>
> var good = ""; // good === ""
> var bad = document.createElement("input").value; // bad === ""
>
> if (good === bad) {
>  // this is the path followed
>  alert("Strings: good === bad");
> } else {
>  alert("Strings: good !== bad");
> }
>
> good = JSON.stringify(good); // good === '""' here
> bad = JSON.stringify(bad); // bad === "null" here
>
> if (good === bad) {
>  alert("JSON.stringify: good === bad");
> } else {
>  // this is the path followed
>  alert("JSON.stringify: good !== bad");
> }

Below is the answer from Microsoft about this bug in JSON.stringify.  Thanks
Douglas Crockford for forwarding on to the appropriate contact at Microsoft.

It appears the short answer is that you have to test for empty strings coming
off DOM elements and replace with a real empty string.  That can be done via the
replacer function or at the time of retrieving the value.

---------- Forwarded message ----------
From: Allen Wirfs-Brock
Date: Tue, Jun 2, 2009 at 08:15
Subject: RE: [Fwd: [json] IE8 Native JSON Bug]


This is a  bug in the initial production version of IE8 that we were already
aware of.  The problem is that within the DOM a special encoding is used to
represent a missing string value.  Even though this special value is different
from the encoding of the JavaScript literal "", throughout the JScript
implementation the value is treated as being === to "" ... except for one
oversight in JSON.stringify.

Since this special value only originates from accesses to DOM objects one
workaround is to explicitly censor them on every DOM access that might return
one.  For example,
   var good, possiblyBad = good =document.createElement("input").value;
   if (possiblyBad === "") good = ""; //ensure possibly bogus "" is replaced with
a real ""
In particular, this should be done when accessing the value of an input element
if that value is going to be assigned to a structure that will be passed through
stringify.

Since the difference is only observable via stringify, another alternative is to
use the replacer function to perform the substitution:
   JSON.stringify(document.createElement("input").value,
                  function(k,v) { return v==="" ? "" : v});
   //the above will return "", not "null"

A post describing this problem and the workaround should appear on the JScript
blog (http://blogs.msdn.com/jscript/ ) sometime this week.

Allen

jswoof version 1.05 has been released. This version contains
a small fix for escaped uni-code characters during serialization.
please check out http://www.waynemike.co.uk/jswoof for more details.

--- In json@yahoogroups.com, "W" <wayne.ivor@...> wrote:
>
> jswoof version 1.04 has been released. providing more speed improvements. some
minor bug fixes and updated documentation.
> as usual you can get the latest version from:
> http://www.waynemike.co.uk/jswoof
>

Allen Wirfs-Brock suggested another work-around to the IE8 native JSON issue:

Another work-around that is isolated to a single place is to use IE8's "mutable
DOM prototypes" support to patch HTMLInputElement.prototype.value so that the
bogus "" value is filtered out.  For example:

...

(function() {

         var builtInInputValue =
Object.getOwnPropertyDescriptor(HTMLInputElement.prototype, "value").get;

         Object.defineProperty(HTMLInputElement.prototype, "value",

          { get: function() {

              var possiblyBad = builtInInputValue.call(this);

              return possiblyBad === "" ? "" : possiblyBad;

          }

          });

       })();

...

A patch like this could be conditionally executed as part of the initialization
code of a framework.

<!-- this is the javascript json parser function -->

     <script type="text/javascript" src="../jquery-1.2.6.min.js">
     </script>

     <script type="text/javascript">

     $(document).ready(function()
      {
        	 $('form#search').bind("submit", function(e)
		 {
            		 e.preventDefault();
            		 $('#content').html('');

            		 var query1 = urlencode($('input[name="user_a"]').val()); //userA
                         var query2 = urlencode($('input[name="user_b"]').val());
//userB


            		
$.ajax('http://twitter.com/friendships/exists.json?user_a='+query1+'&user_b='+qu\
ery2,
                         function(data,textdata)
			 {


                                   if(data == 'true')
                                     {
                     	               var newDiv = '<p>true</p>';
				     }

                    	      $('#content').append(newDiv);

                                 }, 'text');
                         });
                 })

           function urlencode(str) {
             return escape(str).replace(/\+/g,'%2B').replace(/%20/g,
'+').replace(/\*/g, '%2A').replace(/\//g, '%2F').replace(/@/g, '%40');
           }
     })

     </script>

<!-- javascript ends here -->

this functions will GET the json response from twitter which is true or false
after checking will append new div to the body....

problem is tht it doesnt seem to be working n i cant find the error...plzz
help...

--- In json@yahoogroups.com, "JIJO DASGUPTA (ANAND)"
> problem is tht it doesnt seem to be working n i cant find the error...plzz
help...

Your question is out of scope for this group. Ask the jQuery people.

jswoof version 1.06 has been released. containing a major speed
improvement to the array parsing functions.
As usual please check out http://www.waynemike.co.uk/jswoof for
more details.

--- In json@yahoogroups.com, "W" <wayne.ivor@...> wrote:
>
> jswoof version 1.05 has been released. This version contains
> a small fix for escaped uni-code characters during serialization.
> please check out http://www.waynemike.co.uk/jswoof for more details.
>
> --- In json@yahoogroups.com, "W" <wayne.ivor@> wrote:
> >
> > jswoof version 1.04 has been released. providing more speed improvements.
some minor bug fixes and updated documentation.
> > as usual you can get the latest version from:
> > http://www.waynemike.co.uk/jswoof
> >
>