4 ms·
Good question! Jevko itself, defined by the spec, is not the same as a format based on Jevko. If you use a plain spec-compliant Jevko parser you for this you
by djedr 4y ago
Good question!
Jevko itself, defined by the spec, is not the same as a format based on Jevko.
If you use a plain spec-compliant Jevko parser you for this you indeed should have all whitespace included. Although it will look more like this:
{
subjevkos: [
{ prefix: "first name ", jevko: { subjevkos: [Array], suffix: "John" } },
{ prefix: "\nlast name ", jevko: { subjevkos: [Array], suffix: "Smith" } },
{ prefix: "\nis alive ", jevko: { subjevkos: [Array], suffix: "true" } },
{ prefix: "\nage ", jevko: { subjevkos: [Array], suffix: "27" } },
{ prefix: "\naddress ", jevko: { subjevkos: [Array], suffix: "\n" } }
],
suffix: ""
}
Now on top of that you can build a format that specifies what happens to whitespace, etc. Usually you'd want it trimmed if the prefixes mean keys in a map.
The simplest format/library that does just that is this:
* https://github.com/jevko/easyjevko.lua https://github.com/jevko/easyjevko.lua
* https://github.com/jevko/easyjevko.js https://github.com/jevko/easyjevko.js
That will give you the JSON (or equivalent) that you expect (with autotrimmed keys).
- zffr 4y agoIf the Jevko spec does not handle white space and leaves it to clients, then it will cause issues for data interchange. In order for 2 different clients to read the same Jevko file, they will need to align on how they handle white space.
- HelloNurse 4y agoFor the dubious benefit of defining only three special characters (opening delimiter, closing delimiter and escaping prefix) without the usual commitment of defining a whitespace character class (like in most mainstream languages) and/or more delimiters and punctuation. Jevko seems "simpler" than traditional syntaxes in the same way that a heap of bricks is simpler than a wall.
- djedr 4y agoThis is a valid concern, but on a higher-level. Jevko leaves whitespace handling not to clients, but to formats built on Jevko which would be the thing the clients typically use (rather than plain Jevko). Such formats of course should be clearly specified, which is something I hope to get around to soon. I already have a good candidate format for specifying first, which has 2 implementations: * https://github.com/jevko/easyjevko.js https://github.com/jevko/easyjevko.js * https://github.com/jevko/easyjevko.lua https://github.com/jevko/easyjevko.lua For more details see also: * https://news.ycombinator.com/item?id=33335181 https://news.ycombinator.com/item?id=33335181 * https://github.com/jevko/specifications/issues/1 https://github.com/jevko/specifications/issues/1
- zokier 4y agoWithout any whitespace rules I wouldn't really call this human-readable format. The canonical serialization of a tree is without any whitespace and unlike json/xml/sexpr you can not reformat the document for human readability because any added whitespace changes the content.
- djedr 4y agoPlain Jevko is a notch below JSON/XML/S-expr -- it's not really a format, but a syntax that can be leveraged to build a format. This is where the rules for whitespace would be specified. These can then be taken advantage of by tools to reformat, etc. The simplest format that I came up with and should specify next that will most likely do what you want is Easy Jevko. For details see this rabbit hole: https://news.ycombinator.com/item?id=33337098 https://news.ycombinator.com/item?id=33337098 For an alternative minimal syntax which is based around whitespace check out: * https://ogdl.org/ https://ogdl.org/ * https://treenotation.org/ https://treenotation.org/