RE: <xsl:stylesheet xmlns...

["Chris Bayes" <Chris@xxxxxxxxxxx>]

>> >> >Besides, that often requires to transfer more data.
>> >>
>> >> Depends on the application
>> >
>> >That is why I use "often".
>>
>> I dispute that. It depends on what you send down the line. Obviously you
>> wouldn't send a whole SQL database to a client to do a query.
>You send the
>> results. If the results consist of the minimum amount of data then the
>> transform will *always* produce more output than input if you are
>> transforming to html (transforming to text less). Add cacheing into the
>> equation and client-side transformation will *always* produce less line
>> traffic.
>
>You do not know my but I can assure I am not SO dumb. I made my
>measurements
>by only sending the necessary XML data.

So why say more

>There is also the overhead associated with fetching 2 documents (XML, XSL)
>instead of one (HTML). In most cases I focused on it only saves traffic if
>the browser caches the XSLT.

Um no! think of an xslt and an xml snipped to the limit for brevity
<xsl:template match="row">
	<tr><td><xsl:value-of select="c" /></td></tr>
</xsl:template>

<row>
<c>xxxxx</c>
<c>yyyyyy</c>
for another 3000
</row>

>Now, that being an advantage depends on the nature of the site. It only
>works better if the template caching is used often enough.
>

No not even then!

>There are NO absolute rules. One has to analyse case by case.
>

Yup!

>And there is still the issue of having to work with browsers like Netscape,
>Opera, older Internet Explorer versions and so on.
>
And that is a red herring too. I can't browse most stuff on my WAP phone.
Did Philips(crosshead) think of that when they produced + screws?
Was it a lockin? Who knows. Who cares. You use the right tool for the right
job. I am agnostic when it comes to browsers. I am looking forward to ns v6.
Check the other parts of my site I bend over backwards to accomodate all of
them.

>> >
>> >> >IMHO, server side transformations rule.
>> >>
>> >> Are you selling hardware too?
>> >
>> >I agree that it might be different in an Intranet scenario.
>> >
>> Slightly but not much.
>
>Much. In an Intranet there is more control over the used browser and there
>is not so much compatibility concerns. You also tend to know the use cases
>better.

Yeh but by now most developers know the internet. We hope

>
>>
>> >(Is hardware that expensive these days that I would get a profit form
>> >preaching this???
>> >=:o)
>
>This was an irony. Noticed the smiley?
>
>> Possibly if you are running a data center. The cost of hardware
>> is miniscule
>> compared to the cost of support staff.
>
>And of development staff.

Yup! et al.

>
>> Throw more hardware at it is just not an answer to badly designed
>> applications as many people are aware.
>
>Correct, but some people are also aware that throwing more hardware in a
>concious and controlled way can be a valid strategy to save development
>effort and have faster results.

True but now we are talking a finesse and that wasn't the point!

>
>> I won't even tell you what I think of preachers.
>
>Again, noticed the irony?

Yeh but even a smile doesn't cover the smell of bullshit.

Ciao Chris


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