知らないということは単に自分だけの問題にとどまらず、大いに他人にも迷惑をかけることであると感じました．今回のXSL-FO 2.0をめぐる議論で、XSL-FO 2.0が流産してCSSへの道まっしぐらというのはW3CにとってもXSL-FOのユーザーにとってもまったく良いことではないというのが私の思うところです．
しかし実は私個人はXSL-FO 2.0の仕様に今までなんのかかわりも持っていませんでした．言い訳になりますが、実際のところXSL-FOを使ったアプリケーションの実装に手一杯で、XSL-FOそのものの行く先を論じる場を見る余裕などまったくなかったからです．
でも流産したXSL-FO 2.0 Wroking Draftから過去をさかのぼってみました．もちろんすべてを見るのはとてもできません．
Extensible Stylesheet Language (XSL) Version 2.0 W3C Working Draft 17 January 2012
↓
Extensible Stylesheet Language (XSL) Version 2.0 W3C Working Draft 27 September 2011
↓
Design Notes for Extensible Stylesheet Language (XSL) 2.0 W3C Working Draft 16 December 2010
↓
Design Notes for Extensible Stylesheet Language (XSL) 2.0 W3C Working Draft 04 February 2010
↓
Design Notes for Extensible Stylesheet Language (XSL) 2.0 W3C Working Draft 29 September 2009
↓
Extensible Stylesheet Language (XSL) Requirements Version 2.0 W3C Working Draft 26 March 2008
この「Extensible Stylesheet Language (XSL) Requirements Version 2.0」がXSL 2.0への要求事項をまとめたものとなります．しかしこれを見て唖然としました．
2.1.2 Add text to path
以降に並ぶXSL-FOへの要求事項の一覧です．
簡単に言えば、イラストレータみたいな機能や、Wordの機能をXSL-FOで出来るようにするということではないかと思います．
何故唖然としたかというと、こんな機能は私の接しているXSL-FOのお客様からは決して寄せられないからです．まあ組版の機能としてありえるのかもしれません．でもマーケットの要求とは全然マッチしていません．お客様はもっと実用的な用途でXSL-FOを利用しています．例えば製品マニュアルのようなものは典型的なXSL-FOの用途です．製品マニュアルにこのような機能はまず必要とされません．
このような出発点があったとはまったく知りませんでした．出発点において誤っていては、決してユーザーやベンダーに支持される着地点にはたどりつけないでしょう．
XSL-FOに要求される機能とは、もっと現実的に必要とされるものではないかと思います．ですので
I think the few things that are needed and are found (or not) in some
vendor extensions would be good fodder for an XSL-FO 1.2 rather than
an XSL-FO 2.0 (e.g. line numbering, repeating sets of page master
references, more page-position testing options, etc.).
というG. Ken Holmanさんの意見にまったく賛成です．
現実的に必要とされるものとは、たとえば以下のような機能です．
１．部分的な段組
Microsoft Wordではセクション属性として段組が簡単に実現できます．でもXSL-FOではfo:region-bodyにしか段数（column-count）を指定できません．仕様としてfo:block-containerに段数を指定できるようにすれば、仕様として完成度が高まります．
（⇒会社のFormatterではfo:block-containerの拡張属性として実装されています．）
２．ブロックのページ分割時の定型出力
以下の画像をご覧ください．技術書などでプログラムのコードを載せるとき、それがページに収まらないときは、▽＋○のマークを出します．次のページには△＋○のマークを出します．この例は「Scala スケーラブルプログラミング」（インプレスジャパン）で使われているものです．
［ページにおさまらない場合］
［前ページから続く場合］
同じようなことは、DITAのtask/taskbody/steps/stepでも寄せられています．製品の整備/修理マニュアルなど厳格性が要求されるものは、task/stepがページ分割される場合、やはり"Step continued"などと表示して読者がtaskの実行を決して誤らないようにしたいという要望があります．XSL-FO 1.1はtableがページ分割されるとき、"(Table continued)"と出すことはできますが、単純なfo:blockがページ分割されるときに定型的な情報をページ下部やページ上部に出す機能がないのです．
私はこのようなより現実的な機能が仕様として取り上げられ、XSL-FO 1.2として熟成されてゆくのが一番良い道ではないかと考えています．
Liam Quinは
It's true that XSL-FO adoption is on the rise, as publishers move to
mixed PDF/print and ebook workflows. Other publishers who have been
using XSl-FO for a while seem to be moving towards CSS, and although the
claim that it's easier to find CSS expertise than XSl-FO expertise seems
spurious (CSS-for-complex-print expertise is very very hard to find!)
people do seem to find it compelling.
と言っていますが、そもそも"CSS-for-complex-print expertise"は存在し得ないでしょう．何故なら、HTMLのclass属性（またはid属性）と要素の出現条件を正確に複数のCSSスタイルシートファイルの記述にマッチングさせて認識できるのは人間ではなくて、formatter（またはrenderer）しかありえないからです．つまり人間技では複雑なCSS組版はデバッグできないのです．
