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
Cart
