XML application descriptors (configurations) in core schemas of various IoC frameworks are more or less plain Java or C++ (or other languages) method invocations expressed in XML. Such a low level schema has the advantages of being compact, straightforward, and applicable to general applications. However, it has weaknesses of being poorly expressive and involving low level programming signatures (APIs). Therefore, IoC core schemas are verbose, error-prone, and not desirable for domain users. One of the approachs to address these issues is to raise the abstracion level of XML configurations by supporting user-defined domain specific modeling/language (DSM/DSL) schemas in IoC frameworks. Spring 2.0 introduced the so-called extensible XML authoring (Spring 2.0 appendix B) allowing users to extend the core schema by user-implemented plug-in handlers. These manually crafted handlers process XML DOM elements that are defined by users to extend the core schema. This scenario has the disadvantages of involving low level XML DOM programming and tying to proprietary (Spring 2.0) callback interface API. Therefore, it is not suitable for domain users, not able to be automated/tooled, and not likely to be followed by other IoC containers. The article Domain Specific Modeling in IoC Frameworks suggests a plain-old but straightforward model transformation based scenario. The idea here is simply leverage the IoC framework itself and the ubiquitous W3C XSLT technique without involving any proprietary plug-in API or low level XML DOM. To define a DSM, one only needs to define its XML schema and then design a XSLT stylesheet that maps a configuration in this DSM schema to a configuration in a target schema (such as the core schema). To use this new DSM schema, a XML configuration (in this DSM schema) only needs to have the stylesheet file name (or URL) specified in its process instruction (PI) section. With a XSLT transformer integrated IoC container, this XML configuration will be recursively transformed until a final target configuration that does not have such a transformation process-instruction (presumbly, it ends up with the core schema). This model-transformation based DSM scenario has already been supported in the PocoCapsule/C++ IoC and DSM Framework and is straightforward to be applied to most other IoC containers. The PocoCapsule also supports the so-called higher order transformations (HOTs). Namely, not only the scenario of user-defined high level DSM schemas is applicable to application configurations, it is also applicable to the transformation stylesheets themselves in reducing the verboseness and erroneousness of the generic XSLT. With this model transformation DSM scenario, an IoC framework can be used as a framework to build other user-defined or committee-design component frameworks. Several such frameworks are presented out-of-the-box in PocoCapsule and with numerous examples. For instance, a SCA assembly model for C++ is implemented as a DSM in merely 500 lines of code (XSL and C++). As argued in the article, with this DSM scenario in IoC frameworks, disadvantages of XML configurations of core IoC schemas can largely be avoided, while advantages of their declarativeness, self-documenting, schema validations, and easy manipulation start to become significant.

the current approach need to do coding for a NamespaceHandler and Coding for a BeanDefinitionParser, the Domain Specific Modeling (DSM) by using Model transformation seems a better approach.

In fact, the prototype of PocoCapsule/C++ IoC and DSM was originally built as a java framework on top of Spring 1.x. It was released a year ago (9/25/2006).

Guice is a natural fit in this area. The use of custom annotations for binding and the type-safe fluent interface lets you express your configuration in domain-relevant lexicology. A metadata layer on top of PicoContainer is also a good example (and easy to develop to), a la NanoContainer.

Guice is a natural fit in this area. The use of custom annotations for binding and the type-safe fluent interface lets you express your configuration in domain-relevant lexicology.

A metadata layer on top of PicoContainer is also a good example (and easy to develop to), a la NanoContainer.

The point of my post is not about whether a particular IoC container able to support user-define high level DSM/DSL, but how it is supported. Like I said, Spring 2.0 has been able to support user-authoring schema for more than a year. However, it tightly ties to proprietary APIs and involving low-level (DOM) programming. It is certainly possible that other containers can add similar proprietary and/or low-level solution of their own. A similar example is database logic view. Most relational database nowadays allow users to define logic views. A column of a logic view is usually transformed to an expression of multiple columns from different physical tables (or even clumns of other logic views). The nice thing of today's databases is that they let users to define views using SQL DML/DDL statements, instead of providing a set of APIs to let users hook their callback handlers to the internal SQL query plan abstraction-syntax-tree (AST). Hope this clarifies ....

Hmmm..This is good stuff. I bet a lot of computer lovers are loving this post right? - The Balancing Act Lifetime