Cart
|
[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Re: Re: XSLT Architecture: Next Step
 At 09:19 AM 7/4/2003, you wrote: I agree with you, which comes back to my first expression. Why don't keep XSLT for what it was created, presentation purposes (as Michael recalled from the w3c sentence), and leave the process in the server level with more specific elementary process programming under C, Java, Assy, compiled language, giving the necessary XML view for the XSLT. Because notwithstanding the ostensible purpose of its designers (as indicated in the sentence Mike cited), XSLT turns out to be *really good* at lots of middleware types of operations. "Middleware" too benefits from being specified declaratively, and so often the same people are designing the back-office processes as are designing the targetting of presentations (indeed, as has been pointed out they can often be seen as species of one another -- a process targetting an interface), that it makes sense to unify on a single technology to do both, if it happens to be suited to the task(s). Understanding the "intent" of the design of XSLT is really helpful to understand why and how it has particular limitations ... but ultimately we are limited by the technology's intrinsic capabilities, aren't we, not the intentions of its designers? (The good designers know that.) Cheers, Wendell ___&&__&_&___&_&__&&&__&_&__&__&&____&&_&___&__&_&&_____&__&__&&_____&_&&_
"Thus I make my own use of the telegraph, without consulting
the directors, like the sparrows, which I perceive use it
extensively for a perch." -- ThoreauXSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
