A configuration option you might consider supporting is the dynamic specification of the XSLT file used for the transformation. Multiple XSLT files could be packaged in the .esb archive and dynamic selection happens for each incoming message. One possible selection method is an XPath expression that computes the XSLT filename from the incoming XML. The configuration might look something like this:
<property name="templateFileXPathSelector" value="concat(/someElement/text(),'.xslt')" />
thanks for your suggestion!
Just a thought, could we have a content based router that does the xpath stuff and routes to a service which would then have the dedicated XsltAction. This would keep the XsltAction simple which I think would be an advantage. What do you think?
Now the xpath router stuff is not there yet but should be soon:
Daniel - yes, I think the XPath CBR would be sufficient for lots of use cases. So the XPath CBR action could be configured to route, for example, all messages containing an "order" element to the order-xslt service which would contain an action specifying the XSLT file for transforming orders. You would need a service for each required XSLT transformation. As you said, it keeps the XsltAction simple, which is typically a good thing.
Thanks for the quick response.