json-php on slashdot

[George Jempty]

In my journal anyway:

"JSON: Javascript Unusable by the Client"

http://slashdot.org/~scriptify/journal/103074

[Lasse Reichstein Nielsen]

"George Jempty" <sc*******@yaho o.com> writes:

In my journal anyway:

"JSON: Javascript Unusable by the Client"

http://slashdot.org/~scriptify/journal/103074

I must admit, I fail to see the point of your journal entry. It appears
to try to point out problems with JSON, but which problems? And are
they JSON problems or strawmen? (I'm leaning towards the latter).
quote: "This same sample data file specified as the src attribute of a
script tag results in a page throwing a Javascript error"

Well, what did you expect?

JSON is a *value* description language. It is a subset of ECMAScript's
literal notation, which is *expression* syntax. When you try loading
and evaluating it as a statement, it fails.

If you fetch the text using XMLHttpRequest and evaluates it using
"eval", then it works perfectly (and if you are targeting a browser
only, it's a much better format to send your data in than, e.g., XML).

You have a language for expression values. You want these values to
be available to your code, so you must have some way of getting the
text and parsing it.

*One* such way is to put the *JSON* text into a *Javascript*
assignment and load the assignment into a script tag on a web page.
That does not make the assignment part of the JSON value, nor
does it need to be.

But, looking at the *first* answer in the PHP-JSON thread linked to,
all this has already been said.
<URL:http://groups.yahoo.co m/group/json-php/message/9>

Ah, I now see that you are the "scriptify" of that conversation.
I'll just chip in and say that Michal Migurski is *absolutely right*.

From what you have written so far, I am not able to see a need that
cannot be solved using PHP and the JSON library. If you can express
your need more clearly, I am certain we can find a way to fulfill it.

(On the other hand, the "sample data for a C# parser" does have an
error. It should not end with a semicolon).
/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[George Jempty]

Lasse Reichstein Nielsen wrote:

"George Jempty" <sc*******@yaho o.com> writes:

In my journal anyway:

"JSON: Javascript Unusable by the Client"

http://slashdot.org/~scriptify/journal/103074
I must admit, I fail to see the point of your journal entry. It

appears to try to point out problems with JSON, but which problems? And are
they JSON problems or strawmen? (I'm leaning towards the latter).
quote: "This same sample data file specified as the src attribute of a script tag results in a page throwing a Javascript error"

Well, what did you expect?

JSON is a *value* description language.

JSON is nothing but an idea: there's no official specification. Mine
is nothing but an idea to possibly improve it. A viable and easily
implementable idea to fully accomodate all manner of client side
scripting. An idea to spark debate. To perhaps get enough momementum
behind JSON so that it becomes a specification.

Or to result in a fork. I've already got my acronym ready. Help me
stir up some controversy.

"When a true genius appears, you can know him by this sign: that all
the dunces are in a confederacy against him. -- Jonathan Swift"

[Jim Ley]

On 5 Apr 2005 13:31:52 -0700, "George Jempty" <sc*******@yaho o.com>
wrote:

JSON is nothing but an idea: there's no official specification.
Definie "official"
Mine is nothing but an idea to possibly improve it.
but you've not made a proposal to improve it, you've made a load of
complaints against an implementation that isn't in anyway wrong, and
doesn't even stop you doing exactly what you want to do.
To perhaps get enough momementum
behind JSON so that it becomes a specification.
There's no standards body appropriate to take it - ECMA, there's no
point, too expensive, W3, not chartered to do anything in the area, a
member submission perhaps, but that would be the end of it, and we'd
need to dig up a member to submit it (or a 11,000 dollars to become a
member) but it doesn't need to go before a standards body or
consortium, it has a specification already.
Or to result in a fork. I've already got my acronym ready. Help me
stir up some controversy.

but there is no controversy, there's just your strange complaint
against an implementation which the developers seem to have addressed
well by my reading.

Jim.

[George Jempty]

Jim Ley wrote:

On 5 Apr 2005 13:31:52 -0700, "George Jempty" <sc*******@yaho o.com>
wrote:

JSON is nothing but an idea: there's no official specification.

Definie "official"

Mine is nothing but an idea to possibly improve it.

but you've not made a proposal to improve it

I most certainly have, and more than once; I suggest you re-read my
comments.

"The purpose of the Rule of Least Surprise is to reduce the amount of
complexity a user must absorb to use an interface." -- Eric S Raymond

[Lasse Reichstein Nielsen]

"George Jempty" <sc*******@yaho o.com> writes:

JSON is nothing but an idea: there's no official specification.
Douglas Crockford's specification exists. Whether it is official
or not is a matter of definition.
Mine is nothing but an idea to possibly improve it.
My problem with your suggestion is that I don't see what problem it
solves, that doesn't already have a simpler solution (if you can
explain the problem so that I can see that I am wrong at this, please
do).

Instead it complicates the specification with extra fluff that is only
relevant to one single, very specific, use of JSON: in webpages read
by browsers and added to the page by a Javascript script element with
only the JSON expression as the script code.
A viable and easily implementable idea to fully accomodate all
manner of client side scripting.
No, not all manner of client side scripting.
*Webpage* in a *browser* using *Javascript* and loading the JSON
expression using a *script element* with a *src attribute*.

Any of these could be changed, and your addition has just become
an obstacle. And if everything matches, there is no problem
adding the assignment to the script without adding it to the JSON
syntax.
An idea to spark debate. To perhaps get enough momementum behind
JSON so that it becomes a specification.
Debate is raging. Your side is not doing too well at convincing the
other side :)

Momentum will come with use. One of the strengths of JSON is its
simplicity and generality, both of which your suggested addition
goes against.
Or to result in a fork. I've already got my acronym ready. Help me
stir up some controversy.

I don't see a need for controversy. It works perfectly well as
written. Again, if you can show a situation where it doesn't, I'd be
happy to see it.

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

[Lee]

George Jempty said:

Jim Ley wrote:

On 5 Apr 2005 13:31:52 -0700, "George Jempty" <sc*******@yaho o.com>
wrote:

>JSON is nothing but an idea: there's no official specification.

Definie "official"

> Mine is nothing but an idea to possibly improve it.

but you've not made a proposal to improve it

I most certainly have, and more than once; I suggest you re-read my
comments.

So far, everybody who's read your comments seems to disagree with you.
JSON defines a format for values. You're asking for it to also include the
assignment of the value to a variable. That's not an improvement.

[George Jempty]

Lasse Reichstein Nielsen wrote:

"George Jempty" <sc*******@yaho o.com> writes:

JSON is nothing but an idea: there's no official specification.
Douglas Crockford's specification exists. Whether it is official
or not is a matter of definition.

Mine is nothing but an idea to possibly improve it.

My problem with your suggestion is that I don't see what problem it
solves, that doesn't already have a simpler solution (if you can
explain the problem so that I can see that I am wrong at this, please
do).

Instead it complicates the specification with extra fluff that is

only relevant to one single, very specific, use of JSON: in webpages read
by browsers and added to the page by a Javascript script element with
only the JSON expression as the script code.

And this one single very specific use of JSON is *precisely* the way
you would expect to be able to use it. The way Javascript has been
getting done *for ten years*. A way prescribed by the W3C for using
Javascript.

And the way I am going to use it, if I have to fork my own "standard"
and write my own parsers.

[Lasse Reichstein Nielsen]

"George Jempty" <sc*******@yaho o.com> writes:

Lasse Reichstein Nielsen wrote: ....

one single, very specific, use of JSON: in webpages read
by browsers and added to the page by a Javascript script element with
only the JSON expression as the script code.

And this one single very specific use of JSON is *precisely* the way
you would expect to be able to use it.

No, not only that specific use, but also the additional requirement
that the script contents must
1) be static (if dynamically generated, e.g., with PHP, it's trivial
to add the assignment before the JSON value)
2) contain *only* a valid JSON expression (since otherwise, you could
just let it contain the assignment as well)
The way Javascript has been getting done *for ten years*. A way
prescribed by the W3C for using Javascript.
Then keep doing it. But your requirements are unnecessary. Drop the
second requirement above, and you don't need to change JSON's
syntax. If I have misinterpreted it, please tell me where I missed the
point.
And the way I am going to use it, if I have to fork my own "standard"
and write my own parsers.

Go right ahead, but I think there are easier ways to solve whatever
problem you are trying to solve.

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

[Douglas Crockford]

> And this one single very specific use of JSON is *precisely* the way

you would expect to be able to use it. The way Javascript has been
getting done *for ten years*. A way prescribed by the W3C for using
Javascript.

And the way I am going to use it, if I have to fork my own "standard"
and write my own parsers.

The usage pattern you have been describing is brittle and badly
factored. You certainly have a right to practice bad design, though I
don't understand why anyone would want to pay you to do so.

The changes you are proposing to JSON are unnecessary and will tend to
promote bad practices. Fork if you must, but I think you would do better
to understand the comments of the other people who have contributed to
this topic.

http://www.JSON.org