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

JsonML

Expand Messages
  • Stephen M. McKamey
    Those interested in JSoda should also check out JsonML. JsonML is a more compact representation and is fast for converting any XML to JSON. Example client
    Message 1 of 7 , Nov 14, 2007
    • 0 Attachment
      Those interested in JSoda should also check out JsonML. JsonML is a
      more compact representation and is fast for converting any XML to JSON.

      Example client scripts and XSLT are available at: http://jsonml.org

      IBM developerWorks wrote an excellent tutorial:
      http://www.ibm.com/developerworks/library/x-jsonml/

      Coming soon is an Ajax framework which has native JsonML support for
      ASP.NET: http://jsonfx.net/Architecture/

      --- In json@yahoogroups.com, "Kyle Alan Hale" <kylealanhale@...> wrote:
      >
      > In my search for a convenient way to represent XHTML DOM elements, I
      > assembled some ideas of how to apply the native JavaScript objects to
      > the W3C DOM objects. I call this assembly of ideas JSoda.
    • Kyle Alan Hale
      Indeed, JSoda and JsonML serve much the same purpose, but with slightly different styles and goals. ... This is probably the best reason to choose Stephen s
      Message 2 of 7 , Nov 14, 2007
      • 0 Attachment
        Indeed, JSoda and JsonML serve much the same purpose, but with
        slightly different styles and goals.

        > JsonML is a more compact representation

        This is probably the best reason to choose Stephen's JsonML over
        JSoda. A JSoda object is much more verbose by design, which has some
        readability and usability advantages over JsonML.. but it also takes
        up more space/bandwidth. There are several other reasons
        <http://jsoda.info/JSoda+is#an+answer+to+jsonml> why I formulated
        JSoda, rather than just using JsonML, but if those reasons aren't
        issues for you, JsonML will save you some bandwidth.
      • Tatu Saloranta
        ... I may be bit slow, but I am not sure I understand why you would want to wrap DOM within JSON? Why not deal with xml via DOM as is? And when transferring,
        Message 3 of 7 , Nov 14, 2007
        • 0 Attachment
          On Nov 14, 2007 12:01 AM, Kyle Alan Hale <kylealanhale@...> wrote:
          >
          > In my search for a convenient way to represent XHTML DOM elements, I
          > assembled some ideas of how to apply the native JavaScript objects to
          > the W3C DOM objects. I call this assembly of ideas JSoda.
          >
          > JSoda is JSON compliant <http://jsoda.info/JSoda+and+JSON> , so that a
          > DOM element represented as a JSoda object can be stored or transmitted
          > as JSON and utilize existing JSON solutions.

          I may be bit slow, but I am not sure I understand why you would want
          to wrap DOM within JSON?
          Why not deal with xml via DOM as is? And when transferring, let
          efficient xml generators/parsers take care of marshalling aspects?

          I do understand the interoperability aspects sometimes require one to
          use mappings to make things work (albeit inefficiently or awkwardly),
          but are there some other benefits?

          -+ Tatu +-
        • Kyle Alan Hale
          ... The DOM element objects themselves aren t being wrapped in JSON. In fact, JSoda isn t JSON at all, it s just nested JavaScript objects. Each object type
          Message 4 of 7 , Nov 14, 2007
          • 0 Attachment
            > I may be bit slow, but I am not sure I understand why you would want
            > to wrap DOM within JSON?
            > Why not deal with xml via DOM as is? And when transferring, let
            > efficient xml generators/parsers take care of marshalling aspects?
            >
            > I do understand the interoperability aspects sometimes require one to
            > use mappings to make things work (albeit inefficiently or awkwardly),
            > but are there some other benefits?
            >
            > -+ Tatu +-
            >

            The DOM element objects themselves aren't being wrapped in JSON. In
            fact, JSoda isn't JSON at all, it's just nested JavaScript objects.
            Each object type represents a different thing:

            Object object -> DOM element
            Array object -> DOM document fragment
            String object -> DOM text node

            However, it is JSON compliant, meaning that you can conveniently store
            or transmit representations of DOM via, say, JSON RPC, or the proposed
            JSONRequest, or any other method of transmitting textual information.
            So, if you're using JSON anyway to transmit data, a JSoda object
            could be embedded within the JSON text and not cause any problems with
            JSON parsers... and not need an additional XML parser. In my case,
            I'll be using it to transmit XHTML-based rich-text.. and I didn't want
            to use a full fledged xml solution. I may change my mind about that
            as the project that I'm working on develops, but for now this is perfect.

            I also use JSoda objects to build DOM elements, using the script
            available on the site. Sure, I could do everything in XHTML and
            innerHTML it into my doc, but I'd rather be as ready for the future as
            possible by implementing a wrapper around standards-based DOM methods.
            Or, I could use XML and parse it, but the parsing overhead of a
            native JavaScript object based solution is almost nonexistent,
            compared to the intrinsically bulky XML parsers out there.

            ha.. I didn't expect anyone to ask "Why not just use XML?" in the JSON
            group. If I were intending for this to be a markup language in
            itself, then, you're right, XML would be more appropriate. But JSoda
            is just representing one language (XHTML) in terms of another
            (JavaScript). I like being able to think of DOM nodes as JavaScript
            objects when working on JavaScript/AJAX based applications, but I
            don't like the tedium of using the DOM functions on their own. JSoda
            meets both needs with a syntax that is analogous to DOM objects, but a
            hell of a lot easier to build.
          • Tatu Saloranta
            ... Ah ok. So it s more about javascript objects, not so much about json per se? If so, it is also related to methods like Badgerfish, which likewise allows
            Message 5 of 7 , Nov 14, 2007
            • 0 Attachment
              On Nov 14, 2007 12:41 PM, Kyle Alan Hale <kylealanhale@...> wrote:
              > > I may be bit slow, but I am not sure I understand why you would want
              > > to wrap DOM within JSON?
              > > Why not deal with xml via DOM as is? And when transferring, let
              > > efficient xml generators/parsers take care of marshalling aspects?
              > >
              > > I do understand the interoperability aspects sometimes require one to
              > > use mappings to make things work (albeit inefficiently or awkwardly),
              > > but are there some other benefits?
              >
              > The DOM element objects themselves aren't being wrapped in JSON. In
              > fact, JSoda isn't JSON at all, it's just nested JavaScript objects.
              > Each object type represents a different thing:
              >
              > Object object -> DOM element
              > Array object -> DOM document fragment
              > String object -> DOM text node

              Ah ok. So it's more about javascript objects, not so much about json per se?
              If so, it is also related to methods like Badgerfish, which likewise
              allows dealing with xml data by converting it to a more palatable
              structure. :-)

              Thanks!

              -+ Tatu +-
            • Kyle Alan Hale
              ... per se? ... Yes, much like Badgerfish, just not as comprehensive.. but a bit easier to read. Badgerfish is ideal for representing any XML-based data.
              Message 6 of 7 , Nov 14, 2007
              • 0 Attachment
                > Ah ok. So it's more about javascript objects, not so much about json
                per se?
                > If so, it is also related to methods like Badgerfish, which likewise
                > allows dealing with xml data by converting it to a more palatable
                > structure. :-)
                >
                > Thanks!
                >
                > -+ Tatu +-
                >

                Yes, much like Badgerfish, just not as comprehensive.. but a bit
                easier to read. Badgerfish is ideal for representing any XML-based
                data. JSoda is a simple alternative for storing XHTML (by utilizing
                my toJSoda() function), and for quickly building DOM nodes with
                toDOM(). The format of JSoda, though, has the same aim as Badgerfish:
                JSON compatibility.
              Your message has been successfully submitted and would be delivered to recipients shortly.