4 ms·

Seems like there's a bunch of problems: 1. It relies on later stages to do things like convert to native values or remove whitespace. As such an intermediary c

Seems like there's a bunch of problems: 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. 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. 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. 4. If an intermediary can't understand it then why define a syntax at all? 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. 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. 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. [1] https://docs.python.org/3/library/xml.etree.elementtree.html#element-objects https://docs.python.org/3/library/xml.etree.elementtree.html...

djedr 4y ago
> 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. From the point of view of Jevko, handling whitespace is a higher-level concern. Indeed, you typically will need additional rules to communicate effectively with it. This is where you should specify a format (which should be standardized) that you use, e.g.: * https://github.com/jevko/easyjevko.lua https://github.com/jevko/easyjevko.lua Note: this is just a simple library I wrote recently that does the most straightforward thing imaginable. I haven't yet wrote a spec for the format. > 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. Yes, Jevko has the features of both XML and S-expressions (or neither, depending on how you look). It's supposed to be uniquely suitable for both markup and encoding of data/code in a simple way. > 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. A markup format built on Jevko can have the notion of attributes and rules for whitespace, e.g. see https://news.ycombinator.com/item?id=33334774 https://news.ycombinator.com/item?id=33334774 -- a nice thing about this particular format is that text nodes are explicitly specified, so you know exactly where your significant whitespace goes. The nice thing about attributes made with Jevko over XML attributes is that you could naturally make them extensible (which is a pain in XML -- if you want to turn your unstructured string value stored in an attribute into a tree you have a problem). > 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. That's not correct. There are only 3 special symbols (delimiters) and they can all be escaped. It's all in the specification. > 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. Indeed, Jevko is not a binary format. Although I've been experimenting with binary equivalents, e.g.: https://github.com/jevko/binary-experiments https://github.com/jevko/binary-experiments At some point I might go forward with one, but that's not the focus right now.
int_19h 4y ago
In XML world, XDM (XPath and XSLT data model) is the de facto standard on how to interpret whitespace.
- djedr 4y ago
  If this standard is abstract/modular enough then it should be easy to use/adapt it for use with Jevko. A Jevko-based markup format combined with that would then be similar to XML+XDM, albeit much more minimal. This would be in line with how Jevko is intended to be used.

djedr 4y ago

> 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. From the point of view of Jevko, handling whitespace is a higher-level concern. Indeed, you typically will need additional rules to communicate effectively with it. This is where you should specify a format (which should be standardized) that you use, e.g.: * https://github.com/jevko/easyjevko.lua https://github.com/jevko/easyjevko.lua Note: this is just a simple library I wrote recently that does the most straightforward thing imaginable. I haven't yet wrote a spec for the format. > 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. Yes, Jevko has the features of both XML and S-expressions (or neither, depending on how you look). It's supposed to be uniquely suitable for both markup and encoding of data/code in a simple way. > 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. A markup format built on Jevko can have the notion of attributes and rules for whitespace, e.g. see https://news.ycombinator.com/item?id=33334774 https://news.ycombinator.com/item?id=33334774 -- a nice thing about this particular format is that text nodes are explicitly specified, so you know exactly where your significant whitespace goes. The nice thing about attributes made with Jevko over XML attributes is that you could naturally make them extensible (which is a pain in XML -- if you want to turn your unstructured string value stored in an attribute into a tree you have a problem). > 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. That's not correct. There are only 3 special symbols (delimiters) and they can all be escaped. It's all in the specification. > 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. Indeed, Jevko is not a binary format. Although I've been experimenting with binary equivalents, e.g.: https://github.com/jevko/binary-experiments https://github.com/jevko/binary-experiments At some point I might go forward with one, but that's not the focus right now.

int_19h 4y ago

In XML world, XDM (XPath and XSLT data model) is the de facto standard on how to interpret whitespace.

djedr 4y ago
If this standard is abstract/modular enough then it should be easy to use/adapt it for use with Jevko. A Jevko-based markup format combined with that would then be similar to XML+XDM, albeit much more minimal. This would be in line with how Jevko is intended to be used.