[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: XSL-FO Does it have the guts?

---

---

> In Leventhal's critic of XSL on xml.com, one of his first arguments
> against XSL is that it provides flow objects that don't make sense on
> the web, such as page flow objects.

Most of the formatting objects currently in XSL are appropriate for both
online and print. Some are designed for paginated environments like print
(although you can have paginated environments online too, mind you)

> Then he says that the number of people who will be publishing to more than
one media (paper and web)
> will be small in number

Lots of people want to publish stuff in dual media. I don't know where
Michael gets the idea they don't.

> and they can easily pick up existing standards: CSS, and DSSSL to do that
kind of publishing.

It is much easier to manage dual-media publishing if the same stylesheet
language / system is used for each medium. I don't understand the argument
that says that CSS for online and DSSSL for print is easier than XSL for
both.

> He later goes onto state: "I am qualified to give an expert opinion in
this area and my opinion is
> that DSSSL and XSL are hard!"  Since I am not an expert in
> formatting/transformation languages, I'm trying to validate this claim.

Formatting is hard. If I wrote FOP (my XSL formatter) for CSS instead of for
XSL, it would not make my job much easier. Most of the advances XSL
currently (note use of the word "currently") makes over CSS are relatively
easy to implement. Multiple page masters and regions weren't hard at all in
FOP. I even know how I'm going to implement dictionary-style headers for
when they make it in the XSL spec. The *hard* parts of FOP are generally in
the areas (no pun intended) that apply to CSS or any other formatting
system.

> I buy into the *concept* that XSL will be able to publish to more than
> one media with the same source and formatting language, and I think
> Leventhal misses the point that XML is all about looking beyond the
> web.  Does the set of flow objects currently in the XSL spec have enough
> power for publishing?  On the continuum from 'easy' to 'hard' publishing
> jobs, what will XSL be able to address?

In my opinion (I have worked in both web and print publishing, but I won't
claim to give an "expert" opinion) the XSL spec *as it currently stands*
will give pretty powerful print capabilities---probably exceeding your
typical word processor (but maybe not by much). Even if it stops at this
point, this has the potential to revolutionize publishing. In the longer
term, though, I suspect XSL will achieve more advanced capabilities like
dictionary-style headings, sychronized marginalia, etc.

The great thing is that XSL has, I believe, a solid framework. XSL does
CSS-like formatting in a very CSS-like way (from an abstract formatting view
they have *a lot* in common for the simple stuff) but it is possible to
increase the functionality to its current spec state and beyond *within* the
framework.

XSL draws a lot from DSSSL and this is one of its great advantages. A lot of
the tough conceptual thinking was done for DSSSL. With XSL, the great minds
behind DSSSL (people like James Clark and Anders Berglund* ) have been able
to make it really practical to use.

James Tauber

*just to pick two :-)


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

---