XSL入門以前 2 XSL-FOのためにXMLを作るのは面倒
この記事はXSL Advent Calendar 2020の6日目の記事です。
別に1人アドベントカレンダーとして作ったワケではないので、埋めてもらって構わないんですよ？
さて、XSLを学習するにはどこかの段階で変換元のXMLやXML以外の文書を引っ張ってくる必要があります。既にXML資産がある状態ではXSLTはかなり効率の良い手段となり得ますが、そうでない場合はそうでない。
ひだるまが技術書典9で頒布したのは、「CommonMarkで書いた文章をCommonMarkパーサでXMLにして、それとJSONをXSLT 3.0で変換してHTMLページを作る」という内容でした。書典10で改稿版を出せるように頑張ります。まあそういうことで、「文書を直接XMLで書く」作業を省く方法について触れておきます。プレーンテキストの話についてです。
あと、AsciiDocからDocBookを吐くのはDocBookが割とヘビィなのでXSL入門に使うにはひだるまは推奨しません。
DBから吐く
組版ソフトや途中経過に違いはあれど、DBからデータを取り出して整形して組版するのは割とメジャーユースのはず。XSL-FOであると、直接データを置く形になってXSLTを経由しないこともあるかもしれません。XSLTを使うにしてもテンプレート言語みが高い形になるのではなかろうか。
CommonMarkからXMLを吐く
cmarkやcommonmark.jsには処理したCommonMarkのASTをXMLで吐く機能があります。
参考記事として次の2つを挙げます。
CommonMarkの利点として、（ASTは）要素が単純であり、網羅すべき変換の見通しが立てやすいことが挙げられます。HTMLタグを許容することを利用してどうしても追加したい+アルファを都度足すこともできなくはないですからね。XSL入門記事でもこれでやっていきたい。
JSONを使う
ページサイズやフォントサイズの情報をXMLで書きたくないというあなた。XSLT 3.0はJSONを読み込めるので、JSONやJSONに変換できる設定記述言語でこれらを書いて、必要なときに処理ができます。この辺りは全部一度にやろうとするよりは、XSLT（xsl:attribute-setだけの集合のような）ファイルを吐くフェイズと文書を処理するフェイズは分けた方がシンプルです。
XHTMLを吐かせる
大抵の軽量マークアップ処理系やテンプレートエンジンは変換ターゲットにXHTMLを持っています。XHTMLはXMLですから、当然XSLTで処理できます。最大の問題は「HTMLならCSS組版でいっか」となったりしてしまうところですかね。
CSS組版の仕組みとしてはO'ReillyのAtlas君やVivliostyleがありますね。
『MathML数式組版入門』はRuby製のSlimから吐いたXHTMLからCSS組版されているそうです。
これらはある程度「書籍のレイアウト」を念頭に記述をしているので、「普通にWebページ用に書いたHTML」とはまた違う話になります。多くの軽量マークアップ言語のHTML変換もWebでの閲覧を意図している形なので、そういう意味ではWeb用XHTMLから書籍用XHTMLの変換にXSLTを使うことを考えてもよいのかもしれません。いや、ドキュメンテーションソフトはテンプレートや変換フィルタを弄れたりするので前段階での処理の方がやっぱり楽かもしれませんが。
未検証 reST、IDGXML
reStructuredText（reST）の処理をするdocutilsにはDTDがあり[1]、XML出力が可能ではあるはずなんですが、未検証です。Sphinxから触ろうとしたら処理を色々書き足す必要がありそうな感じがする。
Re:VIEWはInDesignに流し込めるXML形式の出力に対応していますね。これに言及した記事や書籍はどれも辛そうなのでそのまま使うのは厳しそうですが。
任意の形式を使う
XSLT 3.0の勧告ページに例があるように[2]、自分でパーサを書けば何でもXSLTで変換できます。XSLT（XPath）でパーサを実装すれば！ 「大学時代、JavaScript書きたくないでござる！」って言ったらボスに「じゃあJavaScriptを書かないための研究をしようか」と言われ、いつの間にかミニマイズされたasm.jsのコードから壊れてる箇所を探す作業をしていたことを思いだしました。
Discussion