Specifications related to Jevko. (by jevko)

Specifications Alternatives

Similar projects and alternatives to specifications

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a better specifications alternative or higher similarity.

specifications reviews and mentions

Posts with mentions or reviews of specifications. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-11-03.
  • SVGs as Elm Code
    4 projects | news.ycombinator.com | 3 Nov 2022
    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.

  • Jc – JSONifies the output of many CLI tools
    16 projects | news.ycombinator.com | 3 Nov 2022
    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

  • Jevko: a minimal general-purpose syntax
    30 projects | news.ycombinator.com | 25 Oct 2022
    > What's happening here is parsing. `jevkoToHtml` is a kind of parser-transpiler which operates on a syntax tree, rather than a sequence of characters or tokens.

    That is obviously false. It's operating on a nested list of strings, whereby it's making a semantic decision whether a string in a certain position of a nested item in the structure ends in the = character.

    In other words the syntax is character-level. The strings themselves have syntax, which is made of characters. That's in the Jevko specification. Characters are the atoms in Jevko.

    The = character that the code is looking for is a %x3D element.

    It's right here: https://github.com/jevko/specifications/blob/master/draft-st...

    The = character is %x3D. An %x3D is Character. A Character is one of the kinds of Symbol (the other being Digraph). A Symbol is a constituent of Text. Text generates a Prefix or Suffix. A Suffix alone can be a Jevko due to this rule:

      Jevko ::= *Subjevko Suffix
    30 projects | news.ycombinator.com | 25 Oct 2022
    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:


    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:


    (linked from the blog post)

    and here:


    (linked from jevko.org)

    All three link to Jevko examples here:


    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.

    30 projects | news.ycombinator.com | 25 Oct 2022
  • Syntax Design
    9 projects | news.ycombinator.com | 18 Oct 2022
  • A note from our sponsor - Appwrite
    appwrite.io | 1 Oct 2023
    The open-source backend cloud platform for developing Web, Mobile, and Flutter applications. You can set up your backend faster with real-time APIs for authentication, databases, file storage, cloud functions, and much more! Learn more →


Basic specifications repo stats
10 months ago

jevko/specifications is an open source project licensed under MIT License which is an OSI approved license.

The primary programming language of specifications is HTML.

Popular Comparisons

Free Global Payroll designed for tech teams
Building a great tech team takes more than a paycheck. Zero payroll costs, get AI-driven insights to retain best talent, and delight them with amazing local benefits. 100% free and compliant.