RE: [xml-dev] The impact of data format selection on applicationdevelopm

[Roger L Costello <costello@mitre.org>]

Hi Folks,

I have been having a discussion with a colleague on this topic. I thought it would be useful to share part of our discussion. 

[To remind people what the topic is about, we are trying to come up with rules/heuristics on when to use super-simple data formats versus when to use comparatively complicated data formats such as XML or JSON.]

My colleague argues that a JSON document containing a list of numbers or an XML document containing a list of numbers is superior to a plain text file containing a list of numbers because the JSON specification sets limits on the numbers and similarly if there is an XSD associated with the XML document it will set limits on the numbers, whereas there are no limits on the numbers in a plain text file. I think there is a problem with that argument. Suppose I create a document, using a super-simple data format, to express the length of rivers in the U.S., e.g.,

Missouri River	2,341
Mississippi River	2,340
Yukon River	1,979
Rio Grande	1,759

When I provide that data (file) to someone I will inform them:

Hey, the file consists of the lengths of rivers in the U.S. Each line of the file contains two fields: the U.S. name of a river and its length. The fields are separated by a tab. The length is expressed in miles as an integer and groups of digits are separated by the comma symbol (such as 1,759).

Without that explanation, the file (data) is useless. But that holds true for an XML file containing the same data and a JSON file containing the same data. One might argue that with XML the tags describe the data, so an accompanying explanation is not needed. But relying on XML tags to explain data is folly (e.g., what if the developer uses generic tags such as <li>, such tags hardly "explain" the data). I would argue, regardless of the data format, there needs to be some accompanying explanation about the data. And if that's the case, then heck, use the simplest possible data format (use the super-simple data format shown above) and take advantage of the plethora of tools available for processing super-simple data formats.

Comments?

/Roger