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

Re: JsonML

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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.