 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion GroupsGeneralPHPASPPerlColdFusionFlashHTML, CSS, ScriptsBrowsers |
Webmaster Forum / HTML, CSS, Scripts / JavaScript / July 2005proposed new standard: JSON++
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. > http://htmatters.net/htm/1/2005/07/evaling-JSON.cfm > [quoted text clipped - 11 lines] > 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. Matthew J wrote: > http://htmatters.net/htm/1/2005/07/evaling-JSON.cfm > [quoted text clipped - 5 lines] > 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. 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. > 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  SignatureLasse Reichstein Nielsen - lrn@hotpop.com DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html> 'Faith without judgement merely degrades the spirit divine.' > 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 SignatureLasse Reichstein Nielsen - lrn@hotpop.com DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html> 'Faith without judgement merely degrades the spirit divine.' > > I merely find it interesting that Mr Crockford chooses to assign a > > function literal as a value within an object literal for his JSON [quoted text clipped - 3 lines] > 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 [quoted text clipped - 5 lines] > 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. > 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 SignatureLasse Reichstein Nielsen - lrn@hotpop.com DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html> 'Faith without judgement merely degrades the spirit divine.' The problem is eval(). JSON++ avoids it. Thanks for playing. 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?') SignatureRandy comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly > 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 ;) > 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 SignatureLasse Reichstein Nielsen - lrn@hotpop.com DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html> 'Faith without judgement merely degrades the spirit divine.' > "eval" is a function of Javascript, and . JSON is independent of programming > languages. Adding features to JSON to avoid using "eval" in Javascript is [quoted text clipped - 5 lines] > 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. > 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. > 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 [quoted text clipped - 9 lines] > 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. 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. > I guess I'll be acused of a nasty trolling, but I'm serious and calm > :-| [quoted text clipped - 5 lines] > 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. |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.