xml-dev - Re: XSL Translations using Java Servlets / JSP

[Paul Tchistopolskii <paul@qub.com>]

> > I'm not saying that there is no hypoteteical usecases when 
> > you may realy like to use the 'standard' way of binding.
> 
> Say, to offload the XSLT processing to the client in those
> cases where it can render it.  It's a brand new model of
> how to use XML on the web!  ;-)

let me just re-send the quote of myself once again, because 
it appears to me that it has been ignored. As I already said:

> Frankly, I'l not recommend using the 'standard' way. On the 
> server side,  I think alsmost any 'other' way of binding / linking  
> is better. Not on the client side, but that's another story.

That means I obviosly understand that there is some 
( hypotetical, again ) advantage of using the 'standard'  
binding on the client side.

However :

1. XSLT supported  in current web browsers is not 
XSLT at all ( anyone who reads the XSL-list should 
be aware of the real shape of MSXSL ).

2. Giving the browser a favicon.ico-alike behavior 
( I mean when the browser  encounters some.xml
it could by default try to get some.xsl from the 
same base url ) will work pretty well for the most 
usecases, I think. Yeah, this will not be 'standart'.

> Rgds.Paul.

> Surely there will be fully XSLT conformant browser addons,
> sometime before the end of this year.

Of course not.  At the end og the year we'l see, whos
prediction is more accurate. 

( Are you predicting  that MS will sacrifice their 
'result-tree-fragment-to-node-set-hidden-typecast'
to become 'conformant' ?  Strong assumption, 
I think, and I think it will be not good for the community 
if they'l do that ).

Rgds.Paul.



***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************