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

New JSON superset -- RSON

Expand Messages
  • Patrick
    I am developing a superset of JSON called RSON (Readable Serial Object Notation), at http://code.google.com/p/rson/ (Not that JSON isn t eminently readable,
    Message 1 of 4 , Mar 12, 2010
    • 0 Attachment
      I am developing a superset of JSON called RSON (Readable Serial Object Notation), at http://code.google.com/p/rson/

      (Not that JSON isn't eminently readable, but when deeply nested, it suffers from the same sorts of syntax issues that keep lisp from being a commercial mainstream success.)

      RSON is for things like configuration files, where non-technical
      humans are expected to maintain the data, and it needs to be easily
      editable and diff-able. But RSON is also a strict superset of JSON,
      so that, for example, you could just dump out a configuration using
      JSON and then reload it later.

      (As an aside, I tried YAML, but didn't like it for several reasons. IMHO, the best design decision the YAML folks made was to try to bring their spec into compliance with JSON, so this is one decision I have wholeheartedly embraced, and RSON should always parse valid UTF-8 encoded JSON.)

      Currently, I have a poor excuse for the beginnings of a manual, and a pretty passable Python decoder. The decoder has lots of replaceable parts (through subclassing or calling the decoder with user-defined functions), and if I replace a few parts to disallow some things which are not valid JSON, and to allow 'Infinity' and 'Nan' to be floats, it passes the Python simplejson regression tests. The decoder speed is on a par with the Python 2.6 json module, but slower than simplejson, and much slower than simplejson with the C speedups (but an order of magnitude faster than the pure Python PyYaml decoder).

      To get an idea of the flavor of RSON, you can look at the (hastily converted, previously pure JSON) rst2pdf default stylesheet:

      http://code.google.com/p/rst2pdf/source/browse/trunk/rst2pdf/styles/styles.styles

      Comments and criticism welcome.

      Thanks and best regards,
      Patrick Maupin
    • Gregg Irwin
      Hi Patrick, P I am developing a superset of JSON called RSON (Readable Serial P Object Notation), at http://code.google.com/p/rson/ I know there was a pyson
      Message 2 of 4 , Mar 16, 2010
      • 0 Attachment
        Hi Patrick,

        P> I am developing a superset of JSON called RSON (Readable Serial
        P> Object Notation), at http://code.google.com/p/rson/

        I know there was a pyson project, but if it's dead, maybe you could
        use the name. I think PySON is a much better fit for your notation.
        It's not that your notation isn't readable--it's very much like REBOL
        in many ways--but the indent option gives it a very Pythonic feel.

        I agree on YAML. It seemed great at first glance, but I found it was
        more complex than I cared for once I went to write a parser for it.
        The goals are different for YAML, so it's not a blanket criticism.

        --Gregg
      • Patrick Maupin
        ... I agree that it came out that way. And I do code in Python, but frankly, I started using YAML, and then changed it until I got something I like (which
        Message 3 of 4 , Mar 16, 2010
        • 0 Attachment
          On Tue, Mar 16, 2010 at 2:46 AM, Gregg Irwin <gregg.irwin@...> wrote:
          > I know there was a pyson project, but if it's dead, maybe you could
          > use the name. I think PySON is a much better fit for your notation.
          > It's not that your notation isn't readable--it's very much like REBOL
          > in many ways--but the indent option gives it a very Pythonic feel.

          I agree that it came out that way. And I do code in Python, but
          frankly, I started using YAML, and then changed it until I got
          something I like (which might be because I code in Python, but who
          knows?). While I feel the syntax does mesh well with Python, I would
          prefer not to give the impression that it is restricted to Python. It
          would be easy to create a parser for this in almost any language.
          Besides, I would like for RSON to "set fire to configuration files all
          over the planet." (Although helping out in the goal of World
          Domination would be good too..)

          > I agree on YAML. It seemed great at first glance, but I found it was
          > more complex than I cared for once I went to write a parser for it.
          > The goals are different for YAML, so it's not a blanket criticism.

          Yes, a YAML parser is very much not a thing you can knock out in an
          afternoon, and while YAML is very powerful, explaining its more
          powerful features to non-technical people can be quite a challenge.

          Regards,
          Pat
        • Tatu Saloranta
          ... Yes. YAML is a good candidate to explain concept of Too Much of Everything (or, American Ice Cream syndrome :-)). It is unfortunately quite common to
          Message 4 of 4 , Mar 16, 2010
          • 0 Attachment
            On Tue, Mar 16, 2010 at 8:21 AM, Patrick Maupin <pmaupin@...> wrote:
            > On Tue, Mar 16, 2010 at 2:46 AM, Gregg Irwin <gregg.irwin@...> wrote:
            >> I know there was a pyson project, but if it's dead, maybe you could
            >> use the name. I think PySON is a much better fit for your notation.
            >> It's not that your notation isn't readable--it's very much like REBOL
            >> in many ways--but the indent option gives it a very Pythonic feel.
            >
            > I agree that it came out that way.  And I do code in Python, but
            > frankly, I started using YAML, and then changed it until I got
            > something I like (which might be because I code in Python, but who
            > knows?).  While I feel the syntax does mesh well with Python, I would
            > prefer not to give the impression that it is restricted to Python.  It
            > would be easy to create a parser for this in almost any language.
            > Besides, I would like for RSON to "set fire to configuration files all
            > over the planet."  (Although helping out in the goal of World
            > Domination would be good too..)
            >
            >> I agree on YAML. It seemed great at first glance, but I found it was
            >> more complex than I cared for once I went to write a parser for it.
            >> The goals are different for YAML, so it's not a blanket criticism.
            >
            > Yes, a YAML parser is very much not a thing you can knock out in an
            > afternoon, and while YAML is very powerful, explaining its more
            > powerful features to non-technical people can be quite a challenge.

            Yes. YAML is a good candidate to explain concept of "Too Much of
            Everything" (or, "American Ice Cream syndrome" :-)).

            It is unfortunately quite common to get carried away by desire add
            just 'one more feature', instead of carefully considering how much is
            enough, what is really needed, and where is 80/20 point.
            Not everything has to be done at the very lowest level, syntax of data
            notation; oftentimes optimal place is somewhat higher in processing
            stack. It's just necessary to have basic hooks so other layers can
            tackle other things, such as reference resolution, inclusions, type
            information handling.
            And at some point increasing theoretical expressive power comes at
            expense when users can't figure out how to use the thing. ;-/

            For what it's worth, I think JSON is slightly underpowered, personally
            (lacking comments is an absolute killer, but there are couple of other
            small but important omissions), but it is quite close to optimal. So I
            understand why defining supersets has some appeal, especially for
            configuration definitions.

            -+ Tatu +-
          Your message has been successfully submitted and would be delivered to recipients shortly.