Earlier quoted context omitted.
> I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I call BS. If people want to have custom parsing directives they can send them out of band, encode them in the filename, or whatever. But they don't. And I've not seen this happening with most other serialisation formats either, so why would JSON be a particular targe…
If people really wanted parsing directives, they could just say that keys starting with # and their values are parsing directives - e.g: { "#if": "parserversion > 1.5", "key": "somevalue", "#else": "", "key": "othervalue" } Thought I also don't really see any reason to include parsing directivesin JSON.
Since JSON objects don't support order or repeated keys, that syntax can't be represented, edited or processed by the rich ecosystem of JSON tools. Most decent JSON editors will show that text with squigly red underlines. It's not worth giving up interoperability, and having to make yet another new set of tools for an incompatible syntax.
That was the mistake that the Angular 2 template syntax made.
But XML-based templating languages like Genshi [1] show how you can obey the rules of XML, use namespaces correctly, support element, attribute and text based expressions, looping, logic and macros, and it works just fine and interoperates perfectly with existing tools.
Genshi was based on another Python based XML templating system called Kid [2], which itself was influenced by Zope's page templates, TAL template attribute language, TALES expressions [3] and METAL templates [4]. Genshi and Kid templates are simple and easy to use compared to the conglomeration of Zope stuff.
Here is the essential trick, described in the Zope manual, which all those languages share, that makes it possible to sidestep the fact that attributes are not ordered:
When there is only one TAL statement per element, the order in which they are executed is simple. Starting with the root element, each element’s statements are executed, then each of its child elements is visited, in order, to do the same.
Any combination of statements may appear on the same elements, except that the content and replace statements may not appear together.
Due to the fact that TAL sees statements as XML attributes, even in HTML documents, it cannot use the order in which statements are written in the tag to determine the order in which they are executed. TAL must also forbid multiples of the same kind of statement on a single element, so it is sufficient to arrange the kinds of statement in a precedence list.
When an element has multiple statements, they are executed in this order:
1) define
2) condition
3) repeat
4) content or replace
5) attributes
6) omit-tag
[1] https://genshi.edgewall.org/
[2] http://turbogears.org/1.0/docs/GettingStarted/Kid.html
[3] https://docs.zope.org/zope2/zope2book/AppendixC.html
[4] https://docs.zope.org/zope2/zope2book/AppendixC.html#metal-o...