Goals & requirements

[ribose-jeffreylau]

Goals

• To be able to easily generate a static directory site using static-site generators like Jekyll, where one file corresponds directly to one static page
• To be able to translate between files that are in ISO 56001 serialization format (textual) and GraphQL instructions
• To be able to manipulate records (CRUD) with the commandline interface

But since ISO 56001 is not the only file format that we'll be dealing with, this layer should be able to support multiple input / output formats, i.e. this can be thought of a sort of templating workflow / a compiler that compiles both ways

Use cases

Performance

One of the use cases is, for performance reasons, to first export the DB into (e.g.) MySQL, and hand off all CRUD actions to the MySQL server for the duration of the directory server. And as a backup mechanism, periodically dump it back to the flat file DB and possibly git-committing the patch. This requires exporting to and importing from MySQL.

CRUD

Another use case is the aforementioned translation from GraphQL, to JSON / XML / HTML (i.e. the read operation), and from GraphQL back to the flat file (i.e. create / update / destroy).

Requirements

Compilation flow tapping

We also have a requirement on the compilation flow itself, which is to be able to provide exposed compilation stages for others to tap into.

E.g., I'd like to implement a layer that uses results from stages A, B, and E, where A, B and E are names of the compilation stages that are configurable say from the compilation / translation configuration file.

These different stages act as some sort of data abstraction mechanism, i.e. a chance for source documents to be translated into intermediary formats that are possibly easier to perform CRUD operations and to provide greater performance (e.g. the MySQL example above).

Configuration file as blueprint

The configuration file would probably be some sort of a blueprint that lists out all the "compiler plugins", their names, and most importantly, where each output goes (e.g. to specify that output from stage A should go into B, C and D, and outputs from B and C should go to E).

[ribose-jeffreylau]

Here is a starting point of the file layout that should be used as the underlying structure for ffdb:

https://github.com/riboseinc/ffdb/tree/doc/spec/support/fixtures/layouts/sample-1

This layout is not final and will need more inputs.

[ronaldtse]

ffdb represents an approach we see already applicable to a number of sites we run, including the Geolexica site (https://github.com/ISO-TC211/geolexica.com).

Hoping we can use ffdb in Geolexica very soon 👍

[ronaldtse]

(and it will be awesome to use it in Metanorma/Selagraph...)