In the previous example, we have already seen how to transform a structured value into HTML. Schemas offer a more structured approach to this: Typically, you write a schema file that contains all required types and defines the root type, and then in your input, you import that schema and use it.
Our new example does the same as the previous one, but with the processing and structure moved to a schema.
The main input is now much cleaner, the types and processing has been moved to the separate Section input.
A schema is defined via a call to \SchemaDef, which is a predefined type but acts like a keyword when called.
We declare our types like before in the main block, and then add a backend named html that does the transformation.
A backend can define functions, and must have a body that evaluates to a concatenation of \Output, another predefined type.
An \Output has a name, which means that we don't get <stdout> output anymore, but an output named input.html.
We can potentially create multiple outputs with a single backend.
We now use \standalone to declare the root type of our input's content.
\standalone means that this module can be the main module for processing.
Nyarna calls its inputs modules.
Interpreting our input will automatically use the html backend as it's the only backend defined.
We can define multiple backeds for our schema, for example if we also wish to produce LaTeX source code.
Details
Nyarna predefines the schema Schema which is the schema of schemas.
It is best practice to have your schemas use that schema.
In the future, this predefined schema may have backends, which you could use to autogenerate code from your schema, for example if you want to load a document of your schema into your application.
If you import a standalone module into another module, the schema of the imported module doesn't matter, just its root type.