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

JSoda

Expand Messages
  • Kyle Alan Hale
    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.
    Message 1 of 7 , Nov 14, 2007
    • 0 Attachment
      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.

      The details are located at http://jsoda.info/ <http://jsoda.info/> .
      The site also contains an MIT licensed script
      <http://jsoda.info/Object.toDOM#script> for parsing JSoda objects into
      their DOM counterparts. A simple (X)HTML to JSoda converter
      <http://jsoda.info/DOM+to+JSoda> is also provided.

      JSON-related comments or suggestions can be made in reply to this post.
      If you have any input that is not JSON related, such as problems with
      the site or JSoda improvement suggestions, please send an email to
      notalanguage at jsoda dot info.

      Looking forward to your feedback!


      [Non-text portions of this message have been removed]
    • 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 2 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 3 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 4 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 5 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 6 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 7 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.