Yes, although this is an XML DTD discussion. Most DTDs including the XML-RPC and SOAP DTDs don't encode using attribute values but instead using child elements with character data (apparently this is the XML best practice). Much Much bigger.
Also, the JSON takes one line of code to parse and access natively in our defacto web browser language 'JavaScript'.
The second requires a bloated JavaScript XML parser (as this is not built in to many browsers) and CPU intensive processing and a cumbersome API to get the data out. Also try doing 100 RPC calls a second with SOAP in a browser (this can be done with JSON-RPC on a local network - 10ms round trip on simple methods).
A1. The idea is to make it transparent to the programmer. You can practically just call a Java method from your JavaScript web application. one line of code is required to export or allow access to a server-side object.
A2. Yes, security is an interesting topic. The Java implementation refered to works on a deny all by default - allow specific objects to specific clients. It does require the programmer to think about what methods they are exposing. I have been using it over HTTPS with selective objects exported to authorized clients (using the existing JAAS Java authorization and Authentication framework), so I believe it can be used in a very secure way.
Slashdot Mirror
When you've put it on the web, send a mail to the author of this page: http://www.crockford.com/JSON/ I'm sure he'll be interested.
Yes, although this is an XML DTD discussion. Most DTDs including the XML-RPC and SOAP DTDs don't encode using attribute values but instead using child elements with character data (apparently this is the XML best practice). Much Much bigger.
Also, the JSON takes one line of code to parse and access natively in our defacto web browser language 'JavaScript'.
The second requires a bloated JavaScript XML parser (as this is not built in to many browsers) and CPU intensive processing and a cumbersome API to get the data out. Also try doing 100 RPC calls a second with SOAP in a browser (this can be done with JSON-RPC on a local network - 10ms round trip on simple methods).
A1. The idea is to make it transparent to the programmer. You can practically just call a Java method from your JavaScript web application. one line of code is required to export or allow access to a server-side object.
A2. Yes, security is an interesting topic. The Java implementation refered to works on a deny all by default - allow specific objects to specific clients. It does require the programmer to think about what methods they are exposing. I have been using it over HTTPS with selective objects exported to authorized clients (using the existing JAAS Java authorization and Authentication framework), so I believe it can be used in a very secure way.