At the Semantic MediaWiki conference (SMWCon) a few days ago, Yuri mentioned that we're considering making our web API JSON-only. In response, Steve Newcomb emailed me the message below, and gave me permission to forward it to mediawiki-api for your consideration. Thank you, Steve Newcomb. -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation Dear Ms. Harihareswara, The remarks that appear below, after my signature, are informed by participation in years of earnest presentations and discussions about XML vs. JSON at the Balisage conferences (see balisage.org). The below remarks are extracted from the documentation of a tool we use in our consulting practice, which includes data management/publishing services for U.S. government customers. The extract is from a discussion of how the tool can optionally format XML for human-readability *without* polluting the data with spurious new whitespace. Then it digresses to more general considerations in a NOTE which is directly relevant to the JSON vs. XML question. It all boils down to a simple question: will the data ever be used outside its current known applications and/or software? If the answer is "No", then JSON is probably the right choice. If the answer is "Yes", then XML is certainly a better choice, but then the questions arise: "Whose perspective on the data should be baked into it?", and "Who will pay the cost of baking it in?" All best wishes for you and for humanity's ongoing invention of civilization, which depends on the longevity of knowledge, Steve Newcomb srn(a)coolheads.com ---------------------------------- In consideration of the haphazard way in which XML data are sometimes processed in the real world, one may with some justification worry about how a given XML document may someday be understood, especially when whitespace is significant. [This tool's] use of markup characters for all readability-whitespace moots the criticism of XML that JSON is easier than XML to read and use for data interchange on account of the fact that, in JSON, all whitespace is intrinsically explicit and not subject to subsequent diddling when parsed, even when JSON data are elegantly formatted for readability. Note: Needless to say, both syntaxes, XML and JSON, have advantages and disadvantages. In the context of this discussion, it may be worthwhile to highlight the essential difference between JSON and XML, which is that XML provides (demands, really) an explicit distinction between data and data-about-data (metadata), while JSON does not. In other words, XML requires specific classes of things to be endowed with names, while JSON imposes no such constraint. XML offers a standard way of unambiguously distinguishing the names of classes of data, and the names of attributes of those classes, from the data themselves. These names must be chosen somehow. Normally, the chosen names are meaningful. The choice of a specific name by a human being is the making of a semantic commitment. Thus, in XML, data are expressed in a way that almost inevitably reflects how someone (perhaps even the author!) thought the data should, or at least could, be understood. JSON, by contrast, does not demand that such a perspective be explicitly embedded in the data. If such a perspective is embedded in JSON data, JSON does not provide a standard way of abstracting that perspective from the data. But neither syntax prohibits the processing of data in terms of a data/metadata perspective other than the one(s) that were embedded in them. Whatever information XML can convey, JSON can also convey, and vice versa. However, if a data/metadata distinction needs to be baked into the data, such as when the data may need to be understood by a human being apart from any specific software application, XML is simpler to use, and the baked-in data/metadata distinction will be universally understandable as such, not only because of the World Wide Web Consortium XML Recommendation, but also because of ISO International Standard 8879-1986, as amended. If a baked-in data/metadata distinction is not desired, JSON is pretty clearly the better choice, but then at least two questions arise: (1) Are you certain that an embedded data/metadata distinction will be undesirable for all future applications of these data, including applications that do not yet exist? (2) Are you certain that you wish to forego your opportunity to influence how these data will be understood, including by persons as yet unborn? _______________________________________________ Mediawiki-api mailing list Mediawiki-api(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-api