Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Javascript (http://www.velocityreviews.com/forums/f68-javascript.html)
-   -   XML<-> JSON conversion. What do you think? (http://www.velocityreviews.com/forums/t936761-xml-json-conversion-what-do-you-think.html)

Max 08-09-2008 01:19 PM

XML<-> JSON conversion. What do you think?
 
According to Stefan Goessner, to obtain a correct conversion from XML to
JSON it must apply some patterns to maintain order and structure of the
elements. This not only serves to ensure a reversible conversion, but
especially for documents such as SVG and SMIL that they require a
precisely correct order of the elements.
For example, in the case of:

<e>
some
<a>textual</a>
content
</e>

a direct conversion would be:

"e": {
"#text": ["some", "content"],
"a": "textual"
}

that it would not make sense because it concatenates a text in an array ...
According to Stefan should be as follows:

"e": "some <a>textual</a> content"

In practice the central node should be included in the text.
The same goes for examples like this:

<a>x<c/>y</a>

{
"a":"x<c/>y"
}

Or with a CDATA:

<e>
some text
<![CDATA[ .. some data .. ]]>
more text
</e>

{
"e":"\n some text\n <![CDATA[ .. some data .. ]]>\n more text\n"
}

Or with a double CDATA:

<e>
<![CDATA[ .. some data .. ]]>
<![CDATA[ .. more data .. ]]>
</e>

{
"e":"<![CDATA[ .. some data .. ]]><![CDATA[ .. more data .. ]]>"
}

(I did not understand this last conversion...)


In any case, these examples are confined to CDATA, but in fact they may
well extend to Processing Instruction, Comment etc
Indeed, this approach raises a serious question on the difference
between JSON and XML.
Is it a correct approach or does the nodes need to convert in objects
and chained arrays normally?
What do you think?

Max

Thomas 'PointedEars' Lahn 08-09-2008 06:39 PM

Re: XML<-> JSON conversion. What do you think?
 
Max wrote:
> According to Stefan Goessner, to obtain a correct conversion from XML to
> JSON it must apply some patterns to maintain order and structure of the
> elements. This not only serves to ensure a reversible conversion, but
> especially for documents such as SVG and SMIL that they require a
> precisely correct order of the elements.


Document of which type would not require a precisely correct order of the
elements?

> For example, in the case of:
>
> <e>
> some
> <a>textual</a>
> content
> </e>
>
> a direct conversion would be:
>
> "e": {
> "#text": ["some", "content"],
> "a": "textual"
> }


It would not. A direct conversion could be:

[
{
nodeName: "e",
attributes: {},
childNodes: [
{
nodeName: "#text",
nodeValue: "\n some\n "
},
{
nodeName: "a",
attributes: {},
childNodes: [
{"#text": "textual"}
]
},
{
nodeName: "#text",
nodeValue: "\n content\n"
}
]
}
]

> that it would not make sense because it concatenates a text in an array ...


It is you who is not making sense here. "Concatenates a text in an array"?

> According to Stefan should be as follows:
>
> "e": "some <a>textual</a> content"


A possibility, but it would involve deserializing the content afterwards.
It would be even more inefficient than to serve XML in the first place.


PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

Thomas 'PointedEars' Lahn 08-09-2008 07:28 PM

Re: XML<-> JSON conversion. What do you think?
 
Thomas 'PointedEars' Lahn wrote:
> Max wrote:
>> [...]
>> For example, in the case of:
>>
>> <e>
>> some
>> <a>textual</a>
>> content
>> </e>
>>
>> a direct conversion would be:
>>
>> "e": {
>> "#text": ["some", "content"],
>> "a": "textual"
>> }

>
> It would not. A direct conversion could be:
>
> [
> {
> nodeName: "e",
> attributes: {},
> childNodes: [
> {
> nodeName: "#text",
> nodeValue: "\n some\n "
> },
> {
> nodeName: "a",
> attributes: {},
> childNodes: [
> {"#text": "textual"}


Should have been

{
nodeName: "#text",
nodeValue: "textual"
}

> ]
> [...]



PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7@news.demon.co.uk>

Max 08-10-2008 10:07 AM

Re: XML<-> JSON conversion. What do you think?
 
Thomas 'PointedEars' Lahn ha scritto:
> Document of which type would not require a precisely correct order of the
> elements?


Any custom XML document can not require a correct order of elements...

> It would not. A direct conversion could be:
>
> [
> {
> nodeName: "e",
> attributes: {},
> childNodes: [
> {
> nodeName: "#text",
> nodeValue: "\n some\n "
> },
> {
> nodeName: "a",
> attributes: {},
> childNodes: [
> {"#text": "textual"}
> ]
> },
> {
> nodeName: "#text",
> nodeValue: "\n content\n"
> }
> ]
> }
> ]


A possibility...

>> that it would not make sense because it concatenates a text in an array ...

>
> It is you who is not making sense here. "Concatenates a text in an array"?
>
>> According to Stefan should be as follows:
>>
>> "e": "some <a>textual</a> content"


When a JSON converter find two or more #text nodes it create one array
with all strings elements:

<e>
some
<a>textual</a>
content
</e>

->

"e": {
"#text": ["some", "content"],
"a": "textual"

}

I think that a JSON converter, in this case, can join strings:

"e": {
"#text": "some content",
"a": "textual"

}

What do you think?

> A possibility, but it would involve deserializing the content afterwards.
> It would be even more inefficient than to serve XML in the first place.


Yes, I agree with you. In this case, a use of JSON it would be wrong.

Thomas 'PointedEars' Lahn 08-10-2008 11:01 AM

Re: XML<-> JSON conversion. What do you think?
 
Max wrote:
> Thomas 'PointedEars' Lahn ha scritto:
>> Document of which type would not require a precisely correct order of the
>> elements?

>
> Any custom XML document can not require a correct order of elements...


If I meant nodes for "elements", would you agree then?

>> It would not. A direct conversion could be:
>>
>> [
>> {
>> nodeName: "e",
>> attributes: {},
>> childNodes: [
>> {
>> nodeName: "#text",
>> nodeValue: "\n some\n "
>> },
>> {
>> nodeName: "a",
>> attributes: {},
>> childNodes: [
>> {"#text": "textual"}
>> ]
>> },
>> {
>> nodeName: "#text",
>> nodeValue: "\n content\n"
>> }
>> ]
>> }
>> ]

>
> A possibility...


It would be an accurate representation of the subtree, using the relevant
properties of the corresponding DOM objects. One that is easy and efficient
to iterate over.

> When a JSON converter find two or more #text nodes it create one array
> with all strings elements:
>
> <e>
> some
> <a>textual</a>
> content
> </e>
>
> ->
>
> "e": {
> "#text": ["some", "content"],
> "a": "textual"
>
> }
>
> I think that a JSON converter, in this case, can join strings:
>
> "e": {
> "#text": "some content",
> "a": "textual"
>
> }
>
> What do you think?


It could, but that would not be an accurate representation of the content at
all. It matters that one text node precedes the element node and the other
follows it; neither the array of string values or the resulting primitive
string value would show that. And object properties have no defined order
in the for-in iteration that one would need to resort to then; hence my
arranging data of adjacent nodes as array elements instead.


PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7@news.demon.co.uk>

Max 08-10-2008 11:24 AM

Re: XML<-> JSON conversion. What do you think?
 
Thomas 'PointedEars' Lahn ha scritto:
> If I meant nodes for "elements", would you agree then?


Yes.

> It could, but that would not be an accurate representation of the content at
> all. It matters that one text node precedes the element node and the other
> follows it; neither the array of string values or the resulting primitive
> string value would show that. And object properties have no defined order
> in the for-in iteration that one would need to resort to then; hence my
> arranging data of adjacent nodes as array elements instead.


These cases demonstrates the difference between JSON and XML. I think to
use JSON to transmit simples data and XML for structured data.
More thanks for the help and suggestions.

Max

Lasse Reichstein Nielsen 08-10-2008 11:39 AM

Re: XML<-> JSON conversion. What do you think?
 
Max <adsl@tiscali.it> writes:

> When a JSON converter find two or more #text nodes it create one array
> with all strings elements:


Which "JSON converter" are we talking about. I can assure you that it won't
be any XML<->JSON converter that I'll ever write (because I know that in XML,
order is important).


>
> <e>
> some
> <a>textual</a>
> content
> </e>
>
> ->
>
> "e": {
> "#text": ["some", "content"],
> "a": "textual"
>
> }
>
> I think that a JSON converter, in this case, can join strings:


Can, yes, obviosuly. If anyone writes it to do so. Which they definitly
shouldn't.

>
> "e": {
> "#text": "some content",
> "a": "textual"
>
> }
>
> What do you think?


That it would be a lousy "converter".

/L
--
Lasse Reichstein Nielsen
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

Lasse Reichstein Nielsen 08-10-2008 11:56 AM

Re: XML<-> JSON conversion. What do you think?
 
Max <adsl@tiscali.it> writes:

> For example, in the case of:
>
> <e>
> some
> <a>textual</a>
> content
> </e>
>
> a direct conversion would be:
>
> "e": {
> "#text": ["some", "content"],
> "a": "textual"
> }


That would be a direct conversion *only* if you consider the order of
elements in the "e" element to be irrelevant. The contents suggest that
this is not the case.

This is no more a direct conversion than sorting the words of a book
is a translation of the book. Sometimes, often indeed, the order is
the most important part of the content.

....
> Is it a correct approach or does the nodes need to convert in objects
> and chained arrays normally?


That depends entirly on what you need it for.
A generic conversion between XML and JSON would preserve order and
structure. More specialized conversions, for particular uses, might
know where it can cut corners and keep some of the XML in string form.

/L
--
Lasse Reichstein Nielsen
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

Lasse Reichstein Nielsen 08-10-2008 12:10 PM

Re: XML<-> JSON conversion. What do you think?
 
Max <adsl@tiscali.it> writes:

> These cases demonstrates the difference between JSON and XML.


Not really. It shows that a particularly na´ve implementation
of a conversion from XML to JSON doesn't work well.


What if the conversion of
<e>
some
<a>textual</a>
content
</e>

was:

{"tag": "e",
"content" : [ "some",
{"tag": "a", "content": ["textual"]}
"content" ]}

What is the big difference then?

> I think
> to use JSON to transmit simples data and XML for structured data.


Your choice. Neither is inherently better (although JSON is often
shorter), but their performances depend on the choice of encoding
as much as the format of the data.

XML only has raw text and elements nodes. Element nodes both work as a
list of XML nodes and as a map from strings to strings (attributes),
and it has a type itself (the tag name). Everything is rolled into
this one compound construct.

JSON has two types of compound structures: (unordered) Maps and
(ordered) Lists (i.e., indexed by either name or by number).

In that sense, JSON is richer than XML, where name-indexed attributes
can only contain simple text.

I find that most data can be well represented in JSON, but starting
with XML data obviously makes JSON look worse than XML. Just as starting
with JSON data would probably make XML look worse.

/L
--
Lasse Reichstein Nielsen
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

Max 08-10-2008 01:39 PM

Re: XML<-> JSON conversion. What do you think?
 
Lasse Reichstein Nielsen ha scritto:
> Not really. It shows that a particularly na´ve implementation
> of a conversion from XML to JSON doesn't work well.


Really, then most of implementations of conversion from XML to JSON are
na´ve!

> What if the conversion of
> <e>
> some
> <a>textual</a>
> content
> </e>
>
> was:
>
> {"tag": "e",
> "content" : [ "some",
> {"tag": "a", "content": ["textual"]}
> "content" ]}
>
> What is the big difference then?


For JSON, "textual" is a value of "a" and then { a: "textual" }.
This convertion is your expansive implementation created to bypass the
JSON limitations...
In fact, to obtain the string "some" instead of (example) e["#text"],
you must use a blinded mode tag.content[1], while it is more correct to
log on with the real name of the object/tag, that is "e"!

>> I think
>> to use JSON to transmit simples data and XML for structured data.

>
> Your choice. Neither is inherently better (although JSON is often
> shorter), but their performances depend on the choice of encoding
> as much as the format of the data.
>
> XML only has raw text and elements nodes. Element nodes both work as a
> list of XML nodes and as a map from strings to strings (attributes),
> and it has a type itself (the tag name). Everything is rolled into
> this one compound construct.
>
> JSON has two types of compound structures: (unordered) Maps and
> (ordered) Lists (i.e., indexed by either name or by number).
>
> In that sense, JSON is richer than XML, where name-indexed attributes
> can only contain simple text.
>
> I find that most data can be well represented in JSON, but starting
> with XML data obviously makes JSON look worse than XML. Just as starting
> with JSON data would probably make XML look worse.
>
> /L



Can you suggests to me a good XML-JSON converter?


All times are GMT. The time now is 12:16 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.