Chaining transformers, case intermediate format
When dealing with large amount of formats with nearly similar requirements (for example, invoicing), it’s inefficient to create transformation from every format to another. The amount of transformers required is n*(n-1) where n is the amount of formats.
The idea is to create a chain of transformers where each input or output format is using intermediate format as source or destination. With intermediate format, adding new format only takes up to two new transformers (from and to intermediate format).
Customer extensions to common format transformer
Often customers might use a common base for certain format as their input or required output, but might require small changes. Instead of writing new transformer for every possible customer scenario, it’s common to extend the existing transformer and only changing a part of it. In XSLT this could be done by importing existing transformer and then only overriding one template.
This would become important in a common WS-layer, where all the customers are sending/receiving the same base format, but only want small changes to certain fields. This would place content based requirements to the transformer (certain metadata requirements).
Transformation from format A to B is not always possible with only the input message and might require information from elsewhere. While enrichment processes from outside sources (example database) is common, in service provider business it’s required to have certain information implemented to the outgoing document. This could be something as simple as unique ID for the document (for example UUID), which is then used as acknowledgement information in async communication. Batch runs often don’t have any more information than the documents that were sent to them, but they can return information from the message.
In XSLT transformations, this could be done by setting parameters to the transformer object or otherwise exposing some internal properties.
(left empty on purpose, Smooks?)