[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XSL 2.0 and .NET and VB

Subject: Re: XSL 2.0 and .NET and VB
From: Jirka Kosek <jirka@xxxxxxxx>
Date: Sat, 30 Jun 2007 12:22:07 +0200
Re:  XSL 2.0 and .NET and VB
Hash: SHA1

M. David Peterson wrote:

> Sorry, Jirka, but you haven't show any evidence that suggests its slower
> to render a document via XSLT than it is using the SGML parser, just
> that you seem to think that the process of parsing the XML and XSLT to
> then process the XML with the XSLT is somehow going to result in slower
> processing of the page.

Do you want to see evidence? Then find somewhere your old modem and try
to use dial-up for some time. ;-D

Current browsers when served by HTML are displaying page progressively,
it is not necessary to wait till whole page is loaded before seeing
rendered start of the page. The latency of XML+XSLT will be bigger then
in case of pure HTML irrespective which route will be faster in total.

> Please read through my entire post again and recognize the fact that I
> specifically made mention to that fact that this is only 50% of the
> total solution.  If you're not interested in doing a little more work to
> ensure your visitors have a faster, more enjoyable experience, then so
> be it.  If you are, then doing that extra work will result in a better,
> faster, more reliable experience.

I personally wouldn't use word "reliable" in conjunction with
browser-based XSLT implementations. But might be I have just bad past

1. Doesn't IE strips whitespace-only text nodes anymore?

2. Does IE uses the newest MSXML installed, or it is still using
MSXML3.0 which can quite easily utilize your CPU to 100% if you do a
little bit of grouping without using xsl:key?

3. Is Transformix in Mozilla significantly faster then 2-3 years ago
when I gave it try?

> What I am suggesting is that there is a massive base of developers out
> there that need to pull their head out and realize they don't know jack
> about how to build a high performance web site and what they need to do
> is shut their traps, open up a book, and realize that every that with a
> combination of fewer bytes sent out over the wire coupled with less
> server side processing means they are going to be able to server more
> requests in less time and as such, build better, faster, more reliable,
> and cheaper web-based applications than they *EVER* could if they
> attempt to maintain 100% of the control of the HTML generation on the
> server.

I completely agree with you, I was promoting this idea since time IE
supported <?xml-stylesheet?>. But there are some still XSLT
compatibility problems on client side and not all clients support XSLT.
Of course, you can generate HTML for such clients on server as a
fallback. But you have to maintain two applications pipelines and it is
not cheaper anymore.

> * If with each request I quickly check the header and determine ahead of
> time what the requesting client is I can then make a determination as to
> whether or not that client supports XSLT.  In the case of Google, I
> would send them a prerendered (or potentially dynamically rendered) HTML
> file.  In the case of IE, Mozilla, Safari, and Opera (which collectively
> form well over 99.9% of the web browser market) I can send them a static
> XML file (that same static file can be rendered via a background process
> each time the data for that page changes) of which will be rendered
> *FASTER* than it's HTML counterpart which took 4 times longer to arrive
> and *AT LEAST* 4 times longer to parse.  Of course, an SGML processor is
> by its very nature *SLOWER* than an XML parser and as such you are going
> to be lucky if you can squeak out less than 5-6 times slower than its
> XML counterpart.

- From user experience point of view this holds only in case that
transformation can be done in streaming mode to decrease latency.
Current XSLT implementations are not able to work in streaming mode
(Saxon probably could in some cases, but this state-of-the-art
technology is not used in browsers).

- --
- ------------------------------------------------------------------
  Jirka Kosek      e-mail: jirka@xxxxxxxx      http://xmlguru.cz
- ------------------------------------------------------------------
       Professional XML consulting and training services
  DocBook customization, custom XSLT/XSL-FO document processing
- ------------------------------------------------------------------
 OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member
- ------------------------------------------------------------------
Be in, register for XML Prague 2007 today! http://www.xmlprague.cz
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


Current Thread


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.