Used purely as a markup language it's ok but you really don't want to be mucking around with stuff like canonicalization at all if you value your time.
That's probably one of the worst concieved security standards i have ever read. It should be in a museum for how not to make security standards.
Honestly though, i don't think its entirely possible to separate XML from the culture around it. XML encourages a certain way of doing things that leads to bad, problematically complex, outcomes.
But people don't use xml as a markup language; they use it for data interchange and for that purpose it's horrible because it maps very poorly to data structures in most programming language.
I disagree with you.
A XML file is, by definition, a [context-free grammar](https://en.wikipedia.org/wiki/Context-free_grammar), the same type of grammars used to specify programming languages.
I will make it clearer with the examples below:
/* a simple data structure */
struct Point {
int x;
int y;
};
<point>
<int name="x"></int>
<int name="y"></int>
</point>
/* a recursive data structure */
struct Person {
std::string name;
std::vector<Person> children;
};
<person>
<string name="name"></string>
<vector type="person">
<person>
<string name="name"></string>
<vector type="person">
</vector>
</person>
<person>
<string name="name"></string>
<vector type="person">
</vector>
</person>
</vector>
</person>
If I had to write the second one in JSON, for instance, I would lose the "template type-information" of the list (vector).
<person>
<name></name>
<children>
<person>
<name></name>
<children>
</children>
</person>
<person>
<name></name>
<children>
</children>
</person>
<children>
</person>
<person>
<name></name>
<person>
<name></name>
</person>
<person>
<name></name>
</person>
</person>
> Not that your scheme is much better, really, why are you putting you favourite language's types in the tags? My favourite one uses lists and binaries instead of vectors and strings, you know.
Because that was just an example that came up in my mind in less than 10 seconds to make my point.
I am glad that people understood my point and even came up with better solutions to make my argument even stronger.
Your smugness is unwarranted.
You claimed that XML has an obvious, natural mapping to data structures. After looking at the same extremely simple data structure, two people came up with three different XML representations, each with different pros and cons.
Your argument didn't come out in very good shape from that exchange.
That is an (i.e. your) interpretation of what I said. Please re-read my text below, in context.
>>> [...] and for that purpose it's horrible because it maps very poorly to data structures in most programming language.
>> [...]
>> A XML file is, by definition, a context-free grammar, the same type of grammars used to specify programming languages.
>> [...]
>> To me, it is immediate to see the correct data structure in both examples.
> After looking at the same extremely simple data structure, two people came up with three different XML representations, each with different pros and cons.
> Your argument didn't come out in very good shape from that exchange.
I disagree with you: both understood pretty well my data structures and came up with even clearer notation, making my point that it is a suitable grammar representation for data structures.
> Your smugness is unwarranted.
Seriously?
<point><x>value</x>...</point>
or
<class name="point"><property name="x" value="value"></property>...</class>
You can argue this should not happen, that it's not valid XML, etc...but being so verbose and readable, it tends to attract abuse and then hate.
JavsScript Object Notation makes a lot of sense to describe... The JavaScript objects.
But, nowadays, I see it universally applied.
As a recent personal experience, I had to use it to serialise communication between a C++ and a Java application---two statically typed languages, with basic types similar among each other but different from JavaScript.
To set the contract between the two applications, I had to write a JSON spec [1], which is written in... JSON. That was an abstruse and abusive use of JSON, in my opinion.
Then comes `jq` and its own notation, in which I suffer to do the basics of a simple XPath---e.g., return all the objects of a certain kind (i.e., a tag) in any level you find it.
Abuse happens [2] because there is a human behind it, especially under the lens of the adage "if all you have is a hammer, everything looks like a nail".
The problem I see in this discussion is that people either want a "magic tool" that works at all cases, or they want to control the human behind it.
In my experience, it is difficult to get both: generality does not play well with constraint.
---
<digression>
I think most people just need to use a plain-text format [4] for most of the things they want, à lá RFC 822 [5].
</digression>
---
[2]: I believe this is a Fibonacci series: https://www.xorpd.net/pages/xchg_rax/snip_01.html
[3]: http://blog.aerojockey.com/post/iocccsim
[4]: https://www.arp242.net/the-art-of-unix-programming/#id290742...
The XML equivalent is an XML schema, also written in XML. This is pretty decent as document validation goes.
> I think most people just need to use a plain-text format [4] for most of the things they want, à lá RFC 822 [5].
You linked to formats which don't even support nesting.
If you roll your own markup it's going to be brittle and people are going to parse it with regexps.
* In XML an "object property" can be represented as either an attribute or an element, in JSON only dicts can have attributes. * In XML elements can contain a mix of text and child elements. For serializing objects this is almost never desired. * JSON has a single way to define lists, in XML you need to roll your own.
JSON can contain a mix of differently typed objects too, which is similarly meaningless for serialization. And serialization is not the only usage of json.
JSON has a concept of list, but lists can be defined in many ways. And list is not the only collection type one might want to express in json. For example, is package dependency list a list or a dict?
The problem is that everybody has their own subset of xml for serializing objects, while for json you can load arbitrary json into a straight-forward tree of dicts, lists and literals.
If receive arbitrary xml the only way to process it is with xml-specific tools because the object model does not map to any programing language.
As I understand it, few modern programming languages have context-free grammars.
I do. I use it to build a simple website (well, 'simple' being relative, I guess), and for that it works fairly well.
the xml everything culture was a faux-progress (basically language design gone wild)