3 ms·

Think what the author meant is that XML allows documents where the structure is less predefined. It can be the markup that drives the interpretation. With a JSO

by igrekel 16y ago

Think what the author meant is that XML allows documents where the structure is less predefined. It can be the markup that drives the interpretation. With a JSON payload, you need to know how the whole is structured to know how to use it, or build additional mechanisms over it. Also XML brings other useful features like data types.

Groxx 16y ago
Is there a reason JSON fields can't be an object (of sorts) which defines data type, parsing rules, depth to read, circular structures, etc? You can convert, losslessly, between XML and JSON. Doesn't that mean they have identical capabilities, though one may be easier in certain circumstances? There's no "need" in any one which the other doesn't also need.
- 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 ago
    Obvious 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.
- igrekel 16y ago
  Well... as far as I know, json by itself is just objects with fields, these fields are either objects or string values. Of course you can do all you mention but you'll have to build a convention on top of json. So reading these json payload would require more than just knowledge of json, it would also require knowledge of what are these fields or objects that carry special interpretation meaning and what to do about it. A lot of these conventions are available the XML standards. Of course if they had started with something like json the result would be less verbose but maybe not that simple either.

by igrekel 16y ago

Groxx 16y ago

Is there a reason JSON fields can't be an object (of sorts) which defines data type, parsing rules, depth to read, circular structures, etc? You can convert, losslessly, between XML and JSON. Doesn't that mean they have identical capabilities, though one may be easier in certain circumstances? There's no "need" in any one which the other doesn't also need.

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 ago
  Obvious 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.
igrekel 16y ago
Well... as far as I know, json by itself is just objects with fields, these fields are either objects or string values. Of course you can do all you mention but you'll have to build a convention on top of json. So reading these json payload would require more than just knowledge of json, it would also require knowledge of what are these fields or objects that carry special interpretation meaning and what to do about it. A lot of these conventions are available the XML standards. Of course if they had started with something like json the result would be less verbose but maybe not that simple either.