Seems like there's a bunch of problems:<p>1. It relies on later stages to do things like convert to native values or remove whitespace. As such an intermediary can't really "understand" the document very well. E.g., if you are using this syntax to express key/value then you can only know the keys if you know the whitespace rules that will be used to interpret the keys.<p>2. It reminds me more of XML than S-Expressions. If you are familiar with the ElementTree [1] representation of XML then these parsed examples become more familiar, just a prefix instead of suffix, and no attribute children.<p>3. Connecting whitespace and XML, I suppose this explains why so many XML formats ended up only using attributes for text values, and used tags and children only for nesting. Otherwise interpretation requires understanding how to interpret these mixed documents with unclear whitespace rules. But Jevko doesn't have attributes.<p>4. If an intermediary can't understand it then why define a syntax at all?<p>5. I don't see any escaping rules so including literal [] seems... impossible? You can essentially deserialize the parsed value to reintroduce them, but that's weird and awkward, and only works with balanced brackets anyway.<p>6. No way to embed binary data, or otherwise uninterpreted data. JSON has the same problem. Base64 encoding things is yet another way in which the data is not interpretable by intermediaries.<p>I think XML shows that "just strings" isn't fatal, and lots of things get jammed into strings in JSON too, you'll never be able to reproduce every type in a general purpose serialization format (I guess XML with namespaces attempted, but also clearly failed). So I can see a place for something that defines a tree where all leaves are strings. But this doesn't seem like a very clean way to do that.<p>[1] <a href="https://docs.python.org/3/library/xml.etree.elementtree.html#element-objects" rel="nofollow">https://docs.python.org/3/library/xml.etree.elementtree.html...</a>
I don't understand the whitespace handling here, it seems very underdefined?<p>Taking the example from github page (abbreviated):<p><pre><code> first name [John]
last name [Smith]
address [
street address [21 2nd Street]
]
</code></pre>
why isn't it equivalent to this json?<p><pre><code> {
"first name ": "John",
"\nlast name ": "Smith",
"\naddress ": {
"\n street address ": "21 2nd Street"
}
}
</code></pre>
somehow the whitespace is instead implicitly magiced away, but that isn't defined in the grammar anywhere as far as I can see?
I'd be interested in a more detailed comparison to s-exprs. Jevko reads less noisily because it uses fewer brackets, which is nice, but the ambiguity around whitespace gives me pause.<p>How is it simpler or lower-level than s-exprs?
I appreciate your effort, but your explanation on the first page is too abstract to the point that I read to the end and still didn't know exactly what Jevko is and how to use it.<p>E.g. you introduce "Subjevko" as if it's known knowledge.<p>Also, the singular link to "examples" on that page, which is what I <i>really</i> want to see first, was broken.<p>My advice: for every point you make have a single, simple, illustrative example right below the explanatory text (or better yet, right above it!).
Found an example where it is used as markup: <a href="https://github.com/jevko/jevkodom.js/blob/master/test.js#L6" rel="nofollow">https://github.com/jevko/jevkodom.js/blob/master/test.js#L6</a>
How does this relate to the (earlier?) tree-annotation/TAO system (seemingly from the same author): <a href="https://djedr.github.io/mirror/tao/tao.html" rel="nofollow">https://djedr.github.io/mirror/tao/tao.html</a>
Nice! I wrote a little parser for it (<a href="https://github.com/lgastako/jevko" rel="nofollow">https://github.com/lgastako/jevko</a>). It was fun. I'll have to play with building higher level formats on top of it.