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

["M. David Peterson" <m.david@xxxxxxxxxxxxx>]

On Sat, 30 Jun 2007 04:22:07 -0600, Jirka Kosek <jirka@xxxxxxxx> wrote:

> 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.

Fair enough.  You have me on this one.  I do forget that there are still a  
good portion of folks still using dial-up, so you're right, in this case,  
the load speed would seemingly be longer no matter how long it actually  
takes.


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

I use, by force of habit, xsl:text for all significant white space in my  
transformation files, so I never run into this problem.

> 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?

IE 7.0 uses, I believe, MSXML 6.0.  IE 6, I believe, uses MSXML 4.0,  
though I'm not absolutely certain to be honest.  But your point regarding  
MSXML 3.0 still being around is a fair point.  I'm not sure how many  
installations still exist, but when you're dealing with 100's of millions  
of Window's installs, the number has a chance of still being pretty high,  
obviously.

Okay, so you got me on this one too ;-)  They might be edge cases, but  
none-the-less,

+2 Jirka ;-)

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

The Fx 3.0 bits seem to be quite a bit faster, yes.  Anyone know for sure?

> 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.

Hmmm... Yes and know.  I would lean more towards things being faster when  
you consider that a significant majority of the requests are for browsers  
that support XSLT.  Of course, dependent upon how busy your site is, a  
good portion of those requests are going to be from search engines.  For  
less busy sites in which the perentage of non-XSLT-support requests are  
going to be noticably higher, I think it's going to be a matter of testing  
to really find out for sure if there is an overall savings or not.

+1/2 Jirka
+1/2 M:D

> - 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,

And of course Saxon (unfortunately!) isn't embedded into any browsers.  I  
do believe that the combination of cached XSLT files and smaller data  
files will make the streaming transformations less of a concern, but it's  
obviously a per-use-case type scenario.

So,

+1/2 Jirka
+1/2 M:D

Which totals to,

+3 Jirka
+1 M:D

Hmmm... DAMN!

I'll be back, Jirka... I'll be back.  Bwah, haa, haa, ha, haaahhhh.... ;-)  
:D

--
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |  
http://dev.aol.com/blog/3155