Issues in the BadgerFish (XML to JSON Convention)

Currently BadgerFish [1] convention is used for translating an XML
document into a JSON [2] object, since this convention handles XML
namespaces better than the “mapped” convention. But IMHO there are some
issues. Consider the following XML element and corresponding JSON object.

<alice xmlns=”http://some-namespace” xmlns:charlie=”http://some-other-namespace“>

<bob>david</bob>
<charlie:edgar>frank</charlie:edgar>

</alice>

It becomes

{ “alice” :

  { “bob” :

      { “$” : “david” ,

         “@xmlns” :

           { “charlie” :”http:\/\/some-other-namespace” ,

              “$” : “http:\/\/some-namespace”}

       } ,

     “charlie:edgar” :

       { “$” : “frank” ,

          “@xmlns”

            {“charlie”:”http:\/\/some-other-namespace”,

              “$” :”http:\/\/some-namespace”}

       },

     “@xmlns” :

       { “charlie” :”http:\/\/some-other-namespace”,

          “$” : “http:\/\/some-namespace”}

   }

}

This is the 9th example in [1].

Two namespaces are declared in the XML element “alice” and it has two
child elements called “bob” and “edger” which is in a namespace whose
prefix is “charlie”.

In the corresponding JSON object, these two namespaces becomes the child
properties of the “@xmlns” property which in turn becomes a property of
the “alice”. But the “@xmlns” property is added after the “bob” and
“charlie:edgar” child properties. AFAIK this rule introduces a problem
when translating the JSON object back to XML. Lets say we have a
requirement to implement a StAX parser which reads JSON object and
outputs StAX events to build an XML object model. In this scenario StAX
parser has to store the JSON object in an intermediary data structure,
because namespaces and attributes(if any) of a corresponding XML element
are declared at the end of its child properties. This may reduce the
performance of the parser. The jettison parser [3] is implemented in
this way and it is used to provide JSON support for Axis2.

My suggestion is to reorder the child properties of a JSON object, so
that the namespaces and attributes can be specified at the beginning of
the child properties. Following example shows the reordered JSON Object.

{ “alice” :

  { “@xmlns” :

       { “charlie” : “http:\/\/some-other-namespace”,

          “$” : “http:\/\/some-namespace”},

    “bob” :

       { “@xmlns” :

          { “charlie” :”http:\/\/some-other-namespace” ,

              “$” : “http:\/\/some-namespace”},

          “$”: “david”

       } ,

    “charlie:edgar” :

     { “@xmlns” :

        { “charlie”:”http:\/\/some-other-namespace”,

           “$” :”http:\/\/some-namespace”},

        “$” : “frank

      }

  }

}

AFAIK this change will help to improve the performance of a StAX parser
which read JSON.

Your comments welcome!

[1] http://badgerfish.ning.com/

[2] http://www.json.org/

[3] http://jettison.codehaus.org/

Podcast on E4X Implementation in Rhino using Apache Axiom

In this podcast you can find some information about using Apache Axiom/Java to implement E4X in Rhino. And also it explains how this helps to improve performance of Javascript Web services in Apache Axis2/Java.

E4X Implementation in Rhino using Apache Axiom

Axiom, implementing E4x specification in Rhino

Rhino is an open source java implementation of the core JavaScript language. It can be embeded into java applications for scripting purposes. E4X (ECMAScript for XML) is a language extention for JavaScript which supports XML processing.

AXIOM stands for AXis Object Model (also known as OM – Object Model) and refers to the XML infoset model that was initially developed for Apache Axis2. XML Infoset refers to the information included inside the XML and for programmatical manipulation it is convenient to have a representation of this XML infoset in a language specific manner. For an object oriented language the obvious choice is a model made up of objects. DOM and JDOM are two such XML models. OM is conceptually similar to such an XML model by its external behavior but deep down it is very much different.

—Axiom home page

E4X implementation using axiom is now available at wso2 site. You can use following link can be used to checkout the source code.

svn https://wso2.org/repos/wso2/wsf/javascript/rhino/

fisheye http://wso2.org/fisheye/viewrep/svn/wsf/javascript/rhino

Once source code is downloaded you can rebuild the rhino with E4X implementation (Axiom). Instructions can be found in Readme.txt file. If you encounter any problem, bug or any thing please inform us.