JSON has quite a few shortcomings. It is only useful in well-known
unambiguous structures, because in structures with more possible types,
you don't know the type.
For example if you have an element with a number in it or an element
with a text in it, JSON cannot differentiate between a text or a number
when the text is a number that should be treated as text,
this is a weakness, so the other side has to know what is there.
Yes, but this is the same as with XML.
<something>
<value>5432</value>
</something>
and
{ "something": { "value": 5432 } }
Both are meaningless without each side knowing what it is through a schema.
Suppose 1960, this can be a date in yyyy-XX-XX-pattern, or it can be
your roomnumber in an office-complex or a number.
You need type information to parse this example safe.
Suppose the archetype gives no clue (this is legal ADL):
items cardinality matches {0..*} matches{
ELEMENT[at0010] occurrences matches {*} matches{
value{*}
}
}
Why would you want to use such a construction?
I know it is possible, but is it a good idea to use it?
If you want clean, type safe interfaces, you should not use these kind of anything-is-possible data fields.
XML can give, and in ambiguous situations, it should give,
type-information, JSON does not, as far as I know. JSON also has no way
to express the attributes.
In XML this would look like this:
<items archetype_node_id="at0010"]>
<value xs:type="DV_DATE">
<value>1960</value>
</value>
</items>
Nothing prevents you from adding the same type information to the JSON document:
"items": [
{ "archetype_node_id": "at0010",
"value": {
"type": "DV_DATE",
"value": "1960"
}
}
]
and depending on the JSON serializer you're using they might have standardized it.
But the better way might be to have an accompanying JSON schema which tells you what that field is. IMHO an JSON schema does not need to be a static document which can match any possible document.
Why not have a JSON schema describing just the document you are interested in? So if the field is a date in this document, the JSON schema says its a date.
But the best way is to avoid such ambiguities and not allow it to happen.
JSON is useful and efficient, but it is not that rich or trustworthy
that you can use it for everything.
Just a JSON file alone is indeed worthless. The same as just an XML file is worthless.
If you want a rich and trustworthy XML file, you'll need an XML schema, just as with JSON.
Just an XML file and just an JSON file convey exactly the same information. Perhaps XML has standardized more but you can do the same in JSON.
I am not saying JSON is better or XML is better. They both have their pros and cons.
But in our case, as a transport mechanism to exchange data between browser based UIs, JSON won. And by using JSON schemas and avoiding unambiguous constructions, I think it is a clean, typesafe, trustworthy way of communicating.
Ralph.
