[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Client-side XSLT. Re: Bad News on IE6 XML Support
- From: Paul Tchistopolskii <pault12@pacbell.net>
- To: David Carlisle <davidc@nag.co.uk>
- Date: Tue, 11 Sep 2001 07:09:15 -0700
> 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.