The following links appear to have died:

<a href="http://blog.beef.de/2008/01/04/tinyjson/">TinyJSON</a>.

<a
href="http://www.tom.sfc.keio.ac.jp/%7Esakai/d/data/200604/JSON.hs">JSON.hs</a>.

<a href="http://vraptor.org/ajax.html">VRaptor</a>.

They have been removed from the JSON.org page. If you own one of them, please
send me the update so that I can reinstate it.


The following links are failing:

<a href="http://www.erlang-projects.org/Public/news/ejson/view">ejson</a>.

<a
href="http://blakeseely.com/blog/archives/2006/03/29/bsjsonadditions-12/">BSJSON\
Additions</a>.

If they do not come back soon, they will be removed.

Jansson v1.0.3 out! This is a bugfix release in the 1.0 release series.

Changes since v1.0.2:

* Check for integer and real overflows and underflows in decoder
* Use the Python json module for tests, or simplejson if the json
   module is not found

Download source: http://www.digip.org/jansson/releases/jansson-1.0.3.tar.bz2
View documentation: http://www.digip.org/jansson/doc/1.0/
Changelog: http://www.digip.org/jansson/releases/CHANGES


What is Jansson?

Jansson is a C library for encoding, decoding and manipulating JSON
data. It features:

* Simple and intuitive API and data model
* Comprehensive documentation
* No dependencies on other libraries
* Full Unicode support (UTF-8)
* Extensive test suite

Jansson is licensed under the MIT license.

For more details, see http://www.digip.org/jansson/.


Petri Lehtinen
petri@...

Hello,

Is there a standard way to represent the information in following XML
snippet
as JSON output.

<attributes>
   <attribute a1="v1">value1</attribute>
   <attribute a2="v2">value2</attribute>
</attributes>

Is there an online tool that would generate this conversion?

Appreciate your response.

~S


[Non-text portions of this message have been removed]

On Mon, Sep 14, 2009 at 9:17 AM, Shalab Goel <goel.shalab@...> wrote:
> Hello,
>
> Is there a standard way to represent the information in following XML snippet
> as JSON output.
>
> <attributes>
>  <attribute a1="v1">value1</attribute>
>  <attribute a2="v2">value2</attribute>
> </attributes>
>
> Is there an online tool that would generate this conversion?

It depends on what you'd expect to get out of it, but I think the
answer is no: there is nothing obvious and standard.
It really depends on meaning of data above.

<rant>
personally I think it is better to convert from original data
(objects, relational data) into structurally distinct data formats
(xml and json have fundamentally differen data models, hierachic vs
struct/frame/object model... but I digress). And as such, if possible,
it's better to figure out meaning of data and then produce "native"
xml and json, without trying to convert from json to xml or vice
versa. Latter is more difficult, and data in one (... or both) of
formats will end up looking funny and somewhat unreadable
</rant>

Anyway: instead of "the" standard, there however multiple competing
standard proposals (called "mapping conventions") that do allow
converting any XML content into well-formed (if bit odd-looking and
alien-feeling :) ) JSON.
One such convention is Badgerfish (see, for example
[http://sujitpal.blogspot.com/2007/10/converting-xml-to-badgerfish-json.html]);
and there are multiple others that claim to produce natural JSON.

-+ Tatu +-

”instead of "the" standard, there however multiple competing standard proposals
[…] that do allow converting any XML content into well-formed […] JSON.”

I don’t think that’s true, and it is certainly not true for Badgerfish. All of
the mapping conventions I know of fail to correctly represent “document type”
XML such as:

<asdf>
<a>…</a>
<a>…</a>
<b>…</b>
<a>…</a>
</asdf>

This speaks to the heart of the difference between XML and JSON. In order to
represent something like this in JSON, the contents of the “asdf” element would
have to be in an array. This is not an impossible solution, but using that
convention throughout makes for very ugly JSON.

/Jakob

Fra: json@yahoogroups.com [mailto:json@yahoogroups.com] Pĺ vegne af Tatu
Saloranta
Sendt: 14. september 2009 18:51
Til: json@yahoogroups.com
Emne: Re: [json] JSON representation for XML snippet


On Mon, Sep 14, 2009 at 9:17 AM, Shalab Goel <goel.shalab@...> wrote:
> Hello,
>
> Is there a standard way to represent the information in following XML snippet
> as JSON output.
>
> <attributes>
>  <attribute a1="v1">value1</attribute>
>  <attribute a2="v2">value2</attribute>
> </attributes>
>
> Is there an online tool that would generate this conversion?

It depends on what you'd expect to get out of it, but I think the
answer is no: there is nothing obvious and standard.
It really depends on meaning of data above.

<rant>
personally I think it is better to convert from original data
(objects, relational data) into structurally distinct data formats
(xml and json have fundamentally differen data models, hierachic vs
struct/frame/object model... but I digress). And as such, if possible,
it's better to figure out meaning of data and then produce "native"
xml and json, without trying to convert from json to xml or vice
versa. Latter is more difficult, and data in one (... or both) of
formats will end up looking funny and somewhat unreadable
</rant>

Anyway: instead of "the" standard, there however multiple competing
standard proposals (called "mapping conventions") that do allow
converting any XML content into well-formed (if bit odd-looking and
alien-feeling :) ) JSON.
One such convention is Badgerfish (see, for example
[http://sujitpal.blogspot.com/2007/10/converting-xml-to-badgerfish-json.html]);
and there are multiple others that claim to produce natural JSON.

-+ Tatu +-

[Non-text portions of this message have been removed]

To do the XML to JSON conversion I use our XSLT (which can also go the other way
as well)

<xsl:output method=’json’/>
https://www.p6r.com/articles/2008/11/02/xsloutput-methodjson/




Mark Joseph, Ph.D.
President
P6R, Inc
408-205-0361
mark@...
Skype: markjoseph_sc
   _____

From: Jakob Kruse [mailto:kruse@...]
To: json@yahoogroups.com
Sent: Mon, 14 Sep 2009 10:38:56 -0700
Subject: SV: [json] JSON representation for XML snippet






”instead of "the" standard, there however multiple competing standard
proposals […] that do allow converting any XML content into well-formed […]
JSON.”

   I don’t think that’s true, and it is certainly not true for Badgerfish.
All of the mapping conventions I know of fail to correctly represent “document
type” XML such as:

   <asdf>
   <a>…</a>
   <a>…</a>
   <b>…</b>
   <a>…</a>
   </asdf>

   This speaks to the heart of the difference between XML and JSON. In order to
represent something like this in JSON, the contents of the “asdf” element
would have to be in an array. This is not an impossible solution, but using that
convention throughout makes for very ugly JSON.

   /Jakob

   Fra: json@yahoogroups.com [mailto:json@yahoogroups.com] PĂĄ vegne af Tatu
Saloranta
   Sendt: 14. september 2009 18:51
   Til: json@yahoogroups.com
   Emne: Re: [json] JSON representation for XML snippet


   On Mon, Sep 14, 2009 at 9:17 AM, Shalab Goel <goel.shalab@...> wrote:
   > Hello,
   >
   > Is there a standard way to represent the information in following XML
snippet
   > as JSON output.
   >
   > <attributes>
   >  <attribute a1="v1">value1</attribute>
   >  <attribute a2="v2">value2</attribute>
   > </attributes>
   >
   > Is there an online tool that would generate this conversion?

   It depends on what you'd expect to get out of it, but I think the
   answer is no: there is nothing obvious and standard.
   It really depends on meaning of data above.

   <rant>
   personally I think it is better to convert from original data
   (objects, relational data) into structurally distinct data formats
   (xml and json have fundamentally differen data models, hierachic vs
   struct/frame/object model... but I digress). And as such, if possible,
   it's better to figure out meaning of data and then produce "native"
   xml and json, without trying to convert from json to xml or vice
   versa. Latter is more difficult, and data in one (... or both) of
   formats will end up looking funny and somewhat unreadable
   </rant>

   Anyway: instead of "the" standard, there however multiple competing
   standard proposals (called "mapping conventions") that do allow
   converting any XML content into well-formed (if bit odd-looking and
   alien-feeling :) ) JSON.
   One such convention is Badgerfish (see, for example
  
[http://sujitpal.blogspot.com/2007/10/converting-xml-to-badgerfish-json.html]);
   and there are multiple others that claim to produce natural JSON.

   -+ Tatu +-

   [Non-text portions of this message have been removed]




[Non-text portions of this message have been removed]

On Mon, Sep 14, 2009 at 10:38 AM, Jakob Kruse <kruse@...> wrote:
> ”instead of "the" standard, there however multiple competing standard
proposals […] that do allow converting any XML content into well-formed […]
JSON.”
>
> I don’t think that’s true, and it is certainly not true for Badgerfish. All of
the mapping conventions I know of fail to correctly represent “document type”
XML such as:
>
> <asdf>
> <a>…</a>
> <a>…</a>
> <b>…</b>
> <a>…</a>
> </asdf>
>
> This speaks to the heart of the difference between XML and JSON. In order to
represent something like this in JSON, the contents of the “asdf” element would
have to be in an array. This is not an impossible solution, but using that
convention throughout makes for very ugly JSON.

Perhaps I should have worded it as "try to allow...". And that they do
it with varying level of success -- as you point out, badgerfish fails
for that case, and others in variety of other ways. Plus even if all
nuances of XML Infoset were covered (from namespaces to processing
instructions etc), resulting JSON does look ugly. So yes, this is part
of the whole impedance part, JSON <> XML.

-+ Tatu +-

In taht way you are loosing data type.
If interested, this is not that standard but kinda an easy spec to follow
(plus a script)
http://webreflection.blogspot.com/2008/07/jxon-lossless-javascript-to-xml-object\
.html

Hope will help somehow


On Mon, Sep 14, 2009 at 5:17 PM, Shalab Goel <goel.shalab@...> wrote:

>
>
> Hello,
>
> Is there a standard way to represent the information in following XML
> snippet
> as JSON output.
>
> <attributes>
> <attribute a1="v1">value1</attribute>
> <attribute a2="v2">value2</attribute>
> </attributes>
>
> Is there an online tool that would generate this conversion?
>
> Appreciate your response.
>
> ~S
>
> [Non-text portions of this message have been removed]
>
>
>


[Non-text portions of this message have been removed]

er, me too in the precedent link there is a demo:
http://www.3site.eu/JXON/

I guess my spec is simple:

<element>
Boolean = <boolean>true|false</boolean>
Date = <date>YYYY-MM-DDTHH:II:SS</date>
Null = <null/>
Number = <number>N|Z</number>
String = <string>string content</string>
Array = <array><element-list/></array>
Object = <object><element-list key="element-key"/></object>

<element-list> = a list of precedent element

While the code to transform to and from XML to JSON and vice-versa is here:
http://www.devpro.it/code/193.html

A bit old, I need to rewrite some stuff, but maybe examples and the
code itself could be a hint.

Regards




On Mon, Sep 14, 2009 at 7:17 PM, Mark Joseph <mark@...> wrote:

>
>
> To do the XML to JSON conversion I use our XSLT (which can also go the
> other way as well)
>
> <xsl:output method=’json’/>
> https://www.p6r.com/articles/2008/11/02/xsloutput-methodjson/
>
> Mark Joseph, Ph.D.
> President
> P6R, Inc
> 408-205-0361
> mark@... <mark%40p6r.com>
> Skype: markjoseph_sc
> _____
>


[Non-text portions of this message have been removed]

On Mon, Sep 14, 2009 at 11:17 AM, Mark Joseph <mark@...> wrote:
> To do the XML to JSON conversion I use our XSLT (which can also go the other
way as well)
>
> <xsl:output method=’json’/>
> https://www.p6r.com/articles/2008/11/02/xsloutput-methodjson/

Does this (JSON -> xml events) work with any JSON input? Aside from
some cases that should be impossible (JSON content can include
character content that is illegal in XML), there are smaller questions
of what to map Arrays to... but those would be solvable. But do
require adoption some kind of convention. :-)

So, what do array markers translate to? I'm mostly asking because I
have been planning addition of some xml compatibility features for
JSON processor I am working on, and this is one of things where there
any many options. But if there are emerging (de facto) standards, it'd
be good to follow.

-+ Tatu +-

So the way the system works is that our JSON parser is called from a plugin to
our DOM parser.   That plugin calls the DOM parser API that creates nodes in the
DOM tree.
This is documented in another article:
https://www.p6r.com/articles/2008/05/06/xslt-and-xpath-for-json/

The plugin architecture is also used for XML, where a separate plugin calls our
SAX-2 XML parser so they both work the same way.

This way we convert whatever into a DOM tree and then can run full XSLT 2.0 (
not 1.0 ) and full
XPATH 2.0  on any of the data.

-Mark
P6R Inc


   _____

From: Tatu Saloranta [mailto:tsaloranta@...]
To: json@yahoogroups.com
Sent: Mon, 14 Sep 2009 12:37:39 -0700
Subject: Re: SV: [json] JSON representation for XML snippet

On Mon, Sep 14, 2009 at 11:17 AM, Mark Joseph <mark@...> wrote:
   > To do the XML to JSON conversion I use our XSLT (which can also go the other
way as well)
   >
   > <xsl:output method=’json’/>
   > https://www.p6r.com/articles/2008/11/02/xsloutput-methodjson/

   Does this (JSON -> xml events) work with any JSON input? Aside from
   some cases that should be impossible (JSON content can include
   character content that is illegal in XML), there are smaller questions
   of what to map Arrays to... but those would be solvable. But do
   require adoption some kind of convention. :-)

   So, what do array markers translate to? I'm mostly asking because I
   have been planning addition of some xml compatibility features for
   JSON processor I am working on, and this is one of things where there
   any many options. But if there are emerging (de facto) standards, it'd
   be good to follow.

   -+ Tatu +-


   ------------------------------------

   Yahoo! Groups Links





[Non-text portions of this message have been removed]

On Mon, Sep 14, 2009 at 12:46 PM, Mark Joseph <mark@...> wrote:
> So the way the system works is that our JSON parser is called from a plugin to
our DOM parser.   That plugin calls the DOM parser API that creates nodes in the
DOM tree.
> This is documented in another article:
> https://www.p6r.com/articles/2008/05/06/xslt-and-xpath-for-json/
>
> The plugin architecture is also used for XML, where a separate plugin calls
our SAX-2 XML parser so they both work the same way.

Right, I did skim through it, it's just that article is omitting a few
details. The basic idea of exposing JSON as SAX events is of course
simple (and obvious, but useful): JSON start/end object/array gets
converted to SAX start/end element events, no attributes.

But one thing I didn't see mentioned was the the question of mapping
JSON arrays (it does mention use of "JSON-document” as dummy name for
outermost JSON object, which is needed). In XML there are couple of
ways of expressing logical arrays (sequences of items), so one has to
choose one from alternatives (separate container for array itself? or
for elements? or both? and what name to use for either?)
So it seems that either JSON arrays are not supported, or that details
are just not mentioned.
Also: this problem affects JSON output as well.

Another smaller issue is handling of JSON content with characters that
are legal in JSON, but illegal in XML (like control characters) is not
mentioned. Maybe such content is just passed as is; which works ok
unless app code is assuming that no such content will be received.

-+ Tatu +-

But one thing I didn't see mentioned was the the question of mapping
   JSON arrays (it does mention use of "JSON-document” as dummy name for
   outermost JSON object, which is needed). In XML there are couple of
   ways of expressing logical arrays (sequences of items), so one has to
   choose one from alternatives (separate container for array itself? or
   for elements? or both? and what name to use for either?)
   So it seems that either JSON arrays are not supported, or that details
   are just not mentioned.
   Also: this problem affects JSON output as well.
   The the code that generates JSON output detects an array in the DOM tree and
generates a JSON array from it.   The "array" are just several nodes in the tree
with the same element name that are adjacent to each other.

The JSON parsing to DOM nodes just places all the array elements adjacent to
each
other in the tree with the same name.   But this is an internal implementation
thing that I could
do several ways.   (I could add a special node in the DOM tree indicating an
array
start and array end.  Where these nodes are not output.)

What is in the DOM tree is not XML and not JSON and not any other format.  It
   is instead an intermediate format with extra "schematic" marker nodes a
necessary
   to indicate other information.


   Another smaller issue is handling of JSON content with characters that
   are legal in JSON, but illegal in XML (like control characters) is not
   mentioned. Maybe such content is just passed as is; which works ok
   unless app code is assuming that no such content will be received.
   Well I can't discuss everything in a single article, but in the DOM tree there
are
no illegal characaters since at that point its not XML.   However, when you take
the DOM tree and want to output it as XML then there are standard
escape/encoding
rules in XML that are used to force proper XML.

What is really nice about our approach is now I can add another plugin that
takes our
ASN.1 parser (for example) and converts that into a DOM tree (since it has
structure too).   And then
do whatever I want to it.



Best,
Mark
P6R, Inc




   -+ Tatu +-


   ------------------------------------

   Yahoo! Groups Links





[Non-text portions of this message have been removed]

Sorry the previous version of this message was hard to read:


>But one thing I didn't see mentioned was the the question of mapping
>JSON arrays (it does mention use of "JSON-document” as dummy name for
>outermost JSON object, which is needed). In XML there are couple of
>ways of expressing logical arrays (sequences of items), so one has to
>choose one from alternatives (separate container for array itself? or
>for elements? or both? and what name to use for either?)
>So it seems that either JSON arrays are not supported, or that details
>are just not mentioned.
>Also: this problem affects JSON output as well.


***************************************
My Response:

The the code that generates JSON output detects an array in the DOM tree and
generates a JSON array from it.   The "array" are just several nodes in the tree
with the same element name that are adjacent to each other.

The JSON parsing to DOM nodes just places all the array elements adjacent to
each
other in the tree with the same name.   But this is an internal implementation
thing that I could
do several ways.   (I could add a special node in the DOM tree indicating an
array
start and array end.  Where these nodes are not output.)

What is in the DOM tree is not XML and not JSON and not any other format.  It
is instead an intermediate format with extra "schematic" marker nodes a
necessary
to indicate other information.

***************************************


>Another smaller issue is handling of JSON content with characters that
>are legal in JSON, but illegal in XML (like control characters) is not
>mentioned. Maybe such content is just passed as is; which works ok
>unless app code is assuming that no such content will be received.


*****************************************
My Response:

Well I can't discuss everything in a single article, but in the DOM tree there
are
no illegal characaters since at that point its not XML.   However, when you take
the DOM tree and want to output it as XML then there are standard
escape/encoding
rules in XML that are used to force proper XML.

What is really nice about our approach is now I can add another plugin that
takes our
ASN.1 parser (for example) and converts that into a DOM tree (since it has
structure too).   And then
do whatever I want to it.

Best,
Mark
P6R, Inc

****************************************

Thank you for all the responses. I guess there were two parts to it. I was
specifically interested in your insights on a XML element with both text and
attributes
can be represented in JSON.

   <attribute a2="v2">value2</attribute>

If XML were

   <attribute a2="v2">value2</attribute>

equivalent JSON could be

  {"attribute" : "value2"}

if XML were

<attribute a2="v2" />

JSON could be

{
    "attribute" :
      { "a2" : "v2" }
}

But how about when both XML element's text and attributes are specified
as in

   <attribute a2="v2">value2</attribute>

Thanks
Shalab

On Mon, Sep 14, 2009 at 1:36 PM, Mark Joseph <mark@...> wrote:

>
>
> But one thing I didn't see mentioned was the the question of mapping
> JSON arrays (it does mention use of "JSON-document” as dummy name for
> outermost JSON object, which is needed). In XML there are couple of
> ways of expressing logical arrays (sequences of items), so one has to
> choose one from alternatives (separate container for array itself? or
> for elements? or both? and what name to use for either?)
> So it seems that either JSON arrays are not supported, or that details
> are just not mentioned.
> Also: this problem affects JSON output as well.
> The the code that generates JSON output detects an array in the DOM tree
> and
> generates a JSON array from it. The "array" are just several nodes in the
> tree
> with the same element name that are adjacent to each other.
>
> The JSON parsing to DOM nodes just places all the array elements adjacent
> to each
> other in the tree with the same name. But this is an internal
> implementation thing that I could
> do several ways. (I could add a special node in the DOM tree indicating an
> array
> start and array end. Where these nodes are not output.)
>
> What is in the DOM tree is not XML and not JSON and not any other format.
> It
> is instead an intermediate format with extra "schematic" marker nodes a
> necessary
> to indicate other information.
>
> Another smaller issue is handling of JSON content with characters that
> are legal in JSON, but illegal in XML (like control characters) is not
> mentioned. Maybe such content is just passed as is; which works ok
> unless app code is assuming that no such content will be received.
> Well I can't discuss everything in a single article, but in the DOM tree
> there are
> no illegal characaters since at that point its not XML. However, when you
> take
> the DOM tree and want to output it as XML then there are standard
> escape/encoding
> rules in XML that are used to force proper XML.
>
> What is really nice about our approach is now I can add another plugin that
> takes our
> ASN.1 parser (for example) and converts that into a DOM tree (since it has
> structure too). And then
> do whatever I want to it.
>
> Best,
> Mark
> P6R, Inc
>
> -+ Tatu +-
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>


[Non-text portions of this message have been removed]

I do not get all these problems ... first of all I expect that JSON to XML
will parse JSON first and then create XML via proper namespace/libarry and
character problem should not exist in this case.

Secondly ASAIK JSON escapes a lot of characters adding \uXXXX from 0000 to
FFFF, other characters are escaped like \\n and the rest is basically ASCII.
Which parser gives you all these problems during convertion, assuming you
are avoiding the "to Current Language before, to XML after" strategy?

On Mon, Sep 14, 2009 at 9:04 PM, Tatu Saloranta <tsaloranta@...>wrote:

> On Mon, Sep 14, 2009 at 12:46 PM, Mark Joseph <mark@...> wrote:
> > So the way the system works is that our JSON parser is called from a
> plugin to our DOM parser.   That plugin calls the DOM parser API that
> creates nodes in the DOM tree.
> > This is documented in another article:
> > https://www.p6r.com/articles/2008/05/06/xslt-and-xpath-for-json/
> >
> > The plugin architecture is also used for XML, where a separate plugin
> calls our SAX-2 XML parser so they both work the same way.
>
> Right, I did skim through it, it's just that article is omitting a few
> details. The basic idea of exposing JSON as SAX events is of course
> simple (and obvious, but useful): JSON start/end object/array gets
> converted to SAX start/end element events, no attributes.
>
> But one thing I didn't see mentioned was the the question of mapping
> JSON arrays (it does mention use of "JSON-document” as dummy name for
> outermost JSON object, which is needed). In XML there are couple of
> ways of expressing logical arrays (sequences of items), so one has to
> choose one from alternatives (separate container for array itself? or
> for elements? or both? and what name to use for either?)
> So it seems that either JSON arrays are not supported, or that details
> are just not mentioned.
> Also: this problem affects JSON output as well.
>
> Another smaller issue is handling of JSON content with characters that
> are legal in JSON, but illegal in XML (like control characters) is not
> mentioned. Maybe such content is just passed as is; which works ok
> unless app code is assuming that no such content will be received.
>
> -+ Tatu +-
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>


[Non-text portions of this message have been removed]

**********************************
From: Shalab Goel [mailto:goel.shalab@...]
To: json@yahoogroups.com
Sent: Mon, 14 Sep 2009 14:23:34 -0700
Subject: Re: SV: [json] JSON representation for XML snippet

Thank you for all the responses. I guess there were two parts to it. I was
specifically interested in your insights on a XML element with both text and
attributes
can be represented in JSON.

   <attribute a2="v2">value2</attribute>

If XML were

   <attribute a2="v2">value2</attribute>

equivalent JSON could be

  {"attribute" : "value2"}

if XML were

<attribute a2="v2" />

JSON could be

{
    "attribute" :
      { "a2" : "v2" }
}

But how about when both XML element's text and attributes are specified
as in

   <attribute a2="v2">value2</attribute>
*************************************


It would be great if there was a standard defined for the transformation, but
other than that I can only mention what I have done.

I have played with both formats:

a flat format:
   {  "attribute" : "value2",
      "a2" : "v2"
   }

OR

An array format:
   {  "attribute" : [ { "a2" : "v2" }, { "value2" } ]   }


Of course, with either of these outputs we lose something and cannot easily turn
this
back into XML afterwards.   Since JSON has no attributes I have no solution
unless
everyone agrees to what the mapping should be.


Best,

Mark Joseph, Ph.D.
President
P6R, Inc
408-205-0361
mark@...
Skype: markjoseph_sc

On Mon, Sep 14, 2009 at 1:53 PM, Mark Joseph <mark@...> wrote:
> Sorry the previous version of this message was hard to read:

>>But one thing I didn't see mentioned was the the question of mapping
>>JSON arrays (it does mention use of "JSON-document” as dummy name for
...
> ***************************************
> My Response:
>
> The the code that generates JSON output detects an array in the DOM tree and
> generates a JSON array from it.   The "array" are just several nodes in the
tree
> with the same element name that are adjacent to each other.

Ok. So DOM tree does have extra metadata that indicates this "array-ness".

I assumed that DOM tree itself had no knowledge of this, given that
SAX API would not have a way of indicating such data.
But if API is just SAX-like (or extension of SAX with additional
callback types, startArray/endArray), this could be handled.

> The JSON parsing to DOM nodes just places all the array elements adjacent to
each
> other in the tree with the same name.   But this is an internal implementation
thing that I could
> do several ways.   (I could add a special node in the DOM tree indicating an
array
> start and array end.  Where these nodes are not output.)

Right. There are multiple ways of exposing it, that is why I asked.

> What is in the DOM tree is not XML and not JSON and not any other format.  It
> is instead an intermediate format with extra "schematic" marker nodes a
necessary
> to indicate other information.

Ok.

> ***************************************
>
>>Another smaller issue is handling of JSON content with characters that
>>are legal in JSON, but illegal in XML (like control characters) is not
>>mentioned. Maybe such content is just passed as is; which works ok
>>unless app code is assuming that no such content will be received.
>
> *****************************************
> My Response:
>
> Well I can't discuss everything in a single article, but in the DOM tree there
are
> no illegal characaters since at that point its not XML.   However, when you
take
> the DOM tree and want to output it as XML then there are standard
escape/encoding
> rules in XML that are used to force proper XML.

Yes, except that this is not possible in xml 1.0, not even with
character entities. There is no way include control characters (except
for standard tab, lf, cr) in xml. This is different from having to
escape less-than and ampersand characters.
XML 1.1 allows for use of character entities for many of these
characters, not including null.

But I guess this is usually not a significant problem in practice.

> What is really nice about our approach is now I can add another plugin that
takes our
> ASN.1 parser (for example) and converts that into a DOM tree (since it has
structure too).   And then
> do whatever I want to it.

It is good to have interoperability tools, and I think this use case
makes sense. It is easier to map JSON to XML if necessary than the
other way around.

Thank you for your explanation,

-+ Tatu +-

On Mon, Sep 14, 2009 at 1:33 PM, Andrea Giammarchi
<andrea.giammarchi@...> wrote:
> I do not get all these problems ... first of all I expect that JSON to XML
> will parse JSON first and then create XML via proper namespace/libarry and
> character problem should not exist in this case.

Unfortunately, no. I am specifically referring to XML inability to
contain control characters like 0xA.
There is no way to include those in XML 1.0 documents, not even by
using character entities (char entity production must match
valid-char, which excludes these). They can be included in JSON via
escape mechanism.
Reverse is not a problem as JSON can contain any Unicode character;
any without escaping. I consider this a good thing (at least for
String values).

-+ Tatu +-

*******************************************************
Ok. So DOM tree does have extra metadata that indicates this "array-ness".

I assumed that DOM tree itself had no knowledge of this, given that
SAX API would not have a way of indicating such data.
But if API is just SAX-like (or extension of SAX with additional
callback types, startArray/endArray), this could be handled.
******************************************************

Our JSON parser does this:
https://www.p6r.com/articles/2008/05/22/a-sax-like-parser-for-json/

Its sax2 like in that its event based.


>XML 1.1 allows for use of character entities for many of these
>characters, not including null.
>
Since there is no standard way to handle this my code actually output
the text "null" so you can see at least what the value was meant to be.



Best,
Mark
P6R, Inc

just use a non valid attribute name as JSON property, so you won't have
ambiguity in the parser.

<attribute a2="v2">value2</attribute>
will be
{"attribute":{"a2":"v2"},"#text":"value2"}

as example ... while JSONML uses this kind of schema

["nodeName",{"a2":"v2"},"text or nested nodes"]

so that this:

<attributes>
    <attribute a2="v2">value2</attribute>
</attributes>

will be this

["attributes",{},["attribute",{"a2":"v2"},"value2"]]

Regards

On Mon, Sep 14, 2009 at 10:23 PM, Shalab Goel <goel.shalab@...> wrote:

>
> But how about when both XML element's text and attributes are specified
> as in
>
>  <attribute a2="v2">value2</attribute>
>
> Thanks
> Shalab
>


[Non-text portions of this message have been removed]

Handling XML attributes when converting to JSON:
**************************************
<attribute a2="v2">value2</attribute>
will be
{"attribute":{"a2":"v2"},"#text":"value2"}

as example ... while JSONML uses this kind of schema

["nodeName",{"a2":"v2"},"text or nested nodes"]

so that this:

<attributes>
    <attribute a2="v2">value2</attribute>
</attributes>

will be this

["attributes",{},["attribute",{"a2":"v2"},"value2"]]
  ****************************************

So all of the above works well when you have simple XML.
But with something like:

<node1 a="45">
     <node2 b="9" c="hithere">
         <node3 d="abc">
            <node4 e="12345">JSON has no attributes</node4>
         </node3>
     </node2>
     Now is the time for all good men to come to the aid of their party

     <node5 d="45">temperature is 70 degrees today</node5>
</node1>

The resulting JSON is going to be "ugly".   Many added arrays
are added to handle the attributes and nested nodes now appear in the
added arrays.   To me this adds a lot of extra complexity that I am
not sure I want.



Best,
Mark Joseph, Ph.D.
P6R, Inc

The encoding used by JsonML <http://jsonml.org> isn't prioritized to be "pretty"
or even really encoded by humans. It is intended to be compact and loss-less.
This means it can unambiguously encode and decode valid XML. Namespaces are
handled the same way as XML 1.0: as part of the element (or attribute) name.

Off-topic: Where JsonML really fills a void is its ability to be extended to be
a full intermediate language for client-side templates.  Templates are written
by humans in an ASP/JSP style syntax and then compiled to JsonML+Browser-Side
Templates (JBST) <http://bit.ly/2poc6d>.  No parsing has to take place in the
browser, and the site markup may be fully compacted and cached with the rest of
the scripts as it is now pure JavaScript.

--- In json@yahoogroups.com, "Mark Joseph" <mark@...> wrote:
>
>
> Handling XML attributes when converting to JSON:
> **************************************
> <attribute a2="v2">value2</attribute>
> will be
> {"attribute":{"a2":"v2"},"#text":"value2"}
>
> as example ... while JSONML uses this kind of schema
>
> ["nodeName",{"a2":"v2"},"text or nested nodes"]
>
> so that this:
>
> <attributes>
>    <attribute a2="v2">value2</attribute>
> </attributes>
>
> will be this
>
> ["attributes",{},["attribute",{"a2":"v2"},"value2"]]
>  ****************************************
>
> So all of the above works well when you have simple XML.
> But with something like:
>
> <node1 a="45">
>     <node2 b="9" c="hithere">
>         <node3 d="abc">
>            <node4 e="12345">JSON has no attributes</node4>
>         </node3>
>     </node2>
>     Now is the time for all good men to come to the aid of their party
>
>     <node5 d="45">temperature is 70 degrees today</node5>
> </node1>
>
> The resulting JSON is going to be "ugly".   Many added arrays
> are added to handle the attributes and nested nodes now appear in the
> added arrays.   To me this adds a lot of extra complexity that I am
> not sure I want.
>
>
>
> Best,
> Mark Joseph, Ph.D.
> P6R, Inc

Hi, I am developing an application with GIS and a hand me the server returns a
string containing a JSON object. I need to go through this object to separate
the fields, what happens is that he came in the form of String. How can you
convert this String in JSON, I tried this way and it did not work:

# JSONArray ja = new JSONArray (objetos.toString ()); / / objects is my json
array

--- In json@yahoogroups.com, "rubao" <diegorrborges@...> wrote:
>
>
> Hi, I am developing an application with GIS and a hand me the server returns a
string containing a JSON object. I need to go through this object to separate
the fields, what happens is that he came in the form of String. How can you
convert this String in JSON, I tried this way and it did not work:
>
> # JSONArray ja = new JSONArray (objetos.toString ()); / / objects is my json
array
>

If your server string contains a json-object then parse it to an object, if its
a json-array then parse it into an array. Pick a JSON-implementation at
www.json.org to do the work. If the implementation does not allow json-arrays to
be parsed directly, then wrap the array into a dummy object, ie.: "{ \"dummy\":
"+server_string+"}"

Thank you for your attention.
Reading the documentation could utilizare "eval" that solved my problem.

Thank you.

2009/9/17 Fredag_d13 <jonas@...>

>
>
> --- In json@yahoogroups.com <json%40yahoogroups.com>, "rubao"
> <diegorrborges@...> wrote:
> >
> >
> > Hi, I am developing an application with GIS and a hand me the server
> returns a string containing a JSON object. I need to go through this object
> to separate the fields, what happens is that he came in the form of String.
> How can you convert this String in JSON, I tried this way and it did not
> work:
> >
> > # JSONArray ja = new JSONArray (objetos.toString ()); / / objects is my
> json array
> >
>
> If your server string contains a json-object then parse it to an object, if
> its a json-array then parse it into an array. Pick a JSON-implementation at
> www.json.org to do the work. If the implementation does not allow
> json-arrays to be parsed directly, then wrap the array into a dummy object,
> ie.: "{ \"dummy\": "+server_string+"}"
>
>
>



--
________________________________________________
Diego Roberto
(62) 9619-0902
"Corra atrás dos seus sonhos... Eles săo a única coisa que te acompanham até
quando vc está dormindo!!!"

________________________________________________


[Non-text portions of this message have been removed]

Hello everyone,
    New versions of Jenner, Esel, and Kouprey are available.

    Jenner (http://www.deadpixi.com/jenner) is a completely in-browser template
engine using JSON datasources. It is as powerful as most server-side template
engines, but, by running completely in-browser saves server resources and
provides a clean separation from interface and backend.

    Esel (http://www.deadpixi.com/esel) is an expression language for JSON. It is
about as powerful as Java's Unified Expression Language, but runs inside a
hosting JavaScript application as opposed to a Java application. It can also be
used as a selection language from JSON databases.

    Kouprey (http://www.deadpixi.com/kouprey) is a parser generator for
JavaScript. It allows the specification of grammars in pure JavaScript, but in
such a way that the grammars are similar to EBNF specifications. It is the
underlying parsing technology of Esel, and has been used to write compilers for
large, Turing-complete programming languages.

    All of these projects are under the LGPL. The major changes of these latest
releases are much improved Unicode support and some performance and
documentation improvements.

    If you're using any of these projects for something, I'd love to know about
it!

    Thanks,
    Rob

There have been many requests for JSON t-shirts.
So I have made a couple of designs available at
http://www.zazzle.com/douglascrockford/products

Douglas, can I put my name in your Business Card? :D

Btw, specially the gray scale one looks really good, congrats.

Regards

P.S. do you sell outside USA as well? I did not check everything, cheers

On Thu, Oct 1, 2009 at 1:37 PM, Douglas Crockford <douglas@...>wrote:

>
>
> There have been many requests for JSON t-shirts.
> So I have made a couple of designs available at
> http://www.zazzle.com/douglascrockford/products
>
>
>


[Non-text portions of this message have been removed]

Hi all,
JSwoof tiny has finally been released. For those of you who do not want to be
tied into the FLEX framework. Or have size limitations to deal with.

It is a fraction of the size of its bigger brother JSwoof, but retains all of
its speed. As it is built using JSwoof's parsing core.

It does however come with some minor limitations like it will not be able to
serialize ArrayCollections as these are part of the main FLEX framework.

As usual you can download it at: http://www.waynemike.co.uk/jswoof

Regards
Wayne IV Mike