Hi guys. Sorry for being late in joining this conversation :) I think we are definitely talking about different things here. My 2c worth... Configuration Model In terms of Smooks configurations, the latest version of Smooks (v1.1) is backward compatible (BC) with versions back to v0.9 (and probably before). So you can throw the v0.9 DTD, the v1.0 XSD or the v1.1 XSD at it and it will be able to generate it's internal config model from it. As far as v1.0 and v1.1 are concerned, what was added here in v1.1 was the ability to define extended namespaces i.e. to extend the Smooks base configuration in order to define a configuration namespace for specific features e.g. for java binding configurations, for applying freemarker templates to a fragment of the input data, for triggering a read on a DB in order to enrich the source message etc etc. My understand is that this extended config namespace approach should help with tooling because it allows for the creation of stricter/tighter configs. I might be wrong there. In v1.0, all of these configuration "resources" had to be defined in the base config model, which made the configs very verbose... poor XSD based help from your IDE etc. In Smooks v1.1, all of these resource types have a namespace of their own so they are far more strongly typed, less verbose etc etc. That said... Smooks v1.1 would still be able to read a v1.0 style config no problem. We made a lot of effort to try and ensure this, so I'd be very p*ssed off if we found somewhere here that we broken BC. I think this was the subject of Max's thoughts, right? Data Source Model Then you have the source data that Smooks is going to process in some way e.g. XML, EDI, JSON, CSV, Java etc. To process these, Smooks needs to be configured with a "Reader", whose responsibility is to generate a stream of SAX events from the source data model, no matter what it's format is i.e. anything that's structured/hierarchical - not just XML. The smooks runtime processes this stream of events and, at the appropriate times, fires the resources configured in the smooks config. So the source data may be an EDI/JSON/CSV message, but the data model "seen" by the smooks runtime is a stream of SAX events generated by the EDI reader that was plugged into Smooks for reading the source. The reader is defined in the smooks config. If not defined, it defaults to whatever is configured in the JAXP environment e.g. Xerces. The supplied Reader must implement org.xml.sax.XMLReader (JDK). I think this was the subject of Maurice's thoughts, right? Smooks API The Smooks "API" is actually very simple and hasn't changed in a few versions and I don't see any reason to change it in the future. In terms of the configuration API... Smooks receives the XML config as a InputStream via it's constructor. I don't think there's any need to discuss programmatic configuration since the editor will not be using that, right? In terms of the execution API... there are 2 methods on the Smooks class that are of interest: - createExecutionContext() - filter() The filter method takes 3 params: - javax.xml.transform.Source (JDK). - javax.xml.transform.Result (JDK). - ExecutionContext (Smooks core/runtime). This interface would be stable/BC (v1.0, v1.1). So going forward, I'd be confident we can maintain backward compatibility on at an API level. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4217739#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...