7056Re: [XSL-FO] Why XSL-FO? Any WYSIWYG tools?
- Dec 22, 2005At 2005-12-23 13:45 +1100, hedley.finger@... wrote:
>I have been lurking on this list for several months now after reading theI would rather see it as a printer's HTML, not as either of those.
>W3C specs. So I have a couple of questions for you experts.
>WHY DO WE NEED XSL-FO?
>I realise this question is like asking the pope if we really need the
>Catholic church, but here goes.
>It seems to me that XSL-FO is an XML equivalent of Word's RTF or
>I realise thatRight ... the same way a browser uses the HTML you've created from your XML.
>XSL-FO is only a temporary way-station on the way to outputting to print
>via PDF, so is inherently disposable
>once you have your required output.
>But wasn't the great promise of XML that it separated content fromIndeed ... your XML vocabulary is your content, XSL-FO is the
paginated formatting, XSLT is the bridge.
If your formatting is browser-based instead of pagination-based, then
use HTML/CSS instead of XSL-FO (which includes CSS).
>And weren't CSS and XSL designedIndeed. XSLT for the rearrangement of the information, and XSL-FO
>to supply that formatting externally to the XML content file?
for the pagination.
>Once youIndeed you cannot ... just the same as with HTML ... once you convert
>have transformed your content into an XSL-FO file,
>you have effectively eliminated all semantic tagging, so you can't modify
>the file and replicate it back to the XML original.
your XML for a web browser you've replaced <account> with <p> and
<address> with <p> and you can't go from <p> back to your XML without
a lot of effort (if at all).
>So why not develop CSS or XSL for print formatting?Ummmmmm ... that's what XSL-FO is. XSLT is a spin-off off of
XSL-FO. XSL is the formal name for XSL-FO, and XSLT is normatively
referred to from chapter 2 of XSL.
>Why introduce a cumbersome and verbose alternative insteadWhich formatting languages? RTF is a proprietary word processing
>that replicates all the functionality of these formatting languages --
format with more than just layout, and Framemaker is a proprietary
publishing system with more functionality that just pagination as it
incorporates the equivalent of DTD, XSLT and XSL-FO. Both are
proprietary and not necessarily platform dependent, one of the
objectives of using markup.
And are they not also cumbersome and verbose?
>while admittedly adding extra pagination capabilities?XSL-FO is solely targeted to pagination. Internationally-accepted
standard pagination terminology is used throughout XSL-FO for ease of
use by people familiar with typography and layout. And most of the
vocabulary is CSS anyway.
>CSS3 promises to add the required pagination capability,And has promised it for a long time. XSL-FO has been in production
for five years now. Commercial and non-commercial XSL-FO engines
have been powering some very large and very small publishing
solutions around the world in multiple languages.
>and at least oneWhat it was five years ago or what it is today? One could instead
>renderer, Prince, uses CSS2 with extensions
>for this purpose. So can someone tell me what the justification for
ask what's the justification for CSS3 to come around so much later
when pagination has already been solved? It seems quite unfair to
ask XSL-FO to be justified five years after it has been successful
against a yet-to-be-published CSS3 standard.
Taking a look at the two, XSL-FO is a standalone vocabulary to which
you transform instances of your document model into instances
representing the paginated layout you require, while CSS3 decorates a
document instance with pagination properties. Both models have
existed for a while, users transforming their XML instances into
instances of HTML for browsers, and users decorating documents
structures with CSS.
So I'm guessing the designers of CSS3 wanted to maintain the document
decoration approach ... does that negate the transformation
model? To each his own. There are multiple data models for
XML. There are multiple transformation models for XML. What's the problem?
Transforming information to HTML for a browser with browser semantics
was a model before XML came around ... creating XSLT to transform XML
to HTML fits that existing model ... creating XSL-FO for pagination
semantics instead of browser semantics fits that model as well.
Decorating information in HTML with properties is another model and
the CSS3 developers are further extending that. And they haven't
finished yet. I wholeheartedly support those who wish to follow that
decoration model of publishing instead of the transformation
model. And they can wait until that model is complete and
standardized, while those who have chosen the other model have been
solving publishing problems for the last five years.
Why would XSL-FO need justification? Why can't both exist?
>WHAT ARE THE BEST WYSIWYG EDITORS FOR XSL-FO DEVELOPMENT?It would only get you up to speed with a given vendor's idea of how
>Having questioned the whole rationale for XSL-FO, I thought I would go for
>broke by asking the list's advice about
>suitable WYSIWYG designers or editors for developing XSL-FO stylesheets
>interactively. It appears that XSL-FO
>is here to stay, so it is probably prudent to add the relevant skills to
>my existing publishing experience. I figured that
>developing stylesheets via a GUI and then examining the code would get me
>up to speed faster.
to abstract the pagination into the semantics of their GUI. And that
may be just fine for you. I have no comment on any vendor's choice
of abstractions for their tools that assist in the creation of XSLT
stylesheets for XSL-FO.
I've yet to see any vendor create the abstractions that would help me
solve my customers publishing problems, so I just use XSLT. And I
get to design my XSLT my way to meet my customers' business
requirements regarding their development staff and practices. How
would a vendor even guess what those requirements are?
Publishing needs are unique to each and every customer. What kinds
of transformation are required and what nuanced layout manipulations
are needed are very particular to publishing objectives.
>Can any users of WYSiWYG editors recommend those I should investigate?I recommend you learn XSLT and get full control of XSL-FO by
transforming your XML to the XSL-FO needed for your publishing
solution. If you find the constraints of a given vendor's GUI
doesn't interfere with that, then all power to you, but please don't
judge the power of XSL-FO by measuring only a vendor's choice of how
much control over XSL-FO they give to their customers.
Oh, and to boot, if you do choose to tie up your learning and your
stylesheet construction solely to the choices of a given vendor's
GUI, it almost becomes proprietary: what happens if the vendor goes
away? How would you be able to support your stylesheets? What
happens if the boss asks for something that is available in XSL-FO
but isn't available in the vendor's GUI? Has XSL-FO failed you? Not
at all ... the vendor has failed you.
Knowing XSLT and knowing XSL-FO gives you the platform, vendor and
product independence promised by the use of markup.
I've enjoyed this holiday gift of the chance to discuss this
question, but it is a tired question that perhaps some people haven't
heard discussed ... I hope you weren't being malicious in trying to
goad a CSS vs. XSL-FO killer fight with last one standing wins ...
that is very old talk from many years ago that is water under the
bridge and the world lives in harmony with the two approaches.
CSS3 would not be able to solve my customers' publishing objectives
and I would not ask it to. It may very well solve other peoples'
problems and they are welcome to use it.
Happy holidays and happy new year to all readers!
. . . . . . . . . . . . Ken
Upcoming XSLT/XSL-FO hands-on courses: Denver,CO March 13-17,2006
World-wide on-site corporate, govt. & user group XML/XSL training.
G. Ken Holman mailto:gkholman@...
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/f/
Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05 http://www.CraneSoftwrights.com/f/bc
Legal business disclaimers: http://www.CraneSoftwrights.com/legal
- << Previous post in topic Next post in topic >>