Loading ...
Sorry, an error occurred while loading the content.
 

RE: Re: [json] JSON representation of common types

Expand Messages
  • Mert Sakarya
    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
    Message 1 of 19 , Jul 18 2:55 AM
      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@yahoogroups.comFrom: 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-datatypesRegards,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/mailto:info@...


      _________________________________________________________________
      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]
    • Andy
      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
      Message 2 of 19 , Aug 7, 2006
        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@...
        >
      • Matt
        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
        Message 3 of 19 , Aug 8, 2006
          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.
        Your message has been successfully submitted and would be delivered to recipients shortly.