MNX in JSON discussion

[adrianholovaty]

Here's a discussion topic for issue #290 — whether to change MNX to use JSON. Let's try to have a conversation here, as it's a bit more manageable than a normal GitHub issue, thanks to the threading features.

[adrianholovaty]

Responding to @ahankinson's comment from here:

On the other hand, maybe I want to change the colour of a specific accidental; to make it red, independent of any note, for some reason, and preserve this markup in a file. If it's just defined as a property of a note event, then there's actually no way to address that accidental's colour independently.

I think JSON offers a better story here. For the example of a note's accidental, a note struct could support either a string or an object, like this:

// Simple version
{
    "pitch": "G#4",
    "accidental": "sharp"
}

// Extended version
{
    "pitch": "G#4",
    "accidental": {
        "value": "sharp",
        "color": "red"
    }
}

Parsing this would be relatively simple. In pseudocode:

if typeof note['accidental'] is string:
    value = note['accidental']
else:
    value = note['accidental']['value']

This is what I meant by "upgrading" simple attributes in the advantage number 8 of my original post.

In contrast, "upgrading" XML attributes to child elements (as you've described in MEI) feels more complicated and less natural, because an attribute is a completely different animal than a child element. Accessing an XML element's attribute has an entirely different API than accessing a child element.

[shoogle]

Schema validation is a good point in favour of XML. It will get lost here though so why not raise it in a separate thread on this discussion page?

XML as an encoding format is forward-safe, since there can be no unexpected values

You can create unexpected values in XML by adding sub-elements to elements that previously only contained text. This is essentially the same as converting simple values into objects or arrays in JSON.

This would prevent dot-notation accessors

Those are unsafe in Python as it involves evaluating the data to turn it into a native Python object, which can allow for arbitrary code execution. They are potentially in JavaScript too depending on how you do it. It's usually best to access the data through a JSON object rather than a native object, which means using data["value"] or data.get("value") rather than data.value.

[This] allows vendors to slip in undocumented encoding data

That's the whole point! And you could do this in MusicXML if you really wanted to, either by adding new attributes or tags and then ignoring validation warnings, or by adding extra semantic data inside text directions.

If a vendor decides that it doesn't like the way "pitch" is encoded, for example, it can put in a basic value for the "standard" pitch, and then vendor the actual value in their own hidey-hole, while not releasing any documentation for it.

I highly doubt that anybody would bother doing this in practice. If a mainstream product did this everyone would see and update their importers to handle that data specifically. For smaller products, two-way interoperability is too valuable a feature to make it worthwhile.

You make a good point about roundtripping but it applies to all formats.

[ahankinson]

Those are unsafe in Python as it involves evaluating the data to turn it into a native Python object, which can allow for arbitrary code execution.

Hm. Getting into the weeds a bit, but the JSON string -> Python dict process is handled in the JSON library, and then dict -> object is a fairly straightforward and safe operation. There's no need for an eval() call. But I take your point that dot-accessors in other languages are not an obvious form of interaction. I mostly mentioned it because it was a factor in the "developer happiness" improvements in IIIF, where @ prefixes were used on some keys and were subsequently removed because JS devs wanted to do dot notation. (I don't really like dot accessors either, since it seems pretty fragile.)

That's the whole point!

If the point is to put effort into an standard interchange format, then putting in non-standard proprietary data into that format that nobody else can use seems to be counter-productive?

I highly doubt that anybody would bother doing this in practice. If a mainstream product did this everyone would see and update their importers to handle that data specifically. For smaller products, two-way interoperability is too valuable a feature to make it worthwhile.

If the data is undocumented, then it's difficult to see how others could update their software to handle it. If what I see when I open a file are properties like "__muse.timebase": 75623190 what does this mean? And if it's undocumented, then how could I be sure that I'm handling all the possible values? Maybe a specific vendor property is only used in 1 out of every 100 files... that's a lot of work to make sure my software can handle your data. And I would have to do this same thing for every possible vendor's data.

I think people will do this in practice. Some devs are not known for following specs terribly closely, either because of laziness or inexperience, particularly in large corporations (I'm looking at you, Sibelius MusicXML support!) If you provide a way that lets them fit the format to their software, rather than insisting that they fit their software to the format, then I'm sure many people will take the former as it's usually much easier than the latter. Not everyone, mind you, and not all the time. But it will almost certainly happen.

[mscuthbert]

Rather than value and comment, it might make sense to usen symbols like = and # as the special object keys.

{
    "pitch": {"#": "This is the sounding pitch.", "=": "G#4"},
    "accidental": {"#": "Technically we don't need an accidental here.", "=": "sharp"}
}

I don't think we're going to recommend any key names that are not acceptable keys for objects in most modern and commonly used programming languages, since (as Andrew already noted) this removes one of the main advantages of accessing values via "measures[1].events[0].pitch.value" and similar standard routines.

I am going to advocate also for "_" over "-" as a standard word connector for the same reason.

But yes, a shorter name than "comment" or "value" might be a benefit.

[mscuthbert]

@ahankinson

@mscuthbert

I do want there to be a key on each object where individual vendors can store information which others can safely ignore

That opens up your format to proprietary markup, and allows vendors to slip in undocumented encoding data. If a vendor decides that it doesn't like the way "pitch" is encoded, for example, it can put in a basic value for the "standard" pitch, and then vendor the actual value in their own hidey-hole, while not releasing any documentation for it. This allows them to use your name for marketing purposes, while not actually conforming to the spirit of the community and open standards. This also promotes vendor lock-in. ("Oh, when I open this file in Finale it doesn't look as good as MuseScore, so I'm just going to recommend you use MuseScore to open this." Substitute any other notation editor for the named ones...)

It would be contrary to the spirit of the community and open standards if someone decided to store pitch: "C4" everywhere and put their actual pitch value in their own vendor specification. It seems to me with the community spirit if I decided to store a value at {'vendors': {'music21': {'harmonic_fundamental': 'Bb1', 'harmonic_number': 10, 'cents_off': -14.2} } } until the community decides that storing the fundamentals for harmonics was as important to them as it is to me.

There are many files in common use that look better in MuseScore than Finale. They end with .mscz'. And ones that look better in Finale than MuseScore (.musx`). Even 20+ years after the release of MusicXML over 99% (my estimate) of music files out there are not interoperable, because everyone uses internal formats that can represent all of their data without loss. Probably some vendors will still do that for efficiency or trade-secret reasons. But I'd like MNX to allow designers to decide to make it their main file format even if their software has features that MNX does not allow. This change would be the huge improvement for interoperability that no other standard has yet achieved.

[mscuthbert]

@ahankinson wrote in reply to @shoogle :

XML allows this with namespaces and but these are often hard to work with, and easily dropped in roundtrip code.

If a piece of software ignores a JSON key it doesn't know, it has a high probability of being dropped in round trip as well. This is just a reality of how this process works in practice:

• Read a file, extract the information you need
• Parse that into data structures in your code that your software needs
• Manipulate the data structures
• Save the changed data to a file

Yes, and the point that MNX can be used as an internal format allows this workflow:

• Read a file with JSON.parse (json.load, etc.) into a root object
• Manipulate the data structures you want to change
• Write the root object as a file

Values that you didn't touch such as comments, other vendor items, etc. remain preserved.

In music21 there are still parts of the MusicXML spec (and lots from MEI) that we can't work with as data (and definitely all other namespace items, processor instructions, etc.). Because there's no place to store them, they're dropped on parse and not emitted on writing. With a standard json-parsed-object for non-standard items, they can just be stored in one place and written out with the code on output.

There are disadvantages, of course, such as if someone changes the main pitch of a note, and a vendor has additional information stored about the original pitch, these might get out of date. But the same can happen with processing instructions/non-namespace items in XML.

If someone is transforming the JSON data into native objects, manipulating them, and then writing out JSON (what much software will likely do), then it becomes up to them to decide to preserve comments, vendor additions, etc. but this becomes much easier if there are only a few standard places where extra instructions can go (and these remain as basic JSON datastructures which, like asbestos, is harmless if left undisturbed).

[mscuthbert]

Let's try to have a conversation here

Meta discussion: Can I close and lock #290 so discussion stays in one place?

[mscuthbert]

It's locked.

[adrianholovaty]

Thanks for taking care of that!

[pavelstudeny]

Considering what can be done with one and not with the other, there is plenty of XSLT tools and native browser support for XSLT. This would still allow to transform MusicXML to MNX, but not the other way around. I'm not sure about the other pros and cons. E.g. XQuery and XPath without XSLT loses half the use cases.

I can't find advantages of JSON that would be impossible in XML except perhaps the upgrades mentioned at 8.

What's problematic on transforms in general is the scope. There is so many elements and attributes. A good structure of the schema with several sub-schemas would allow to differentiate the basic and less frequently used extras. To achieve this, XML schema nesting works better than JSON schema nesting, at least the last time I worked with it. This would be a little advantage of XML.

[shoogle]

I think the upgrades mentioned in advantage 8 are also possible with XML. I guess XML attributes can't be upgraded, but there is no requirement to use attributes (except possibly for forwards compatibility, which JSON doesn't natively support).

I don't think there is anything that JSON can do that XML can't. The main advantage is the simplicity of the format. XML is filled with bloat that hardly anybody needs, uses, or even truly understands (e.g. namespaces, and how they affect attributes differently to objects).

Of course there is no requirement for MNX to make use of those unnecessary features. MusicXML largely avoided them.

[mscuthbert]

I think the upgrades mentioned in advantage 8 are also possible with XML. I guess XML attributes can't be upgraded, but there is no requirement to use attributes (except possibly for forwards compatibility, which JSON doesn't natively support).

XML attributes are the only parts of the schema that are explicitly unordered: <a b="x" c="y"></a> is always the same as <a c="y" b="x"></a> whereas there are often real difficulties and complexities in saying that <a><b>x</b><c>y</c></a> is the same as <a><c>y</c><b>x</b></a>. This is what makes attributes important in any xml schema. I can't imagine specifying all of the styling attributes in MusicXML as a set of subelements that needed to appear at a particular place in a particular order, and the slowness in any schema to ensure that they all appear in the same order.

We're not yet at the point of defining style in MNX (see #283) but I think that the ability to treat what would have been attributes as objects will be powerful. Grouping all the (text) font attributes into an object { 'font': { 'family': ['Adobe Garamond Pro', 'Garamond', 'serif'], 'weight': 400, 'italic': true } } seems like a useful way to get the best of XML attributes and XML sub-elements.

[shoogle]

(I didn't want to turn this into a format war, but now it's a discussion I feel a bit less guilty about mentioning my personal favourite 😉)

I think MNX should consider using StrictYAML.

• Ordinary YAML looks nice, but it's bloated with features that nobody uses.
• JSON is simple, but it's ugly and annoying to write.
• XML is bloated, ugly, and annoying to write.

StrictYAML discards all the bloat from ordinary YAML so you're just left with objects, arrays, and string values. It's like JSON but a lot prettier and much easier to edit by hand.

XML	StrictYAML	JSON
<event id="event1" value="/4"> <note pitch="C4" /> <note pitch="Db5" accidental="flat" /> </event>	- id: event1 value: /4 notes: - pitch: C4 - pitch: Db5 accidental: flat	{ "id": "event1", "value": "/4", "notes": [ { "pitch": "C4", }, { "accidental": "flat", "pitch": "Db5" } ] }

Unlike JSON, StrictYAML supports comments and preserves key order in objects during a roundtrip.

Sadly StrictYAML only has one implementation and it's in Python. However, it is a subset of ordinary YAML so you can use any YAML parser and simply avoid using any features except for objects, arrays, and string values.

[ahankinson]

Sure, but if you're in JSON, then I would presume a first-order client language will be JavaScript, and doing ZIP compress / decompress in JS, while possible, isn't built-in. So you would need to rely on third-party libraries for that facility.

[mscuthbert]

In terms of support, there's XML and JSON which we can argue about (and are arguing about) which has the better built-in language support, schema tools, translation tools, editors, translation into native objects, etc. And then about a mile down the support/adoption chain are all the YAML variants (and TOML, .ini, etc.). I haven't consulted with the other co-chairs but I don't think anything but JSON or XML are likely to be the format of choice. The uncompressed file size of YAML is important. Yes, for exchange, one can gzip most of that space to nothing, but for storing in a database, even an internal sqllite format, and retrieval, all that whitespace storage becomes a major issue. One of my projects switched recently from the beauty of indented/well-formatted JSON to zero-whitespace JSON and saved 60GB of storage. I can't imagine not having that option.

[shoogle]

Technically you would still have that option as StrictYAML is really just another way of writing JSON. Both formats support objects, arrays, and string values, so converting between the two representations is fairly trivial.

But you would only need to do this if you want to perform queries on the MNX data while it is in the database, using the database program's built-in APIs for JSON manipulation (if it even has such APIs). If all you want to do is store the MNX data in a database and then access it later on then you could gzip it before storage and decompress when you retrieve it, saving far more room than if you just remove the whitespace.

[mscuthbert]

But you would only need to do this if you want to perform queries on the MNX data while it is in the database, using the database program's built-in APIs for JSON manipulation (if it even has such APIs).

This is exactly what I do. :-)

[adrianholovaty]

Thanks for the suggestion @shoogle, but I think YAML is a non-starter, if only because it would require a third-party parsing library in front-end JavaScript. The significant-whitespace factor also disqualifies it, in my opinion.

[ahankinson]

Schema validation is a good point in favour of XML. It will get lost here though so why not raise it in a separate thread on this discussion page?

Raising it here in a new thread. But I will point out that JSON has JSON Schema which I imagine any standardization effort would need to adopt. A format that cannot be validated somehow isn't a great format.

[mscuthbert]

Great point. When MNX was first being discussed, I wanted to advocate for JSON, but the schema support was not there. I was using schema'd JSON ca. 2015 in a project and I was appalled what it couldn't do (I was adding all sorts of random fields just so the schema could distinguish one object from another). Without a verifiable schema, there's no way to recommend the format.

Since then, JSON schemas have become well standardized, adopted, and powerful. Most top XML schema editors also support JSON schema. There are easy implementations for every major programming language except pure-C (C# and C++ and objective C is fine; Swift at https://github.com/kylef/JSONSchema.swift) There will be a question on whether we can implement in the 2020 version or need to use 2019 or draft 7 for widest support. (My view is generally when creating a new format, use the latest spec at the time you start and by the time MNX is at 1.0, the tools will have caught up; but that's just my thought). ajv (the node/JS implementation) is especially strong and fast. If you have any packages that use any node_modules, odds are you already have ajv installed.

I've been looking through key snags that would have happened if MusicXML's schema were implemented in JSON schema instead (NOTE: THAT IS NOT UNDER CONSIDERATION) and I couldn't find any that would have appeared from draft-07 or above.

[paul-bayleaf]

The current MNX documentation makes use pseudocode to define parsing of micro-syntaxes, e.g. the Chromatic pitch data type. Making the MNX JSON schema a formal part of the specification would greatly reduce the need for such pseudocode. The micro-syntax of strings can be defined in the schema by regular expressions. E.g. "pattern": "^A-G[0-9]+([+-][0-9./]+[ow]?)?$" or some such. The text can then concentrate on the semantics of the string, whereas the syntax is defined formally by the schema, not by pseudocode.

I would very much like to see the schema developed hand in hand with the descriptive specification, and not something that is left until the end, - q.v. continuous integration.

[mscuthbert]

Agreed with @ahankinson -- and json-schema allows regular expressions for complex datatypes as well: https://json-schema.org/understanding-json-schema/reference/regular_expressions.html . I believe it exceeds XML Schema (because it's a newer format) in that property keys (equivalent to XML attribute names / element-or-tag names) can also be regular expressions (pattern properties) as well: https://json-schema.org/understanding-json-schema/reference/object.html#patternproperties

I'm not so convinced that microsyntaxes are the way to go for a data structure that can also be used internally (I'm highly unlikely to store "Db4" anywhere as a fundamental data type; more likely to store it as {'step': 'D', 'acc': 'b', 'octave': 4}, or something more abbreviated.) but that's not on this discussion.

[ahankinson]

Both XML Schema and RelaxNG schemas allow regular expressions for attribute datatype validation. We also use this extensively in MEI for complex datatypes (like measure/beat timestamps) and to only allow [a-g] as pitchname values, among other things.

Here's a fairly compact example where we define an attribute datatype allowing only certain values for harmonic intervals: https://music-encoding.org/guidelines/dev/data-types/data.INTERVAL.HARMONIC.html

[mscuthbert]

Yes, XML Schemas can do this. I was pointing out that so can JSON Schemas.

[ahankinson]

Sorry, I was responding to "I believe it exceeds XML Schema..." and just pointing out that you can do that with XSD and RNG as well (so they're still on par). +1 to your microsyntaxes comment too.

The funny thing is, I don't consider myself an "XML guy". I really don't like XSLT (couldn't write my way out of a wet paper bag there) and wouldn't ever choose XML as a data communication format (e.g., client/server). But as a document encoding format, I'm still struggling to see the advantages of using JSON; I'm not aware of any other "document encoding" format in JSON, for any kind of material: Text, Music, etc.

[mscuthbert]

Ah! I didn't realize that XML Schema could have regex in property keys. My bad if that's possible.

Part of my believing that XML Schema are limited is from MusicXML which began as DTDs. So for now, the MusicXML Schema only uses features that are also available in DTD. The DTD for MusicXML is deprecated since 4.0 (though the outage of the dtd on musicxml.org was unplanned and still being investigated), so it's time for me to think about a future for Schemas that isn't limited to DTD.

(But given that I'm not an XML expert like Michael Good is, and I have a lot to catch up on...just hinting...it's possible that the DTDs might go away in MusicXML 4.1, or at least by 5.0 -- I'll make an issue there to discuss).

[adrianholovaty]

I've been reflecting on the various feedback, and here's a general observation/question: for the people who prefer XML over JSON, how much of that preference is tied to your usage of static typing?

Personally I use dynamically typed languages — primarily Python and JavaScript — so I'm completely comfortable with the idea that a data format would itself be dynamic. By this, I mean I'm happy to parse it without requiring a formal schema, and philosophically I'm completely OK with not knowing types of things until the last possible moment. I'm also deeply influenced by Postel's law: "be liberal in what you accept."

For those of you who primarily use Java, C++, etc., does something about JSON's dynamic nature clash with your approach to programming?

I personally have never used a formal schema when parsing XML or JSON, across two decades of being a professional software developer, but the various comments here have opened my eyes to other developers' desire for formal schemas. I have a hunch this is a sort of fundamental difference in attitude, which may be correlated with strong typing, and I'd like to understand it more.

To make this general point in another way: I'm wondering how much of the anti-JSON pushback represents a larger cultural difference (static vs. dynamic) more than anything else.

[paul-bayleaf]

For C++ there is plenty of support for JSON - the main problem being which of the many JSON libraries to choose.

This lists some JSON libraries from github:
https://bestofgithub.com/blog/c-libraries-for-manipulating-json-data-format_73.

The boost library also supports JSON:
https://www.boost.org/doc/libs/1_81_0/libs/json/doc/html/index.html

[evanlenz]

@adrianholovaty Thanks for the inquiry. Actually, I regularly use XSLT and XQuery which by default are dynamically- and weakly-typed languages. I have often eschewed the use of a schema when it's unnecessary. But for an interchange standard I agree that it's necessary. Another benefit of schemas besides validation (and maybe this was implied) is that it simplifies your code because you have fewer scenarios to code for. Many useful assumptions are thus rolled up into a single assumption: that the input is valid.

XSLT also offers schema-aware processing (which I haven't personally used as yet).

Ironically, if JSON is used, I might delve more into the static-typing world to see how Haskell might be used to process it. (I see there's a Hackage library called aeson.)

But if I'm realistic, I will probably convert between JSON and XML so I can still use the power of XSLT against MNX data. Or define a custom view (maybe using Invisible XML if it makes sense, though I doubt it). Saxon and XSLT 3.0 actually support JSON but not to the degree that you get with transformations of XML node trees.

I personally think that tying the specification to an object serialization format (JSON) favors some programming paradigms at the expense of others. I also fear that it will be very tempting to design it too closely to fit the designers' own language and internal APIs of their own product(s) and, as a result, other products' will have the same temptation and consequently create a splintering of the format in the wild. (And everyone will feel frustrated, since the standard format is almost native to them but never quite all the way.) Whereas with XML, this temptation won't be there, since no one can skip the mapping step (by design). It would be designed purely in terms of its semantic integrity, and the design process would not feel pressure to shoehorn the format into the native processing environment of a particular product.

[ahankinson]

I also fear that it will be very tempting to design it too closely to fit the designers' own language and internal APIs of their own product(s) and, as a result, other products' will have the same temptation and consequently create a splintering of the format in the wild.

👍 🎉 ☝️

This is a really important observation IMO.

[adrianholovaty]

Rest assured that MNX already is significantly different from the internal format of my own product and I don't see that trend changing. If anything, I'll be changing my product's internal format to more closely match the decisions we've made in MNX — not the other way around.

[mscuthbert]

Like @adrianholovaty I don't think I'll get anywhere even if I wanted to (which I don't!) in making MNX look like music21's internal data format. But I do think that for anything music21 doesn't already natively support, I'm more likely to make the format respect decisions of MNX (as I've done with musicxml and Dublin Core and MuseScore and in one case already MNX) than to make my own. And for things that are not in MusicXML or MNX, I'll try to make my own format something that looks palatable to become part of the format in the future.

Just to reply to a previous message, I don't think the whole css: -moz-glob-glock: 1px; -ie-glob-glock: 1px; -o-glob-glock: 1px; glob-glock: 1px stage has been a disaster. In my own projects I've done this and one of my joys each New Year is reviewing browser support and figuring out what has enough support for standards that I can remove -...-box-shadow, for instance, in favor of standards. The alternative is never having support for glob-glock in any system which is vitally important to me. One of my major projects that, looking at old code, had 100 different places where we had vendor support tags now has only three. And half of them were related to disability access. Those were 50 places where if we followed only endorsed standards we would have had an inaccessible website for everyone for three additional years for everyone, instead of an inaccessible website for 30%, then a year later 10%, then 3% of users (still about 1% because just because a standard exists doesn't mean everyone implements it)

[evanlenz]

I was happy to see that the co-chairs still consider the issue open. I'm wondering if it would be amenable to the co-chairs if we explored some friendly parallel development of MNX in both XML and JSON formats. I don't mean committing to both XML and JSON as alternative formats (though that's always a possibility). More concretely, I'm wondering if I might have the blessing of the co-chairs to contribute my XML (and music) expertise toward the continued development/maintenance of MNX in XML format. I had shown interest a couple years ago (MNX having the distinction of being the topic of my last tweet 😁). And @adrianholovaty replied with a friendly invitation to get involved. But I had not followed up in earnest until now, after it might be too late!

I bring this up for three immediate reasons, all related:

• I've been incrementally enhancing my (still early-stage) painless-mnx project for converting MusicXML to MNX using XSLT; working on this is a good way to get my head into the music representation space.
• I'm still hopeful that XML is a serious candidate for consideration as the format for MNX.
• I'd like to propose rolling back a specification change (based on DTD-era practices and a misunderstanding of XML Schemas) that escaped my attention a year ago (because I wasn't paying attention): the renaming of elements to <measure-global> and <directions-global>.

What are people's thoughts on the overall idea? Does it make sense to welcome my involvement in this way? If so, how can I contribute? There's nothing like the potential loss of something I loved to motivate me to do so. Thanks for your consideration.

[evanlenz]

I suppose it would make sense to briefly mention my relevant background. I'm professionally trained as a classical pianist and professionally engaged as an independent software engineer. I've written several books on XML. I was formerly a member of the W3C Joint XSL and XML Query Working Groups, helping to define XQuery 1.0 and XSLT 2.0.

MNX represents an intersection of passions for me. Musical data representation has become most relevant to me because of my interest in creating tools to help people memorize information to be performed (whether piano music, play scripts, or memory verses). Data transformations (and thus a plurality of user-level representations) are central to enabling the tools I'm creating.

Parallel development of MNX in XML might support an "iron sharpening iron" effect for the JSON design efforts, such that whatever the final outcome (JSON, XML, or both), you might benefit from hearing the XML-centric perspective. For example, even though JSON is theoretically just a data format, I understand that there's typically no way in JSON APIs to provide something akin to XPath's "parent axis" (I supposed because an object's parent is not considered to be a property of that object). I'm not yet sure how this would affect the design of MNX in JSON, but discussion on things like this might be fruitful, especially when looking at use cases for data processing.

[adrianholovaty]

@evanlenz Thanks for the extra context!

I don't think it would be a good idea to develop MNX in both XML and JSON in parallel. We're already risking the project's momentum by considering the move to JSON, and prolonging the "pain" by keeping both options open for a long time wouldn't be healthy. We should bite the bullet, pick one and commit.

Your experience with data processing in XML is definitely valuable to the project, though, so I hope you continue to poke holes and raise issues with the JSON approach.

To your specific point about accessing elements' parents: with JSON, I'd expect this to be done at the level of a custom script as opposed to a translation language such as XPath.

[paul-bayleaf]

As a light relief, I found this looking for views on JSON. It's somewhat tongue-in-cheek, and a little out of date, but looking past the humour and sarcasm there are some interesting comments on JSON in here.

JSON Considered Harmful

https://taylor.town/json-considered-harmful

[pavelstudeny]

There are many statements that are not applicable for MNX, shared between XML and JSON or outdated, e.g. the schemas mentioned in point 2..

[adrianholovaty]

Closing this, as the JSON decision has been made. Thanks to all for the thoughts!