Mark – A simple and unified notation for both object and markup data
I would strongly suggest a renaming. Mark is so generic that you can already tell you want {mark}, which has a pronouncability issue, and the name is too similar to the big player that is markdown (like a bright star making it impossible to see a dimmer one right next to it), making &quot;mark&quot; sound to me more likely to be a markdown renderer than a JSON replacement. Given that both mark and markdown are markup languages of various sorts, the names are just too close to each other, i.e., it would be different if markdown was what it was and you were proposing &quot;mark&quot; as the name of a library that lets you put marks based on geographical criteria on a map or something totally different.<p>Mark reserving all number-only keys is statistically likely to become a problem as a project grows larger. I&#x27;d suggest finding a different way to get out-of-band data to be <i>fully</i> out-of-band, rather than trying to carve out a chunk of keys.<p>Somewhat similarly, defining a &quot;pragma&quot; as &quot;something surrounded with braces that isn&#x27;t a legal object&quot; means that if you ever want to change the definition of an object in the future, you can&#x27;t, because you will turn things that used to be pragmas into objects, or less likely (because you&#x27;ll try to avoid this going forward) but still possible, vice versa. You need to concretely specify what a pragma is unambiguously, in a way that you can evolve either without affecting the other. It also means errors in generation become legal pragmas instead of errors, which will cause surprises, and on the flip side, errors in parsing objects can turn them into legal pragmas rather than parse errors.<p>I would reserve saying &quot;Mark is a superset of JSON&quot; for the case when you really can feed any JSON to a Mark parser and get a (roughly) equivalent structure. Alternatively, go through the documentation with a text find option and make sure every time you say &quot;superset&quot; it is qualified as a &quot;<i>feature</i> superset&quot;. Especially in light of &quot;(Mark does not support hexadecimal integer. This is a feature that Mark omits from JSON5.)&quot; The word superset should either be qualified every time or mean a <i>strict</i> superset; &quot;Mark is a nearly-feature-superset of JSON&quot; would be more accurate.<p>In general, a review of <a href="http:&#x2F;&#x2F;seriot.ch&#x2F;parsing_json.php" rel="nofollow">http:&#x2F;&#x2F;seriot.ch&#x2F;parsing_json.php</a> may be appropriate; mark addresses only one serious issue, and the other fixes are ultimately fairly superficial (the trailing comma issue, for instance, is almost never a problem for me because ninety-nine-point-I-don&#x27;t-know-how-many-nines percent of the time, JSON is a thing my tools generate; the cases where that is a <i>serious</i> issue have generally already moved on to another format like YAML, same for comments). Also, per my comment about parse errors turning objects into pragmas, if you expect this to become a big cross-language standard it is worth reviewing a snapshot of the variability in JSON parsers, which is a simpler format. A more complicated format should expect to see <i>even more</i> subtle divergences in its multiple implementations and things like &quot;misreading an object as a pragma&quot; to become even more likely at scale.