RE: [xsl] Re: Re: XSLT Architecture: Next Step

[Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>]

Claudio,

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." -- Thoreau


XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list