Re: [xsl] XSL 2.0 and .NET and VB

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&amp;city=Seattle
&amp;state=wa&amp;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