Re: Netscape Support for XSL - client vs server rant

Subject: Re: Netscape Support for XSL - client vs server rant
From: Dan Morrison <dman@xxxxxxxx>
Date: Sat, 20 May 2000 05:11:53 +1200
Matt Sergeant wrote:
> 
> On Sat, 20 May 2000, Dan Morrison wrote:
>
> > In so many ways this is a better model of information transfer and
> > management....
> 
> Except for the fact that the user gets access to all the benefits of
> stylesheets without having to have the latest and greatest browser.

Oh sure, bring reality into it. No fair!

To compare tho, It's an almost trivial task to take a css stylesheet and
an html page on the server, and cook the html so that _every_ text block
is wrapped in a <font face="arial,helvetica" size="2" color="white" ...>
and pipe it out, thus overriding the need for stylesheet support! Viola,
version 2 browsers get the benifit of CSS.
Horrid thought is it not?

Why then is doing exactly the same thing with XML+XSL any better? 
The largest difference is probably that css took a while to come into
general use, and by that time the browsers had started to support it to
some extent or another.
XML is jumping ahead of the crowd, and as Heather noted, there's little
chance of browsers being able to keep up.


> It's not reactionary at all - but in fact a stepping stone. 

I guess so. You want results, this is the only way to achieve them
today. 'Nuff said.

> With AxKit I explicitly have given developers the chance
> of writing a "Passthru" plugin, so that they can detect browsers which are
> XSL aware and send pure XML. For people not so lucky the plugin doesn't
> activite it's passthru flag and they get XML transformed on the server.

This sounds cool and right. I personally avoid client detection as a
matter of style, but realize it has its place. 
After 4 years of HTML-wrangling in advanced online interfaces, only once
have I had to use explicit server-side client detection (and that was
something to do with Java on IE3...)

Then there was the lie where IE declares itself "Mozilla Compatible" ...
User Agent uurrgh.

> > As a thinking person however, giving the client control is "morally"
> > better. And logistically correct. And, in sub-cable conditions, usually
> > much quicker, when done right.
> 
> And here's the major point you're missing. You're thinking desktop,
> browser based display.

Not at all, not at all. It is specifically with alternative media in
mind that I don't want the only view of the data to be pre-cooked HTML.
What I was aiming at was the client being able to choose its own
presentation of the info within its own capabilities.

I don't expect your server to know or understand what flavour of UI my
palmtop wants to talk, but I would still like to talk with it.
Yet my palmtop version xx.03 beta knows more about its own capabilities
than you do. Pop-ups float in holographic 3d, and I've specified the
alert sound to be delivered as a mild electric shock. Give it the option
to do its own formating.

> Do you really think people
> are going to be installing XSLT engines in WAP devices so that they can
> fit into your ideal world?

Fair call, but are these mythical WAP devices going to speak HTML4
either? Do we want them to? XML is a hell of a lot lighter than that.
It doesn't have to be XSLT the language per se, but a transformation of
XML data into a presentation media native to the device. XSLT is simply
one of the basic ways of doing that job.

> XSLT is massively resource consuming,

True,

> and the benefits of
> sending pure XML to a WAP device (or Braille, or other W3C supported media
> device) are going to be much smaller than sending it to a browser on a
> desktop machine.

Yet the desktop machine does have the resources to consume, and I would
look forward to them being able to do their own transformations.
The fact that only IE does that - yet - is just one of those things that
will come to pass.

And this brings us back to looking forward to the XSLT support on
Mozilla, which the eloquent Keith Visco appears to be bringing us.

Basically I believe we agree on many of the concepts here. 
I was originally comparing server-side data _manipulation_ to
client-side. 
No magic servlet is going to live up to the handiness of the
microsoft.com expanding FAQs and the XML/XSLT-driven Tree-view
Navigation menus. 

As an implimentor you use server-side solutions because they work. As an
implimentor I use server-side solutions for the same reason. I just
don't want to lose sight of the fact that this _is_ a compromise and
when the true alternatives become available they should be jumped at. 

.dan.

:=====================:====================:
: Dan Morrison        : The Web Limited    :
:  http://here.is/dan :  http://web.co.nz  :
:  dman@xxxxxxxx      :  danm@xxxxxxxxx    :
:  04 384 1472        :  04 495 8250       :
:  025 207 1140       :                    :
:.....................:....................:
: If ignorance is bliss, why aren't more people happy?
:.........................................:


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


Current Thread