Here are what I see as the necessary components of the Open Styles project.
The Basics
a source format/structure
an entry method
a parser for rendering output into HTML, PDF, Vale YAML, etc
For the source format, I am proposing YAML files that can be concatenated to make up a full listing. This means any tooling must be able to assemble the complete data object out of 1+ files. I hope the advantages of a flat-file database over an RDB are clear, as they enable source/version control and forking. My recommended "schema" is here.
For the entry method, we can obviously just edit YAML files, but we might consider repurposing a web interface like NetlifyCMS or another headless CMS that can be schemed to generate entry forms for YAML objects. That doesn't feel like a core part of the project, but it could be if people find the data format too overwhelming.
Finally, we will need to be able to generate new source files and rendered artifacts alike. My preference here is to go via AsciiDoc for HTML and PDF, so our templates can be used to build both HTML and PDF. We also need to parse rules into Vale or other linter formats. My go-to here is Liquid, which I've had some success teaching. But I also think we just need exemplary tooling, and this is simple enough that folks will create rendering systems through their preferred environments.
Nice-to-haves/Stretch Goals
Front-end tools that recognize terms and present popovers, as I've done with my Jekyll theme's glossary. This is done in rudimentary jQuery, but it would be great to make it available under other frameworks or even just clean it up really good.
Packaging (and maybe a renderer) that will excite front-end developers, which probably means NodeJS/npm on the back end and something modern like React or Vue on the front end.
Here are what I see as the necessary components of the Open Styles project.
The Basics
For the source format, I am proposing YAML files that can be concatenated to make up a full listing. This means any tooling must be able to assemble the complete data object out of 1+ files. I hope the advantages of a flat-file database over an RDB are clear, as they enable source/version control and forking. My recommended "schema" is here.
For the entry method, we can obviously just edit YAML files, but we might consider repurposing a web interface like NetlifyCMS or another headless CMS that can be schemed to generate entry forms for YAML objects. That doesn't feel like a core part of the project, but it could be if people find the data format too overwhelming.
Finally, we will need to be able to generate new source files and rendered artifacts alike. My preference here is to go via AsciiDoc for HTML and PDF, so our templates can be used to build both HTML and PDF. We also need to parse rules into Vale or other linter formats. My go-to here is Liquid, which I've had some success teaching. But I also think we just need exemplary tooling, and this is simple enough that folks will create rendering systems through their preferred environments.
Nice-to-haves/Stretch Goals
Front-end tools that recognize terms and present popovers, as I've done with my Jekyll theme's glossary. This is done in rudimentary jQuery, but it would be great to make it available under other frameworks or even just clean it up really good.
Packaging (and maybe a renderer) that will excite front-end developers, which probably means NodeJS/npm on the back end and something modern like React or Vue on the front end.
What am I missing?