[jboss-dev] Apologize (was Usecase xml ...)

Ke Jin kejin at pocomatic.com
Wed Nov 21 00:46:08 EST 2007


On Nov 20, 2007; 07:16am, Adrian wrote:
>On Mon, 2007-11-19 at 01:20 -0500, Ke Jin wrote:
>> On Thu Nov 15 12:43:18 EST 2007, Adrian wrote:
>> > I saw somebody just "discovered the idea" and called it
>> > the high sounding title "Domain Specific Modelling for IOC"
>> > http://www.pocomatic.com/docs/whitepapers/dsm/
>> > 
>> > Except it uses xslt, yuck!
>> > We've being doing that with our datasources for 4 years. :-)
>> 
>> Adrian, it is my article.
>> 
>> Firstly, I apologize that my article wasted your precious time.
>> 
>
>Not really. I've been advocating the idea (if not your solution)
>for some time now. :-)
>
>> Secondly, I never claimed this was a "just discovered idea", not even the 
>word "discovered". 
>> Instead, I put it very clear that this is similar to the C++ #define marco 
>or Lisp defmacro expression. Both of them have been used for decades. Even 
>exactly within the area of IoC frameworks, I knew JICE has already supported 
>the similar thing for years. Even for ourselves, our first implementation 
>supporting this model transformation on top of a third party Java IoC 
>container (either Spring or JBoss Microcontainer) was released a year ago 
>(PocoCapsule for Java, Sept-25 2006). If we intended to claim this as a "just 
>discovered idea", we would have claimed it last year instead of waiting almost 
>14 months. Therefore, in the TSS news post (most people found my article from 
>thsi post), I used the term "plain-old" to describe this approach, instead of 
>a "just discovered idea". 
>> 
>
>Yep. I've never liked preprocessors, they allow too many hacks
>and don't catch the unintentional ones (i.e. bugs). 
>
>Hence my "YUCK" :-)

It seems we have some communication problem. Let me clarify it again. I have never claimed using XSLT transformation to simplify XML configuration is my "just discovered idea". Because the key concept of this idea has been around for decades. I don't mind your yuck, neither care whoever want to claim it is their idea few years ago.

[snip]

>
>> Fourthly, for using the XSLT, please read my post and article closely (pay 
>attention to "higher order transformation"). The XSLT is just used as the core 
>schema for model transformation, because it is standardized and ubiquitous 
>(therefore, would be easy for third party support). None-XSLT transformation 
>stylesheet schema can certainly be supported, and already supported by 
>PocoCapsule for C++. 
>> 
>
>The problem for me is that the XSLT (or similar approaches) 
>looses what the user actually configures.
>i.e. for programmatic deployment, error reporting 
>or if they want to change the model dynamically.
>
>e.g. In our datasource that uses XSLT it is impossible to do:
>
>DataSourceModel dsm = new DataSourceModel(); // pun intended :-)
>dsm.setPoolSize(20);
>deploy(dsm);
>
>// Later - oops need to xslt, etc.
>dsm.setPoolSize(40);
>
>You pretty much have to recreate the whole thing
>because of implementation details. :-(
>

Firstly, our configuration is not in the w3c XSLT but in a XML scheam similar to spring and jboss microcontainer.  

Secondly, the inconvenience of programmatic programming (I guess you meant "imperative" programming) in XSLT, is not the weakness of XSLT, but a paradigm shift for a classic OO mindset. XSLT is designed as a declarative language, delibrately avoided the concept of muteable variables which is vital for imperative (programmatic) configuration. This is just like not supporting pointers (i.e. direct memory access) in Java and not supporting record navigation (direct data access without cursors) in SQL DML had let a lot classic minds hard to accept them initially. The good frameworks nicely balances what code should be in the imperative language implemented components (beans), what code should be in the declarative XML configurations and XSLT stylesheets. Neither imperative programming style nor declarative paradigm is the silver bullet to address all issues at all levels.

Thirdly, all things in your mission impossible list are coincidentally supported in our IoC+DSM solution as handy to use features. For instance, our model transformer (even if it is based on XSLT 1.x) supports user-defined, subject specific and programmatic error reporting, our IoC container (and the core schema) supports dynamic configuration changes, and also it supports the configuration in your mission impossible increasing pool size example. 

Cheers!
Ke

>> Sincerely,
>> Ke
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>-- 
>xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>Adrian Brock
>Chief Scientist
>JBoss, a division of Red Hat
>xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
>_______________________________________________
>jboss-development mailing list
>jboss-development at lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/jboss-development



More information about the jboss-development mailing list