Re: <xsl:stylesheet xmlns...

[Paul Tchistopolskii <paul@xxxxxxx>]

----- Original Message ----- 
From: Sebastian Rahtz 

> Paul Tchistopolskii writes:
>  > Well - consider Sebastian's test6.xsl ;-) He is generating 
>  > 40K HTML out of 500K of data. I can not belive he'l send 
>  > those 500K to the client. I got the impression that he 
>  > said that he may do that , but  I think  there is some 
> 
> I might well deliver the main data file, and a slew of small .xsl
> files to do amusing things with it

I'm sure I still don't understand  you. Let me explain.

What do you mean by saying "I'l deliver the main data file
to the client,  and a slew of .xsl files" ?  The <xsl:stylesheet  
directive provides one - to -one binding. I mean you use 
this directive to say : "this XML file should be rendered 
with this xsl stylesheet".

How can you deliver main data file and a slew of small 
.xsl files using <xsl:stylesheet  directive?

Or you are talking about some proprietary-absolutely 
non-standard-vendor-specific API which allows you 
to associate the same main data file with multiple 
xsl stylesheets ? Shame on you, Sebastian, you should 
not get your hands dirty with using  the API's which 
are not blessed by W3C ( right? ;-). 

<OT> 
Please forgive me for biting you one more time, 
if you can ;-)   I realy respect your oppinion and as I 
already told you,  your work with cemeteries is so 
influencing that I'm now changing all the scheduling 
I had for Ux to support your usecase. I'm also now 
thinking  about the very interesting problems XSL 
realy has with 'flat' structures. I think biting sometimes 
results in the real progress - that means everything 
is OK, right?  I wish on your side it is also OK.) 
</OT>

Now back to the point. Unfortunately that proprietary API 
mentioned above also has some problems and this 
makes the senario you are describing to be very much 
hypotetical. ( I mean static vs dynamic + caching is 
a problem ).

The smart  processing model for complex 
XML / XSL client / server apps simply 
*does not exist*. Those who are saying 
it does exist should have something 
to show. In the form of working app, I 
mean.

I also think that the *simple*  processing model 
supported by 'standards' will hardly fly in the real life. 

Sofar  *all* of XSLT client/side/rendering relatively 
complex ( other than trivial ) pages which I saw 
are simply failing in unpredictable fashion with  
some versions of MS IE 5.*

Just today I have tested one recourse which claims 
to be based on XSLT client-side rendering. As it 
already happened - it crashed my  version of IE 5.* 
after 10 random mouse-clicks. In current browsers there 
is  some hacking / threads when user clicks multiple 
URLs rapidly. I mean the entire browser 'machine' is 
not yet prepared for XSL / XML. I can explain this in more 
detail, but this will require discussing JavaScript ,  internals 
of Mozilla e t.c. et.c. Not too much XSLT here.

Rgds.Paul.




 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list