Mark – A simple and unified notation for both object and markup data (github.com)

I don't know if it's useful to have a universal format; each format (YAML, XML) is suited for for a specific purpose (human readable, completeness).

The headline reminds me of: https://xkcd.com/927/

Looks awfully similar to Clojure's EDN

waiting for mark 2. No... seriously, it's enough already https://xkcd.com/927/

So this is literally Lisp, just with curly braces instead of parenthesis :).

I don't understand this part of the readme:

> The advantage of Mark over S-expressions is that it is more modern, and can directly run in browser and node.js environments.

Does this mean I'm so out of date with JS that this syntax is actually legit JS? Or does Mark run its own parsers, at which point it's just like sexps, except it uses the "more modern" curly brace instead of "less modern" parenthesis?

    #S(foo :bar 3)

    #(1 2 3)

  ;; structure:
  #s(type :slot1 value1 :slot2 value2 ...)

  ;; vector:
  #(1 2 3 4)

Interesting project but a little overboard with the self back-patting in the README.

> The advantage of Mark over S-expressions is that it is more modern, and can directly run in browser and node.js environments.

There seems to be a ton of s-expression parsers in npm already, that can run in browser and in node.js: https://www.npmjs.com/search?q=s-expression

Besides being able to run in js environments, what else does {mark} bring over s-expressions?

I like the idea but I don't think the benefits outweighs the negative implications it would have to implement it.

I mean JSON as a data format for api stuff is just enough as it is and you'd need some serious reason why to change from JSON and these reasons just doesn't cut it.

Needs a "Why was Mark created?" section because this appears more 'neat' than 'useful'.

If you want a better JSON, try binary-json "Concise Binary Object Representation" RFC 7049 http://cbor.io/

Looks like a worse HAML...

Defining the type of objects is a must when you want to exchange things in a strongly typed environment (Java on the server, TypeScript on the client, for ex). So +1 for {mark}. Do you handle multiple typing? (We use that a lot in Neo4J, and we think it is really neat)

Another comment: Coming from a Semantic Web background, and using N3 as the exchange format and N3.parse() as my client-side lib, I would advise to have a UID parameter to uniquely identify objects, and a refId syntax, so any parameter can reference some other objects of the data structure. That helps when you want to transmit a graph [1].

My humble 2 cents.

[1]: I would add that it is also useful when you retrieve some refIds that are not defined in the current data structure. You can then ask the server to dereference these refIds, and send another (portion of the) graph, that you can connect with the existing data structure.

So it's basically just XML with curly braces or sexps...

And why bring YAML in the mix? Yaml isn't used for transfer I hope? Should be compared to TOML as well in that case that seems a lot better than YAML, especially for configs: https://github.com/toml-lang/toml

Or msgpack? Which also seems useful. Why not protobuf? Or just s-exps which is basically what this is.

Not sure how many more xkcd 927s this thread will have but personally what bugs me the most is the thought that being slightly more versatile than JSON means that Mark is worth the trouble of adopting. Data structures are well represented by JSON, markup is mostly well represented with XML. I rarely really want to mix the two. Additionally, this doesn't feel like a language I would want to write documents in any more than I do XML.

I think we're fine with separate languages for data and markup.

"Whoever does not understand Lisp is doomed to reinvent it"

- A wise man on the Internet once said

> It has clean syntax

You could remove every '{' with 0 loss of meaning.

One major weakness of JSON is lack of a corresponding "infoset"; that is, an equivalence predicate. When are two JSON blobs "the same"? There's no sign of anything like this here.

Another is the lack of support for binary data. There's no sign of support for binary data here.

Finally, there's this claim:

> The advantage of Mark over S-expressions is that it is more modern, and can directly run in browser and node.js environments.

Is it more modern? I don't think I care.

Can it directly run in browser and node.js environments? What does that mean? It seems to need a parser. But then, S-expression parsers certainly directly run in browser and node.js environments.

---

IMO, SPKI SEXPs are much more sensible than this design and many, many other designs:

https://people.csail.mit.edu/rivest/Sexp.txt

    (my_dict (key value) (key value) (key value))

Comparing {mark} to XML, it doesn't seem to support namespaces which makes the claim to be extensible somewhat dubious. How am I supposed to add custom objects without risking name clashes? Namespaces also make XML kind of fully typed without being tied to a single programming language.

Another strength of XML is support for mixed content which seems rather awkward in {mark}. The following

    <p>Some <b>bold</b> text</p>

apparently needs to written as

    {p 'Some' {b 'bold'} 'text'}

It would be more honest to mark support for mixed content as "verbose" in the feature table.

Besides, the name {mark} seems like a bad idea. How could you find relevant results when searching for {mark} using a search engine?

What would you use for schema validation? Obviously http://json-schema.org/ won't cut it.

> Mark utilizes a novel feature in JavaScript that an plain JS object is actually array-like, it can contain both named properties and indexed properties.

Where can I read more about this feature of JavaScript?

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 "mark" 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 "mark" as the name of a library that lets you put marks based on geographical criteria on a map or something totally different.

Mark reserving all number-only keys is statistically likely to become a problem as a project grows larger. I'd suggest finding a different way to get out-of-band data to be fully out-of-band, rather than trying to carve out a chunk of keys.

Somewhat similarly, defining a "pragma" as "something surrounded with braces that isn't a legal object" means that if you ever want to change the definition of an object in the future, you can't, because you will turn things that used to be pragmas into objects, or less likely (because you'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.

I would reserve saying "Mark is a superset of JSON" 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 "superset" it is qualified as a "feature superset". Especially in light of "(Mark does not support hexadecimal integer. This is a feature that Mark omits from JSON5.)" The word superset should either be qualified every time or mean a strict superset; "Mark is a nearly-feature-superset of JSON" would be more accurate.

In general, a review of http://seriot.ch/parsing_json.php 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't-know-how-many-nines percent of the time, JSON is a thing my tools generate; the cases where that is a serious 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 even more subtle divergences in its multiple implementations and things like "misreading an object as a pragma" to become even more likely at scale.

nope, data shouldn't include structural information (except maybe in the header) and markup shouldn't include style information.

Each existing format have advantages and disadvantages for particular purposes.

Benefit of HTML: You can actually write it by hand and easily see where each element begins and ends, even when the document is longer than a screenfull. Mark has the "}}}}} problem with larger documents, so it is not as suitable for human-written markup.

It is not clear to me how mixed content like <cite>Hello <i>world</i></cite> is expressed in Mark. I expect it will be pretty convoluted.

Benefits of JSON: Maps directly to simple data structures: List, dictionaries and simple values. Similar data structures are supported in almost any language. Mark has "type names" and anonymous text content which complicates serialization and serialization a lot, and is sure to give interoperability (and perhaps security) problems.

So - worst of both worlds? Instead of tying to be an overall worse alternative to all the formats, they should rather focus on a specific niche where Mark can be a better alternative.

Take configuration files, for example. They don't have large amount of textual content like HTML, and they don't need to be transferred between disparate systems.

   {size width:100 height:100}

vs

   <size width="100" height="100"></size>

vs

  {"size": {"width":100,"height":100 }}

In this case, the Mark syntax is simpler and cleaner. Mixed content is not needed, which would make the format simpler. Yeah it is basically the same as S-expressions, but that is not a bad thing.

  size: {width:100, height:100 /*yay*/}

  It is not clear to me how mixed content like <cite>Hello <i>world</i></cite> is expressed in Mark.

  {
     size: {width:100, height:100 /*yay*/},
  }

Reinventing LISP is a nice thing.

I like this project.

Pros: At least its not JSONx :D

Cons: Not seeing any advantage over JSON. If you want a type for objects just add a type field and have your code read it. Then you can use any of the existing parsers.

The doesn't have a grammar? When will people realize this is completely unacceptable.