specifications VS easyjevko.js

Notice that here I used a convention where names which end with "=" become XML attributes, whereas names which don't become children.

I have used the same convention here (except I don't bother with transforming names with spaces into camelCase): https://github.com/jevko/specifications/blob/master/easyjevk... to generate this HTML file: https://htmlpreview.github.io/?https://github.com/jevko/spec...

Now I intend to write specifications that codify conventions like this into different formats based on this fundamental syntax of square brackets.

It can be useful for all kinds of things. Its advantage is extreme simplicity and flexibility.

BTW, for clarity I have to say that the format that I used here: https://news.ycombinator.com/item?id=32995047 does a bit more transformations -- it actually sometimes treats whitespace as a separator (e.g. in `svg width[391]` space is a separator). That allows for extreme conciseness, but is not necessary and introduces complexity.

A plain Jevko parser simply turns your unicode sequence into a tree which has its fragments as leaves/labels.

No data types on that level, much like in XML.

Now above that level there is several ways to differentiate between them.

The simplest pragmatic way is a kind of type inference: if a text parses as a number, it's a number, if it's "true" or "false", it's a boolean. Otherwise it's a string. If you know the implicit schema of your data then this will be sufficient to get the job done.

Otherwise you employ a separate schema -- JC in particular has per-parser schemas anyway, so that's covered in this case.

Or you do "syntax-driven" data types, similar to JSON, e.g. strings start w/ "'".

Here is a shitty demo: https://jevko.github.io/interjevko.bundle.html

It shows schema inference from JSON and the schemaless (syntax-driven) flavor.

Jevko itself is stable and formally specified: https://github.com/jevko/specifications/blob/master/spec-sta...

It's very easy to write a parser in any language (I've written one in several) and from there start using it.

However, I am still very much working on specifications for formats above Jevko. I have some recent implementations of the simplest possible format which converts Jevko to arrays/objects/strings:

* https://github.com/jevko/easyjevko.lua

Thank you for your feedback. Can you clarify?

What is the "first page" that you are referring to?

Can you paste a link to it along with the broken examples link?

This Hacker News submission features the blog post under this URL:

https://djedr.github.io/posts/jevko-2022-02-22.html

Clearly, you are not talking about this page, as that contains multiple links rather than a singular link.

Perhaps you are talking about the specification which is here:

https://github.com/jevko/specifications/blob/master/spec-sta...

(linked from the blog post)

and here:

https://jevko.org/spec.html

(linked from jevko.org)

All three link to Jevko examples here:

https://github.com/jevko/examples

but all these examples links seem to be correct on my end.

I agree about the importance of examples, and I try to lead with them on jevko.org and jevko.github.io (which are the front pages of Jevko -- possibly I should merge them into one).

However a formal specification is not necessarily the place to put the leading examples.

This is also where the Subjevko rule is defined. It isn't quite introduced as "known knowledge" -- the purpose of a specification is to define the unknown, more or less from the ground up. This is also why specifications tend to get a little abstract. Jevko's spec is no exception. This should be in line with expectations of authors of tools such as parsers, validators, generators, or other kinds of processors, for which the spec is the authoritative reference.

It is not necessarily the best first place to look for explanation, if you are approaching from a more casual side.

I agree that from that side a clear picture of what Jevko is and how it can be used is still lacking. I certainly should add more examples and explain the concepts with analogies.

So I appreciate the essence of your advice and hope I'll manage to improve on that.

Short answer: in https://github.com/jevko/easyjevko.js a thing like [ my text ] is converted to a JS string " my text " -- all whitespace is preserved.

Responding to some points I left off here https://news.ycombinator.com/item?id=33336789

I guess the main one is this:

> If your audience is people like me, I think it would probably be worthwhile for you to spend some time up front describing the intended semantics of a data model, as I've attempted above, rather than leaving people to infer it from the grammar. (Maybe OCaml is not a good way to explain it, though.) You might also want to specify that leading and trailing whitespace in prefixes is not significant, though it is in the suffix ("body"); this would enable people to format their name-value pairs readably without corrupting the data. As far as I can tell, this addendum wouldn't interfere with any of your existing uses for Jevko, though in some cases it would simplify their implementations.

You're right, things should be explained more clearly (TODO). Especially the exact role of Jevko and treatment of whitespace. I'll try to improve that.

Here is a sketch of an explanation.

Plain Jevko is meant to be a low-level syntactic layer.

It takes care of turning a unicode sequence into a tree.

On this level, all whitespace is preserved in the tree.

To represent key-value pairs and other data, you most likely want another layer above Jevko -- this would be a Jevko-based format, such as queryjevko (somewhat explained below) or, a very similar one, easyjevko, implemented and very lightly documented here: https://github.com/jevko/easyjevko.js

Or you could have a markup format, such as https://github.com/jevko/markup-experiments#asttoxml5

This format layer defines certain restrictions which may make a subset of Jevkos invalid in it.

It also specifies how to interpret the valid Jevkos. This includes the treatment of whitespace, e.g. that a leading or trailing whitespace in prefixes is insignificant, but conditionally significant in suffixes, etc.

Different formats will define different restrictions and interpretations.

For example:

# queryjevko

queryjevko is a format which uses (a variant of) Jevko as a syntax. Only a subset of Jevko is valid queryjevko.

> I think this is a more useful level of abstraction, and it's more or less the level used by, for example, queryjevko.js's jevkoToJs, although that erroneously uses () instead of [].

The `()` are used on purpose -- queryjevko is meant to be used in URL query strings and be readable. If square brackets were used, things like JS' encodeURIComponent would escape them, making the string unreadable. Using `()` solves that. "~" is used instead of "`" for the same reason. So technically we are dealing not with a spec-compliant Jevko, but a trivial variant of it. Maybe I should write a meta-spec which allows one to pick the three special characters before instantiating itself into a spec. Anyway the parser implementation is configurable in that regard, so I simply configure it to use "~()" instead of "`[]".

> (Also, contrary to your assertion above that this is an example of "leaving [Jevko's data model] as-is", it forgets the order of the name-value pairs as well as I guess all but one of any duplicate set of fields with the same name and also the possibility that there could be both fields and a body.)

I meant [whitespace] rather than [Jevko's data model].

Again, queryjevko is a format which uses Jevko as an underlying syntax. It specifies how syntax trees are converted to JS values, by restricting the range of valid Jevkos. It also specifies conversion in the opposite direction, likewise placing restrictions on JS values that can be safely converted to queryjevko.

The order of name-value pairs happens to get preserved (because of the way JS works), but that's not necessarily relevant. If I were to write a cross-language spec for queryjevko, I'd probably specify that this shouldn't be relied upon.

Duplicate fields and Jevkos with both fields and a non-whitespace body will produce an error when converting Jevko->JS.

I hope this clarifies things somewhat.

Lastly, I'll respond to this for completeness:

> (By the way, if you want to attribute your JSON example for copyright reasons, you need to attribute it to its author or authors, not to the Wikipedia, which is just the site they posted it on.)

According to this:

https://en.wikipedia.org/wiki/Wikipedia:Reusing_Wikipedia_co...

there are 3 options, one of them being what I did, which is to include a link.

I think that's all.

Have a good one!