proposed new standard: JSON++

[G Matthew J]

http://htmatters.net/htm/1/2005/07/evaling-JSON.cfm

This is more or less in response to Mr Crockford's admonition a few
months ago, "fork if you must". Ironically, although in that usenet
post he calls what I am suggesting "brittle", his own Javascript JSON
parser is not valid JSON, but rather conforms to my proposed variation
on JSON!! With an identifier prepended to the front of the JSON block,
and function literals as values: see
http://www.crockford.com/JSON/json.js

Out of deference to Mr Crockford's outstanding original idea, I propose
this new standard be called JSON++. One of my key motivations is to
help a JSON-based technology to get more traction; XML is entrenched as
a data format so I believe adding declarative capabilities could make
JSON more valuable.

[Christopher J. Hahn]

G Matthew J wrote:

http://htmatters.net/htm/1/2005/07/evaling-JSON.cfm

This is more or less in response to Mr Crockford's admonition a few
months ago, "fork if you must". Ironically, although in that usenet
post he calls what I am suggesting "brittle", his own Javascript JSON
parser is not valid JSON, but rather conforms to my proposed variation
on JSON!! With an identifier prepended to the front of the JSON block,
and function literals as values: see
http://www.crockford.com/JSON/json.js

Out of deference to Mr Crockford's outstanding original idea, I propose
this new standard be called JSON++. One of my key motivations is to
help a JSON-based technology to get more traction; XML is entrenched as
a data format so I believe adding declarative capabilities could make
JSON more valuable.

I see what you're saying, but I disagree about ignoring the identifier.
A standardized identifier amounting to an array container would seem
most useful, as with minimal modification the identifier could easily
be converted (or ignored, as seen fit) by other languages, and the JSON
could be said to always evaluate to a predictable thing.

Another option might be wrapping it in a function call to avoid naming
conflicts as multiple JSON objects are loaded.

i.e.

JSON(
// JSON literals
)
This seems most portable and reuseable, and gets around the eval()
issue. It does take a slight bit away from JSON, but I think what it
takes away in purity it gives back in useability.

[Christopher J. Hahn]

Matthew J wrote:

http://htmatters.net/htm/1/2005/07/evaling-JSON.cfm

This is more or less in response to Mr Crockford's admonition a few
months ago, "fork if you must". Ironically, although in that usenet
post he calls what I am suggesting "brittle", his own Javascript JSON
parser is not valid JSON, but rather conforms to my proposed variation
on JSON!! With an identifier prepended to the front of the JSON block,
and function literals as values: see
http://www.crockford.com/JSON/json.js

Now are you proposing that functions be declarable by pure JSON++? At
that point, aren't we leaving the realm of data interchange and
entering the realm of... well, language-specific programming?

What works in JS won't work in VBS, PERL, Python, and many, many other
languages. A data interchange format is one thing, but if you're
talking about actually passing functions around then the recipient
would have to have a full JS parser + translate into the native
language, or a parser + compiler that would provide an interface to the
JS functionality. Then we're into security issues because essentially,
you're downloading what amounts to arbitrary code.

[G Matthew J]

I merely find it interesting that Mr Crockford chooses to assign a
function literal as a value within an object literal for his JSON
parser, whereas this is illegal with JSON itself. I agree that to
expect various server side languages to parse Javascript function
literals is unrealistic.

However, most such languages already process regular expressions, and
with little effort they may be able to convert a Javascript regular
expression literal, passed via JSON, to their own regular expression
format. I think there is tremendous power in that.
*** Sent via Developersdex http://www.developersdex.com ***

[Richard Cornford]

G Matthew J wrote:

http://htmatters.net/htm/1/2005/07/evaling-JSON.cfm

This is more or less in response to Mr Crockford's admonition
a few months ago, "fork if you must". <snip>

The question you never actually answered at the time was why you thought
you needed this. A general form of text data as an object literal
without any extraneous material can be imported/included in server side
scripts to add your identifier and assignment with virtually no effort.
E.G. (JSP):-

var myIdentifier = <%=getJASONtext(); %>;

(Or half a dozen equally trivial alternatives)

- and sent off to the browser as a JS file if that is how you want to
send it. All you do by including the identifier and assignment is
restrict the contexts in which the data can be used.
Out of deference to Mr Crockford's outstanding original
idea, I propose this new standard be called JSON++.

That hardly seems like deference, maybe JSON-- would be a better name
for a less flexible sub-set ;)

Richard.

[G Matthew J]

Richard Cornford wrote:

The question you never actually answered at the time was why you thought
you needed this. A general form of text data as an object literal
without any extraneous material can be imported/included in server side
scripts to add your identifier and assignment with virtually no effort.
E.G. (JSP):-

var myIdentifier = <%=getJASONtext(); %>;

(Or half a dozen equally trivial alternatives)

- and sent off to the browser as a JS file if that is how you want to
send it. All you do by including the identifier and assignment is
restrict the contexts in which the data can be used.

I want to be able to at least start my Javascript programming the way
it has been being done for 10 years: using plain text. That is why I
need this, and I'm quite certain I actually communicated this a number
of times earlier. Please let me know not only if I am being unclear,
but also how I am being unclear.

To elaborate, I'm trying to write a general purpose Javascript
application, for which I will then write controllers in the half dozen
or so server side alternatives you allude to. I don't want to be tied
down to just one server side solution while I do my original client
side programming. All that should be required is HTML and Javascript,
and all that has ever been required to program with these technologies
is a text editor.

Out of deference to Mr Crockford's outstanding original
idea, I propose this new standard be called JSON++.

That hardly seems like deference, maybe JSON-- would be a better name
for a less flexible sub-set ;)

Although in general I respect your contributions to this newsgroup, I
completely disagree with you. You yourself a dependency on top of
Javascript in order to program with JSON: you must programmatically
generate a Javascript/JSON expression. Using a text editor is no
longer an option. My concept does away with this added dependency, and
"fewer dependencies" is generally seen as synonymous with "_more_
flexible"

Furthermore, and for the umpteenth time, the identifier I propose is
_optional_. Again, this makes my proposal _more_ flexible, not less.
Server-side parsers are free to throw away the identifier, and then
process the remainder as they would with present-day JSON. Here is a
quasi-use-case:

No identifier: no problem. Just parse it as normal. Identifer: oh,
that's for client side flexibility. Throw it away, then just parse as
normal.

This in my opinion clearly makes my concept a super-set of JSON. As
does my concept of allowing Javascript regular expression literals.
Let me try to explain the power of this concept:

JSON parsers are free to continue to reject Javascript regex literals
as I believe they do at present; JSON++ parsers won't reject regex's
out of hand, but rather can pass them to an additional handler to
convert them to their server side's native regex implementation.

I am convinced this will enable a more declarative model for
client-server web development. Spring is being called Java's killer
app. My vision along the same lines is to make JSON++, a subset of
Javascript and a superset of JSON, Javascript's killer app.

[Lasse Reichstein Nielsen]

G Matthew J <je**********@yahoo.com> writes:

I merely find it interesting that Mr Crockford chooses to assign a
function literal as a value within an object literal for his JSON
parser, whereas this is illegal with JSON itself.
JSON is not Javascript. The parser is written in Javascript. Why
are you surpriced that it contains something that is not valid JSON
syntax?
However, most such languages already process regular expressions, and
with little effort they may be able to convert a Javascript regular
expression literal, passed via JSON, to their own regular expression
format.

Send a string.

I still think that you are trying to fix a problem that isn't there,
or merely using the wrong tool to fix the problem.
/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[Lasse Reichstein Nielsen]

Lasse Reichstein Nielsen <lr*@hotpop.com> writes:

JSON is not Javascript.

That was too simplistic. JSON is a *subset* of Javascript syntax,
so technically, it is Javascript. It's just not all of Javascript.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[G Matthew J]

Lasse Reichstein Nielsen wrote:

G Matthew J <je**********@yahoo.com> writes:

I merely find it interesting that Mr Crockford chooses to assign a
function literal as a value within an object literal for his JSON
parser, whereas this is illegal with JSON itself.

JSON is not Javascript. The parser is written in Javascript. Why
are you surpriced that it contains something that is not valid JSON
syntax?

Not necessarily surprised, just pointing out the irony of Mr Crockford
calling my proposed data format, with optional prepended identifier,
"brittle", but then himself using it. Also I seem to recall having
heard something about the power of a language being implemented in
itself.

However, most such languages already process regular expressions, and
with little effort they may be able to convert a Javascript regular
expression literal, passed via JSON, to their own regular expression
format.

Send a string.

I still think that you are trying to fix a problem that isn't there,
or merely using the wrong tool to fix the problem.

I disagree. I believe that there has been an unmitigated "impedence
mismatch" between client-side Javascript and server-side web
development for 10 years. For instance, you have to code one way to
validate forms in the browser, but another way to validate forms on the
server.

JSON++, especially with its proposed support for Javascript literal
regular expressions, will minimize this gap. The same JSON++
configuration file can be used by a client side Javascript controller,
and a server-side controller in your choice of language.

The first JSON++ parser will be announced here next month at the
latest. I'm beginning by extending Mr Crockford's Java classes -- more
testimony on my part to the value I certainly see in all his ideas and
work. I just want to take them further, to a declarative model, where
the same JSON++ configuration file can be used by client-side
Javascript controllers, and server-side controllers in your choice of
language.

[Lasse Reichstein Nielsen]

"G Matthew J" <je**********@yahoo.com> writes:

Lasse Reichstein Nielsen wrote:
Not necessarily surprised, just pointing out the irony of Mr Crockford
calling my proposed data format, with optional prepended identifier,
"brittle", but then himself using it.
He is not using it (extended JSON). He is using Javascript. JSON is not
a programming language.
Also I seem to recall having heard something about the power of a
language being implemented in itself.
Pretty much any programming language can do that. However, JSON is not
a programming language. It is a data format for static data, not an
executable program.
I disagree. I believe that there has been an unmitigated "impedence
mismatch" between client-side Javascript and server-side web
development for 10 years. For instance, you have to code one way to
validate forms in the browser, but another way to validate forms on the
server.
Probably because the client side is based on DOM and the server side
is working purely on name/value pairs (or more likely because the
server side is not written in Javascript).
JSON++, especially with its proposed support for Javascript literal
regular expressions, will minimize this gap. The same JSON++
configuration file can be used by a client side Javascript controller,
and a server-side controller in your choice of language.
You can already do that, if you send the regular expressions as strings.

And there is still no need for adding browser-specific assignments,
even if optional, to a format that is meant to be platform
independent.
The first JSON++ parser will be announced here next month at the
latest.

I still fail to see the problem that extending JSON solves, that can't
be solved by just using pure Javascript.
JSON is not a programming language. It is a data format, and chosen to
be platform independent. Adding features aimed at a single target
platform, which already have Javascript, does not enhance your
expressive power, but it does confuze things.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[VK]

I guess I'll be acused of a nasty trolling, but I'm serious and calm
:-|

Did you guys think that you are actually inventing LISP ?

Your JSON/JSON++ stopped in a step from a LISP subset. All you have to
do is to solve the eval() ugliness, allow to create n-nested structures
of structures and allow many-to-many connections between structures'
members.

P.S. I just happened to know LISP (in theory, did not program too
much), because it's used widely in A.I., speech recognition and other
"self-learning" systems.

[G Matthew J]

The problem is eval(). JSON++ avoids it. Thanks for playing.

[Randy Webb]

G Matthew J said the following on 7/26/2005 7:33 PM:

The problem is eval(). JSON++ avoids it. Thanks for playing.

What problem with eval? The one where people who don't know better use
it for things that it should never be used for?

Or is it the usage as such:

eval('User Who doesn't understand how to quote?')

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly

[Lasse Reichstein Nielsen]

"G Matthew J" <je**********@yahoo.com> writes:

The problem is eval(). JSON++ avoids it. Thanks for playing.

"eval" is a function of Javascript, and . JSON is independent of programming
languages. Adding features to JSON to avoid using "eval" in Javascript is
counter to the goal of JSON.

The problem is your insisting that the file sent from a web server to
a web browser client must be only JSON.

So, my suggestion: Go ahead with what you do, but please call it
something else to avoid confuzing with JSON.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[G Matthew J]

Randy Webb wrote:

G Matthew J said the following on 7/26/2005 7:33 PM:

The problem is eval(). JSON++ avoids it. Thanks for playing.

What problem with eval? The one where people who don't know better use
it for things that it should never be used for?

Precisely. Why play with fire?
Or is it the usage as such:

eval('User Who doesn't understand how to quote?')

I love you too Randy ;)

[G Matthew J]

Lasse Reichstein Nielsen wrote:

"eval" is a function of Javascript, and . JSON is independent of programming
languages. Adding features to JSON to avoid using "eval" in Javascript is
counter to the goal of JSON.

The problem is your insisting that the file sent from a web server to
a web browser client must be only JSON.

So, my suggestion: Go ahead with what you do, but please call it
something else to avoid confuzing with JSON.

I cannot resist trying to make you understand what I'm trying to do,
though at the same time I realize I've failed. I am close to finishing
my first parser, then perhaps an example will help.

As for the name, I'm sorry you find it confusing, but as for usage,
there will be _no_ difference as far as existing JSON users are
concerned. You will be able to use JSON++ to parse existing JSON, just
like you can use a C++ compiler to compile what previously compiled
under C proper.

One goal in naming it JSON++ is to bring more attention to the
technology in general, whether it be strictly as a data format (JSON),
or a data format with additional declarative capabilities (JSON++). I
believe that my backward compatible implementation(s) will in the end
provide increased traction for JSON itself, a beneficial side effect.

[G Matthew J]

VK wrote:

I guess I'll be acused of a nasty trolling, but I'm serious and calm
:-|

Did you guys think that you are actually inventing LISP ?

Your JSON/JSON++ stopped in a step from a LISP subset. All you have to
do is to solve the eval() ugliness, allow to create n-nested structures
of structures and allow many-to-many connections between structures'
members.

Well I don't intend to take JSON++ that far but LISP is one of my
inspirations.