XML vs JSON – Importance of XML in a JSON-Dominated World

If you're working solely with integer ranges, you're probably over-thinking the problem. All you need to store is the lower bound and the upper bound, and use a fixed rule about whether the bounds are inclusive. For example, Python ranges tend to use a half-closed interval, so that:

range(5,10)

Is what mathematicians would write as:

[5, 10)         # interval notation
5 <= x < 10     # inequality notation
5, 6, 7, 8, 9   # list notation

This is easily encoded into XML, JSON, or database values. E.g.:

<range low="5" high="10"/>   # XML
[5, 10]                      # simple list (brackets are data delimiters, 
                                            not mathematical interval notation)
{ "low": 5, "high": 10 }     # JSON fragment 

It's very easy to take a fixed set of rules, which seems very rigid, and get back whatever you want. For example, if you really wanted the 10 high bound included, then don't provide lots of additional flexibility machinery and complexity (which costs extra data encoding bytes, testing requirements, and code complexity). Just encode it as:

<range low="5" high="11"/>  # XML

range(5, 11)                # Python

If you don't like the asymmetry of a half-open interval, there's no reason you can't choose a fully closed / inclusive interval, or any other option (i.e., fully open interval, or half-open at the start interval). The trick is choosing a rule that is consistent throughout, and is most consistent / convenient with your programming environment.

This representation nicely handles finite ranges. It's very compact, can be implemented in a very performance-efficient way, and if you'd like extended operations, can be easily implemented as a neat class in Java, Python, and many other languages.

You also seem to want to represent discontinuous, infinite sets such as x < 10 ∪ x > 40. Those are generally not considered "ranges" by most programming languages / systems, and indeed aren't even intervals in the mathematical sense. But they're obviously interesting adjacent concepts to consider--though it will add notable complexity to the implementation.

For example. your disjoint set can be specified as a "multi-range," a combination of individual ranges:

<union>
    <range low="-Infinity" high="10"/>
    <range low="41" high="Infinity"/>
</union>

Now you've had to add handling for abstract values (negative and positive infinity) as well as a set combining operation (union) as the multi-range constructor. But, I've read the source of a number of numerical set and multi-range modules, and this is actually how many of them do it.

When you get going down this path of generalizing from individual intervals / ranges to multi-interval, multi-range sets, you may also start to generalize the set operations into other constructive formulations. If you do union, why not intersection, difference, and symmetric-difference as well? Your disjoint range could also be specified alternatively as:

<difference>
    <range low="-Infinity" high="Infinity"/>
    <range low="10" high="41"/>
</difference>

But you've got to be careful, because the more operations and the more complexity, the greater chance of errors creeping in.

XML and JSON are both capable of transmitting the same data, but which is better depends mostly on what you want to do with it.

This does touch on existing tooling, but you're not likely to be hand rolling parsers for either, so it is relevant.

XML

• Has better tooling for verifying schema.
• Has built in support for namespaces.
• Can be more easily restructured into HTML.
• Can be queried with XPath, which is really exceptional query language - think SQL for XML. I haven't really seen an equivalent for JSON - but I'd love to hear about it if I'm wrong on this one.

JSON

• Has significantly lower ceremony (and, at least in my experience, better pretty printers), so when a human has to look at it, it can be easier to read.
• Is, unsurprisingly, the best format when one end of the transfer is written in JavaScript.
• Has less legacy, so the chance of being forced to accept malformed JSON is lower. There is also no cultural expectation that you should have to accept malformed input.

Because one is capable of storing anything that can be stored in the other, usability and tooling is about the only criteria that is useful for comparing what it's like to use them.

If all that were wiped away, I'd probably use neither, and transmit the data as chunks of Lisp.

It's lower ceremony than JSON (barely), much easier to transform than XML, and easier to write a parser for than either (which I'd have to do if all the tooling were gone).