https://github.com/henrikingo/xml2json

Translate any XML document to corresponding JSON or vice versa
https://github.com/henrikingo/xml2json

Last synced: 13 days ago
JSON representation

Translate any XML document to corresponding JSON or vice versa

• Host: GitHub
• URL: https://github.com/henrikingo/xml2json
• Owner: henrikingo
• License: lgpl-2.1
• Created: 2013-11-25T08:47:57.000Z (almost 11 years ago)
• Default Branch: master
• Last Pushed: 2014-01-30T13:42:47.000Z (almost 11 years ago)
• Last Synced: 2024-08-01T22:53:58.240Z (3 months ago)
• Language: JavaScript
• Size: 164 KB
• Stars: 52
• Watchers: 8
• Forks: 21
• Open Issues: 1
• Metadata Files:
  • Readme: README.md
  • License: LICENSE

Awesome Lists containing this project

README

        
xml2json

========

Translate any XML document to corresponding JSON or vice versa

HISTORY

-------

Most of this code was written by Stefan Gössner and published at:

http://goessner.net/download/prj/jsonxml/

You can read a description of what the library originally did at:

http://www.xml.com/pub/a/2006/05/31/converting-between-xml-and-json.html

I did 2 major changes to the original code:

1. XML attributes are translated as siblings, rather than children, to their

   corresponding "parent" element in JSON. This produces more **deterministic**

   translation.

2. Use JSON list structure more frequently. This ensures **lossless** translation

   in more cases than the original and also is capable of handling some "mixed"

   cases that the original would just pass along as untranslated XML.

   

Details of these changes are explained below. For anything else, read the xml.com

article linked above.

USAGE

-----

The xml2json library works both in a browser and node.js. (In node.js, it depends

on libxml plugin.)

For example usage in a browser, see xmljson_demo.html

For example usage in node.js, see http://github.com/henrikingo/node-xml2json

DETAILS

-------

An explanation of changes wrt the original library by Stefan Grössner follows:

Consider the following 2 translations in the original library:

    text

    {

      "e":"text"

    }

vs

    text

    {

      "e":{

        "@name":"value",

        "#text":"text"

      }

    }

=> the path to "text" changes depending on whether the element has attributes 

   present or not. Very bad if there could be optional attributes, or attributes

   added over time.

For more examples, see http://goessner.net/download/prj/jsonxml/xmljson_test.html

Solution is to lift out attributes to be on the same level as the element itself:

    text

    {

      e@name:"value",

      e:"text"

    }

Note that for empty elements, we still explicitly print null for clarity:

    

    {

      e@name:"value",

      e:null

    }

The other fix is to use lists to more closely resemble original xml structure

in case of multiple children with same node name.

Original:

     text text 

    {

      "e":{"a":[

          "text",

          "text"

        ]}

    }

Me:

     text text 

    {

      e:[

            {

          a:"text"

        },

            {

          a:"text"

        }

      ]

    }

This approach allows to handle "mixed content" elements better, where original

gives up:

    xy

    {

      "a":"xy"

    }

Me:

    xy

    {

      a:[

        "x",

            {

          c:null

        },

        "y"

      ]

    }

(Same fix also supports CDATA sections, should there be any.)

TODO

----

All types are strings. Preferably types would be defined in xml schema, and 

the xml parser would return node values in correct javascript type. If this is

not the case, we can emulate something by converting strings to other types in 

a separate function to be done later (ie xml schema hard coded into a js function)

For database searches, having the correct types will help.

Not yet supported in json->xml:

Multi-dimensional arrays. What is the correct xml presentation for this?

{ e : [["a", "b"], ["c", "d"]] }