The braille production scripts are build around a system of "transformers" that can delegate to sub-transformers, and transformer "providers" that can delegate to other providers. Almost everything is a transformer. Even the top-level scripts exist of only a css:inline step and a px:transform step (which is an XProc step for selecting and executing a transformer).
Transformers come in different types, each with a well-defined interface and contract. Often CSS is used in these interfaces. A provider is a service that returns a sequence of transformers of a certain type that match a certain query. The definition of a query depends on the particular provider type but typically it is a list of features encoded as a simple string.
The reason why a provider returns a sequence of transformers is to allow the caller to take more control over the matching by doing additional filtering based on the transformers' properties, and to allow the caller to recover from transformation errors (see below).
Limitations
From a separation of concerns points of view this delegation model is a good fit. But for some advanced cases it is less adequate. An example is a transformer/provider that delegates to two or more other transformers/providers, where each sub-transformer only has to match a part of the top level provider's query. When it is well-defined which features target which sub-transformer (i.e. with a strict enough contract), this is not a problem. But otherwise the current provider API is too limiting. All solutions involve giving more control to the caller which conflicts with the idea of delegation, and/or making the provider API more complicated.
Fuzzy matching
Fuzzy matching is about finding the "least imperfect" match if there is no perfect match. The key lies in determining the optimal weights of features. Fuzzy matching brings additional challenges for the delegation model. For example, how to compare matches from a query to several providers, or from several queries to a provider?
Recovering from errors
Another possible improvement would be to recover from transformation errors by selecting and executing the next transformer.
The braille production scripts are build around a system of "transformers" that can delegate to sub-transformers, and transformer "providers" that can delegate to other providers. Almost everything is a transformer. Even the top-level scripts exist of only a css:inline step and a px:transform step (which is an XProc step for selecting and executing a transformer).
Transformers come in different types, each with a well-defined interface and contract. Often CSS is used in these interfaces. A provider is a service that returns a sequence of transformers of a certain type that match a certain query. The definition of a query depends on the particular provider type but typically it is a list of features encoded as a simple string.
The reason why a provider returns a sequence of transformers is to allow the caller to take more control over the matching by doing additional filtering based on the transformers' properties, and to allow the caller to recover from transformation errors (see below).
Limitations
From a separation of concerns points of view this delegation model is a good fit. But for some advanced cases it is less adequate. An example is a transformer/provider that delegates to two or more other transformers/providers, where each sub-transformer only has to match a part of the top level provider's query. When it is well-defined which features target which sub-transformer (i.e. with a strict enough contract), this is not a problem. But otherwise the current provider API is too limiting. All solutions involve giving more control to the caller which conflicts with the idea of delegation, and/or making the provider API more complicated.
Fuzzy matching
Fuzzy matching is about finding the "least imperfect" match if there is no perfect match. The key lies in determining the optimal weights of features. Fuzzy matching brings additional challenges for the delegation model. For example, how to compare matches from a query to several providers, or from several queries to a provider?
Recovering from errors
Another possible improvement would be to recover from transformation errors by selecting and executing the next transformer.
Related issues: