Currently, name generators can't be verified outside their respective, specialized unit-tests. In a production environment, names and paths are volatile, and must easily be changed without breaking the system by overlooking some details in the ruleset.
Also, name generators may implement any logic, which makes it necessary for them to reuse each other directly, without forcing anyone to try reimplement particular logic. Ideally, a generator will never have to know a particular other generator, but there may be instances where this is a requirement, as two programs are somewhat tightly coupled in the workflow.
Even though it might not exactly be semantic's purpose, it must be very easy to understand what a particular name generator expects from a ruleset, and to verify it against a particular ruleset.
It should be very easy to run all name generators available in a context against templates without needing their particular host applications to be present - they must thus be standalone enough to allow that.
Additionally, it must be easy and straightforward to reuse generators implemented by others, which allows to link up outputs of one as inputs of another, just by using contextual data.
Possible Solutions
I think it would be easiest to write plugins with a clearly documented interface, which can be addressed by name or by meta-data attached to their type. That way, the standard plugin system can be used to retrieve implementations.
This plugin type should declare in its interface what data in a ruleset it requires, and it should be possible to call it for name generation even without knowing how it works. That way, a verification step can call it and gather the results.
Currently, name generators can't be verified outside their respective, specialized unit-tests. In a production environment, names and paths are volatile, and must easily be changed without breaking the system by overlooking some details in the ruleset.
Also, name generators may implement any logic, which makes it necessary for them to reuse each other directly, without forcing anyone to try reimplement particular logic. Ideally, a generator will never have to know a particular other generator, but there may be instances where this is a requirement, as two programs are somewhat tightly coupled in the workflow.
Even though it might not exactly be semantic's purpose, it must be very easy to understand what a particular name generator expects from a ruleset, and to verify it against a particular ruleset.
It should be very easy to run all name generators available in a context against templates without needing their particular host applications to be present - they must thus be standalone enough to allow that.
Additionally, it must be easy and straightforward to reuse generators implemented by others, which allows to link up outputs of one as inputs of another, just by using contextual data.
Possible Solutions
I think it would be easiest to write plugins with a clearly documented interface, which can be addressed by name or by meta-data attached to their type. That way, the standard plugin system can be used to retrieve implementations.
This plugin type should declare in its interface what data in a ruleset it requires, and it should be possible to call it for name generation even without knowing how it works. That way, a verification step can call it and gather the results.