XSL Debate, Leventhal responds to Stephen Deach

[Paul Tchistopolskii]

Hello.

>> Claim 3 Print has no place on the web.

> I said the Web is "not about paper documents" and the web was not the
> place to do page composition.  Everyone likes to be able to print
> documents, that isn't the issue, it is whether you should expect to get
> FrameMaker+SGML documents out of a web browser or not using
> a page composition engine.

One practical comment. Even Web is "not about paper documents"
( actualy I don't understand what does it mean ) there is some constant
need to place documents with complex layouts to the Web.  (It's why we
have a buch of RTF2HTML, MIF2HTML e t.c. converters, Net-It startup
e t.c.). I spent a couple of months implementing '1-to-1' converters for
RTF and MIF,  trying to keep tables, N-columns layouts e t.c. Of course
supporting all the goods is  impossible with HTML, but it is not my point.

<POINT>
With MIF you can ( more or less ) do XML / CSS without reimplementing
FrameMaker rendering engine, because MIF keeps columns content
separated ( thanks to Frame ).  With RTF if you want to render layout
with 2 columns and if you want to go XML / CSS you *should*
reimplement some *significant* part of  Word rendering engine
( simply to understand where the contents of first column ends ;-)
It's why MS Word from Office 2000 still has some ...problems ... with
complex RTF layouts...

Being implemented, FO can handle both RTF and MIF resanobly easy
( resanoble and easy ).

</POINT>

I'm just saying that FO model can handle some things with
complex layouts *much* better than CSS / DOM e t.c and people
*do* need complex layouts on the Web.

> XSL-FO does not provide any clear advantages over CSS formatting and
> CSS is, in fact, a powerful formatting language for XML.

That is not true. Mapping complex RTF document to FO is doable. Mapping
it to CSS seems to be  *impossible* without rewriting  significant part of
Word
rendering engine ( or FO engine ;-). The funny thing is that after
implementing
XSL FO you *can* render such things to CSS, because ... well ... XSL FO
rendering is hard to implement, but being implemented it is powerful.

Of course, you can replace 'RTF' with 'FORMAT X' ( even FORMAT X would
be XML. Nobody can predict  what  particular XML would be created by
some vendor in the future ).

> If the goal of all this were just to write a formatter.  So are you
> willing to say that as a general transformation engine XSL is not really
> useful and that it really is designed only to provide one part of a
> page composition engine

Maybe you are right. Maybe some day it would be possible to redesign
FO and CSS so that :

    XSLT would be for transformations
    FO objects would handle page composition
    CSS objects would handle single page

( Definately, CSS objects have many common with FO objects, where
FO is a superset of CSS. Actualy some kind of mapping FO's to
some kind of CSS already inside FO implementations on the level
of internal structures. ;-)

Or something like that. Until such redesign:

     XSL already has XSL
     XSL already has FO
     XSL already has superset of CSS

As a result - it is very powrful engine and when first FO implementation
would appear, it'l be not easy for you to beat  it with DOM / CSS
( especialy if you'l be asked to do something that deals with N-columns
RTF document ;-)

My 2c.

Rgds.Paul.

paul at pault.com
www.pault.com




xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)