SaaSHub helps you find the best software and product alternatives Learn more →
Specifications Alternatives
Similar projects and alternatives to specifications
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
jc
CLI tool and python library that converts the output of popular command-line tools, file-types, and common strings to JSON, YAML, or Dictionaries. This allows piping of output to tools like jq and simplifying automation scripts.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
queryjevko.js
Functions to convert between complex values and a human-readable format which fits into URL query strings.
specifications discussion
specifications reviews and mentions
-
SVGs as Elm Code
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
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
- Syntax Design
-
A note from our sponsor - SaaSHub
www.saashub.com | 3 Oct 2024
Stats
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.