anonymous wrote : Warning - I am a smooks noob, just have that in mind when reading my answers :) No problem. But I must confess that I am wondering now if we are talking about the same thing ;). I am also just brainstorming here, so my theories can also be wrong one or more points ;). anonymous wrote : Of course, the problem is just that the two models of Smooks 1_0 and Smooks 1_1 is vastly different so I'm not sure any strategy can be defined that would work. But of course if it is doable then sure. To make sure that we are talking about the same thing I am going to explain my idea in little more detail.. I am proposing to use Smooks its readers (XML, EDI, CSV, JSON, Java reader) to analyze an example file of the source data, that the final Smooks configuration is going to process. Because of Smooks its flexibility you can let Smooks do the reading but you provide your own code to build the data model. The resulting model will probably look a lot like a DOM model. The visitor classes, provided by the Smooks editor, that build the model, will be Smooks depended. But because Smooks is backwards compatible you can use the same classes for Smooks 1.0 as for Smooks 1.2. I think what you mean is Smooks its configuration model. That changed a lot between version 1.0 and 1.1. But it is still possible to use the 1.0 configuration model with Smooks 1.1. anonymous wrote : Sure, but we would now be bundling how many versions of Smooks ? | What about smooks 1.0.1, 1.0.2, 1.1.0, 1.1.1 etc ? Smooks is backwards compatible at every level. Even when you would provide different strategies for different versions of Smooks, they probably all can use the same version of Smooks. So you don't need to include Smooks 4x times. Only in the theoretical case that Smooks wouldn't be backwards compatible between minor versions, then you would have the possibility to use two different versions of Smooks. That makes sure that the Eclipse Editor isn't Smooks version specific. anonymous wrote : The Reader you mention in that paragraph is from Smooks or from the Smooks plugin ? I meant the Smooks editor implementation of the SmooksReaderStrategy. anonymous wrote : the current editor at least in theory can survive broken parts and still read the rest. Personally I am not sure if surviving a broken part would be the correct thing to do. But that is a something for a different discussion. If surviving a broken input source would be needed then we probably could implement such a feature in our current readers. The biggest point of my idea is that you don't need to re-implement something that is already provided. I don't see the point that you guys need to re-implement the XML, EDI, JSON, etc readers. Max, would you be interested to talk about this topic during a chat session? That would go a lot faster and probably prevent a lot of misunderstandings then discussing this via the forum. Do you use Skype? If you are then maybe Tom Fennelly would also be interested to join the conversation. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4217639#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...