Cart
[Home] [By Thread] [By Date] [Recent Entries]
> > 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@x...&BODY=unsubscribe%20xml-dev List archives are available at http://xml.org/archives/xml-dev/ ***************************************************************************
|
