I've done some test on that, and almost all simple web services that
offer JSON as output could be compiled using the XSD compiler inside
.NET SDK, what was missing is always the response class. In my Yahoo!
example (http://weblogs.asp.net/mschwarz/) I was missing the ResultSet
class, which I wrote at my own. All other classes could be created
using the XML schema. The only thing is that Yahoo! i.e. doesn't use
the same data type for JSON as defined in the XML schema.

Do you we need a new schema or can we use XML schema (the light way).
I would be very interessted in having a schema for JSON, too.

Regards,
Michael




On 7/17/06, Fang Yidong <fangyidong@...> wrote:
>
>
>
>
>
>
>
>
> Common datatypes seem to be a good idea. Maybe we can
> do 'JSON schema'? :-)
>
> But as to XML schema, I think it's too complicated.
>
> --- Michael Schwarz <michael.schwarz@...>:
>
>
> > Because I'm currently using .NET data types in my
> > JSON parser, do you
> > think it would be a good idea to use common data
> > type identifiers like
> > used in XML schema?
> >
> >
> http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#built-in-datatypes
> >
> > Regards,
> > Michael
> >
> >
> >
> > On 7/17/06, Fang Yidong <fangyidong@...>
> > wrote:
> > >
> > >
> > > If used in general purpose,maybe it's good to add
> > the
> > > table name and the field datatypes in the metadata
> > > section.
> > >
> > > --- Mert Sakarya <msakarya@...>:
> > >
> > >
> > > > Hi, I am using readonly datasets in the
> > following
> > > > format;
> > > >
> > > > {
> > > > "DataSet" : {
> > > > "Tables" : [
> > > > {
> > > > "Fields" : ["Column1","ImgDate","Column2"],
> > > > "Records" : [
> > > > ["16.7.2006,Pazar","16.7.2006,Pazar",51],
> > > > ["9.7.2006,Pazar","9.7..2006,Pazar",54],
> > > > ...
> > > > ]
> > > > }
> > > > ]
> > > > },
> > > > "Parameters" : { //Any other you want to return,
> > > > total number of records...
> > > > "RETURN_VALUE" : "0"
> > > > }
> > > > }
> > > >
> > > >
> > > >
> > > >
> > > > Mert Sakarya
> > >
>
> > > > IT Direkt榘庯拷
>
> > >
> > > >
> > > >
> > > >
> > > > Tel
> > > > : (212) 251 85 70 / 112
> > > > Fax
> > > > : (212) 251 89 50
> > > > www.yenibiris.com
> > > >
> > > > ________________________________________
> > > > From: json@yahoogroups.com
> > > > [mailto:json@yahoogroups.com] On Behalf Of Todd
> > > > Sent: Thursday, July 13, 2006 12:02 AM
> > > > To: json@yahoogroups.com
> > > > Subject: RE: [json] JSON representation of
> > common
> > > > types
> > > >
> > > > Thanks for the great feedback Atif.
> > > >
> > > > But I'm really not looking to introduce behavior
> > > > into JSON at all. I don't
> > > > think we even need to get that in depth in order
> > to
> > > > outline a basic way of
> > > > returning the data inside the DataSet.
> > > >
> > > > A DataSet may be an object specific to .NET but
> > each
> > > > language has some form
> > > > of object that represents data returned from a
> > > > database. They may be known
> > > > by a different names, get referenced with
> > different
> > > > syntax, and have
> > > > slightly different behaviors associated with
> > them.
> > > > However, at the most
> > > > fundamental level they are approximately the
> > same
> > > > thing, that being, a
> > > > "flat" 2 dimensional data object (containing
> > columns
> > > > and rows).
> > > >
> > > > My thought is not to duplicate all the
> > "behavioral
> > > > baggage". It is simply to
> > > > take that data (columns and rows) and decide on
> > a
> > > > uniform way of
> > > > representing it within JSON.
> > > >
> > > > In reality there are only two ways to look at
> > > > DataSets, QueryBeans,
> > > > Whatever.....
> > > >
> > > > 1. An Array of Objects (where each object has an
> > > > identical set of keys)
> > > > 2. An Object of Arrays (where each array can be
> > > > assumed to be of the
> > > > exact same length)
> > > >
> > > > These objects can also be returned at the root
> > level
> > > > or nested down inside a
> > > > "wrapper" object that contains "supporting" key
> > > > values such as column Lists,
> > > > record counts, etc...
> > > >
> > > > Everyone who has ever written a JSON parser has
> > come
> > > > up with (in their own
> > > > mind) a great way of doing this already. I
> > simply
> > > > feel it would be helpful
> > > > to the JSON community as a whole, if we all
> > decided
> > > > on ONE way and everyone
> > > > stick to that.
> > > >
> > > > Who gets to decide on what the standard is? I
> > don't
> > > > know. I'm just trying
> > > > to start some dialog and get people thinking
> > about
> > > > it.
> > > >
> > > > Again, maybe I'm way off track here. But it my
> > mind
> > > > it would be helpful to
> > > > know I can write some JavaScript that
> > dynamically
> > > > iterates through an object
> > > > and know it won't break regardless of what
> > parser
> > > > encoded the string.
> > > >
> > > > Just a thought ;)
> > > >
> > > > _____
> > > >
> > > > From: json@yahoogroups.com
> > > > [mailto:json@yahoogroups.com] On Behalf Of Atif
> > > > Aziz
> > > > Sent: Tuesday, July 11, 2006 10:08 AM
> > > > To: json@yahoogroups.com
> > > > Subject: RE: [json] JSON representation of
> > common
> > > > types
> > > >
> > > > I think you'll have a hard time getting input on
> > > > standardization of DataSets
> > > > because most folks who are not familiar with
> > .NET
> > > > Framework may have no clue
> > > > what's being talked about. The DataSet type and
> > > > concept carries a lot of
> > > > structural and behavioral baggage with it.
> > Unless
> > > > one defines the general
> > > > problem (without referring to library-specific
> > > > types) that needs to be
> > > > addressed and then keep the focus on the wire
> > > > format, it's a lost cause. The
> > > > DataSet is specific to the .NET Framework and
> > what's
> > > > mostly interesting
> > > > about it is all the richness it provides to give
> > > > nearly the sense of a
> > > > disconnected database (short of stored
> > procedures
> > > > and a query language
> > > > unless XPath cuts it for your case). Since JSON
> > is
> > > > not about behavior, one
> > > > has to focus on the structure and the wire
> > format.
> > > > The behavior can be
> > > > defined only through an abstract specification
> > that
> > > > defines a processing
> > > > model for each end of the wire that wants to
> > > > interoperate on that data. And,
> > > > mind you, the more you put in there, the more
> > > > behavior each party has to
> >
>
> === message truncated ===
>
> --
> JSON: Action in AJAX!
>
> JSON - http://www.json.org
> JSON.simple - http://www.json.org/java/simple.txt
>
> __________________________________________________
>
> 赶快注册雅虎超大容量免费邮箱?
> http://cn.mail.yahoo.com
>
>
>



--
Best regards | Schöne Grüße
Michael

Microsoft MVP - Most Valuable Professional
Microsoft MCAD - Certified Application Developer

http://weblogs.asp.net/mschwarz/
http://www.schwarz-interactive.de/
mailto:info@...

Because string,number,boolean and null is build-in in
JSON,maybe types represented in string like 'date' be
more helpful.


--- Michael Schwarz <michael.schwarz@...>:

> Here is an example I'm currently using:
>
> {
>   "dataSet" : {
>     "tables" : [
>       {
>       "name": "My Table 1",
>       "columns" :
>
[["Column1","string"],["ImgDate","string"],["Column2","int"]],
>       "rows" : [
>           ["16.7.2006,Pazar", "16.7.2006,Pazar",
> 51],
>           ["9.7.2006,Pazar", "9.7..2006,Pazar", 54],
>           ...
>         ]    // end of rows
>        }
>      ]    // end of tables
>   }
> }
>
>
>
>
>
>
>
>
> On 7/17/06, Michael Schwarz
> <michael.schwarz@...> wrote:
> > Because I'm currently using .NET data types in my
> JSON parser, do you
> > think it would be a good idea to use common data
> type identifiers like
> > used in XML schema?
> >
> >
>
http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#built-in-datatypes
> >
> > Regards,
> > Michael
> >
> >
> >
> > On 7/17/06, Fang Yidong <fangyidong@...>
> wrote:
> > >
> > >
> > > If used in general purpose,maybe it's good to
> add the
> > > table name and the field datatypes in the
> metadata
> > > section.
> > >
> > > --- Mert Sakarya <msakarya@...>:
> > >
> > >
> > > > Hi, I am using readonly datasets in the
> following
> > > > format;
> > > >
> > > > {
> > > > "DataSet" : {
> > > > "Tables" : [
> > > > {
> > > > "Fields" : ["Column1","ImgDate","Column2"],
> > > > "Records" : [
> > > > ["16.7.2006,Pazar","16.7.2006,Pazar",51],
> > > > ["9.7.2006,Pazar","9.7..2006,Pazar",54],
> > > > ...
> > > > ]
> > > > }
> > > > ]
> > > > },
> > > > "Parameters" : { //Any other you want to
> return,
> > > > total number of records...
> > > > "RETURN_VALUE" : "0"
> > > > }
> > > > }
> > > >
> > > >
> > > >
> > > >
> > > > Mert Sakarya
> > >
> > > > IT Direkt鰎�
> > >
> > > >
> > > >
> > > >
> > > > Tel
> > > > : (212) 251 85 70 / 112
> > > > Fax
> > > > : (212) 251 89 50
> > > > www.yenibiris.com
> > > >
> > > > ________________________________________
> > > > From: json@yahoogroups.com
> > > > [mailto:json@yahoogroups.com] On Behalf Of
> Todd
> > > > Sent: Thursday, July 13, 2006 12:02 AM
> > > > To: json@yahoogroups.com
> > > > Subject: RE: [json] JSON representation of
> common
> > > > types
> > > >
> > > > Thanks for the great feedback Atif.
> > > >
> > > > But I'm really not looking to introduce
> behavior
> > > > into JSON at all. I don't
> > > > think we even need to get that in depth in
> order to
> > > > outline a basic way of
> > > > returning the data inside the DataSet.
> > > >
> > > > A DataSet may be an object specific to .NET
> but each
> > > > language has some form
> > > > of object that represents data returned from a
> > > > database. They may be known
> > > > by a different names, get referenced with
> different
> > > > syntax, and have
> > > > slightly different behaviors associated with
> them.
> > > > However, at the most
> > > > fundamental level they are approximately the
> same
> > > > thing, that being, a
> > > > "flat" 2 dimensional data object (containing
> columns
> > > > and rows).
> > > >
> > > > My thought is not to duplicate all the
> "behavioral
> > > > baggage". It is simply to
> > > > take that data (columns and rows) and decide
> on a
> > > > uniform way of
> > > > representing it within JSON.
> > > >
> > > > In reality there are only two ways to look at
> > > > DataSets, QueryBeans,
> > > > Whatever.....
> > > >
> > > > 1. An Array of Objects (where each object has
> an
> > > > identical set of keys)
> > > > 2. An Object of Arrays (where each array can
> be
> > > > assumed to be of the
> > > > exact same length)
> > > >
> > > > These objects can also be returned at the root
> level
> > > > or nested down inside a
> > > > "wrapper" object that contains "supporting"
> key
> > > > values such as column Lists,
> > > > record counts, etc...
> > > >
> > > > Everyone who has ever written a JSON parser
> has come
> > > > up with (in their own
> > > > mind) a great way of doing this already. I
> simply
> > > > feel it would be helpful
> > > > to the JSON community as a whole, if we all
> decided
> > > > on ONE way and everyone
> > > > stick to that.
> > > >
> > > > Who gets to decide on what the standard is? I
> don't
> > > > know. I'm just trying
> > > > to start some dialog and get people thinking
> about
> > > > it.
> > > >
> > > > Again, maybe I'm way off track here. But it my
> mind
> > > > it would be helpful to
> > > > know I can write some JavaScript that
> dynamically
> > > > iterates through an object
> > > > and know it won't break regardless of what
> parser
> > > > encoded the string.
> > > >
> > > > Just a thought ;)
> > > >
> > > > _____
> > > >
> > > > From: json@yahoogroups.com
> > > > [mailto:json@yahoogroups.com] On Behalf Of
> Atif
> > > > Aziz
> > > > Sent: Tuesday, July 11, 2006 10:08 AM
> > > > To: json@yahoogroups.com
> > > > Subject: RE: [json] JSON representation of
> common
>
=== message truncated ===



--
JSON: Action in AJAX!

JSON - http://www.json.org
JSON.simple - http://www.json.org/java/simple.txt




___________________________________________________________
��ע�Ż��������-3.5G������20M������
http://cn.mail.yahoo.com

I don't know. JSON sparkles in its simplicity.It's a
challenge bring in an elegant and simple common type
system,I think.Maybe Douglas can give some comments?

--- Michael Schwarz <michael.schwarz@...>:

> I've done some test on that, and almost all simple
> web services that
> offer JSON as output could be compiled using the XSD
> compiler inside
> .NET SDK, what was missing is always the response
> class. In my Yahoo!
> example (http://weblogs.asp.net/mschwarz/) I was
> missing the ResultSet
> class, which I wrote at my own. All other classes
> could be created
> using the XML schema. The only thing is that Yahoo!
> i.e. doesn't use
> the same data type for JSON as defined in the XML
> schema.
>
> Do you we need a new schema or can we use XML schema
> (the light way).
> I would be very interessted in having a schema for
> JSON, too.
>
> Regards,
> Michael
>
>
>
>
> On 7/17/06, Fang Yidong <fangyidong@...>
> wrote:
> >
> >
> >
> >
> >
> >
> >
> >
> > Common datatypes seem to be a good idea. Maybe we
> can
> > do 'JSON schema'? :-)
> >
> > But as to XML schema, I think it's too
> complicated.
> >
> > --- Michael Schwarz <michael.schwarz@...>:
> >
> >
> > > Because I'm currently using .NET data types in
> my
> > > JSON parser, do you
> > > think it would be a good idea to use common data
> > > type identifiers like
> > > used in XML schema?
> > >
> > >
> >
>
http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#built-in-datatypes
> > >
> > > Regards,
> > > Michael
> > >
> > >
> > >
> > > On 7/17/06, Fang Yidong
> <fangyidong@...>
> > > wrote:
> > > >
> > > >
> > > > If used in general purpose,maybe it's good to
> add
> > > the
> > > > table name and the field datatypes in the
> metadata
> > > > section.
> > > >
> > > > --- Mert Sakarya <msakarya@...>:
> > > >
> > > >
> > > > > Hi, I am using readonly datasets in the
> > > following
> > > > > format;
> > > > >
> > > > > {
> > > > > "DataSet" : {
> > > > > "Tables" : [
> > > > > {
> > > > > "Fields" : ["Column1","ImgDate","Column2"],
> > > > > "Records" : [
> > > > > ["16.7.2006,Pazar","16.7.2006,Pazar",51],
> > > > > ["9.7.2006,Pazar","9.7..2006,Pazar",54],
> > > > > ...
> > > > > ]
> > > > > }
> > > > > ]
> > > > > },
> > > > > "Parameters" : { //Any other you want to
> return,
> > > > > total number of records...
> > > > > "RETURN_VALUE" : "0"
> > > > > }
> > > > > }
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Mert Sakarya
> > > >
> >
> > > > > IT Direkt榘庯拁
> >
> > > >
> > > > >
> > > > >
> > > > >
> > > > > Tel
> > > > > : (212) 251 85 70 / 112
> > > > > Fax
> > > > > : (212) 251 89 50
> > > > > www.yenibiris.com
> > > > >
> > > > > ________________________________________
> > > > > From: json@yahoogroups.com
> > > > > [mailto:json@yahoogroups.com] On Behalf Of
> Todd
> > > > > Sent: Thursday, July 13, 2006 12:02 AM
> > > > > To: json@yahoogroups.com
> > > > > Subject: RE: [json] JSON representation of
> > > common
> > > > > types
> > > > >
> > > > > Thanks for the great feedback Atif.
> > > > >
> > > > > But I'm really not looking to introduce
> behavior
> > > > > into JSON at all. I don't
> > > > > think we even need to get that in depth in
> order
> > > to
> > > > > outline a basic way of
> > > > > returning the data inside the DataSet.
> > > > >
> > > > > A DataSet may be an object specific to .NET
> but
> > > each
> > > > > language has some form
> > > > > of object that represents data returned from
> a
> > > > > database. They may be known
> > > > > by a different names, get referenced with
> > > different
> > > > > syntax, and have
> > > > > slightly different behaviors associated with
> > > them.
> > > > > However, at the most
> > > > > fundamental level they are approximately the
> > > same
> > > > > thing, that being, a
> > > > > "flat" 2 dimensional data object (containing
> > > columns
> > > > > and rows).
> > > > >
> > > > > My thought is not to duplicate all the
> > > "behavioral
> > > > > baggage". It is simply to
> > > > > take that data (columns and rows) and decide
> on
> > > a
> > > > > uniform way of
> > > > > representing it within JSON.
> > > > >
> > > > > In reality there are only two ways to look
> at
> > > > > DataSets, QueryBeans,
> > > > > Whatever.....
> > > > >
> > > > > 1. An Array of Objects (where each object
> has an
> > > > > identical set of keys)
> > > > > 2. An Object of Arrays (where each array can
> be
> > > > > assumed to be of the
> > > > > exact same length)
> > > > >
> > > > > These objects can also be returned at the
> root
> > > level
> > > > > or nested down inside a
> > > > > "wrapper" object that contains "supporting"
> key
> > > > > values such as column Lists,
> > > > > record counts, etc...
> > > > >
> > > > > Everyone who has ever written a JSON parser
> has
> > > come
> > > > > up with (in their own
> > > > > mind) a great way of doing this already. I
> > > simply
> > > > > feel it would be helpful
> > > > > to the JSON community as a whole, if we all
> > > decided
> > > > > on ONE way and everyone
>
=== message truncated ===



--
JSON: Action in AJAX!

JSON - http://www.json.org
JSON.simple - http://www.json.org/java/simple.txt




___________________________________________________________
�Ż��������-3.5G������20M����
http://cn.mail.yahoo.com/

For date, time,... I use this currently:

http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#isoformats



On 7/17/06, Fang Yidong <fangyidong@...> wrote:
>
>
>
>
>
>
>
> Because string,number,boolean and null is build-in in
> JSON,maybe types represented in string like 'date' be
> more helpful.
>
> --- Michael Schwarz <michael.schwarz@...>:
>
>
> > Here is an example I'm currently using:
> >
> > {
> > "dataSet" : {
> > "tables" : [
> > {
> > "name": "My Table 1",
> > "columns" :
> >
> [["Column1","string"],["ImgDate","string"],["Column2","int"]],
> > "rows" : [
> > ["16.7.2006,Pazar", "16.7.2006,Pazar",
> > 51],
> > ["9.7.2006,Pazar", "9.7..2006,Pazar", 54],
> > ...
> > ] // end of rows
> > }
> > ] // end of tables
> > }
> > }
> >
> >
> >
> >
> >
> >
> >
> >
> > On 7/17/06, Michael Schwarz
> > <michael.schwarz@...> wrote:
> > > Because I'm currently using .NET data types in my
> > JSON parser, do you
> > > think it would be a good idea to use common data
> > type identifiers like
> > > used in XML schema?
> > >
> > >
> >
> http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#built-in-datatypes
> > >
> > > Regards,
> > > Michael
> > >
> > >
> > >
> > > On 7/17/06, Fang Yidong <fangyidong@...>
> > wrote:
> > > >
> > > >
> > > > If used in general purpose,maybe it's good to
> > add the
> > > > table name and the field datatypes in the
> > metadata
> > > > section.
> > > >
> > > > --- Mert Sakarya <msakarya@...>:
> > > >
> > > >
> > > > > Hi, I am using readonly datasets in the
> > following
> > > > > format;
> > > > >
> > > > > {
> > > > > "DataSet" : {
> > > > > "Tables" : [
> > > > > {
> > > > > "Fields" : ["Column1","ImgDate","Column2"],
> > > > > "Records" : [
> > > > > ["16.7.2006,Pazar","16.7.2006,Pazar",51],
> > > > > ["9.7.2006,Pazar","9.7..2006,Pazar",54],
> > > > > ...
> > > > > ]
> > > > > }
> > > > > ]
> > > > > },
> > > > > "Parameters" : { //Any other you want to
> > return,
> > > > > total number of records...
> > > > > "RETURN_VALUE" : "0"
> > > > > }
> > > > > }
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Mert Sakarya
> > > >
>
> > > > > IT Direkt榘庯拷
>
> > > >
> > > > >
> > > > >
> > > > >
> > > > > Tel
> > > > > : (212) 251 85 70 / 112
> > > > > Fax
> > > > > : (212) 251 89 50
> > > > > www.yenibiris.com
> > > > >
> > > > > ________________________________________
> > > > > From: json@yahoogroups.com
> > > > > [mailto:json@yahoogroups.com] On Behalf Of
> > Todd
> > > > > Sent: Thursday, July 13, 2006 12:02 AM
> > > > > To: json@yahoogroups.com
> > > > > Subject: RE: [json] JSON representation of
> > common
> > > > > types
> > > > >
> > > > > Thanks for the great feedback Atif.
> > > > >
> > > > > But I'm really not looking to introduce
> > behavior
> > > > > into JSON at all. I don't
> > > > > think we even need to get that in depth in
> > order to
> > > > > outline a basic way of
> > > > > returning the data inside the DataSet.
> > > > >
> > > > > A DataSet may be an object specific to .NET
> > but each
> > > > > language has some form
> > > > > of object that represents data returned from a
> > > > > database. They may be known
> > > > > by a different names, get referenced with
> > different
> > > > > syntax, and have
> > > > > slightly different behaviors associated with
> > them.
> > > > > However, at the most
> > > > > fundamental level they are approximately the
> > same
> > > > > thing, that being, a
> > > > > "flat" 2 dimensional data object (containing
> > columns
> > > > > and rows).
> > > > >
> > > > > My thought is not to duplicate all the
> > "behavioral
> > > > > baggage". It is simply to
> > > > > take that data (columns and rows) and decide
> > on a
> > > > > uniform way of
> > > > > representing it within JSON.
> > > > >
> > > > > In reality there are only two ways to look at
> > > > > DataSets, QueryBeans,
> > > > > Whatever.....
> > > > >
> > > > > 1. An Array of Objects (where each object has
> > an
> > > > > identical set of keys)
> > > > > 2. An Object of Arrays (where each array can
> > be
> > > > > assumed to be of the
> > > > > exact same length)
> > > > >
> > > > > These objects can also be returned at the root
> > level
> > > > > or nested down inside a
> > > > > "wrapper" object that contains "supporting"
> > key
> > > > > values such as column Lists,
> > > > > record counts, etc...
> > > > >
> > > > > Everyone who has ever written a JSON parser
> > has come
> > > > > up with (in their own
> > > > > mind) a great way of doing this already. I
> > simply
> > > > > feel it would be helpful
> > > > > to the JSON community as a whole, if we all
> > decided
> > > > > on ONE way and everyone
> > > > > stick to that.
> > > > >
> > > > > Who gets to decide on what the standard is? I
> > don't
> > > > > know. I'm just trying
> > > > > to start some dialog and get people thinking
> > about
> > > > > it.
> > > > >
> > > > > Again, maybe I'm way off track here. But it my
> > mind
> > > > > it would be helpful to
> > > > > know I can write some JavaScript that
> > dynamically
> > > > > iterates through an object
> > > > > and know it won't break regardless of what
> > parser
> > > > > encoded the string.
> > > > >
> > > > > Just a thought ;)
> > > > >
> > > > > _____
> > > > >
> > > > > From: json@yahoogroups.com
> > > > > [mailto:json@yahoogroups.com] On Behalf Of
> > Atif
> > > > > Aziz
> > > > > Sent: Tuesday, July 11, 2006 10:08 AM
> > > > > To: json@yahoogroups.com
> > > > > Subject: RE: [json] JSON representation of
> > common
> >
>
> === message truncated ===
>
> --
> JSON: Action in AJAX!
>
> JSON - http://www.json.org
> JSON.simple - http://www.json.org/java/simple.txt
>
>
> __________________________________________________________
>
> 抢注雅虎免费邮箱-3.5G容量，20M附件！
>
> http://cn.mail.yahoo.com
>
>
>
>



--
Best regards | Schöne Grüße
Michael

Microsoft MVP - Most Valuable Professional
Microsoft MCAD - Certified Application Developer

http://weblogs.asp.net/mschwarz/
http://www.schwarz-interactive.de/
mailto:info@...

In Section 3 (Encoding) of the JSON Internet Draft, the second
paragraphs starts by saying, "Since the first two characters of a JSON
text will always be ASCII characters [RFC-0020], ...." Does this really
mean that every JSON text encoder must emit a space at the start of JSON
text? The grammar doesn't reflect this rule, so is this just mere
guidance or is there some discrepancy here? I don't think it's the
former due to use of the word "always." I'd appreciate if someone could
help clarify this bit. Thanks.



[Non-text portions of this message have been removed]

On Jul 17, 2006, at 2:50 PM, Atif Aziz wrote:
> In Section 3 (Encoding) of the JSON Internet Draft, the second
> paragraphs starts by saying, "Since the first two characters of a JSON
> text will always be ASCII characters [RFC-0020], ...." Does this
> really
> mean that every JSON text encoder must emit a space at the start of
> JSON
> text? The grammar doesn't reflect this rule, so is this just mere
> guidance or is there some discrepancy here? I don't think it's the
> former due to use of the word "always." I'd appreciate if someone
> could
> help clarify this bit. Thanks.
I'm guessing this is because of the object-or-array rules discussed
here last week. In other words, a JSON text must start with '[' or
'{', which are both ASCII, followed by 'n(ull)', 'f(alse)', 't
(true)', a digit, or quotes to open a string. All of these are also
ASCII.

-mike.

----------------------------------------------------------------
michal migurski- contact info and pgp key:
sf/ca            http://mike.teczno.com/contact.html

I've been doing some thinking along these lines for my work on the
JSON-RPC 1.1 specification. In JSON-RPC 1.1, I added introspection
support for services, meaning that there would be a standard way to
describe a service, its procedures and the paramterers of those
procedures. Needless to say, the last bit needs some type-hinting
support, especially for the strongly-typed languages so that they have a
chance of generating reasonable proxy code. I am not completely done
with all the ideas, but I can shed some light on what I've come up with
so far.

JSON supports 6 data types. As everyone probably can guess, these are
Object, Array, String, Number, Boolean and Null. In JSON-RPC 1.1, these
take the form "object", "array", "string", "number", "bool" and "null"
in text. Dead simple so far, but now let's get to the fun part. From
this, how do you express types representing an array of integers versus
an array of floats? How do you express a type for dates expressed in ISO
8601 format versus those in Unix time? The first rule I came up with is
not to violate or hide the 6 JSON types. These should always be stated
as the root relation of some new type so that parties that don't
understand the extension can still work with the basic ones they know
about. In other words, you express a new data type as specialization of
one of the 6 fundamental types. The type specification expression looks
roughly like this:

type-spec := json-type "/" sub-type
json-type := "null" | "bool" | "number" |
               "string" | "object" | "array"

If you think about it, it looks a lot like MIME-type specification, as
in "text/plain". This is no coincidence. I wanted a familiar syntax so
that people can pick it up quickly and recall it easily. Short of
writing the spec here, the best way to demonstrate how it works is by
showing you a few examples, so here are some concrete ones I have been
working on:

     * string/w3time = String containing time using ISO 8601 format.
     * string/time = String containing time using unix time format.
     * string/guid = String containing a GUID.
     * number/time = Number containing time using unix time format.
     * number/int32 = Number that is a 32-bit integer.
     * number/int64 = Number that is a 64-bit integer
     * number/float = Number with single precision.
     * number/double = Number with double precision.
     * number/decimal = Number for financial application.
     * array/string = Array of String values.
     * array/object = Array of Object values.

You can also now combine to form further hierarchies, which is mostly
useful in the Array case, as in:

     * array/string/time = Array of String values containing time using
unix time format.
     * array/number/int32 = Array of 32-bit integers.

The important thing to realize is that a consumer can stop processing at
the first slash and take only the pure JSON type on its left if it
wishes to ignore the rest. What's more, it can do this without fear of
loosing information that will be held in the containing super type. For
example, if a consumer treats "string/w3time" as String then the time
information has not been lost. It's just delivered to the application as
a String as opposed to a type that is more representative of time in the
development language of the application.

In the case of Object, it would be possible to say, "object/person",
provided that you describe person somewhere as:

{ "name" : "string",
    "sirname" : "string",
    "birthday" : "string/time"
    "children" : "array/object/person" }

In the last case, you see that "children" is defined as array of
"person" Object values.

Finally, as common sense would tell us, so goes the rule...types such as
Null and Boolean cannot be specialized. A consumer would simple ignore
any specialization.

Anyway, there you have it. Hope I've been able to give an idea of how I
am planning to solve the problem for JSON-RPC 1.1, but it certainly has
a wider application and you're free to see if it fits your needs (as in
describing the column types of a table of records). Meanwhile, I've
tried to keep it simple and effective while allowing for fallback cases.
Thoughts?


--- In json@yahoogroups.com, Fang Yidong <fangyidong@...> wrote:
>
> I don't know. JSON sparkles in its simplicity.It's a
> challenge bring in an elegant and simple common type
> system,I think.Maybe Douglas can give some comments?
>
> --- Michael Schwarz michael.schwarz@...:
>
> > I've done some test on that, and almost all simple
> > web services that
> > offer JSON as output could be compiled using the XSD
> > compiler inside
> > .NET SDK, what was missing is always the response
> > class. In my Yahoo!
> > example (http://weblogs.asp.net/mschwarz/) I was
> > missing the ResultSet
> > class, which I wrote at my own. All other classes
> > could be created
> > using the XML schema. The only thing is that Yahoo!
> > i.e. doesn't use
> > the same data type for JSON as defined in the XML
> > schema.
> >
> > Do you we need a new schema or can we use XML schema
> > (the light way).
> > I would be very interessted in having a schema for
> > JSON, too.
> >
> > Regards,
> > Michael
> >
> >
> >
> >
> > On 7/17/06, Fang Yidong fangyidong@...
> > wrote:
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Common datatypes seem to be a good idea. Maybe we
> > can
> > > do 'JSON schema'? :-)
> > >
> > > But as to XML schema, I think it's too
> > complicated.
> > >
> > > --- Michael Schwarz michael.schwarz@...:
> > >
> > >
> > > > Because I'm currently using .NET data types in
> > my
> > > > JSON parser, do you
> > > > think it would be a good idea to use common data
> > > > type identifiers like
> > > > used in XML schema?
> > > >
> > > >
> > >
> >
> http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#built-in-datatypes
> > > >
> > > > Regards,
> > > > Michael
> > > >
> > > >
> > > >
> > > > On 7/17/06, Fang Yidong
> > fangyidong@...
> > > > wrote:
> > > > >
> > > > >
> > > > > If used in general purpose,maybe it's good to
> > add
> > > > the
> > > > > table name and the field datatypes in the
> > metadata
> > > > > section.
> > > > >
> > > > > --- Mert Sakarya msakarya@...:
> > > > >
> > > > >
> > > > > > Hi, I am using readonly datasets in the
> > > > following
> > > > > > format;
> > > > > >
> > > > > > {
> > > > > > "DataSet" : {
> > > > > > "Tables" : [
> > > > > > {
> > > > > > "Fields" : ["Column1","ImgDate","Column2"],
> > > > > > "Records" : [
> > > > > > ["16.7.2006,Pazar","16.7.2006,Pazar",51],
> > > > > > ["9.7.2006,Pazar","9.7..2006,Pazar",54],
> > > > > > ...
> > > > > > ]
> > > > > > }
> > > > > > ]
> > > > > > },
> > > > > > "Parameters" : { //Any other you want to
> > return,
> > > > > > total number of records...
> > > > > > "RETURN_VALUE" : "0"
> > > > > > }
> > > > > > }
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Mert Sakarya
> > > > >
> > >
> > > > > > IT Direkt榘庯拁
> > >
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Tel
> > > > > > : (212) 251 85 70 / 112
> > > > > > Fax
> > > > > > : (212) 251 89 50
> > > > > > www.yenibiris.com
> > > > > >
> > > > > > ________________________________________
> > > > > > From: json@yahoogroups.com
> > > > > > [mailto:json@yahoogroups.com] On Behalf Of
> > Todd
> > > > > > Sent: Thursday, July 13, 2006 12:02 AM
> > > > > > To: json@yahoogroups.com
> > > > > > Subject: RE: [json] JSON representation of
> > > > common
> > > > > > types
> > > > > >
> > > > > > Thanks for the great feedback Atif.
> > > > > >
> > > > > > But I'm really not looking to introduce
> > behavior
> > > > > > into JSON at all. I don't
> > > > > > think we even need to get that in depth in
> > order
> > > > to
> > > > > > outline a basic way of
> > > > > > returning the data inside the DataSet.
> > > > > >
> > > > > > A DataSet may be an object specific to .NET
> > but
> > > > each
> > > > > > language has some form
> > > > > > of object that represents data returned from
> > a
> > > > > > database. They may be known
> > > > > > by a different names, get referenced with
> > > > different
> > > > > > syntax, and have
> > > > > > slightly different behaviors associated with
> > > > them.
> > > > > > However, at the most
> > > > > > fundamental level they are approximately the
> > > > same
> > > > > > thing, that being, a
> > > > > > "flat" 2 dimensional data object (containing
> > > > columns
> > > > > > and rows).
> > > > > >
> > > > > > My thought is not to duplicate all the
> > > > "behavioral
> > > > > > baggage". It is simply to
> > > > > > take that data (columns and rows) and decide
> > on
> > > > a
> > > > > > uniform way of
> > > > > > representing it within JSON.
> > > > > >
> > > > > > In reality there are only two ways to look
> > at
> > > > > > DataSets, QueryBeans,
> > > > > > Whatever.....
> > > > > >
> > > > > > 1. An Array of Objects (where each object
> > has an
> > > > > > identical set of keys)
> > > > > > 2. An Object of Arrays (where each array can
> > be
> > > > > > assumed to be of the
> > > > > > exact same length)
> > > > > >
> > > > > > These objects can also be returned at the
> > root
> > > > level
> > > > > > or nested down inside a
> > > > > > "wrapper" object that contains "supporting"
> > key
> > > > > > values such as column Lists,
> > > > > > record counts, etc...
> > > > > >
> > > > > > Everyone who has ever written a JSON parser
> > has
> > > > come
> > > > > > up with (in their own
> > > > > > mind) a great way of doing this already. I
> > > > simply
> > > > > > feel it would be helpful
> > > > > > to the JSON community as a whole, if we all
> > > > decided
> > > > > > on ONE way and everyone
> >
> === message truncated ===
>
>
>
> --
> JSON: Action in AJAX!
>
> JSON - http://www.json.org
> JSON.simple - http://www.json.org/java/simple.txt
>
>
>
>
> ___________________________________________________________
> �Ż��������-3.5G������20M����
> http://cn.mail.yahoo.com/
>




[Non-text portions of this message have been removed]

Michal, thanks for the explanation. It all makes sense now, especially
after re-reading it with a fresher mind this morning.

(whisper) Truth be told, I was completely misreading the 0020 bit and
interpreting it as ASCII space rather than an RFC document number even
though it was right there in my face (dope slap). It's odd, though, to
see a low RFC document number expressed with leading zeros, which is
what threw me off since I'd been reading a lot of the U+XXXX notation
lately.


--- In json@yahoogroups.com, Michal Migurski <mike-jsonphp@...> wrote:
>
> On Jul 17, 2006, at 2:50 PM, Atif Aziz wrote:
> > In Section 3 (Encoding) of the JSON Internet Draft, the second
> > paragraphs starts by saying, "Since the first two characters of a
JSON
> > text will always be ASCII characters [RFC-0020], ...." Does this
> > really
> > mean that every JSON text encoder must emit a space at the start of
> > JSON
> > text? The grammar doesn't reflect this rule, so is this just mere
> > guidance or is there some discrepancy here? I don't think it's the
> > former due to use of the word "always." I'd appreciate if someone
> > could
> > help clarify this bit. Thanks.
> I'm guessing this is because of the object-or-array rules discussed
> here last week. In other words, a JSON text must start with '[' or
> '{', which are both ASCII, followed by 'n(ull)', 'f(alse)', 't
> (true)', a digit, or quotes to open a string. All of these are also
> ASCII.
>
> -mike.
>
> ----------------------------------------------------------------
> michal migurski- contact info and pgp key:
> sf/ca http://mike.teczno.com/contact.html
>

Are you talking about a JSON schema or a message? Where do you want to
put the type? I think there are two scenarios where type meta
information is neccesary:

1) if we have to describe a JSON "message" comparing to XSD to create
classes on other side. I had a look at the Yahoo! search that are
currently similar to their XSDs.

2) If we return objects which will inherit from others. Where do you
want to add the additional information? Again, I think, we are talking
about something like the __type property.


Michael



On 7/18/06, Atif Aziz <atif.aziz@...> wrote:
>
>
> I've been doing some thinking along these lines for my work on the
> JSON-RPC 1.1 specification. In JSON-RPC 1.1, I added introspection
> support for services, meaning that there would be a standard way to
> describe a service, its procedures and the paramterers of those
> procedures. Needless to say, the last bit needs some type-hinting
> support, especially for the strongly-typed languages so that they have a
> chance of generating reasonable proxy code. I am not completely done
> with all the ideas, but I can shed some light on what I've come up with
> so far.
>
> JSON supports 6 data types. As everyone probably can guess, these are
> Object, Array, String, Number, Boolean and Null. In JSON-RPC 1.1, these
> take the form "object", "array", "string", "number", "bool" and "null"
> in text. Dead simple so far, but now let's get to the fun part. From
> this, how do you express types representing an array of integers versus
> an array of floats? How do you express a type for dates expressed in ISO
> 8601 format versus those in Unix time? The first rule I came up with is
> not to violate or hide the 6 JSON types. These should always be stated
> as the root relation of some new type so that parties that don't
> understand the extension can still work with the basic ones they know
> about. In other words, you express a new data type as specialization of
> one of the 6 fundamental types. The type specification expression looks
> roughly like this:
>
> type-spec := json-type "/" sub-type
> json-type := "null" | "bool" | "number" |
> "string" | "object" | "array"
>
> If you think about it, it looks a lot like MIME-type specification, as
> in "text/plain". This is no coincidence. I wanted a familiar syntax so
> that people can pick it up quickly and recall it easily. Short of
> writing the spec here, the best way to demonstrate how it works is by
> showing you a few examples, so here are some concrete ones I have been
> working on:
>
> * string/w3time = String containing time using ISO 8601 format.
> * string/time = String containing time using unix time format.
> * string/guid = String containing a GUID.
> * number/time = Number containing time using unix time format.
> * number/int32 = Number that is a 32-bit integer.
> * number/int64 = Number that is a 64-bit integer
> * number/float = Number with single precision.
> * number/double = Number with double precision.
> * number/decimal = Number for financial application.
> * array/string = Array of String values.
> * array/object = Array of Object values.
>
> You can also now combine to form further hierarchies, which is mostly
> useful in the Array case, as in:
>
> * array/string/time = Array of String values containing time using
> unix time format.
> * array/number/int32 = Array of 32-bit integers.
>
> The important thing to realize is that a consumer can stop processing at
> the first slash and take only the pure JSON type on its left if it
> wishes to ignore the rest. What's more, it can do this without fear of
> loosing information that will be held in the containing super type. For
> example, if a consumer treats "string/w3time" as String then the time
> information has not been lost. It's just delivered to the application as
> a String as opposed to a type that is more representative of time in the
> development language of the application.
>
> In the case of Object, it would be possible to say, "object/person",
> provided that you describe person somewhere as:
>
> { "name" : "string",
> "sirname" : "string",
> "birthday" : "string/time"
> "children" : "array/object/person" }
>
> In the last case, you see that "children" is defined as array of
> "person" Object values.
>
> Finally, as common sense would tell us, so goes the rule...types such as
> Null and Boolean cannot be specialized. A consumer would simple ignore
> any specialization.
>
> Anyway, there you have it. Hope I've been able to give an idea of how I
> am planning to solve the problem for JSON-RPC 1.1, but it certainly has
> a wider application and you're free to see if it fits your needs (as in
> describing the column types of a table of records). Meanwhile, I've
> tried to keep it simple and effective while allowing for fallback cases.
> Thoughts?
>
>
> --- In json@yahoogroups.com, Fang Yidong <fangyidong@...> wrote:
> >
> > I don't know. JSON sparkles in its simplicity.It's a
> > challenge bring in an elegant and simple common type
> > system,I think.Maybe Douglas can give some comments?
> >
>
> > --- Michael Schwarz michael.schwarz@...:
>
> >
> > > I've done some test on that, and almost all simple
> > > web services that
> > > offer JSON as output could be compiled using the XSD
> > > compiler inside
> > > .NET SDK, what was missing is always the response
> > > class. In my Yahoo!
> > > example (http://weblogs.asp.net/mschwarz/) I was
> > > missing the ResultSet
> > > class, which I wrote at my own. All other classes
> > > could be created
> > > using the XML schema. The only thing is that Yahoo!
> > > i.e. doesn't use
> > > the same data type for JSON as defined in the XML
> > > schema.
> > >
> > > Do you we need a new schema or can we use XML schema
> > > (the light way).
> > > I would be very interessted in having a schema for
> > > JSON, too.
> > >
> > > Regards,
> > > Michael
> > >
> > >
> > >
> > >
>
> > > On 7/17/06, Fang Yidong fangyidong@...
>
> > > wrote:
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Common datatypes seem to be a good idea. Maybe we
> > > can
> > > > do 'JSON schema'? :-)
> > > >
> > > > But as to XML schema, I think it's too
> > > complicated.
> > > >
>
> > > > --- Michael Schwarz michael.schwarz@...:
>
> > > >
> > > >
> > > > > Because I'm currently using .NET data types in
> > > my
> > > > > JSON parser, do you
> > > > > think it would be a good idea to use common data
> > > > > type identifiers like
> > > > > used in XML schema?
> > > > >
> > > > >
> > > >
> > >
> > http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#built-in-datatypes
> > > > >
> > > > > Regards,
> > > > > Michael
> > > > >
> > > > >
> > > > >
> > > > > On 7/17/06, Fang Yidong
>
> > > fangyidong@...
>
> > > > > wrote:
> > > > > >
> > > > > >
> > > > > > If used in general purpose,maybe it's good to
> > > add
> > > > > the
> > > > > > table name and the field datatypes in the
> > > metadata
> > > > > > section.
> > > > > >
>
> > > > > > --- Mert Sakarya msakarya@...:
>
> > > > > >
> > > > > >
> > > > > > > Hi, I am using readonly datasets in the
> > > > > following
> > > > > > > format;
> > > > > > >
> > > > > > > {
> > > > > > > "DataSet" : {
> > > > > > > "Tables" : [
> > > > > > > {
> > > > > > > "Fields" : ["Column1","ImgDate","Column2"],
> > > > > > > "Records" : [
> > > > > > > ["16.7.2006,Pazar","16.7.2006,Pazar",51],
> > > > > > > ["9.7.2006,Pazar","9.7..2006,Pazar",54],
> > > > > > > ...
> > > > > > > ]
> > > > > > > }
> > > > > > > ]
> > > > > > > },
> > > > > > > "Parameters" : { //Any other you want to
> > > return,
> > > > > > > total number of records...
> > > > > > > "RETURN_VALUE" : "0"
> > > > > > > }
> > > > > > > }
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Mert Sakarya
> > > > > >
> > > >
>
> > > > > > > IT Direkt榘庯拁
>
> > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Tel
> > > > > > > : (212) 251 85 70 / 112
> > > > > > > Fax
> > > > > > > : (212) 251 89 50
> > > > > > > www.yenibiris.com
> > > > > > >
> > > > > > > ________________________________________
> > > > > > > From: json@yahoogroups.com
> > > > > > > [mailto:json@yahoogroups.com] On Behalf Of
> > > Todd
> > > > > > > Sent: Thursday, July 13, 2006 12:02 AM
> > > > > > > To: json@yahoogroups.com
> > > > > > > Subject: RE: [json] JSON representation of
> > > > > common
> > > > > > > types
> > > > > > >
> > > > > > > Thanks for the great feedback Atif.
> > > > > > >
> > > > > > > But I'm really not looking to introduce
> > > behavior
> > > > > > > into JSON at all. I don't
> > > > > > > think we even need to get that in depth in
> > > order
> > > > > to
> > > > > > > outline a basic way of
> > > > > > > returning the data inside the DataSet.
> > > > > > >
> > > > > > > A DataSet may be an object specific to .NET
> > > but
> > > > > each
> > > > > > > language has some form
> > > > > > > of object that represents data returned from
> > > a
> > > > > > > database. They may be known
> > > > > > > by a different names, get referenced with
> > > > > different
> > > > > > > syntax, and have
> > > > > > > slightly different behaviors associated with
> > > > > them.
> > > > > > > However, at the most
> > > > > > > fundamental level they are approximately the
> > > > > same
> > > > > > > thing, that being, a
> > > > > > > "flat" 2 dimensional data object (containing
> > > > > columns
> > > > > > > and rows).
> > > > > > >
> > > > > > > My thought is not to duplicate all the
> > > > > "behavioral
> > > > > > > baggage". It is simply to
> > > > > > > take that data (columns and rows) and decide
> > > on
> > > > > a
> > > > > > > uniform way of
> > > > > > > representing it within JSON.
> > > > > > >
> > > > > > > In reality there are only two ways to look
> > > at
> > > > > > > DataSets, QueryBeans,
> > > > > > > Whatever.....
> > > > > > >
> > > > > > > 1. An Array of Objects (where each object
> > > has an
> > > > > > > identical set of keys)
> > > > > > > 2. An Object of Arrays (where each array can
> > > be
> > > > > > > assumed to be of the
> > > > > > > exact same length)
> > > > > > >
> > > > > > > These objects can also be returned at the
> > > root
> > > > > level
> > > > > > > or nested down inside a
> > > > > > > "wrapper" object that contains "supporting"
> > > key
> > > > > > > values such as column Lists,
> > > > > > > record counts, etc...
> > > > > > >
> > > > > > > Everyone who has ever written a JSON parser
> > > has
> > > > > come
> > > > > > > up with (in their own
> > > > > > > mind) a great way of doing this already. I
> > > > > simply
> > > > > > > feel it would be helpful
> > > > > > > to the JSON community as a whole, if we all
> > > > > decided
> > > > > > > on ONE way and everyone
> > >
> > === message truncated ===
> >
> >
> >
> > --
> > JSON: Action in AJAX!
> >
> > JSON - http://www.json.org
> > JSON.simple - http://www.json.org/java/simple.txt
> >
> >
> >
> >
> > __________________________________________________________
>
> > �Ż��������-3.5G����20M����
>
> > http://cn.mail.yahoo.com/
> >
>
>
> [Non-text portions of this message have been removed]
>
>
>
>
>



--
Best regards | Schöne Grüße
Michael

Microsoft MVP - Most Valuable Professional
Microsoft MCAD - Certified Application Developer

http://weblogs.asp.net/mschwarz/
http://www.schwarz-interactive.de/
mailto:info@...

I think, simplicity in mind, JSON is not strong-typed, types are only "Variants"
in JSON. I think, we only have, null, true/false, number and string (and we also
have  Array and Object structures). So we can only use these types in
JSON-Schema.

There is no date, float, function and other primitive/complex types.

I think, JSON-Schema should be simple and it should contain only the basic
types/definitions.
JSON-Schema can have, Constraints (May contain regular expressions - this way
Date/Time or float types can be handled), Min-Max validations and definition of
Object and Arrays...

I admit that, I use Date and "function" or any other JavaScript types in my
code, but I don't call them JSON (Well I decided to not to, after becoming a
member of this group).
For example adding Dataset to JSON is not possible, it could only be a
"recommendation".

Hey, what about J(SON)Pointer and J(SON)Include like XPointer and XInclude? Well
that's another topic but something interesting.

I am wondering, if we should keep JSON simple or add more extensions and make it
complex?Mert


To: json@...: michael.schwarz@...: Mon, 17 Jul 2006
12:35:55 +0200Subject: Re: [json] JSON representation of common types




Because I'm currently using .NET data types in my JSON parser, do youthink it
would be a good idea to use common data type identifiers likeused in XML
schema?http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#built-in-datatypesReg\
ards,MichaelOn 7/17/06, Fang Yidong <fangyidong@...> wrote:>>> If used
in general purpose,maybe it's good to add the> table name and the field
datatypes in the metadata> section.>> --- Mert Sakarya
<msakarya@...>:>>> > Hi, I am using readonly datasets in the
following> > format;> >> > {> > "DataSet" : {> > "Tables" : [> > {> > "Fields" :
["Column1","ImgDate","Column2"],> > "Records" : [> >
["16.7.2006,Pazar","16.7.2006,Pazar",51],> >
["9.7.2006,Pazar","9.7..2006,Pazar",54],> > ...> > ]> > }> > ]> > },> >
"Parameters" : { //Any other you want to return,> > total number of records...>
> "RETURN_VALUE" : "0"> > }> > }> >> >> >> >> > Mert Sakarya>> > IT
Direkt鰎�>> >> >> >> > Tel> > : (212) 251 85 70 / 112> > Fax> > : (212) 251
89 50> > www.yenibiris.com> >> > ________________________________________> >
From: json@yahoogroups.com> > [mailto:json@yahoogroups.com] On Behalf Of Todd> >
Sent: Thursday, July 13, 2006 12:02 AM> > To: json@yahoogroups.com> > Subject:
RE: [json] JSON representation of common> > types> >> > Thanks for the great
feedback Atif.> >> > But I'm really not looking to introduce behavior> > into
JSON at all. I don't> > think we even need to get that in depth in order to> >
outline a basic way of> > returning the data inside the DataSet.> >> > A DataSet
may be an object specific to .NET but each> > language has some form> > of
object that represents data returned from a> > database. They may be known> > by
a different names, get referenced with different> > syntax, and have> > slightly
different behaviors associated with them.> > However, at the most> > fundamental
level they are approximately the same> > thing, that being, a> > "flat" 2
dimensional data object (containing columns> > and rows).> >> > My thought is
not to duplicate all the "behavioral> > baggage". It is simply to> > take that
data (columns and rows) and decide on a> > uniform way of> > representing it
within JSON.> >> > In reality there are only two ways to look at> > DataSets,
QueryBeans,> > Whatever.....> >> > 1. An Array of Objects (where each object has
an> > identical set of keys)> > 2. An Object of Arrays (where each array can be>
> assumed to be of the> > exact same length)> >> > These objects can also be
returned at the root level> > or nested down inside a> > "wrapper" object that
contains "supporting" key> > values such as column Lists,> > record counts,
etc...> >> > Everyone who has ever written a JSON parser has come> > up with (in
their own> > mind) a great way of doing this already. I simply> > feel it would
be helpful> > to the JSON community as a whole, if we all decided> > on ONE way
and everyone> > stick to that.> >> > Who gets to decide on what the standard is?
I don't> > know. I'm just trying> > to start some dialog and get people thinking
about> > it.> >> > Again, maybe I'm way off track here. But it my mind> > it
would be helpful to> > know I can write some JavaScript that dynamically> >
iterates through an object> > and know it won't break regardless of what parser>
> encoded the string.> >> > Just a thought ;)> >> > _____> >> > From:
json@yahoogroups.com> > [mailto:json@yahoogroups.com] On Behalf Of Atif> > Aziz>
> Sent: Tuesday, July 11, 2006 10:08 AM> > To: json@yahoogroups.com> > Subject:
RE: [json] JSON representation of common> > types> >> > I think you'll have a
hard time getting input on> > standardization of DataSets> > because most folks
who are not familiar with .NET> > Framework may have no clue> > what's being
talked about. The DataSet type and> > concept carries a lot of> > structural and
behavioral baggage with it. Unless> > one defines the general> > problem
(without referring to library-specific> > types) that needs to be> > addressed
and then keep the focus on the wire> > format, it's a lost cause. The> > DataSet
is specific to the .NET Framework and what's> > mostly interesting> > about it
is all the richness it provides to give> > nearly the sense of a> > disconnected
database (short of stored procedures> > and a query language> > unless XPath
cuts it for your case). Since JSON is> > not about behavior, one> > has to focus
on the structure and the wire format.> > The behavior can be> > defined only
through an abstract specification that> > defines a processing> > model for each
end of the wire that wants to> > interoperate on that data. And,> > mind you,
the more you put in there, the more> > behavior each party has to> > provide.
For example, if you're going to ship over a> > DataSet in JSON to a> > Java
application, then who's going through the> > trouble of making sure that> >
something on the Java or JavaScript side can provide> > all the expected> >
functionality, like producing updategrams when> > calling back into the server?>
> Don't get me wrong. There's an interesting problem> > domain behind it all> >
that's interesting to try and standardize, but I> > fear that it might be a bit>
> out of scope for this group.> >> > ________________________________> >> >
From: json@yahoogroups.> > <mailto:json%40yahoogroups.com> com> >
[mailto:json@yahoogroups.> > <mailto:json%40yahoogroups.com> com] On Behalf Of>
> 2> > Sent: Tuesday, July 11, 2006 6:10 PM> > To: json@yahoogroups.> >
<mailto:json%40yahoogroups.com> com> > Subject: RE: [json] JSON representation
of common> > types> >> > Good question.> >> > Unless I'm mistaken a Dictionary
is pretty much an> > associative array, which> > will follow the pattern of:> >
{key:value,key:value,key:value}, and Lists will> > just be arrays
[value,value,value]> >> > I know there is no standard for DataSet or DateTime.>
> I started a thread> > about a DataSet standard and got some good feedback> >
on the way people like> > to see them, but I didn't really get a strong sense> >
of urgency about the> > subject of standardizing them. You can check out the> >
thread here:> > http://groups.> >
<http://groups.yahoo.com/group/json/message/436>> >
yahoo.com/group/json/message/436 <http://groups.> >
<http://groups.yahoo.com/group/json/message/436>> >
yahoo.com/group/json/message/436>> >> > As for DateTime, again there is no
formal standard> > other then just returning> > your data in a format that can
be considered a date> > by both languages you> > are developing for (let's say
C# and JavaScript).> >>> === message truncated ===>> --> JSON: Action in AJAX!>>
JSON - http://www.json.org> JSON.simple -
http://www.json.org/java/simple.txt>>>>>>>
__________________________________________________________>
Mp3疯狂搜-新歌热歌高速下>
http://music.yahoo.com.cn/?source=mail_mailbox_footer>>>>>>> -- Best regards |
Schöne GrüßeMichaelMicrosoft MVP - Most Valuable ProfessionalMicrosoft MCAD -
Certified Application
Developerhttp://weblogs.asp.net/mschwarz/http://www.schwarz-interactive.de/mailt\
o:info@schwarz-interactive.de


_________________________________________________________________
Try Live.com: where your online world comes together - with news, sports,
weather, and much more.
http://www.live.com/getstarted

[Non-text portions of this message have been removed]

(longish, sorry if this has come up before, I didn't see it)

Looking at the JSON-RPC spec, it offers a way to hint at types in JSON
messages:

{"__jsonclass__":["constructor", [param1,...]], "prop1": ...}

This pattern supports encoding of complex typed objects in a JSON
message e.g.

{"__jsonclass__":["Date", "Dec 25, 1995"] }

{"__jsonclass__":["Person", "Joe", "Smith", 56] }

Its a neat trick.

And JSON itself *requires* a standard hinting convention. Any JSON
processor written in a typed language (C#, Java etc) needs to handle
type conversions. Today every processor out there is creating its own
ad-hoc hinting convention. These are unlikely to play well together.

With a standard type hinting mechanism we can write "validators"
(everyone groan!) to check the types of a JSON message before
processing. Yay for type hinting!

However, __jsonclass__ goes a step too far, and so only muddies the
water further.

Consider our lowly Date. According to the JSON RPC spec all of the
following could be legal:

{"__jsonclass__":["Date", "Mon, 25 Dec 1995 13:30:00 GMT"] }
{"__jsonclass__":["Date", "Dec 25, 1995"] }
{"__jsonclass__":["Date", 191121232] }
{"__jsonclass__":["Date", 1956, 1, 31] }

Sadly, none of those give us our beloved ISO 8601. For that we'll need
something else, possibly:

{"__jsonclass__":["MyIsoDateClass", "2006-12-15T19:15:00Z"] }

So we have just as many ways to encode a date in JSON as before
__jsonclass__, except we now have more complex format!

The flaw is this: __jsonclass__ aims to solve one problem (tagging
objects with type hints -- a good thing), but as a side effect
introduces an additional untyped data collection (the constructor
args). So then you are back to typing the values in the constructor
args... its pushed the problem further down, adding complexity.

An alternative is the "what the heck, lets throw constructors into
JSON" solution. It goes like this:

{
     "birthDate": new Date("Mon, 25 Dec 1995 13:30:00 GMT"),
}

The main advantage of this over __jsonclass__ is that you can directly
eval the message in JavaScript. The __jsonclass__ approach requires a
second pass over the data to execute constructors. Pretty compelling
given browser perf limitations. If we must have constructors I prefer
this latter solution to __jsonclass__.

However, neither approach get us closer to type hinting mechanism that
is easy for non-JavaScript languges.

What shines most about JSON is its simplicity. So type hinting
deserves a similarly simple solution. I propose a simple hint (e.g.
__jstype) which only carries type information. e.g.

{
     "__jstype": "Person",
     "firstName": "Joe",
     "lastName": "Smith",
     "age": 23,
}

For dates and other core value types, we could even (gasp) agree on
some standard __jstype hints:

{
     "__jstype": "dateTime",
     "value": "2006-12-15T19:15:00Z",
}

Yes, you still have to process the data to convert it to a Date (no
different from the __jsonclass__ approach there).

But the main point is that __jstype does not mix type information in
with the data - it doesn't introduce a new untyped collection that
processors must wrangle with.

For now, I'll probably use the closest I can get __jsonclass__, namely:

{
     "__jsonclass__":["Person"],
     "firstName": "Joe",
     "lastName": "Smith",
     "age": 23,
}

There's an extra array per object during processing, but it conforms
to the spec.

Comments?

Jon

What do you think of the the ideas presented in message #473:
http://groups.yahoo.com/group/json/message/473

There's even an example in there about how to present the structure of a Person
type. Keep in mind that the solution I presented is designed to solve the first
level of problem, which is how to communicate the structure of your data
out-of-band and at design-time. What hinting solves is the problem of
polymorphism, a bit how XML deals with it through xsi:type in the instance
document. In most cases, however, you want to know the structure at design-time
as opposed to run-time (if you can help it). The run-time hinting is only
interesting where the producer says I am going to give you an array of objects,
but you'll have to go digging into each to determine what their actual type is.
Even then, the discovered type is not about how you map it to language
constructs, but rather how you can treat the data. Consequently, I fear that the
problem of run-time hinting is destined (or doomed depending on how you see it)
to be solved by your framework's mapping subsystem rather than being
standardized on the wire. Here are the two main reasons I can think of why:

*
	 Security. It may not be wise to blindly accept the type that the producer might
want you to think a particular JSON data is.

*
	 Decoupling. The producer or consumer may see the logical to physical type
mapping different on each end of the wire. For example, the producer might use a
single person class but an enum field to distinguish the actual types. The
consumer, on the other hand, may wish to use discrete classes.

The problem I see with type-hinting at run-time is that it's not just limited to
reserving a property name. It also entails describing how to use that facility
and this is a difficult exercise that produces limiting results. At best, it
helps those small cases where folks on both ends don't wish to concern
themselves with the wire format and where deployment timelines can be tightly
linked. It's also not a new problem because ORM tools face the same issue with
SQL result sets. The problem there is solved through the mapping language of the
framework rather than changing the table schema (e.g., renaming the column to an
commonly accepted name of, say, "__type") or layering additional views.

- Atif


________________________________

De: json@yahoogroups.com de la part de meyer_jon
Date: lun. 7/24/2006 5:03
�: json@yahoogroups.com
Objet : [json] __jsonclass__ hinting



(longish, sorry if this has come up before, I didn't see it)

Looking at the JSON-RPC spec, it offers a way to hint at types in JSON
messages:

{"__jsonclass__":["constructor", [param1,...]], "prop1": ...}

This pattern supports encoding of complex typed objects in a JSON
message e.g.

{"__jsonclass__":["Date", "Dec 25, 1995"] }

{"__jsonclass__":["Person", "Joe", "Smith", 56] }

Its a neat trick.

And JSON itself *requires* a standard hinting convention. Any JSON
processor written in a typed language (C#, Java etc) needs to handle
type conversions. Today every processor out there is creating its own
ad-hoc hinting convention. These are unlikely to play well together.

With a standard type hinting mechanism we can write "validators"
(everyone groan!) to check the types of a JSON message before
processing. Yay for type hinting!

However, __jsonclass__ goes a step too far, and so only muddies the
water further.

Consider our lowly Date. According to the JSON RPC spec all of the
following could be legal:

{"__jsonclass__":["Date", "Mon, 25 Dec 1995 13:30:00 GMT"] }
{"__jsonclass__":["Date", "Dec 25, 1995"] }
{"__jsonclass__":["Date", 191121232] }
{"__jsonclass__":["Date", 1956, 1, 31] }

Sadly, none of those give us our beloved ISO 8601. For that we'll need
something else, possibly:

{"__jsonclass__":["MyIsoDateClass", "2006-12-15T19:15:00Z"] }

So we have just as many ways to encode a date in JSON as before
__jsonclass__, except we now have more complex format!

The flaw is this: __jsonclass__ aims to solve one problem (tagging
objects with type hints -- a good thing), but as a side effect
introduces an additional untyped data collection (the constructor
args). So then you are back to typing the values in the constructor
args... its pushed the problem further down, adding complexity.

An alternative is the "what the heck, lets throw constructors into
JSON" solution. It goes like this:

{
"birthDate": new Date("Mon, 25 Dec 1995 13:30:00 GMT"),
}

The main advantage of this over __jsonclass__ is that you can directly
eval the message in JavaScript. The __jsonclass__ approach requires a
second pass over the data to execute constructors. Pretty compelling
given browser perf limitations. If we must have constructors I prefer
this latter solution to __jsonclass__.

However, neither approach get us closer to type hinting mechanism that
is easy for non-JavaScript languges.

What shines most about JSON is its simplicity. So type hinting
deserves a similarly simple solution. I propose a simple hint (e.g.
__jstype) which only carries type information. e.g.

{
"__jstype": "Person",
"firstName": "Joe",
"lastName": "Smith",
"age": 23,
}

For dates and other core value types, we could even (gasp) agree on
some standard __jstype hints:

{
"__jstype": "dateTime",
"value": "2006-12-15T19:15:00Z",
}

Yes, you still have to process the data to convert it to a Date (no
different from the __jsonclass__ approach there).

But the main point is that __jstype does not mix type information in
with the data - it doesn't introduce a new untyped collection that
processors must wrangle with.

For now, I'll probably use the closest I can get __jsonclass__, namely:

{
"__jsonclass__":["Person"],
"firstName": "Joe",
"lastName": "Smith",
"age": 23,
}

There's an extra array per object during processing, but it conforms
to the spec.

Comments?

Jon



[Non-text portions of this message have been removed]

Atif couldn't have said better.

Stefan

  >-------- ���������� ����� --------
  >��:  "Atif Aziz" <atif.aziz@...>
  >�������: RE : [json] __jsonclass__ hinting
  >��: <json@yahoogroups.com>
  >��������� ��: ����������, 2006, ��� 24 21:00:31 EEST
  >----------------------------------
  >
  >What do you think of the the ideas presented in message #473:
  >http://groups.yahoo.com/group/json/message/473
  >
  >There's even an example in there about how to present the structure of a
Person type. Keep in mind that the solution I presented is designed to solve the
first level of problem, which is how to communicate the structure of your data
out-of-band and at design-time. What hinting solves is the problem of
polymorphism, a bit how XML deals with it through xsi:type in the instance
document. In most cases, however, you want to know the structure at design-time
as opposed to run-time (if you can help it). The run-time hinting is only
interesting where the producer says I am going to give you an array of objects,
but you'll have to go digging into each to determine what their actual type is.
Even then, the discovered type is not about how you map it to language
constructs, but rather how you can treat the data. Consequently, I fear that the
problem of run-time hinting is destined (or doomed depending on how you see it)
to be solved by your framework's mapping subsystem rather than b
  eing standardized on the wire. Here are the two main reasons I can think of
why:
  >
  >*
  > Security. It may not be wise to blindly accept the type that the producer
might want you to think a particular JSON data is.
  >
  >*
  > Decoupling. The producer or consumer may see the logical to physical type
mapping different on each end of the wire. For example, the producer might use a
single person class but an enum field to distinguish the actual types. The
consumer, on the other hand, may wish to use discrete classes.
  >
  >The problem I see with type-hinting at run-time is that it's not just limited
to reserving a property name. It also entails describing how to use that
facility and this is a difficult exercise that produces limiting results. At
best, it helps those small cases where folks on both ends don't wish to concern
themselves with the wire format and where deployment timelines can be tightly
linked. It's also not a new problem because ORM tools face the same issue with
SQL result sets. The problem there is solved through the mapping language of the
framework rather than changing the table schema (e.g., renaming the column to an
commonly accepted name of, say, "__type") or layering additional views.
  >
  >- Atif
  >
  >
  >________________________________
  >
  >De: json@yahoogroups.com de la part de meyer_jon
  >Date: lun. 7/24/2006 5:03
  >À: json@yahoogroups.com
  >Objet : [json] __jsonclass__ hinting
  >
  >
  >
  >(longish, sorry if this has come up before, I didn't see it)
  >
  >Looking at the JSON-RPC spec, it offers a way to hint at types in JSON
  >messages:
  >
  >{"__jsonclass__":["constructor", [param1,...]], "prop1": ...}
  >
  >This pattern supports encoding of complex typed objects in a JSON
  >message e.g.
  >
  >{"__jsonclass__":["Date", "Dec 25, 1995"] }
  >
  >{"__jsonclass__":["Person", "Joe", "Smith", 56] }
  >
  >Its a neat trick.
  >
  >And JSON itself *requires* a standard hinting convention. Any JSON
  >processor written in a typed language (C#, Java etc) needs to handle
  >type conversions. Today every processor out there is creating its own
  >ad-hoc hinting convention. These are unlikely to play well together.
  >
  >With a standard type hinting mechanism we can write "validators"
  >(everyone groan!) to check the types of a JSON message before
  >processing. Yay for type hinting!
  >
  >However, __jsonclass__ goes a step too far, and so only muddies the
  >water further.
  >
  >Consider our lowly Date. According to the JSON RPC spec all of the
  >following could be legal:
  >
  >{"__jsonclass__":["Date", "Mon, 25 Dec 1995 13:30:00 GMT"] }
  >{"__jsonclass__":["Date", "Dec 25, 1995"] }
  >{"__jsonclass__":["Date", 191121232] }
  >{"__jsonclass__":["Date", 1956, 1, 31] }
  >
  >Sadly, none of those give us our beloved ISO 8601. For that we'll need
  >something else, possibly:
  >
  >{"__jsonclass__":["MyIsoDateClass", "2006-12-15T19:15:00Z"] }
  >
  >So we have just as many ways to encode a date in JSON as before
  >__jsonclass__, except we now have more complex format!
  >
  >The flaw is this: __jsonclass__ aims to solve one problem (tagging
  >objects with type hints -- a good thing), but as a side effect
  >introduces an additional untyped data collection (the constructor
  >args). So then you are back to typing the values in the constructor
  >args... its pushed the problem further down, adding complexity.
  >
  >An alternative is the "what the heck, lets throw constructors into
  >JSON" solution. It goes like this:
  >
  >{
  >"birthDate": new Date("Mon, 25 Dec 1995 13:30:00 GMT"),
  >}
  >
  >The main advantage of this over __jsonclass__ is that you can directly
  >eval the message in JavaScript. The __jsonclass__ approach requires a
  >second pass over the data to execute constructors. Pretty compelling
  >given browser perf limitations. If we must have constructors I prefer
  >this latter solution to __jsonclass__.
  >
  >However, neither approach get us closer to type hinting mechanism that
  >is easy for non-JavaScript languges.
  >
  >What shines most about JSON is its simplicity. So type hinting
  >deserves a similarly simple solution. I propose a simple hint (e.g.
  >__jstype) which only carries type information. e.g.
  >
  >{
  >"__jstype": "Person",
  >"firstName": "Joe",
  >"lastName": "Smith",
  >"age": 23,
  >}
  >
  >For dates and other core value types, we could even (gasp) agree on
  >some standard __jstype hints:
  >
  >{
  >"__jstype": "dateTime",
  >"value": "2006-12-15T19:15:00Z",
  >}
  >
  >Yes, you still have to process the data to convert it to a Date (no
  >different from the __jsonclass__ approach there).
  >
  >But the main point is that __jstype does not mix type information in
  >with the data - it doesn't introduce a new untyped collection that
  >processors must wrangle with.
  >
  >For now, I'll probably use the closest I can get __jsonclass__, namely:
  >
  >{
  >"__jsonclass__":["Person"],
  >"firstName": "Joe",
  >"lastName": "Smith",
  >"age": 23,
  >}
  >
  >There's an extra array per object during processing, but it conforms
  >to the spec.
  >
  >Comments?
  >
  >Jon
  >
  >
  >
  >[Non-text portions of this message have been removed]
  >
  >
  >
  >
  >Yahoo! Groups Links
  >
  >
  >
  >
  >
  >
  >
  >

-----------------------------------------------------------------
http://ide.li/ - ������ �� ��������� �� �����. ������, ������, ������, ������,
����������.

--- In json@yahoogroups.com, "Atif Aziz" <atif.aziz@...> wrote:
>
> What do you think of the the ideas presented in message #473:
> http://groups.yahoo.com/group/json/message/473

My concern is that, rather than leveraging JSON as a rich syntax for
expressing type metadata, you are inventing a new syntax based on
slashes, a slippery slope that will lead to a mini language of its
own. (Look at what happened with MIME types. They started simple, now
you have things like:

     "application/xhtml+xml; charset=utf-8"

)

Following this approach will presumably lead to things like:

     "array/string/w3time;nullable=true;required=true;maxentries=5"

to express "a required array of up to 5 dates, or null".

or
     "number/int;min=0;max=100;"

etc.

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.

There as two cases: either you care about types (in which case you
need to reason about types in as straightforward a way as possible) or
you don't care about types (in which case the six types in raw JSON
messages are all already well-enough defined). Can you explain where
this middle category of "caring a little about types" comes in?

You want to address proxies for typed languages. We've just done
similar work for Jitsu using Xml (see
www.jitsu.org/jitsu/guide/data.html). We found we also needed enums;
restrictions; hooks for hanging documentation comments, and a
mechanism for adding additional application-specific attribute
metadata (e.g. to add a tag saying how something is stored on the
backend, or indicate what C# type to use for a JSON-RPC type etc).

I agree you need some kind of syntax is to express arrays -
programming languages already have a compact convention for this which
everyone knows: "Person[]".

So my reaction would be more in a direction like:

{
     "name":"Person",
     "docs":"My person class",
     "properties":[
         {
            "name":"firstName",
            "type":"string",
            "docs":"The persons first name",
         },
         {
            "name":"birthdate",
            "type":"string",
            "encoding":"iso8601",
            "docs":"The persons birthdate, encoded as a an ISO string",
         }
         {
            "name":"friends",
            "type":"Person[]",
         }
     ]
}

etc.

> What hinting solves is the problem of polymorphism, a bit how XML
deals with it through xsi:type in the instance document.

Yes. But consider that in Xml, you typically do:

     <Person>
         <firstName>Joe</firstName>
         <age>22</age>
     </Person>

In other words, by design Xml is implicitly a far more redundant
format than JSON.

JSON doesn't have a way to do this - JSON is a bit like Xml but with
only six element names (the ones you listed). There is no way to add
new element names. All the objects in JSON are anonymous, you just have:

     {
         "firstName":"Joe",
         "age":22,
     }

As soon as you have any non-trivial data structure (even just a
Hashtable of objects), you need a __jstype mechanism. This need is
much greater in JSON than xsi:type is in Xml.

I don't agree with your arguments for why a type hint would never take
off: Everyone working with JSON in typed languages is adding some kind
of type hinting, the need for this is very apparent.

Some specific responses to your comments:

> Security. It may not be wise to blindly accept the type
> that the producer might want you to think a particular JSON data is.

I don't see how adding type hints changes security issues. Any server
should still check that the data conforms to its internal schema. No
change there.

>  Decoupling. The producer or consumer may see the logical
> to physical type mapping different on each end of the wire.
> For example, the producer might use a single person class but
> an enum field to distinguish the actual types. The consumer,
> on the other hand, may wish to use discrete classes.

Different implementations can of course choose different strategies
for mapping types. Adding hints doesn't change that, it actually makes
this task easier.

> The problem I see with type-hinting at run-time is
> that it's not just limited to reserving a property name.
> It also entails describing how to use that facility and
> this is a difficult exercise that produces limiting results. ...
> It's also not a new problem because ORM tools face the same
> issue with SQL result sets.

Every object oriented language out there (including JavaScript)
supports named classes which have a set of properties (instances/slots
whatever you call them).

Today, JSON specifies how to encode properties, but doesn't specify
how to encode what classes those properties belong to. This is just a
simple shortcoming, its not about how to use those classes, what those
classes mean, the service contact between client and server,
polymorphism or anything else. Unless we can agree on a solution, JSON
is a handicapped serialization format, because everyone will invent
their own workarounds for this issue.

> My concern is that, rather than leveraging JSON as a rich syntax for
> expressing type metadata, you are inventing a new syntax based on
> slashes, a slippery slope that will lead to a mini language of its
> own.

The slash syntax is only used for naming the type, but JSON is certainly
being leveraged to describe the structure of a type as show in the
Person example:

{ "name" : "string",
    "sirname" : "string",
    "birthday" : "string/time"
    "children" : "array/object/person"
}

The slash-like approach is really there to qualify the simple and
primitive types like String with further precision. How else can you say
that a string really contains at date and time? Have you checked out the
JSON formatted response from one of Yahoo's services[1]. They encode
time using the Unix time format, which yields a number, but then go on
to put it inside of a String rather than a Number. Short of twisting
Yahoo's hand to give you a static type hint in the response,
"string/time" seems to me the simplest and most straightforward way to
describe exactly that. Anything else resulted in a scheme that seemed
like an overkill for the problem at hand.

> (Look at what happened with MIME types. They started simple, now
> you have things like:

I haven't really seen this complaint anywhere else and MIME types still
seem to be reasonably in control compared to what the spec really does
permit. I do understand your concern and so I don't wish to allow any
kind of additional attributes to express limits and other facets of a
type. So this example would never happen, or rather, is out of scope:

> Following this approach will presumably lead to things like:
>
> "array/string/w3time;nullable=true;required=true;maxentries=5"
>
> to express "a required array of up to 5 dates, or null".
>
> or
> "number/int;min=0;max=100;"

I say out of scope because these particular example are more about
validation rules, claims and promises (mainly from the producer) than
simply communicating type structure. Nullable, required and maximum
entries do not change the fundamental type, its precision or the
semantics. If you want validation, then this could be worked in so:

{ "name" : "string",
    "sirname" : "string",
    "birthday" : "string/time"
    "children" : {
      type : "array/object/person",
      maxLength : 10,
      nullable : false
    }
}

I've come with the above at the spur of the moment so please don't take
the setup I've presented as literally my recommended way to go. What I
am trying to demonstrate is that we may very well be more in agreement
than you initially thought, especially with respect to where the slash
syntax may have its place.

As for the number/int example, I'm hoping that the standardization of a
few would serve as a starting point and which would also define the
limits in some way. For example, "byte", "int16", "int32", "int64" and
so on would be cover a lot of the cases and the type-names are unique
and indicative of their bit lengths (and therefore implied limits).

> www.jitsu.org/jitsu/guide/data.html). We found we also needed enums;
> restrictions; hooks for hanging documentation comments, and a
> mechanism for adding additional application-specific attribute
> metadata (e.g. to add a tag saying how something is stored on the
> backend, or indicate what C# type to use for a JSON-RPC type etc).

We can talk about the syntax and structural details as soon as we're
working on the same problem, and that is 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.

> I agree you need some kind of syntax is to express arrays -
> programming languages already have a compact convention for this which
> everyone knows: "Person[]".

Yes, it's certainly more terse and it's my preference too. However, it
doesn't help in the case of subtyping other values. I wanted to come up
with a generic syntax first, which always leaves room for mentioning
shorthand versions. The generic syntax can be read and interpreted left
to right, making parsing simple. The use of "[]" is certainly on my list
of things to consider.

> So my reaction would be more in a direction like:

You reaction is not too far from mine. :) I guess throwing some ideas
out in their unfinished form invites more trouble than help, but I was
hoping that the Person example I gave would allow people to see where it
could go.

> Everyone working with JSON in typed languages is adding some kind
> of type hinting, the need for this is very apparent.

I didn't say it will *never* take off. The question is about the problem
you're trying to solve. My opinion is that there's a more urgent problem
waiting and run-time type-hinting as you may want to implement it could
certainly have a dependency on it. 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?

> JSON doesn't have a way to do this - JSON is a bit like Xml but with
> only six element names (the ones you listed). There is no way to add
> new element names. All the objects in JSON are anonymous, you just
have:
>
> {
> "firstName":"Joe",
> "age":22,
> }

That's true. 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. Otherwise, yes, you have to let
the caller on the consumer side tell you how to interpret and map that
data. You'll have to assume they got the type out of some documentation.

> I don't see how adding type hints changes security issues. Any server
> should still check that the data conforms to its internal schema. No
> change there.

If it is checking against the wrong schema based on the type hint then
there's trouble looming, no?

Running out of time right now, so just two quick comments...

> 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. ;)

> There as two cases: either you care about types (in which case you
> need to reason about types in as straightforward a way as possible) or
> you don't care about types (in which case the six types in raw JSON
> messages are all already well-enough defined). Can you explain where
> this middle category of "caring a little about types" comes in?

There isn't any such category. I'm in the first category. Hope of some
of the explanations here help reflect that.

[1]
http://api.search.yahoo.com/NewsSearchService/V1/newsSearch?appid=YahooD\
emo&query=madonna&results=3&language=en&output=json
<http://api.search.yahoo.com/NewsSearchService/V1/newsSearch?appid=Yahoo\
Demo&query=madonna&results=3&language=en&output=json>


--- In json@yahoogroups.com, "meyer_jon" <jonmeyer@...> wrote:
>
> --- In json@yahoogroups.com, "Atif Aziz" atif.aziz@ wrote:
> >
> > What do you think of the the ideas presented in message #473:
> > http://groups.yahoo.com/group/json/message/473
>
> My concern is that, rather than leveraging JSON as a rich syntax for
> expressing type metadata, you are inventing a new syntax based on
> slashes, a slippery slope that will lead to a mini language of its
> own. (Look at what happened with MIME types. They started simple, now
> you have things like:
>
> "application/xhtml+xml; charset=utf-8"
>
> )
>
> Following this approach will presumably lead to things like:
>
> "array/string/w3time;nullable=true;required=true;maxentries=5"
>
> to express "a required array of up to 5 dates, or null".
>
> or
> "number/int;min=0;max=100;"
>
> etc.
>
> 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.
>
> There as two cases: either you care about types (in which case you
> need to reason about types in as straightforward a way as possible) or
> you don't care about types (in which case the six types in raw JSON
> messages are all already well-enough defined). Can you explain where
> this middle category of "caring a little about types" comes in?
>
> You want to address proxies for typed languages. We've just done
> similar work for Jitsu using Xml (see
> www.jitsu.org/jitsu/guide/data.html). We found we also needed enums;
> restrictions; hooks for hanging documentation comments, and a
> mechanism for adding additional application-specific attribute
> metadata (e.g. to add a tag saying how something is stored on the
> backend, or indicate what C# type to use for a JSON-RPC type etc).
>
> I agree you need some kind of syntax is to express arrays -
> programming languages already have a compact convention for this which
> everyone knows: "Person[]".
>
> So my reaction would be more in a direction like:
>
> {
> "name":"Person",
> "docs":"My person class",
> "properties":[
> {
> "name":"firstName",
> "type":"string",
> "docs":"The persons first name",
> },
> {
> "name":"birthdate",
> "type":"string",
> "encoding":"iso8601",
> "docs":"The persons birthdate, encoded as a an ISO string",
> }
> {
> "name":"friends",
> "type":"Person[]",
> }
> ]
> }
>
> etc.
>
> > What hinting solves is the problem of polymorphism, a bit how XML
> deals with it through xsi:type in the instance document.
>
> Yes. But consider that in Xml, you typically do:
>
> <Person>
> <firstName>Joe</firstName>
> <age>22</age>
> </Person>
>
> In other words, by design Xml is implicitly a far more redundant
> format than JSON.
>
> JSON doesn't have a way to do this - JSON is a bit like Xml but with
> only six element names (the ones you listed). There is no way to add
> new element names. All the objects in JSON are anonymous, you just
have:
>
> {
> "firstName":"Joe",
> "age":22,
> }
>
> As soon as you have any non-trivial data structure (even just a
> Hashtable of objects), you need a __jstype mechanism. This need is
> much greater in JSON than xsi:type is in Xml.
>
> I don't agree with your arguments for why a type hint would never take
> off: Everyone working with JSON in typed languages is adding some kind
> of type hinting, the need for this is very apparent.
>
> Some specific responses to your comments:
>
> > Security. It may not be wise to blindly accept the type
> > that the producer might want you to think a particular JSON data is.
>
> I don't see how adding type hints changes security issues. Any server
> should still check that the data conforms to its internal schema. No
> change there.
>
> > Decoupling. The producer or consumer may see the logical
> > to physical type mapping different on each end of the wire.
> > For example, the producer might use a single person class but
> > an enum field to distinguish the actual types. The consumer,
> > on the other hand, may wish to use discrete classes.
>
> Different implementations can of course choose different strategies
> for mapping types. Adding hints doesn't change that, it actually makes
> this task easier.
>
> > The problem I see with type-hinting at run-time is
> > that it's not just limited to reserving a property name.
> > It also entails describing how to use that facility and
> > this is a difficult exercise that produces limiting results. ...
> > It's also not a new problem because ORM tools face the same
> > issue with SQL result sets.
>
> Every object oriented language out there (including JavaScript)
> supports named classes which have a set of properties (instances/slots
> whatever you call them).
>
> Today, JSON specifies how to encode properties, but doesn't specify
> how to encode what classes those properties belong to. This is just a
> simple shortcoming, its not about how to use those classes, what those
> classes mean, the service contact between client and server,
> polymorphism or anything else. Unless we can agree on a solution, JSON
> is a handicapped serialization format, because everyone will invent
> their own workarounds for this issue.
>




[Non-text portions of this message have been removed]

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.

Apparently PHP has a bug that they marked "Won't Fix", which will
prevent error reporting when JSON is output:

http://bugs.php.net/bug.php?id=38184

You may wish to add comments and/or votes to the bug report to try to
convince PHP developers to fix the bug.

If you have any questions about the nature of the bug, please add
those questions as comments to the bug report at the above link, and I
will respond there. Do not ask me questions about the bug here on
this yahoo group. I will not answer here. Thanks.

Could someone here post to this group as to why (if) this is really an
issue, I feel like I must be missing something.

Is there a reason why a custom error handler doesn't cover this and that
your app should catch if it can't translate the incoming stream to json?

--
Matthew P. C. Morley


[Non-text portions of this message have been removed]

> new element names. All the objects in JSON are anonymous, you just have:
>
>     {
>         "firstName":"Joe",
>         "age":22,
>     }
>
> As soon as you have any non-trivial data structure (even just a
> Hashtable of objects), you need a __jstype mechanism. This need is
> much greater in JSON than xsi:type is in Xml.
>
> I don't agree with your arguments for why a type hint would never take
> off: Everyone working with JSON in typed languages is adding some kind
> of type hinting, the need for this is very apparent.

Just some thoughts..  I was experimenting with different ways to name things and
came up
with these:

1) Name the anonymous members using some sort of extended syntax.

<Person>{
     "name": "Fred",
     "age":22
}

2) Alternatively, allow one of these inside an object:

{
     <Person>,
     "name": "Fred"
}

3) JSON already has a way to do this (sort of):

{
     "Person":{ "name":"Fred", "age":22 }
}

4) This could be extended:

{
     "Person":{ "name":"Fred", "age":22 }
     "isInstance":true
}

Or we could have "isClass", etc.

5) This could be used to define types instead:

<Person>{
     "property":"name",
     "property":"age"
}

6) This could be shrunk:

<Person>["name", "age"]

7) Or:

<Person>[{"name":"string"},{"age":number}]

etc...

I think of JSON more as the "lexing" layer with a few extra types, and then the
meaning is
tacked on by some sort of external program or schema.

Just some random thoughts on the subject...

         -Shawn

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the json
group.

   File        : /json-lib-1_0.zip
   Uploaded by : shawnsilverman <shawn@...>
   Description : A Java library for processing JSON data.

You can access this file at the URL:
http://groups.yahoo.com/group/json/files/json-lib-1_0.zip

To learn more about file sharing for your group, please visit:
http://help.yahoo.com/help/us/groups/files

Regards,

shawnsilverman <shawn@...>

The JSON RFC has been published.

http://www.ietf.org/rfc/rfc4627.txt

>>
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.

--- In json@yahoogroups.com, "neil_b" <neil@...> wrote:
>
> First Post - I see most environments are covered with a library for
> json except Classic ASP. I have one last major development to do with
> it before moving on to something newer.
>
> I imagine I could simply use Javascript mixed in with whatever other
> scripting languages I use (VBScript and ActivePerl). Does anyone have
> any guidance, comments or even code to help me with this approach?
>
> I am also interested in creating json with T-SQL in SQL Server.
> Comments on that are appreciated too.
>
> Neil
>

For converting ASP objects into JSON, I've had to write my own code to
walk dictionaries, arrays, etc.  I can't really share that.
For converting JSON into something ASP can use, add

function gParseJSON(aStr){
	 return aStr.parseJSON();
}

to the bottom of the stock JSON.js script file.
Include in your site's code:

%>
<SCRIPT Language="JAVASCRIPT" RUNAT="SERVER" SRC="/json.js"></script>
<%
This will expose the scripts in there to your VB and JS server side
scripting.
Example:

const BR = "<br>"
response.write "Testing parsing JSON into something:" & BR
dim Point
set Point = gParseJSON("{ ""x"" : 1, ""y"" : 2 }")
response.write Point.x & BR
response.write Point.Y & BR
response.write Point.toJSONString() & BR
response.write TypeName(Point) & BR
response.write "Done Testing parsing JSON into something." & BR

I have not yet learned how to find out what the names of all the
properties are or how to access those dynamically.  "For Each fld in
Point" does not work.

IMarv

Hi,
   I went to the root of the conversation since I couldn't find a good
spot elsewhere for this thought:
I think JSON is fine as-is.  If you want something that can carry more
complicated data types, use XML.  If you want something simple, use
JSON.  If you're after something in the middle, make up something new.

The way JSON defines types is by its delimiters.
Currently, we have {} for objects, [] for arrays, "" for strings and
nothing for numbers, and true, false, and null stand alone.
If you wish to add more strict data types, you need to add more
delimiter choices.  Perhaps Parenthesis should be used for Dates ()
and angle brackets <> for another type.  The question eventually
becomes, when are there enough?

Incorporating limits for values is beyond the scope of JSON as a data
serializer.  The point of JSON is to efficiently get data from here to
there.  The end-points are responsabile for understanding the
capabilities and limitations of the data.  If you need to communicate
those, do so in a separate set of correspondance.  This can either be
off-line in some agreement, talking to yourself while making up an
AJAX app, or through some nifty schema description language.  In any
case, don't mix data with schema.

Another way:  If I were a bakery, I don't need to tell my courier that
he's sending bread and include direction on how to eat it each time I
send it.  I expect the recipient to know how to eat bread, and if he
doesn't, he can come to my shop and ask for any of my wonderful
sandwich recipies, but I don't need to ship my collection of recipies
with every order of bread.

IMarv
Andy Bay
--- In json@yahoogroups.com, "Michael Schwarz" <michael.schwarz@...>
wrote:
>
> Hi,
>
> I'd like to know if there are already some common representations of
> common types like following .NET data types:
>
>  - DataSet, DataTable
>  - Dictionary
>  - List, Collection
>  - DateTime -> sometimes handeled as "new Date(...)" or maybe the
> SortablePattern string representation
>
> --
> Best regards | Sch�ne Gr��e
> Michael
>
> Microsoft MVP - Most Valuable Professional
> Microsoft MCAD - Certified Application Developer
>
> http://weblogs.asp.net/mschwarz/
> http://www.schwarz-interactive.de/
> mailto:info@...
>

Out of band data for creating types in other languages which don't
cleanly/easily support raw javascript types should be done as optional
data, which can still be encoded as json.

It should be easy enough to take your objects before json encoding,
and run them through a function to turn them into wrapper objects, the
additional data you need being stored in properties, without polluting
json or json-rpc directly.

Assuming you know that the consumer of the data needs these additional
suggestions as to type election, otherwise as Andy said that `burden`
should be on the decoder to figure it out.


--
Matthew P. C. Morley
MPCM Technologies Inc.

Hi,

I am stuck on a sample json call. I see that the group is addressing
bigger topics other than "im stuck and need help" stuff.
With your permission I will post my elementary problem, otherwise
kindly can someone point me to a more fitting forum for
json support?

Best regards,

Dane Ensign
dane@...

i know u can read json data with the dynamic script tag.But can i post
json crossDomain without xmlhttpObject? Evvvery link i go,they either
talk about only webservices (reading json data) or other forms of
strictly 'reading' json data. what about posting ? if people say you
an avoid ajax with json ,why is that you still need xmlhttprequest
object to 'send ' json data .
PS:i dont want to send via a quertystring . any other options ?

Keep CLicking,
BHasker V Kode

The only sense in which JSON "avoids" Ajax, is that it's not XML
("Ajaj"?). JSON is just a format for your data, you still need to
move it around using the same mechanisms provided by browsers such as
the terribly misnamed XmlHttpRequest or whatever. All the usual
methods and techniques used in Ajax apply, except the hassle of
parsing and building XML messages.

-mike.

On Aug 19, 2006, at 9:57 AM, Bhasker wrote:

> i know u can read json data with the dynamic script tag.But can i post
> json crossDomain without xmlhttpObject? Evvvery link i go,they either
> talk about only webservices (reading json data) or other forms of
> strictly 'reading' json data. what about posting ? if people say you
> an avoid ajax with json ,why is that you still need xmlhttprequest
> object to 'send ' json data .
> PS:i dont want to send via a quertystring . any other options ?
>
> Keep CLicking,
> BHasker V Kode

----------------------------------------------------------------
michal migurski- contact info and pgp key:
sf/ca            http://mike.teczno.com/contact.html

Not entirely true.  You can use JSON and dynamically created script
tags to get around cross site scripting limitations.  I think the
question here was can you use HTTP POST with this technique, and the
answer is no.  You can only HTTP GET with dynamically created script tags.

--- In json@yahoogroups.com, Michal Migurski <mike-jsonphp@...> wrote:
>
> The only sense in which JSON "avoids" Ajax, is that it's not XML
> ("Ajaj"?). JSON is just a format for your data, you still need to
> move it around using the same mechanisms provided by browsers such as
> the terribly misnamed XmlHttpRequest or whatever. All the usual
> methods and techniques used in Ajax apply, except the hassle of
> parsing and building XML messages.
>
> -mike.
>
> On Aug 19, 2006, at 9:57 AM, Bhasker wrote:
>
> > i know u can read json data with the dynamic script tag.But can i post
> > json crossDomain without xmlhttpObject? Evvvery link i go,they either
> > talk about only webservices (reading json data) or other forms of
> > strictly 'reading' json data. what about posting ? if people say you
> > an avoid ajax with json ,why is that you still need xmlhttprequest
> > object to 'send ' json data .
> > PS:i dont want to send via a quertystring . any other options ?
> >
> > Keep CLicking,
> > BHasker V Kode
>
> ----------------------------------------------------------------
> michal migurski- contact info and pgp key:
> sf/ca            http://mike.teczno.com/contact.html
>