I’m somewhat lukewarm about the XML vs JSON debate. I’ll admit, from a straight reading perspective I usually find JSON more attractive. But in the end it all seems somewhat minor when compared to all of the work invested in XML.
At some point you need to reinvent the wheel, but I’m not sure JSON is to the point that justifies this yet. I’d personally hope that before the long road of redoing everything people have done in XML in JSON is undertaken that we could take a hard look at JSON itself and make sure it’s really really right.
Once you start down that road, you can’t fix JSON anymore than you can fix XML. Maybe it’s too late already.
On a less “in the clouds” note, reading Dave Meginson, Douglas Crockford and Don Box made me think. Megginson says there is only a syntactic difference (and community differences), but I think that’s wrong. In the section “Additional node attributes” the difference is clear. Things that are ad-hoc in one format are formalized in other formats.
While this may seem minor, it definitely surpasses syntax. Ad-hoc conventions do not convey the same level of information as formalized conventions do. Formalized conventions can be safely used as an additional meta-layer, where ad-hoc must be handled carefully.
Where are the formats different? JSON and LISP formalize the strongly typed list, where XML formalizes the loosely typed list. Douglas Crockford’s response illustrates this quite well as his solution highlights the JSON strength of a strongly typed list with “people: [...]“. Every item inside those brackets becomes a singular type because there is no formal mechanism to indicate any differentiation.
At the same time it highlights the weakness in the lack of formalization of the elements. Crockford’s refactoring of Megginson’s example works because in our society male names and female names are the same type. However, if instead you used an example of something like “Earth name”, and “Martian name”, the example makes more sense. We know what earth names are and could define the structure of those fairly well today. But we can’t write a structure for Martian names yet because we don’t know much about them. If we want to have any chance of supporting Martian names in the future, we need a typed list that lets us separate our earth names from the Martian names.
We can by informal or exterior convention specify a single name value pair, such as origin-planet to query upon, but if that’s not communicated clearly and universally we’ll always be afraid to add Martian names because someone may not have got the memo.
Just for giggles, I’ve taken a stab at a format modification that might accomplish both these goals, though I have not yet given it even one percent of the thought such a thing really deserves, but here’s the concept:
“people”= [
{"EarthName": lang="it", given="Anna Maria", surname="Mozart"}
{"MartianName": alphabet="#", ["Translations":
{dayOfWeek="Monday", earthTranslation={"EarthName": lang="en", given="who"}}
{dayofWeek="Tuesday", earthTranslation={"EarthName": lang="en", given="tfatf"}}
]}
]
["EarthNames":
{lang="it", given="Anna Maria", surname="Mozart"}
{lang="en", given="Fitzwilliam", surname="Darcy"}
{lang="fr", given="Maurice", surname="Chevalier"}
]
Recent Comments