On Wed, 2007-11-21 at 00:46 -0500, Ke Jin wrote: You are correct we have a communication problem (many of them, I think :-). I claim that preprocessors are not the way to go. The model should be used by both the front end and backend. If you know of examples that don't use preprocessors but do bind models to implementations that "go back decades" I'd like to know about them to understand the lessons learned. :-) If however you are only talking about preprocessors then yes this hack has been around forever. e.g. if you've looked at the gcc code you write front ends and backends almost entirely in c macros. Why didn't they just define their own DSL? :-) I don't care whether the preprocessor is XSLT or some other transformation. It's still a "script" that introduces cognative dissonance (since you like long words :-) between what the user defines and what the back end actually uses. The use case xml we are discussing is a way to bind the model/contract to the implementation details without exposing those details to the user (for clarity I also define user to include any management tool). e.g. Using the example from my original post (slightly extended to give more explanation): <!-- Possible xml deployment of queue --> <deployment xmlns:jms="urn:jboss:jms:2.0"> <jms:queue name="MyQueue"/> </deployment> is programmtically (for just the basic queue model) QueueModel model = new QueueModel(); model.setQueueName("MyQueue"); Something like (using JAXB): @XmlElement("queue") public class QueueModel { @XmlAttribute("name") private String queueName; } You can then introduce the IOC part: public QueueBeans extends QueueModel implements BeanMetaDataFactory { List<BeanMetaData> getBeans() { Collections.singletonList( new BeanMetaDataBuilder(name, Queue.class.getName()). addProperty("model", this)). } } This effectively "transforms" the xml file into: <deployment> <bean name="MyQueue" class="org.jboss.jms.Queue"> <property name="model">queue-model-here</property> </bean </deployment> but it does it while still maintaining the link between the front end DSM (the contract) and the implementation. Then handle implementation details (things that aren't part of the user contract) on the implementation class - you could also handle them in QueueBeans: public class Queue { // The DSM @Inject private QueueModel model; // Implementation detail @Inject private QueueManager manager; } I know in the "loosely coupled" world of SOA there is a tendency to not expose models and use transformations to translate different models/contracts. This is a separate issue. i.e. multiple models with only one being "native". It's orthogonal to what we are discussing. Translations/transformations are an unnecessary step if the model can be used natively. By Programmatic, I mean the opposite of imperative. Everything that can be done with xml should be doable from a java program. i.e. You shouldn't force people to make the "paradigm shift" to IOC+DSM. They shouldn't have to create a DOM tree run it through an xslt before they can deploy a datasource like they have do in our current implementation. :-) -- xxxxxxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Chief Scientist JBoss, a division of Red Hat xxxxxxxxxxxxxxxxxxxxxxxxxxxx