mike at saxonica.com
Thu May 10 10:02:34 PDT 2012
There's been a lot of work on JSON-to-XML and XML-to-JSON
transformations. There is no single answer that works well in all cases.
There is a tension between being lossless and producing something that
is usable. An XML-to-JSON transformation that can handle mixed content
may produce indigestible output for simple data-oriented XML.
I don't think there is any good architectural reason to regard XML-JSON
transformation as being part of the same component in the architecture
as an XML tree model. Just because it needs doing doesn't mean it needs
doing in JDOM. To me it's best kept separate.
On 10/05/2012 16:43, Rolf Lear wrote:
> So, searching the interweb, I see some discussion about JSON parsers... I
> don't see a SAX specific one, but there appear to be a number of StAX-like
> ones.... and we have StAX support directly now... ;-)
> Loading JSON in to JDOM is probably a lot simpler than the opposite
> I don't see how anything but a simple XML document could be output as a
> JSON 'output'.... the challenge would be how to deal with the 'unusual'
> XML-like concepts, rather than the easy stuff?
> Like, if your XML has a namespace, then what?
> On Thu, 10 May 2012 08:38:03 -0700, Chris Pratt<thechrispratt at gmail.com>
>> Correct me if I'm wrong, but all that JDOM would need for that to work
>> would be a JSON SAX parser and a JSON Outputter. Those could even be
>> packaged in a companion jar file for those that want the JDOM JSON
>> On Thu, May 10, 2012 at 4:12 AM, Brad Cox<bcox at virtualschool.edu>
>>> This is based on experience using both, not a deep analysis. More with
>>> than JSON to date. This work was in the context of building XACML
>>> that use the W3C DOM tree as their expression tree. And inspired by
>>> W3C mailing list discussions on standardizing a JSON syntax for XACML.
>>> They seem to be viewing JSON as I do, as a useful subset of XML, with
>>> lack of namespaces and attributes the main differences I can think of
>>> the moment. Lack of attributes not a problem for XACML; it hardly uses
>>> them, just element values.
>>> The notion is to add a JSON parser in front that builds the same XML
>>> (J)DOM tree you build now, plus a output path that converts the tree to
>>> JSON on demand. The proposed extension is appealing because it would
>>> the same XACML compiler to accept standard XACML and/or standard JSON,
>>> to trivially convert between the representations.
>>> On Wed, May 9, 2012 at 10:24 PM, Rolf Lear<jdom at tuis.net> wrote:
>>>> I would *love* to hear how you expect JDOM (XML-based) and JSON to
>>>> out' in the same place .... ;-)
>>> Cell: 703-594-1883
>>> Blog: http://bradjcox.blogspot.com
>>> Web: http://virtualschool.edu
>>> Manassas VA 20111
>>> To control your jdom-interest membership:
> To control your jdom-interest membership:
More information about the jdom-interest