3 ms·
"You can convert losslessly" – that's not the whole truth. It's an issue that there's no obvious or agreed upon way to render an XML format like ATOM into JSON,
by c3o 16y ago
"You can convert losslessly" – that's not the whole truth.
It's an issue that there's no obvious or agreed upon way to render an XML format like ATOM into JSON, because everyone makes up their own transformation rules. Here are two distinct attempts:
* http://www.ibm.com/developerworks/library/x-atom2json.html http://www.ibm.com/developerworks/library/x-atom2json.html
* http://code.google.com/apis/gdata/docs/json.html http://code.google.com/apis/gdata/docs/json.html
- Groxx 16y agoObvious or agreed-upon does not mean cannot. Google's, for instance, looks nigh-identical to what I'd have aimed for; nodes = fields, node-attributes = fields in the object on a field, node-text-content = specially-named field. It's a naive, 1-1 transformation between the two. Simple enough that I'd actually consider it the "obvious" way to do so. IBM's, on the other hand, has a number of nonsensical statements like this: >Because JSON is incapable of preserving any notion of a Base URI, it is unlikely that an application using the JSON serialization is capable of properly rendering markup containing relative URI paths. It is therefore important that such paths be resolved automatically during the conversion process as shown ... Bull. Base URI is just a field, or inferred by the document's source. ie: the same as XML. Their technique is incapable of translating a Base URI, it has nothing to do with JSON. Theirs also cannot handle namespacing, while Google's is simple, and almost identical to how XML does it: namespace$field: value.