Re: Client-side XSLT. Re: Bad News on IE6 XML Support

[Paul Tchistopolskii <pault12@pacbell.net>]

> With client side scripting I can sent MathML to the client and 
> the client can transform to whatever it needs.

What does it mean 'to whatever it needs' ? When 
somebody acesses some URL on your website, 
you just dump out the XML ? And how do you know 
what xsl stylesheet to bind on client side? 

Really, you like the idea of 
"user clicks the drop-down menu and selects 
the appropriate stylesheet every time he 
downloads the page"? It  makes sense to you? 
Looks like the usability nightmare to me. 

Well, it will be still better than not displaying 
any page at all.
 
> If you are not interested in Mathematics replace MathML by SVG or some
> other language of choice in the above.

So are you telling me that you can render SVG into 
HTML and CSS ? 

May I see the stylesheets, please? 
 
> > To render MathFO in the browser that does not understand 
> > MathFO ??? How can client-side XSLT help you???
> 
> "presentation MathML" not "MathML". Client side XSLT can help by passing
> the code straight through (mozilla) or wrapping it in an applet (webeq)
> or converting it to absolute CSS positioning and Javascript (IE, and
> probably netscape) depending on the client its running on. And in all
> cases the user has access to the MathML so can also pass it to a MathML
> aware computer algebra system such as Mathematica, something they
> couldn't do with any server side transformed version.

But they can! If user want's to get plain MathML ( to pass it to mathematika), 
user should ask the server for plain MathML.

If user want's MathML rendered into HTML + CSS - user should 
ask the server for such a functionality.

In your "client-side XSLT" scenarios you are masqerading the 
fact that *anyway* user has to ask for something in particular, 
even using this 'client-side XSLT' ... drop-down menues ... 

> > I think you're playing with words here...
> >  ( in the absence of scalable client-side FO ) are *very much*
> > questionable.
> 
> You need a client side rendering language for XSLT to make sense I
> agree, but HTML+CSS will do in place of FO for a large class of online
> uses. Most of the extra functionality of FO is in the area of printing.

SVG ?

> If XML only lives on the server and what you send to the client 

I *never* said this. I never said that you should not 
send plain XML from the server. You can, why not.

You just don't need 'client-side XSLT' without 
client-side FO. 

> is a translation of that to a rendering vocabulary (be it FO or HTML)
> then really there is no real point in most of the features in the XML
> design. It is a cut down version of SGML precisely so it may be served
> over the web to lighter weight clients than a traditional SGML system.
> If it's just on the server the data could be in SGML or some other
> format of choice.

If you can show me a single sentense from my previous letters 
that you are arguing with, I'l be glad. To me it looks like a mess.

If the media is HTML+CSS - rendering into that media could be 
and I think should be server-side. There is no problem with 
serverside rendering of HTML+CSS+JavaScript. Client-side 
XSLT is 'solving' a mythical, non-existant problem ( and 
it introduces more. There are particular problems with 
libraries e t.c., but let us not get there. Let us first see 
*why*use*client*side*XSLT* at all ? )

It seems that the problem solved by client-side XSLT  is mythical. 

I'm *not* saying distributed computing is bad and I'm *not*
saying that 'XML should exist only on the server'.

I'm saying one *simple* thing. "Why do you need client-side 
XSLT at all" ? What gives? ( I understand that it buys 
some set of buzzwords in the resume, but I'm trying to 
see a technological reasoning ). 

Rgds.Paul.