4 ms·
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 el
by olavk 9y ago
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.
- singularity2001 9y agofor completeness: json5 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. {cite "Hello" {i "world"}}
- olavk 9y agoOh, that is pretty cool. I didn't know about json5. This would also be quite nice for config files. Regular json is not nice for config files due to lack of comments. Json5 is still not as "editable" as it looks though. You need to separate values with comma (except the last value), so there is more syntactic noise. So you get: { size: {width:100, height:100 /*yay*/}, } This is not an issue when the text is machine-generated (as Json typically is), but is an issue when it is edited by hand as config files often is.
- anentropic 9y agoYAML is nicer still for config files
- olavk 9y agoYeah, nicer to read and write. More complex to parse though. S-expressions are incredibly simple to parse. But I guess every language have a YAML-parser these days.
- akvadrako 9y agoI do prefer to write YAML, but the complexity is so bad every parser in every language is broken: http://matrix.yaml.io http://matrix.yaml.io
- anentropic 9y agobut for config you can stick to a self-documented subset of YAML that works so in practice you don't notice any brokenness it's not like a web browser that has to work on a diversity of third party sources I'm not even sure how to read that matrix anyway, and it does say: > The YAML Test Suite currently targets YAML Version 1.2. ... some frameworks implement 1.1 or 1.0 only
- akvadrako 9y agoWhat's the point in using YAML if you're using an ad-hoc subset!?
- phoe-krk 9y agoMark has the "}}}}} problem with larger documents, so it is not as suitable for human-written markup. And HTML has a problem of </span></li></ul></div></div></div></div></body></html>, all spread over nine different lines, one tag per line. Take a look at https://github.com/keithj/alexandria/blob/master/definitions.lisp#L24 https://github.com/keithj/alexandria/blob/master/definitions... which is Lisp code styled in a standard manner. I don't see any problem there.
- henryluo 9y agoHTML has the problem of </div></div></div></div></div></div></div>. Lisp has the problem of '))))))))'. JSON has the problem of '}}}}}}'. And YAML has the problem of deep indentation. When it comes to worse-case scenario, no one wins. :-(
- olavk 9y agoThe HTML example is much better than "}}}}} though, since you can e.g. add a new item at the end of the list without needing a specialized editor to locate the right position. This is one of the reasons for the redundancy in repeating the tag name in the end-tag. In theory Lisp should have the same problem, but usually code (hopefully) rarely have nested blocks larger than a screen, so it is not a big issue in practice, even if )))) looks ugly. Bottom line is code have a different structure than typical hypertext documents, so just because a notation is suitable for one does not mean it is suitable for the other.
- henryluo 9y agoBut when s-expression is used to represent document, not a program, then it is also not free to refactor deep nested content. So s-expression is no better than XML/HTML/JSON/Mark when encountering deep nested content.
- olavk 9y agoIt is exactly the same as Mark, but I am arguing it is worse than XML/HTML for these scenarios.