Re: [xsl] Is letting the browser transform XML to XHTML using XSLT a good choice?

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

I read through this again, and am still amazed at how much you seemed to 
take liberties to adapt my comments to fit into something you felt you 
could argue against.  But I decided to take some time to step away from 
this for a bit to make sure I could reapproach this will a clear head, 
having thought through as many scenarios as I could, that would seem to 
warrant a static approach.  In fact, a static approach to this problem 
is something we are both proposing -- me partially, you completely.

Lets present a simple scenario that is fairly common in the world of 
blogging, and see if we can come to a compromise:

Many of us generate static HTML files when we write our blog entries.  
In fact, so do I.  So I am not one who can suggest this is totally and 
completely wrong.  In my particular case, your comments regarding a file 
never changing (or rarely any way) are valid -- except when you bring 
into play the notion that comments and/or trackbacks will cause a 
rebuild of a page, and depending on the last visit of the visitor to a 
page, the conditional get request might invoke a need for a partial, or 
full page sent back in the response stream.  If its been recent enough, 
then we might be able get away with a partial fulfillment and be happy 
with this.  Not exactly a strategy that can be given a whole lot of 
credit as there is no predictable pattern to ensure a consistant 
experience.  But its not a death knell either.

Extending this just a tad, however... if we simply took the time to 
create a transformation file that contained all of the pre-rended 
content that never -- or a least rarely -- changes, and then invoke a 
transformation process that would check if the post source XML file has 
changed, and if it has not, plop in the cached file fragment into place, 
and then the same for a comments/trackback section that would, gaining 
either partial or full acces to the updates, we have now created 
something that allows for both stratgedies to thrive in the areas they 
were designed for, 

We could, of course, make this even more generic, and implement a 
similar process for things like side bars, and what have you which would 
allow for one generic transforamtion file for all entry pages that 
constucted the client side file in small, easy to cache and manage pieces.

The result ensures a clean, simple, waste not, want not approach... 
something it seems we can easily agree with each other as being a good 
focus for any particular project or project section.

I realize I came across QUITE STRONG earlier... there were good reasons 
for it, but what I should have done is stepped away for an hour and 
analyzed things before returning to then write -- the above, more than 
likely, would have been the result if I had.

None-the-less, twisting the words of other folks into something that 
fits the argument instead of arguing the points as originally stated. is 
just bad policy.

That said, so is writing a response to a post after your firecracker 
fuze has recently been lit.  That was my mistake.  I hope you can accept 
my apology.

Maybe we can try and bring this discussion into something that seems 
more like an attempt at an adaptible solution we call can extend from, 
and subsequently benefit from, instead of tempting Tommie to bring out 
the "MulberryTech SmackDown CrackDown", something I know she must dread 
having to deal with when things like this get out of hand... like they 
did when I entered into the conversation with my flame thrower and 
bucket of oily rags. :)  Not a good combination, nor a good idea all 
together.  Again, my apologies.

How can we solve this such that we can all walk away feeling like we 
have done something positive, instead of something potentially VERY 
negative to both ourselves and the community?

Any ideas?

(probably best if I keep my mouth shut for a bit longer and let others 
chime in :)


Jesper Tverskov wrote:

> Case for client-side/server-side XSLT transformation
>
> Mr Peterson is telling us that XSLT support in browsers has been good enough
> for at least a year or so, and that many websites could benefit from making
> use of client-side transformation. This I accept could be true for a small
> minority of websites, but not and probably never in general.
>
> I think most of us have s strong feeling that webdesign must be as simple as
> possible to be able to develop and maintain in the long run. We simply hate
> the idea of having to test each request for a webpage and serve webcrawlers
> like Google one page transformed at the server, then to test if browsers
> need an XSLT 1.0 or an XSLT 2.0 stylesheet, and then to send both some xml
> data store file and the proper XSLT stylesheet to the browser.
>
> Transformation server-side is not just one thing. We should do it the smart
> way, that is we only transform our data store to an XHTML/HTML webpage each
> time the data store has changed. For the majority of webpages the
> transformation server-side only takes place once or twice in a lifetime. For
> other pages a couple of times a year, a month, a week, a day, an hour.
>
> Could it really be better to transform each end every webpage every time a
> browser requests it, in the browser, compared to once or twice in a life
> time server-side? This is what we are talking about for the majority of
> webpages.
>
> Even when client-side transformation has some advantages, these must really
> be big advantages to make me set up a more complex website.
>
> My conclusion is that the potential benefits of client-side transformation
> will in most cases not be great enough to be worth considering.
>
> But I will implement it for at least one of my websites as I test.
>
> Best regards,
> Jesper Tverskov