Subject: Re: [xsl] XSL 2.0 and .NET and VB From: "M. David Peterson" <m.david@xxxxxxxxxxxxx> Date: Fri, 29 Jun 2007 08:40:50 -0600 |
On Fri, 29 Jun 2007 05:39:41 -0600, Mark Anderson <mark.anderson@xxxxxxxxxxxxxxxxxxx> wrote:
Furthermore, I want to move to 100% server-side transforms so I don't have to worry about XSLT support in the myriad of browser out there and what transformation engine is being used.
Do you have access to unlimited resources? Moving to 100% server-side transforms is a *HUGE* mistake! Of course, not taking *FULL* advantage of your control of the server-side software is a *HUGE* mistake. The answer is to use both. Use Saxon on .NET as a messaging router and transformation service on the server that passes nothing but the data back to the client to be transformed into whatever format the application prefers. (X)HTML, SVG, XUL, XAML, whatever. If the client doesn't support client-side transforms, then send them something they do support, but these are edge cases which won't bring your network down to a screaching halt at capacity increases, so it's of less concern.[1]
I would also like to use EXSLT but there's no way the extensions could be managed with client-side transforms.
Yes and no. Yes, that is true about the current state of the browser market. But that is quickly changing. None-the-less, you are obviously concerned with what you can do in the here and now, and the only EXSLT support you can rely on at this stage is node-set()[2] See http://dpcarlisle.blogspot.com/2007/05/exslt-node-set-function.html for more detail.
IF I'm doing everything server side, I can control the transform engine, the extensions, etc. and send nothing but pure (and simple) HTML to the browsers.
You will find that you can send nothing but pure, simple, and raw XML that is transformed via client-side XSLT is *MUCH* more efficient because once the initial base of transformation files (both base and imported) has been cached by the browser, your doing nothing but sending the data itself with each request. You should also consider the fact that using client-side XSLT the browser skips the relatively slow SGML parser and moves directly to the relatively fast XML parser, transforming the result directly into a DOM object. As such, your page load time increase dramatically. There's a reason that modern day browsers have introduced terms such as "quirks mode", making every attempt that they can to try and speed up the SGML parsing/processing by sniffing the (X)HTML ahead of time to determine if its tag soup or something a bit more reliable in its content structure and usage of tags. For this same reason, there is a reason why XHTML is considered to be such an important upgrade > It's *FASTER* to parse and render.
Of course there are those who will argue that because IE x.x doesn't support XHTML it's useless even trying, of which my response would be: "IE supports XHTML. Well, at least the XML part of XHTML. You just have to get a little creative and find ways to force the XML processor to kick into gear." For example, using a PI to invoke a client-side transform.
Now to the crux of the problem. My developers are telling me there's no support for XSLT 2.0 in .NET and VB. Is this the case.
Hmmm... Maybe you need new developers? ;-) I kid, I kid, but the reality of the situation is that there has been support for XSLT 2.0 on the .NET platform since July of 2004. Please see both Martin Honnen and Dr. Michael Kays response regarding this matter.
If so, any idea when Bill is going to support it?
Yes. See http://www.oreillynet.com/xml/blog/2007/01/i_heart_xml_team.html for more detail.
[1] If interested, I just so happen to have just such a system already developed ;-) http://extf.googlecode.com/svn/trunk/ < For an example, see
http://personplacething.info/service/json-to-xml/?debug=true&uri=http://api.l ocal.yahoo.com/MapsService/V1/trafficData?appid=EricBlogDemo&city=Seattle &state=wa&output=json < which utilized FXSL's JSON-to-XML extension and implements a proxy-based call to Yahoo's traffic service returning back the XML to be transformed client-side (this returns plain text to make it easier to see the returned message) That entire service is implemented via http://extf.googlecode.com/svn/trunk/WebApp/service/json-to-xml/service.op which is a direct reflection of just how powerful and wonderful XSLT 2.0, FXSL, and Saxon truly are.
[2] BTW, everyone... Dave Hyatt from earlier this morning > @http://bugs.webkit.org/show_bug.cgi?id=4079#c15 "Someone needs to sign up to do the work here for this to make Safari 3." < there's already a submitted patch, and Todd Ditchendorf (an internal Apple employee) has created a patch as well, so my guess is support for EXSLT will make it into the final release of Safari 3 for both Windows and Mac. I'll keep at it to make sure of it ;-)
-- /M:D
M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | http://dev.aol.com/blog/3155
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] XSL 2.0 and .NET and VB, Anthony B. Coates (X | Thread | Re: [xsl] XSL 2.0 and .NET and VB, Jirka Kosek |
Re: [xsl] XSL 2.0 and .NET and VB, Anthony B. Coates (X | Date | Re: [xsl] XSL Project Shut Down, Karl Stubsjoen |
Month |