>>

My impression is that in formulating the spec you are mostly thinking

about RPC being used to sending normalized data tables e.g. from a

database

<<



I'll admit that the roots are in RPC, but the application of the solution is

quite general when you consider that RPC is nothing more than structured request

and response.



> Your assumption here is that the end-point

> returns only one type of regularized data.



In the 90% case, yes. For the 10% case where the data ends up being dynamic in

shape from invocation to invocation, I'm hoping that the frameworks will step in

and provide a way to designate a field as the type discriminator. The upside of

this is that you get tremendous flexibility and no one needs to define a

standard. The producer shapes the data and the consumer maps it to their manner

of convenience. The downside is that you'll need fairly mature frameworks to

deal with this sort of mapping.



>>

object GetPageData();

This is where runtime __jstype comes in.

In our case we've already defined a Person class on both the client

and the server. So our app already knows what a Person looks like.

<<



Obviously, if the client and server know the types and have been able to

describe it to each other in a neutral manner, then you're already ahead of me.

:)



>>

My point is if you only care about the 6 basic types, you don't

need a type schema at all, because JSON is already happily

unambiguous when it comes to those 6 basic types. If you receive a

message, there's no way you can mistake a string for a bool for a

number.

<<



True and in this case, the only purpose the schema will be serving is in

describing the shape of JSON objects. That is, what properties they are expected

to carry and of which of the basic types. Again, this is only beneficial for the

strongly-typed languages camp.



BTW, I've come to the conclusion that there are only 5 types interesting for

schemas: Boolean, Number, String, Array and Object. It is useless to recognize

Null as a type since it can only bear one run-time value.



________________________________________

From: json@yahoogroups.com [mailto:json@yahoogroups.com] On Behalf Of meyer_jon

Sent: Tuesday, July 25, 2006 5:11 PM

To: json@yahoogroups.com

Subject: Re: RE�: [json] __jsonclass__ hinting



I guess I need to wait for the full document - in your example:



> { "name" : "string",

> "sirname" : "string",

> "birthday" : "string/time"

> "children" : {

> type : "array/object/person",

> maxLength : 10,

> nullable : false

> }



I don't yet see how you define "time" or "person". How do you support

enums? What about multidimensional arrays? Subclassing?



My impression is that in formulating the spec you are mostly thinking

about RPC being used to sending normalized data tables e.g. from a

database - a scenario which fits well with using an external schema

definition. The Yahoo service you mention is one such example. As you

say, you want to:



> providing a machine-readable

> way of describing the expected structure of some JSON data

> in advance to (rather than during) the reception of the data.



You also point out that



> Given just this piece of JSON data, you can't say anything

> about it *unless* you consider *where* it came from. If the source

> end-point has a way to describe its structure and the structure

> of its results then you've got what you wanted.



Your assumption here is that the end-point returns only one type of

regularized data. But our app has RCP endpoints like:



object GetPageData();



where, according to how the user has configured their page, different

objects are returned. Think of netvibes (www.netvibes.com). Presumably

they have a call like:



object[] GetColumnContents()



which returns different types of objects according to what modules the

user has dragged onto a page.



In this scenario, RPC is being used not to send database tables but

rather dynamic graphs of objects. For us, knowing "where it came from"

and "in advance" cannot tell us the structure of the data.



This seems like a very reasonable use of JSON-RCP, but it requires

support for sending dynamically typed data, where you can do:



var x = server.GetPageData();

if (x instanceof Person) { ... }



This is where runtime __jstype comes in.



You could argue that this is a niche use of RPC. But my impression is

that, as Ajax matures, you will see much more of this kind of thing -

and the standards process is slow so its important to be forward looking.



Regarding:



> How does it help to know that

> "__jstype" is a person when I don't have a standard way to describe what

> person data could look like?

>



In our case we've already defined a Person class on both the client

and the server. So our app already knows what a Person looks like. We

just want to be able to pass Person instances back and forth using RPC.



>

> > I don't see how adding type hints changes security issues.

> If it is checking against the wrong schema based on the

> type hint then there's trouble looming, no?



Secure servers are written defensively. They never assume that

the messaging layer produces valid messages. Any data from a client

is checked against an internal schema maintained on the server.

Changing __jstypes in a message might confuse the Serializer, but it

shouldn't get past the internal security checks.



> > You make a claim that "parties that don't understand the extension can

> > still work with the basic types they know about." I see this as a

> > false claim.

>

> Care to expand? Can't let you get away with just that. ;)



My point is if you only care about the 6 basic types, you don't

need a type schema at all, because JSON is already happily

unambiguous when it comes to those 6 basic types. If you receive a

message, there's no way you can mistake a string for a bool for a

number. That's one of the great things about JSON.

> In the 90% case, yes. For the 10% case where the data ends up

> being dynamic in shape from invocation to invocation, I'm

> hoping that the frameworks will step in and provide a

> way to designate a field as the type discriminator.



I guess this is our point of departure.



You view dynamic data as a 10% rare case that falls outside what you

are interested in, one which you hope others will figure out.



I have a dynamic app - one where the user can turn on and off

different options, and as they do a single RPC method returns

different types of JSON objects. Is that really so rare? I don't think so.



Are others out there doing dynamic data interchanges in JSON like this?



Type hinting is hardly controversial. As evidence, consider that every

mature JSON serializer has a way of doing it. JSON-RPC-Java uses

javaClass:



{

   "javaClass": "java.util.ArrayList",

   "list": [0, 1, 2, 3, 4]

}



Refeed uses "jsonclass":



{"jsonclass": ["RF_Feed", [{"id": 3}]]}.



json-rpc.org uses "__jsonclass__":



  {"__jsonclass__": ["MyDate", [2005, 4, 4]]}



We use "jstype":



  {"jstype": "MyDate"}



And that's just the problem: right now everyone has a different

attribute name and slightly different technique for doing exactly the

same thing - tagging a { } struct with a type name. Surely this this

is the kind of thing a standard should address?



Relegating dynamic data to the "10%" case is shortsighted. Sure,

static data is common. But so is dyanamic data. Addressing dynamic

data enables a range of richer apps. As JSON matures these richer apps

are going to dominate.



Its a bit like a C programmer arguing that, since 90% of data is

static, and typedef covers that, who needs class? That position stuck

for many years, and as a result every single C coder had to create a

homegrown solution for doing classes in C - it was a mess.



Fortunately, JavaScript is already object oriented. And so are nearly

all server languages. Expecting data to be static 90% of the time is

ignoring the nature of the web.