There are three generic kinds of transformation tools we should consider:
Production tools, i.e. mostly already existing tools such as MkDocs, SpecUP or Docusaurus, that create the presentable products that are needed, such as websites, pdf documents etc.
Extraction tools, i.e. tools that extract parts of the corpus, and transform that into a format that can be used by one or more production tools. Extraction tools are thus specific for (groups) of production tools.
Ingestion tools, i.e. tools that transform "ingestible documents" into the corpus internal format. Ingestion tools are specific for the kinds of documents the different ToIP groups allow their authors to write.
Since the ingestion tools and extraction tools will be used by (representatives of) existing as well as future ToIP groups, we can only definitively predict what the restrictions should be for their inputs and outputs if that happens to be the internal data model.
So we need a way to cope with this uncertainty, which is also a way that does not prohibit us from making progress.
Proposed Solution
We create a process for contributing (plugins for existing) tools, that ensures that
its possible configurations/settings/transformation-features (including defaults) are documented;
the way of setting up/getting access to the functionality of a tool is documented;
the way of accessing/using the tool is documented;
specifics of the transformations are documented, e.g.:
I propose to create (directories in) repos where such tools can be contributed, accepted, maintained, deprecated etc. (perhaps also with status as we use in concepts and terms).
I also propose that the TT-tool be the first tool to be contributed, thereby setting an example for others to follow. It would imply that documentation is created, which might also serve as a specification for as long as the tool itself does not yet exist.
Need
There are three generic kinds of transformation tools we should consider:
Since the ingestion tools and extraction tools will be used by (representatives of) existing as well as future ToIP groups, we can only definitively predict what the restrictions should be for their inputs and outputs if that happens to be the internal data model.
So we need a way to cope with this uncertainty, which is also a way that does not prohibit us from making progress.
Proposed Solution
We create a process for contributing (plugins for existing) tools, that ensures that
I propose to create (directories in) repos where such tools can be contributed, accepted, maintained, deprecated etc. (perhaps also with status as we use in concepts and terms).
I also propose that the TT-tool be the first tool to be contributed, thereby setting an example for others to follow. It would imply that documentation is created, which might also serve as a specification for as long as the tool itself does not yet exist.