I'd probably tackle that with a "strict" switch.  If strict=true then you throw an exception when unsupported content is recognized.  If strict=false then you silently ignore it (or maybe trace/debug level log it).<div>

  (*Chris*)<br><br><div class="gmail_quote">On Thu, May 10, 2012 at 8:43 AM, Rolf Lear <span dir="ltr"><<a href="mailto:jdom@tuis.net" target="_blank">jdom@tuis.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
So, searching the interweb, I see some discussion about JSON parsers... I<br>
don't see a SAX specific one, but there appear to be a number of StAX-like<br>
ones.... and we have StAX support directly now... ;-)<br>
<br>
Loading JSON in to JDOM is probably a lot simpler than the opposite<br>
though....<br>
<br>
I don't see how anything but a simple XML document could be output as a<br>
JSON 'output'.... the challenge would be how to deal with the 'unusual'<br>
XML-like concepts, rather than the easy stuff?<br>
<br>
Like, if your XML has a namespace, then what?<br>
<br>
Rolf<br>
<br>
On Thu, 10 May 2012 08:38:03 -0700, Chris Pratt <<a href="mailto:thechrispratt@gmail.com">thechrispratt@gmail.com</a>><br>
wrote:<br>
<div class="HOEnZb"><div class="h5">> Correct me if I'm wrong, but all that JDOM would need for that to work<br>
> would be a JSON SAX parser and a JSON Outputter.  Those could even be<br>
> packaged in a companion jar file for those that want the JDOM JSON<br>
support.<br>
>   (*Chris*)<br>
><br>
> On Thu, May 10, 2012 at 4:12 AM, Brad Cox <<a href="mailto:bcox@virtualschool.edu">bcox@virtualschool.edu</a>><br>
wrote:<br>
><br>
>> This is based on experience using both, not a deep analysis. More with<br>
>> XML<br>
>> than JSON to date. This work was in the context of building XACML<br>
>> compilers<br>
>> that use the W3C DOM tree as their expression tree. And inspired by<br>
>> recent<br>
>> W3C mailing list  discussions on standardizing a JSON syntax for XACML.<br>
>><br>
>> They seem to be  viewing JSON as I do, as a useful subset of XML, with<br>
>> lack of namespaces and attributes the main differences I can think of<br>
at<br>
>> the moment. Lack of attributes not a problem for XACML; it hardly uses<br>
>> them, just element values.<br>
>><br>
>> The notion is to add a JSON parser in front that builds the same XML<br>
>> (J)DOM tree you build now, plus a output path that converts the tree to<br>
>> JSON on demand. The proposed extension is appealing because it would<br>
>> allow<br>
>> the same XACML compiler to accept standard XACML and/or standard JSON,<br>
>> and<br>
>> to trivially convert between the representations.<br>
>><br>
>> On Wed, May 9, 2012 at 10:24 PM, Rolf Lear <<a href="mailto:jdom@tuis.net">jdom@tuis.net</a>> wrote:<br>
>><br>
>>> I would *love* to hear how you expect JDOM (XML-based) and JSON to<br>
'hang<br>
>>> out' in the same place .... ;-)<br>
>><br>
>> --<br>
>> Cell: <a href="tel:703-594-1883" value="+17035941883">703-594-1883</a><br>
>> Blog: <a href="http://bradjcox.blogspot.com" target="_blank">http://bradjcox.blogspot.com</a><br>
>> Web: <a href="http://virtualschool.edu" target="_blank">http://virtualschool.edu</a><br>
>> Manassas VA 20111<br>
>><br>
>><br>
>> _______________________________________________<br>
>> To control your jdom-interest membership:<br>
>> <a href="http://www.jdom.org/mailman/options/jdom-interest/youraddr@yourhost.com" target="_blank">http://www.jdom.org/mailman/options/jdom-interest/youraddr@yourhost.com</a><br>
>><br>
</div></div></blockquote></div><br></div>