Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible enhancements to system of transformer selection #36

Open
1 task
bertfrees opened this issue Mar 16, 2015 · 0 comments
Open
1 task

Possible enhancements to system of transformer selection #36

bertfrees opened this issue Mar 16, 2015 · 0 comments

Comments

@bertfrees
Copy link
Member

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:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant