Skip to search.

Breaking News Visit Yahoo! News for the latest.

×Close this window

json · JSON JavaScript Object Notation

The Yahoo! Groups Product Blog

Check it out!

Group Information

  • Members: 593
  • Category: Data Formats
  • Founded: Jul 19, 2005
  • Language: English
? Already a member? Sign in to Yahoo!

Yahoo! Groups Tips

Did you know...
Message search is now enhanced, find messages faster. Take it for a spin.

Messages

Advanced
Messages Help
RE: RE�: [json] __jsonclass__ hinting   Topic List   < Prev Topic  |  Next Topic >
Summarize Messages Sort by Date  
#488 From: "Atif Aziz" <atif.aziz@...>
Date: Mon Jul 31, 2006 11:44 pm
Subject: RE: RE�: __jsonclass__ hinting
azizatif
Send Email Send Email
 
>>
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.




#489 From: "meyer_jon" <jonmeyer@...>
Date: Wed Aug 2, 2006 12:30 am
Subject: Re: RE�: __jsonclass__ hinting
meyer_jon
Send Email Send Email
 
> 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.







 
Add to My Yahoo!      XML What's This?

Copyright © 2010 Yahoo! Inc. All rights reserved.
Privacy Policy - Terms of Service - Guidelines NEW - Help