Loading ...
Sorry, an error occurred while loading the content.

7056Re: [XSL-FO] Why XSL-FO? Any WYSIWYG tools?

Expand Messages
  • G. Ken Holman
    Dec 22, 2005
      At 2005-12-23 13:45 +1100, hedley.finger@... wrote:
      >I have been lurking on this list for several months now after reading the
      >W3C specs. So I have a couple of questions for you experts.
      >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
      >FrameMaker's MIF.

      I would rather see it as a printer's HTML, not as either of those.

      >I realise that
      >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.

      Right ... the same way a browser uses the HTML you've created from your XML.

      >But wasn't the great promise of XML that it separated content from

      Indeed ... 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 designed
      >to supply that formatting externally to the XML content file?

      Indeed. XSLT for the rearrangement of the information, and XSL-FO
      for the pagination.

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

      Indeed you cannot ... just the same as with HTML ... once you convert
      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 instead
      >that replicates all the functionality of these formatting languages --

      Which formatting languages? RTF is a proprietary word processing
      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 one
      >renderer, Prince, uses CSS2 with extensions
      >for this purpose. So can someone tell me what the justification for
      >XSL-FO is?

      What it was five years ago or what it is today? One could instead
      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?

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

      It would only get you up to speed with a given vendor's idea of how
      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.

      Everyone wins.

      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
    • Show all 12 messages in this topic