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

mixed content and attributes

Expand Messages
  • Marco Rosella
    Hi all, i m new in the JSON world and I m searching in it a good alternative to XML. To begin, I translated some XML data in JSON format, and I crashed soon
    Message 1 of 18 , May 23, 2006
    • 0 Attachment
      Hi all,
      i'm new in the JSON world and I'm searching in it a good alternative
      to XML.
      To begin, I translated some XML data in JSON format, and I crashed
      soon with two doubts: mixed content and attributes.

      About the first, it related about a XML document like this:

      <book>
      <chapter>Content of the first chapter</chapter>
      <chapter>Content of the first chapter
      <chapter>Content of the first subchapter</chapter>
      <chapter>Content of the second subchapter</chapter>
      </chapter>
      <chapter>Third Chapter</chapter>
      </book>

      I would to the light over the second 'chapter' node element
      that contains both elements (the child 'chapter') and text ('Content
      of...' etc).
      W3C called the content of this elements 'mixed content' (XML Schema
      Rec.: http://www.w3.org/TR/xmlschema-0/#mixedContent;
      XML Spec.: http://www.w3.org/TR/2000/REC-xml-20001006#sec-mixed-content; )
      and I think is very important represent it in a datachange format
      remembering that for example XHTML is full of these tags (like
      <p>This is <a href="http://">a link</a>, yeah</p>).
      Searching for a translation way in the JSON site's example page,
      my goal failed because I found only element that contains OR elements OR
      character data.
      Do you know, so, a way to describe a mixed content in JSON?

      The other doubt is about attributes.

      In the second example in JSON site's example page
      an XML document like this:
      <menu id="file" value="File" >
      <popup>
      <menuitem value="New" onclick="CreateNewDoc()" />
      <menuitem value="Open" onclick="OpenDoc()" />
      <menuitem value="Close" onclick="CloseDoc()" />
      </popup>
      </menu>

      is translated in this way:

      {"menu": {
      "id": "file",
      "value": "File:",
      "popup": {
      "menuitem": [
      {"value": "New", "onclick": "CreateNewDoc()"},
      {"value": "Open", "onclick": "OpenDoc()"},
      {"value": "Close", "onclick": "CloseDoc()"}
      ]
      }
      As I understand, the attributes are represented at the same level of
      the first child.
      So I don't find differences in re-translate the JSON format in XML in
      this way:

      <menu>
      <id>file</id>
      <value>File</value>
      <popup>
      <menuitem value="New" onclick="CreateNewDoc()" />
      <menuitem value="Open" onclick="OpenDoc()" />
      <menuitem value="Close" onclick="CloseDoc()" />
      </popup>
      </menu>

      Lost attribute power (a sort of "semanthic enrichment" of the element,
      not a child of this) is like to represented an HTML div like this:
      <div class="ciao"/>
      in this way:
      <div>
      <class>ciao</class>
      </div>

      To confirm if I'm wrong or not, I'll cut'n'paste the third example
      taken from the same page:

      {"widget": {
      "debug": "on",
      "window": {
      "title": "Sample Konfabulator Widget",
      "name": "main_window",
      "width": 500,
      "height": 500
      },
      "image": {
      "src": "Images/Sun.png",
      "name": "sun1",
      "hOffset": 250,
      "vOffset": 250,
      "alignment": "center"
      },
      "text": {
      "data": "Click Here",
      "size": 36,
      "style": "bold",
      "name": "text1",
      "hOffset": 250,
      "vOffset": 100,
      "alignment": "center",
      "onMouseUp": "sun1.opacity = (sun1.opacity / 100) * 90;"
      }
      }}

      The same text expressed as XML:

      <widget>
      <debug>on</debug>
      <window title="Sample Konfabulator Widget">
      <name>main_window</name>
      <width>500</width>
      <height>500</height>
      </window>
      <image src="Images/Sun.png" name="sun1">
      <hOffset>250</hOffset>
      <vOffset>250</vOffset>
      <alignment>center</alignment>
      </image>
      <text data="Click Here" size="36" style="bold">
      <name>text1</name>
      <hOffset>250</hOffset>
      <vOffset>100</vOffset>
      <alignment>center</alignment>
      <onMouseUp>
      sun1.opacity = (sun1.opacity / 100) * 90;
      </onMouseUp>
      </text>
      </widget>

      Where is written that ONLY the name/value pair with the name "title"
      can be an attribute of 'window' element?
      Why the 'image' element has as attribute 'src' and 'name'
      and not 'hOffset' or 'vOffset' too?

      Thanks for your patience long like this email! :)

      -----------------------------------
      Marco Rosella
      http://www.centralscrutinizer.it/en
    • Douglas Crockford
      ... There are many ways that you could render that into JSON. This is how org.json.XML does it in Java: { book : { chapter : [ Content of the first chapter ,
      Message 2 of 18 , May 23, 2006
      • 0 Attachment
        > About the first, it related about a XML document like this:
        >
        > <book>
        > <chapter>Content of the first chapter</chapter>
        > <chapter>Content of the first [sic] chapter
        > <chapter>Content of the first subchapter</chapter>
        > <chapter>Content of the second subchapter</chapter>
        > </chapter>
        > <chapter>Third Chapter</chapter>
        > </book>

        There are many ways that you could render that into JSON. This is how
        org.json.XML does it in Java:

        {"book": {"chapter": [
        "Content of the first chapter",
        {
        "content": "Content of the first [sic] chapter",
        "chapter": [
        "Content of the first subchapter",
        "Content of the second subchapter"
        ]
        },
        "Third Chapter"
        ]}}
      • Mert Sakarya
        Can we use function definitions in JSON? Eg. { book : { name : bookname , chapter : [...], gotoChapter : function(chapterId) {...} } } And how about using
        Message 3 of 18 , May 23, 2006
        • 0 Attachment
          Can we use function definitions in JSON? Eg.

          {"book": {
          "name": "bookname",
          "chapter": [...],
          "gotoChapter" : function(chapterId) {...}
          }
          }

          And how about using Date objects? Eg.

          {"book": {
          "name": "bookname",
          "chapter": [...],
          "gotoChapter" : function(chapterId) {...},
          "printDate" : new Date(2000,06,31,12,11,00)
          }
          }

          The two examples above cannot be parsed, "parse" method on the standard.

          I think, adding function definitions to the standard, adds great
          flexibility for javascript, but decreases portability.
        • Martin Cooper
          ... Please, no! That violates just about everything JSON is about. If you want to pass functions around, just use JavaScript in the first place, and forget
          Message 4 of 18 , May 23, 2006
          • 0 Attachment
            On 5/23/06, Mert Sakarya <msakarya@...> wrote:
            >
            > Can we use function definitions in JSON?


            Please, no! That violates just about everything JSON is about. If you want
            to pass functions around, just use JavaScript in the first place, and forget
            about JSON.

            --
            Martin Cooper


            Eg.
            >
            > {"book": {
            > "name": "bookname",
            > "chapter": [...],
            > "gotoChapter" : function(chapterId) {...}
            > }
            > }
            >
            > And how about using Date objects? Eg.
            >
            > {"book": {
            > "name": "bookname",
            > "chapter": [...],
            > "gotoChapter" : function(chapterId) {...},
            > "printDate" : new Date(2000,06,31,12,11,00)
            > }
            > }
            >
            > The two examples above cannot be parsed, "parse" method on the standard.
            >
            > I think, adding function definitions to the standard, adds great
            > flexibility for javascript, but decreases portability.
            >
            >
            >
            >
            >
            > Yahoo! Groups Links
            >
            >
            >
            >
            >
            >
            >


            [Non-text portions of this message have been removed]
          • Greg Patnude
            You know Mert -- I think you are on to something here but I have to suggest an alternative to your implementation -- I personally can t readily accept a
            Message 5 of 18 , May 23, 2006
            • 0 Attachment
              You know Mert -- I think you are on to something here but I have to
              suggest an alternative to your implementation -- I personally can't
              readily accept a situation where every time the language changes -- I
              would need to update the JSON parser and redeploy it to my server(s) --
              I think a better approach would be for the JavaScript version (let's
              call it the "runtime" or the "client-side parser") of the JSON parser to
              server as a wrapper around the JavaScript core objects. This makes sense
              for a lot of reasons, including:

              * Automatic forward compatibility as the ECMA standard evolves and
              the JavaScript interpreters evolve
              * Native support for ALL JavaScript "types", including the
              troublesome JavaScript "Date" type. If you look closely at the "Date"
              type -- you will see that it is more object than variable -- in fact --
              it is a composite object, encapsulating strings, numbers, and functions
              (methods) -- this is why you can't really parse a native date in the
              core JSON
              * This would implement your idea of incorporating a stringified
              function definition into a callable function

              I wouldn't really suggest throwing out the baby with the bathwater --
              the JSON parser developed by Doug Crockford is excellent -- but I would
              suggest some restructuring -- this is a somewhat major and radical
              solution but it would be a "one-time" restructuring --

              My suggestion would be to blend the JSON tokenizer with a loop iterator.
              Fundamentally -- the JSON parser loops through the stringified object
              and then iterates through the native JavaScript "types" -- the goal of
              the improved parser is to cast the stringified data into a JavaScript
              native type...




              --- In json@yahoogroups.com, "Mert Sakarya" <msakarya@...> wrote:
              >
              > Can we use function definitions in JSON? Eg.
              >
              > {"book": {
              > "name": "bookname",
              > "chapter": [...],
              > "gotoChapter" : function(chapterId) {...}
              > }
              > }
              >
              > And how about using Date objects? Eg.
              >
              > {"book": {
              > "name": "bookname",
              > "chapter": [...],
              > "gotoChapter" : function(chapterId) {...},
              > "printDate" : new Date(2000,06,31,12,11,00)
              > }
              > }
              >
              > The two examples above cannot be parsed, "parse" method on the
              standard.
              >
              > I think, adding function definitions to the standard, adds great
              > flexibility for javascript, but decreases portability.
              >




              [Non-text portions of this message have been removed]
            • Fang Yidong
              I think why JSON be successful as a data-interchange format is its simplicity and neutral nature for many languages. Adding function definition just make JSON
              Message 6 of 18 , May 23, 2006
              • 0 Attachment
                I think why JSON be successful as a data-interchange
                format is its simplicity and neutral nature for many
                languages. Adding function definition just make JSON
                stick to javascript. As to the datatype 'Date',you can
                use number or string to represent it.

                --- Mert Sakarya <msakarya@...>:

                > Can we use function definitions in JSON? Eg.
                >
                > {"book": {
                > "name": "bookname",
                > "chapter": [...],
                > "gotoChapter" : function(chapterId) {...}
                > }
                > }
                >
                > And how about using Date objects? Eg.
                >
                > {"book": {
                > "name": "bookname",
                > "chapter": [...],
                > "gotoChapter" : function(chapterId) {...},
                > "printDate" : new Date(2000,06,31,12,11,00)
                > }
                > }
                >
                > The two examples above cannot be parsed, "parse"
                > method on the standard.
                >
                > I think, adding function definitions to the
                > standard, adds great
                > flexibility for javascript, but decreases
                > portability.
                >
                >
                >
                > ------------------------ Yahoo! Groups Sponsor
                > --------------------~-->
                > Home is just a click away. Make Yahoo! your home
                > page now.
                >
                http://us.click.yahoo.com/DHchtC/3FxNAA/yQLSAA/1U_rlB/TM
                >
                --------------------------------------------------------------------~->
                >
                >
                >
                > Yahoo! Groups Links
                >
                >
                > json-unsubscribe@yahoogroups.com
                >
                >
                >
                >
                >




                ___________________________________________________________
                雅虎免费邮箱-3.5G容量,20M附件
                http://cn.mail.yahoo.com/
              • Lindsay
                ... Agreed. Maybe define a std date format, there s a ISO one which would do fine. -- Lindsay
                Message 7 of 18 , May 25, 2006
                • 0 Attachment
                  Fang Yidong wrote:
                  > I think why JSON be successful as a data-interchange
                  > format is its simplicity and neutral nature for many
                  > languages. Adding function definition just make JSON
                  > stick to javascript. As to the datatype 'Date',you can
                  > use number or string to represent it.
                  >

                  Agreed. Maybe define a std date format, there's a ISO one which would do
                  fine.


                  --
                  Lindsay
                • Greg Patnude
                  I have a JSON compatible date parser which converts a stringified version of a C-Type date (mm-dd-yyyy hh:mm:ss.nnnn [AM:PM]) into a JavaScript native Date
                  Message 8 of 18 , May 26, 2006
                  • 0 Attachment
                    I have a JSON compatible date parser which converts a stringified
                    version of a C-Type date (mm-dd-yyyy hh:mm:ss.nnnn [AM:PM]) into a
                    JavaScript native Date object format...

                    I will offer it to the JSON community to be included as a component of
                    the json.js library -- provided under the JSON License (Doug's "Good
                    NOT Evil" license)...

                    Speaking of the "Good NOT Evil" license -- is anyone interested in
                    formalizing that ? like the myriad licensing already available -- GPL,
                    or LGPL, or BSD Licenses... we could call it the "GNOTE" license....


                    --- In json@yahoogroups.com, Lindsay <lindsay@...> wrote:
                    >
                    > Fang Yidong wrote:
                    > > I think why JSON be successful as a data-interchange
                    > > format is its simplicity and neutral nature for many
                    > > languages. Adding function definition just make JSON
                    > > stick to javascript. As to the datatype 'Date',you can
                    > > use number or string to represent it.
                    > >
                    >
                    > Agreed. Maybe define a std date format, there's a ISO one which
                    would do
                    > fine.
                    >
                    >
                    > --
                    > Lindsay
                    >
                  • Greg Patnude
                    I think everyone is missing teh point I am trying to make --- I truly believe that Object Notation is the holy grail of data interchange. As a result, I
                    Message 9 of 18 , May 26, 2006
                    • 0 Attachment
                      I think everyone is missing teh point I am trying to make --- I truly
                      believe that "Object Notation" is the holy grail of data interchange.
                      As a result, I would like to see object notation extended beyond just
                      support for JavaScript (JSON) to every language --

                      If we are truly talking about Object Notation -- then the parser(s)
                      need to support all of the native object types for any given
                      programming language -- If we are only talking about JavaScript
                      Object Notation -- then I would expect the parser(s) to support all
                      of the object / data types native to JavaScript.

                      So -- if JSON is to TRULY represent the JavaScript Objects -- in
                      addition to String, Number, Array, Object, true, false, and null
                      objects -- the parser should also necessarily include

                      • Date
                      • Math
                      • Function
                      • RegExp
                      and
                      • Boolean objects...

                      My desire is to see object notation become mainstream -- much more
                      than JSON and bigger than XML even -- In order to accomplish that --
                      we would really need an object notation parser for every language
                      that is to be supported -- the purpose of the parser(s) would be to
                      convert the object notation format to and from native language
                      objects (NLO's) and variable data types...

                      So, in a JavaScript implementation -- the parser would support all of
                      the JavaScript core data types: OBject, Array, Function, String,
                      Date, Number, etc...

                      In a VBScript implementation: the parser would support Variant,
                      String, Number, Array, etc...

                      You get the idea -- basically -- I am proposing a "type-mapping"
                      mechanism and wrappers that support a language independent
                      implementation of object-notation


                      --- In json@yahoogroups.com, Lindsay <lindsay@...> wrote:
                      >
                      > Fang Yidong wrote:
                      > > I think why JSON be successful as a data-interchange
                      > > format is its simplicity and neutral nature for many
                      > > languages. Adding function definition just make JSON
                      > > stick to javascript. As to the datatype 'Date',you can
                      > > use number or string to represent it.
                      > >
                      >
                      > Agreed. Maybe define a std date format, there's a ISO one which
                      would do
                      > fine.
                      >
                      >
                      > --
                      > Lindsay
                      >
                    • Martin Cooper
                      ... Why the C format? Why not base it on the ISO standard, if we have to include dates in JSON? And if the above format actually defines what you have, then
                      Message 10 of 18 , May 26, 2006
                      • 0 Attachment
                        On 5/26/06, Greg Patnude <gpatnude@...> wrote:
                        >
                        > I have a JSON compatible date parser which converts a stringified
                        > version of a C-Type date (mm-dd-yyyy hh:mm:ss.nnnn [AM:PM]) into a
                        > JavaScript native Date object format...


                        Why the C format? Why not base it on the ISO standard, if we have to include
                        dates in JSON? And if the above format actually defines what you have, then
                        how would I specify the time zone? Or is it assumed to be UTC?

                        I will offer it to the JSON community to be included as a component of
                        > the json.js library -- provided under the JSON License (Doug's "Good
                        > NOT Evil" license)...
                        >
                        > Speaking of the "Good NOT Evil" license -- is anyone interested in
                        > formalizing that ? like the myriad licensing already available -- GPL,
                        > or LGPL, or BSD Licenses... we could call it the "GNOTE" license....


                        No, no, no! There are already dozens and dozens of open source licenses.
                        There is absolutely no good reason to invent another one. Do you have any
                        idea how much legal crap creating a new license creates for any company or
                        other organisation that actually wants to use the associated software? If
                        you want to formalise the license, please, please pick one of these:

                        http://www.opensource.org/licenses/

                        I'd suggest the Apache License 2.0, which pretty much says you can do
                        whatever you want with the software as long as you keep the original license
                        in place.

                        --
                        Martin Cooper


                        --- In json@yahoogroups.com, Lindsay <lindsay@...> wrote:
                        > >
                        > > Fang Yidong wrote:
                        > > > I think why JSON be successful as a data-interchange
                        > > > format is its simplicity and neutral nature for many
                        > > > languages. Adding function definition just make JSON
                        > > > stick to javascript. As to the datatype 'Date',you can
                        > > > use number or string to represent it.
                        > > >
                        > >
                        > > Agreed. Maybe define a std date format, there's a ISO one which
                        > would do
                        > > fine.
                        > >
                        > >
                        > > --
                        > > Lindsay
                        > >
                        >
                        >
                        >
                        >
                        >
                        >
                        >
                        >
                        > Yahoo! Groups Links
                        >
                        >
                        >
                        >
                        >
                        >
                        >
                        >


                        [Non-text portions of this message have been removed]
                      • Christopher Stumm
                        ... Maybe I m missing something, but why wouldn t one simply use the standard unix time? It does not rely on time-zones (which people seem to largely ignore on
                        Message 11 of 18 , May 26, 2006
                        • 0 Attachment
                          On 26 May, 2006, at 12:31, Martin Cooper wrote:

                          > On 5/26/06, Greg Patnude <gpatnude@...> wrote:
                          > >
                          > > I have a JSON compatible date parser which converts a stringified
                          > > version of a C-Type date (mm-dd-yyyy hh:mm:ss.nnnn [AM:PM]) into a
                          > > JavaScript native Date object format...
                          >
                          > Why the C format? Why not base it on the ISO standard, if we have to
                          > include
                          > dates in JSON? And if the above format actually defines what you
                          > have, then
                          > how would I specify the time zone? Or is it assumed to be UTC?

                          Maybe I'm missing something, but why wouldn't one simply use the
                          standard
                          unix time? It does not rely on time-zones (which people seem to largely
                          ignore
                          on the internet), and is likely supported already by most languages, JS
                          included.
                          In addition it can easily be sent around as a simple int.

                          -Christopher
                        • Dave Balmer
                          Greg, I ve given this a bit of thought too, but in the end this would only complicate matters exponentially. Making a simple data parser is one thing, but
                          Message 12 of 18 , May 26, 2006
                          • 0 Attachment
                            Greg,

                            I've given this a bit of thought too, but in the end this would only
                            complicate matters exponentially. Making a simple data parser is one
                            thing, but adding in a language parser (much less many language
                            parsers) on top of that just isn't practical.

                            Taking this "next logical step" would in fact narrow JSON's use as a
                            lightweight data exchange format, and limit adoption.

                            There's nothing which says you can't rig something (there are several
                            applications which abuse CDATA in XML to introduce in-line code, for
                            example), but I see no value in adding it to the specs.

                            Dave


                            On May 26, 2006, at 8:33 AM, Greg Patnude wrote:

                            > I think everyone is missing teh point I am trying to make --- I truly
                            > believe that "Object Notation" is the holy grail of data interchange.
                            > As a result, I would like to see object notation extended beyond just
                            > support for JavaScript (JSON) to every language --
                            >
                            > If we are truly talking about Object Notation -- then the parser(s)
                            > need to support all of the native object types for any given
                            > programming language -- If we are only talking about JavaScript
                            > Object Notation -- then I would expect the parser(s) to support all
                            > of the object / data types native to JavaScript.
                            >
                            > So -- if JSON is to TRULY represent the JavaScript Objects -- in
                            > addition to String, Number, Array, Object, true, false, and null
                            > objects -- the parser should also necessarily include
                            >
                            > • Date
                            > • Math
                            > • Function
                            > • RegExp
                            > and
                            > • Boolean objects...
                            >
                            > My desire is to see object notation become mainstream -- much more
                            > than JSON and bigger than XML even -- In order to accomplish that --
                            > we would really need an object notation parser for every language
                            > that is to be supported -- the purpose of the parser(s) would be to
                            > convert the object notation format to and from native language
                            > objects (NLO's) and variable data types...
                            >
                            > So, in a JavaScript implementation -- the parser would support all of
                            > the JavaScript core data types: OBject, Array, Function, String,
                            > Date, Number, etc...
                            >
                            > In a VBScript implementation: the parser would support Variant,
                            > String, Number, Array, etc...
                            >
                            > You get the idea -- basically -- I am proposing a "type-mapping"
                            > mechanism and wrappers that support a language independent
                            > implementation of object-notation
                            >
                            >
                            > --- In json@yahoogroups.com, Lindsay <lindsay@...> wrote:
                            > >
                            > > Fang Yidong wrote:
                            > > > I think why JSON be successful as a data-interchange
                            > > > format is its simplicity and neutral nature for many
                            > > > languages. Adding function definition just make JSON
                            > > > stick to javascript. As to the datatype 'Date',you can
                            > > > use number or string to represent it.
                            > > >
                            > >
                            > > Agreed. Maybe define a std date format, there's a ISO one which
                            > would do
                            > > fine.
                            > >
                            > >
                            > > --
                            > > Lindsay
                            > >
                            >
                            >

                            ---
                            "Mean people suck." -- unknown
                          • Greg Patnude
                            It is originally based on converting a date-time string from an ANSI SQL database into a JavaScript UTC time... The ANSI SQL datetime (timestamp) appeared to
                            Message 13 of 18 , May 26, 2006
                            • 0 Attachment
                              It is originally based on converting a date-time string from an ANSI
                              SQL database into a JavaScript UTC time... The ANSI SQL datetime
                              (timestamp) appeared to be "closest to" the JavaScript Date()
                              constructor at the time I developed the library --

                              var dt = new Date("mm-dd-yy hh:mm:ss.ms");


                              Since 99.999% of the dates / times I display in the UI come from the
                              RDBMS -- this also made a lot of sense at the time....

                              RE: Unix date / time -- not everyone is into Unix... many people
                              appear to be using PHP, Perl, and ASP... Personally -- if it were
                              100% Unix / C / Java / ANSI SQL types -- I would be a happy camper...
                              but... we gotta provide support for the greatest common
                              denominator... not the lowest common denominator...



                              --- In json@yahoogroups.com, Christopher Stumm <christopher@...>
                              wrote:
                              >
                              > On 26 May, 2006, at 12:31, Martin Cooper wrote:
                              >
                              > > On 5/26/06, Greg Patnude <gpatnude@...> wrote:
                              > > >
                              > > > I have a JSON compatible date parser which converts a
                              stringified
                              > > > version of a C-Type date (mm-dd-yyyy hh:mm:ss.nnnn [AM:PM])
                              into a
                              > > > JavaScript native Date object format...
                              > >
                              > > Why the C format? Why not base it on the ISO standard, if we
                              have to
                              > > include
                              > > dates in JSON? And if the above format actually defines what you
                              > > have, then
                              > > how would I specify the time zone? Or is it assumed to be UTC?
                              >
                              > Maybe I'm missing something, but why wouldn't one simply use the
                              > standard
                              > unix time? It does not rely on time-zones (which people seem to
                              largely
                              > ignore
                              > on the internet), and is likely supported already by most
                              languages, JS
                              > included.
                              > In addition it can easily be sent around as a simple int.
                              >
                              > -Christopher
                              >
                            • Fang Yidong
                              It s not necessary to add Date SPEC to JSON to make things work. JSON just give you the freedom to do whatever you want. I ve used JSON.simple to exchange
                              Message 14 of 18 , May 26, 2006
                              • 0 Attachment
                                It's not necessary to add Date SPEC to JSON to make
                                things work. JSON just give you the freedom to do
                                whatever you want.

                                I've used JSON.simple to exchange millions of records
                                contains date and time fields from Oracle to
                                Postgres,it works very well and just 2 or 3 lines
                                added to convert the date and time format between
                                Oracle and Postgres,without the Date SPEC.

                                So I think the core primitive datetype
                                String,True,False,Number and Null of JSON is enough.

                                --- Greg Patnude <gpatnude@...>:

                                > It is originally based on converting a date-time
                                > string from an ANSI
                                > SQL database into a JavaScript UTC time... The ANSI
                                > SQL datetime
                                > (timestamp) appeared to be "closest to" the
                                > JavaScript Date()
                                > constructor at the time I developed the library --
                                >
                                > var dt = new Date("mm-dd-yy hh:mm:ss.ms");
                                >
                                >
                                > Since 99.999% of the dates / times I display in the
                                > UI come from the
                                > RDBMS -- this also made a lot of sense at the
                                > time....
                                >
                                > RE: Unix date / time -- not everyone is into Unix...
                                > many people
                                > appear to be using PHP, Perl, and ASP... Personally
                                > -- if it were
                                > 100% Unix / C / Java / ANSI SQL types -- I would be
                                > a happy camper...
                                > but... we gotta provide support for the greatest
                                > common
                                > denominator... not the lowest common denominator...
                                >
                                >
                                >
                                > --- In json@yahoogroups.com, Christopher Stumm
                                > <christopher@...>
                                > wrote:
                                > >
                                > > On 26 May, 2006, at 12:31, Martin Cooper wrote:
                                > >
                                > > > On 5/26/06, Greg Patnude <gpatnude@...> wrote:
                                > > > >
                                > > > > I have a JSON compatible date parser which
                                > converts a
                                > stringified
                                > > > > version of a C-Type date (mm-dd-yyyy
                                > hh:mm:ss.nnnn [AM:PM])
                                > into a
                                > > > > JavaScript native Date object format...
                                > > >
                                > > > Why the C format? Why not base it on the ISO
                                > standard, if we
                                > have to
                                > > > include
                                > > > dates in JSON? And if the above format actually
                                > defines what you
                                > > > have, then
                                > > > how would I specify the time zone? Or is it
                                > assumed to be UTC?
                                > >
                                > > Maybe I'm missing something, but why wouldn't one
                                > simply use the
                                > > standard
                                > > unix time? It does not rely on time-zones (which
                                > people seem to
                                > largely
                                > > ignore
                                > > on the internet), and is likely supported already
                                > by most
                                > languages, JS
                                > > included.
                                > > In addition it can easily be sent around as a
                                > simple int.
                                > >
                                > > -Christopher
                                > >
                                >
                                >
                                >
                                >
                                >
                                >
                                > ------------------------ Yahoo! Groups Sponsor
                                > --------------------~-->
                                > Home is just a click away. Make Yahoo! your home
                                > page now.
                                >
                                http://us.click.yahoo.com/DHchtC/3FxNAA/yQLSAA/1U_rlB/TM
                                >
                                --------------------------------------------------------------------~->
                                >
                                >
                                >
                                > Yahoo! Groups Links
                                >
                                >
                                > json-unsubscribe@yahoogroups.com
                                >
                                >
                                >
                                >
                                >



                                ___________________________________________________________
                                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/
                              • Lindsay
                                ... Agreed. I d like to see a std for dates as they are very commonly used and nearly count as a scalar type :) But stick to the KISS principle. Feature bloat
                                Message 15 of 18 , May 28, 2006
                                • 0 Attachment
                                  Dave Balmer wrote:
                                  > Greg,
                                  >
                                  > I've given this a bit of thought too, but in the end this would only
                                  > complicate matters exponentially. Making a simple data parser is one
                                  > thing, but adding in a language parser (much less many language
                                  > parsers) on top of that just isn't practical.
                                  >

                                  Agreed. I'd like to see a std for dates as they are very commonly used
                                  and nearly count as a scalar type :) But stick to the KISS principle.
                                  Feature bloat his killed a lot of stds.


                                  --
                                  Lindsay
                                • Kevin Smith
                                  ... I completely agree. We were unable to use the GNOTE-licensed code in either our GPL application, or in our other app that s currently closed-source.
                                  Message 16 of 18 , Jun 3, 2006
                                  • 0 Attachment
                                    --- In json@yahoogroups.com, "Martin Cooper" wrote:
                                    >
                                    > On 5/26/06, Greg Patnude <gpatnude@...> wrote:
                                    > >
                                    > > Speaking of the "Good NOT Evil" license -- is anyone interested in
                                    > > formalizing that ? like the myriad licensing already available --
                                    > > GPL, or LGPL, or BSD Licenses... we could call it the "GNOTE"
                                    > > license....
                                    >
                                    >
                                    > No, no, no! There are already dozens and dozens of open source
                                    > licenses. There is absolutely no good reason to invent another one.
                                    > Do you have any idea how much legal crap creating a new license
                                    > creates for any company or other organisation that actually wants
                                    > to use the associated software?

                                    I completely agree. We were unable to use the GNOTE-licensed code in
                                    either our GPL application, or in our other app that's currently
                                    closed-source. Fortunately, we found a json implementation under a
                                    simpler license, so we didn't have to re-invent it from scratch.

                                    Personally, my big problem with the GNOTE license is: WHO decides what
                                    is evil? Some folks thing gays are evil, while others think that
                                    anti-gay behavior is evil. Some folks think Bin Laden is evil, but
                                    I'm pretty sure he thinks his enemies are the evil ones. Worse...what
                                    is "evil" can change over time, so I might be allowed to use the
                                    software today, but next year my use might be considered evil by the
                                    license holder.

                                    It's a great idea, but just doesn't work in practice. Basically, it
                                    will either discourage people from using the software, or will
                                    encourage people to ignore or violate the license, whether
                                    intentionally, or due to a disagreement over what is evil. Pretty much
                                    anyone who takes licenses seriously will not be able to use GNOTE
                                    software.

                                    > I'd suggest the Apache License 2.0, which pretty much says you can
                                    > do whatever you want with the software as long as you keep the
                                    > original license in place.

                                    Except that Apache License 2.0 code (arguably) can't be linked with
                                    GPL software, which is unfortunate. For widest compatibility with
                                    other licenses, I prefer the MIT-style license, which is even more
                                    liberal. The LGPL also tends to work well with proprietary and Free
                                    software.

                                    Kevin
                                  • Michal Migurski
                                    ... Except for time zones. ... As another poster commented, unix epoch is a great transmission format thanks to its explicit treatment of time zones. Every
                                    Message 17 of 18 , Jun 3, 2006
                                    • 0 Attachment
                                      > var dt = new Date("mm-dd-yy hh:mm:ss.ms");
                                      >
                                      >
                                      > Since 99.999% of the dates / times I display in the UI come from the
                                      > RDBMS -- this also made a lot of sense at the time....

                                      Except for time zones.

                                      > RE: Unix date / time -- not everyone is into Unix... many people
                                      > appear to be using PHP, Perl, and ASP... Personally -- if it were
                                      > 100% Unix / C / Java / ANSI SQL types -- I would be a happy camper...
                                      > but... we gotta provide support for the greatest common
                                      > denominator... not the lowest common denominator...

                                      As another poster commented, unix epoch is a great transmission
                                      format thanks to its explicit treatment of time zones. Every language
                                      I deal with in my work uses it (PHP, Python, ECMA-, Action-, and
                                      JavaScript in milliseconds), and I find it vastly preferable when
                                      moving data between web servers, DB servers, and client browsers that
                                      are in unknown locations. The Atom spec does something similar, by
                                      requiring dates to be expressed in UTC.

                                      I'm generally opposed to the inclusion of dates and functions into
                                      javascript, though. Python has four ways to describe dates, and PHP
                                      limits what can be done with functions as data. No sense in taking a
                                      simple, beautiful spec and complicating it just to satisfy a few edge
                                      cases.

                                      -mike.

                                      ----------------------------------------------------------------
                                      michal migurski- contact info and pgp key:
                                      sf/ca http://mike.teczno.com/contact.html
                                    • Martin Cooper
                                      ... ... No, that s not the case (and there is no arguably ;), at least from an ASF perspective. There is a policy in place at the Apache Software
                                      Message 18 of 18 , Jun 6, 2006
                                      • 0 Attachment
                                        On 6/3/06, Kevin Smith <yahoogroups@...> wrote:
                                        >
                                        > --- In json@yahoogroups.com, "Martin Cooper" wrote:


                                        <snip/>

                                        > I'd suggest the Apache License 2.0, which pretty much says you can
                                        > > do whatever you want with the software as long as you keep the
                                        > > original license in place.
                                        >
                                        > Except that Apache License 2.0 code (arguably) can't be linked with
                                        > GPL software, which is unfortunate.


                                        No, that's not the case (and there is no "arguably" ;), at least from an ASF
                                        perspective.

                                        There is a policy in place at the Apache Software Foundation (ASF) that
                                        states that ASF projects cannot have required dependencies on, or bundle,
                                        libraries licensed under the GPL or certain other licenses. What that means
                                        is that whenever you download ASF software, you can be absolutely sure that
                                        there are no "tricks up our sleeve" and you do not suddenly find yourself
                                        using additional software, with incompatible licenses, that you may not have
                                        expected.

                                        That is _completely_ different from what you, as a user of ASF software,
                                        choose to do with it. If you want to build an application that includes ASF
                                        and GPL software, that is absolutely fine with the ASF.

                                        For widest compatibility with
                                        > other licenses, I prefer the MIT-style license, which is even more
                                        > liberal. The LGPL also tends to work well with proprietary and Free
                                        > software.


                                        I'd agree that the MIT license is very flexible, but I'd suggest caution
                                        with the LGPL in a business environment. But this is getting way off-topic
                                        for this list...

                                        --
                                        Martin Cooper


                                        Kevin
                                        >
                                        >
                                        >
                                        >
                                        >
                                        >
                                        >
                                        >
                                        > Yahoo! Groups Links
                                        >
                                        >
                                        >
                                        >
                                        >
                                        >
                                        >
                                        >


                                        [Non-text portions of this message have been removed]
                                      Your message has been successfully submitted and would be delivered to recipients shortly.