XML was, in fact, designed with all those things in mind. Here is the 2nd design goal and its rationale, from 1996 draft specification[1]:
> 2. XML shall support a wide variety of applications.
> No design elements shall be adopted which would impair the usability of XML documents in other contexts such as print or CD-ROM, nor in applications other than network browsing. Examples of such applications include:
> validating authoring tools
> batch validators
> simple filters which understand the XML document structure
> normalizers
> formatting engines
> translators to render XML documents into other languages (e.g. RTF, TeX, ...)
It should also be noted, that XML included the DTD specification from the very beginning. Although much different from the current state of affairs—still no namespaces and not quite the flexibility of XSD—it's nevertheless an important distinction.
As you might imagine, such core concept were further developed, which resulted in the 1.0 spec of XML Namespaces[2] (called xml-names at that time) and with XSD soon following suite.
To say that JSON and XML are anything alike is unfair. As JSON's own RFC states, it was meant to be merely:
> JSON's design goals were for it to be minimal, portable, textual, and a subset of JavaScript.
No concern is given for its interoperability between vastly different environments, nor did it try to position itself as a replacement for XML, which would surely be known to its creators at that time. Subsequently, there's no mention of validation or extendibility.
Of course the concept of XML Namespaces is well unique to XML. Even the JSON Schema[3], does not introduce anything similar, but just merely provides an optional meta-document, describing—or should I say—hinting, about how the document may look like:
> It is acknowledged that JSON documents come in a variety of structures, and JSON is unique in that the structure of stored data structures often prescribes a non-ambiguous definite JSON representation.
> Cumulatively JSON Schema acts as a meta-document….
The JSON schema is of course still a draft today, and has received almost no adoption[4] from the community.
This should be, however, obvious, given the fact that it took a whole 4 years for JSON Schema to emerge (such a long time in the noughties), suggesting just how non-essential value it must hold for its users.
What I'm honestly afraid, is that JSON Schema will ultimately get our attention. But neither because we will seek it for its technical brilliance, which it hasn't got, nor because we will seek it for its user-friendliness, which is unimpressive, but because we will be desperate.
After enough developers will get seduces by the carelessness of JSON—“blimey, I don't have to think at all, and it's endorsed by some bloggers”—we will embrace JSON Schema and, surely, invent a whole novel ecosystem, just to deal with the mess, that such ‘fuck open Web, I'd rather just output garbage, because it is more convenient right now’ attitude could only bring.
XML was, in fact, designed with all those things in mind. Here is the 2nd design goal and its rationale, from 1996 draft specification[1]:
> 2. XML shall support a wide variety of applications.
> No design elements shall be adopted which would impair the usability of XML documents in other contexts such as print or CD-ROM, nor in applications other than network browsing. Examples of such applications include:
> validating authoring tools
> batch validators
> simple filters which understand the XML document structure
> normalizers
> formatting engines
> translators to render XML documents into other languages (e.g. RTF, TeX, ...)
It should also be noted, that XML included the DTD specification from the very beginning. Although much different from the current state of affairs—still no namespaces and not quite the flexibility of XSD—it's nevertheless an important distinction.
As you might imagine, such core concept were further developed, which resulted in the 1.0 spec of XML Namespaces[2] (called xml-names at that time) and with XSD soon following suite.
To say that JSON and XML are anything alike is unfair. As JSON's own RFC states, it was meant to be merely:
> JSON's design goals were for it to be minimal, portable, textual, and a subset of JavaScript.
No concern is given for its interoperability between vastly different environments, nor did it try to position itself as a replacement for XML, which would surely be known to its creators at that time. Subsequently, there's no mention of validation or extendibility.
Of course the concept of XML Namespaces is well unique to XML. Even the JSON Schema[3], does not introduce anything similar, but just merely provides an optional meta-document, describing—or should I say—hinting, about how the document may look like:
> It is acknowledged that JSON documents come in a variety of structures, and JSON is unique in that the structure of stored data structures often prescribes a non-ambiguous definite JSON representation.
> Cumulatively JSON Schema acts as a meta-document….
The JSON schema is of course still a draft today, and has received almost no adoption[4] from the community.
This should be, however, obvious, given the fact that it took a whole 4 years for JSON Schema to emerge (such a long time in the noughties), suggesting just how non-essential value it must hold for its users.
What I'm honestly afraid, is that JSON Schema will ultimately get our attention. But neither because we will seek it for its technical brilliance, which it hasn't got, nor because we will seek it for its user-friendliness, which is unimpressive, but because we will be desperate.
After enough developers will get seduces by the carelessness of JSON—“blimey, I don't have to think at all, and it's endorsed by some bloggers”—we will embrace JSON Schema and, surely, invent a whole novel ecosystem, just to deal with the mess, that such ‘fuck open Web, I'd rather just output garbage, because it is more convenient right now’ attitude could only bring.
[1] http://www.textuality.com/sgml-erb/dd-1996-0001.html
[2] http://www.w3.org/TR/1998/NOTE-xml-names-0119
[3] http://tools.ietf.org/id/draft-zyp-json-schema-03.txt
[4] http://json-schema.org/implementations.html