Consider a comparison of examples using JSON schema:
{
"$schema": "http://json-schema.org/draft-04/schema#",
"description": "Modified JSON Schema draft v4 that includes the optional '$ref' and 'format'",
"definitions": {
"schemaArray": {
"type": "array",
"minItems": 1,
"items": { "$ref": "#" }
}
}
...
<schema schema="http://json-schema.org/draft-04/schema#">
<description>Modified JSON Schema draft v4 that includes the optional '$ref' and 'format'</description>
<definitions>
<schemaArray>
<type>array</type>
<minItems>1</minItem>
<items ref="#" />
</schemaArray>
...
$schema and $ref are differentiated by convention in JSON, and require repeated consideration in every parsing scenario to treat them as exceptions relative to actual values within the JSON document. In the XML representation, the distinction is implicit and handled automatically for you by every parser.
>$schema and $ref are differentiated by convention in JSON, and require repeated consideration in every parsing scenario to treat them as exceptions relative to actual values within the JSON document.
This is a good thing. The main issue with XML is how ridiculously overcomplicated and overengineered its design was. This isn't just a matter of usability, it has security implications because it increases the attack surface of anything that uses it (e.g. the XML billion laughs attack).
> This is a good thing. The main issue with XML is how ridiculously overcomplicated and overengineered its design was.
Citing element attributes as an example of such complexity is hardly reasonable. The JSON example above contains the same complexity, just moved to the application/implementation space, instead of the parser (so your app is more complex to handle it).
> e.g. the XML billion laughs attack
Also not a great example. This is a simple DOS attack, of which there are many other examples: zip bombs, yaml bombs, etc. None of these invalidate yaml nor zip themselves.
There are also far worse attacks on XML than the billion laughs attack (XXE attacks are an entire category in the OWASP top 10).
What these attacks have in common is that they use references. They aren't unique to XML because any format wanting to handle references (like JSON schema!) will have to account for them.
The difference is, since references aren't built into the JSON spec, you have to do it yourself (and protect against attack like this in your own code). Since XML handles this at spec. level, common XML parsers can account for & mitigate for this for you (which fyi, modern ones do).
---
Side note (and a vote in favour of JSON):
By your own metric, JSON is actually "more complex" (in a good way) than XML in one area: value types. XML values are strings. Having value types is one massive advantage of JSON imo.
In that sense, it would be nice to see a language that combines both of these "complexities", to form something better.
I would disagree about having more value types. JSON has more syntax for value types, but it only has four: string, integer, float, and boolean. XML has less syntax for value types (everything is serialized as a string), but it has a way to define types of attributes with XML Schema and there you get much more primitive types already (decimal, date & time, binary). XML approach is more uniform: it uses schema to look up all the parsing rules. JSON uses syntax for some types and (ad-hoc) schema-like logic for others.
>Citing element attributes as an example of such complexity is hardly reasonable. The JSON example above contains the same complexity, just moved to the application/implementation space
Where it belongs...
>so your app is more complex to handle it
There is a trade off between more simple markup and more complex code and vice versa. I would argue it is almost always better that way around because it helps enforce clear separation of concerns. I'm similarly allergic to putting complex logic in template code because that also violates a clear separation of concerns.
>Also not a great example. This is a simple DOS attack, of which there are many other examples: zip bombs, yaml bombs, etc.
This is precisely why it's a great example. YAML has the same problem with overcomplexity XML does. JSON has no such issues.
>There are also far worse attacks on XML than the billion laughs attack (XXE attacks are an entire category in the OWASP top 10).
Right, billion laughs is part of a class of security vulnerabilities that are enabled by XML's bloated design.
>The difference is, since references aren't built into the JSON spec, you have to do it yourself
Except you don't. I'm not sure if I've ever implemented references in any JSON schema I've ever used. It's an entirely pointless feature as far as I'm concerned. I've seen them used in YAML (where it's equally yucky) and every time it's been used it's been as a band aid over deficient schema design that also inadvertently made the markup harder to understand.
>By your own metric, JSON is actually "more complex" (in a good way) than XML in one area: value types. XML values are strings. Having value types is one massive advantage of JSON imo.
I hardly think having 4/5 scalar types counts as spec overcomplication. If you want a measure of how complex each markup language is simply look at the length of the respective specifications. XML is ridiculous.
Consider a comparison of examples using JSON schema:
$schema and $ref are differentiated by convention in JSON, and require repeated consideration in every parsing scenario to treat them as exceptions relative to actual values within the JSON document. In the XML representation, the distinction is implicit and handled automatically for you by every parser.