OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

> So you want to render some mathematics stuff,

Often I do, yes.

> sending something  like XSL FO ( just for Mathemathics ) ? Let's
> call the thing MathFO.

Actually supporting mathematics was one of the original requirements
for XSL FO although it (not unreasonably) didn't make it into 1.0.
But no, I didn't mean FO. If I send MathML to the client then some
clients (mozilla, amaya) can render it natively and some can render it
with the help of plugins/applets (techexplorer, webeq) although in this
latter case the markup needs re-arranging to add applet calls etc.
Also for a surprisingly large range of expressions you can display
just using CSS and javascript (CSS to do absolute positioning, and
javascript to find out the rendered size of subexpressions and
construction of large brackets, etc) In this last case the actual code
looks terrible of course, lots of inline script...
With client side scripting I can sent MathML to the client and 
the client can transform to whatever it needs.

If you are not interested in Mathematics replace MathML by SVG or some
other language of choice in the above.

> 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.

> 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.

If XML only lives on the server and what you send to the client 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.


This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.