xsl-list
[Top] [All Lists]

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

2007-06-30 03:21:55
-----BEGIN PGP SIGNED MESSAGE-----
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
experience:

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(_at_)kosek(_dot_)cz      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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGhi7PzwmSw7n0dR4RApK6AJ98XDbQBNTeH/7vQMuU/xr8xTUWBwCfa8Yl
1k31NxZAdzWK1WznIII6I3E=
=4V5r
-----END PGP SIGNATURE-----

--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--

<Prev in Thread] Current Thread [Next in Thread>