cas-support2ワンソース・マルチユースという言葉はかなり長く使われています。テクニカルドキュメントなどでは大きなシステムを構築して実現しているケースもいろいろ報告されています[1]。書籍の出版や学術誌の出版ではワンソース・マルチユースはまだ大きな流れにはなっていません。ここではワンソース・マルチユースがなかなか普及しないのはなぜかを考えてみます。※本ブログをもう少し加筆して次に掲載しています。この続きは下記でどうぞ:「ワンソース・マルチユース実践の難しさを考える」ワンソース・マルチユースの仕組みワンソース・マルチユースを実現するには、まずソースの形式を決める必要があります。ソースの形式としては、DocBook、DITA、JATS、HTML5などXML/HTMLによるドキュメント形式を採用するのが便利です。XMLはもともとドキュメントをデバイスやアプリケーションから独立の形式で記述するために設計されたものです。ソースの形式をどのようにするにせよ、ワンソース・マルチユースの出版工程は二つのステップに分けられます。第一はソースとなるドキュメントを用意する工程です。第二は、それをいろいろな目的に出版する工程です。ソースの形式をどう選択するかで、ソースドキュメントの制作の方法が影響を受けます。出版工程も影響を受けます。第一のステップソースとなるドキュメントを執筆、校正して完成する工程です。XML/HTMLではテキストにマークアップ[2]する工程が必須です。マークアップが正しくないと第二ステップの処理ができません。執筆、校正を初めとして、第一のステップは、人手で行うのが主体です。ドキュメントを制作する工程は、まだコンピュータで処理できるようになっていません。現在、いま問題になっているDeNAのキュレーションサイトのコンテンツの収集についての記事を読むと、文章をリライトするコンピュータ処理は、驚くほど進歩しているようです[3]ので、将来は自動的にできるようになるかもしれません。第二のステップ第二ステップはソースを加工処理してWebページ、PDF、各種のHELPなどを作成する工程です。XMLはもともとドキュメントをコンピュータで処理するための技術です。ソースドキュメントをXMLで用意することができれば、プログラムで様々な成果物を用意するのは容易です。DITAではあまりレイアウトなどに拘らなければDITA-OTを使うだけで、HTML、PDFを初めとする多種類の出力が得られます。このように、ソース文書さえXMLあるいはHTMLで作ることができれば、いまの技術を使えば多種類の出力を作成するのは比較的容易です。問題はなにか?ワンソース・マルチユースの難しさはソースをどのように用意するかというプロセスにあり、マルチ出力は大きな問題ではありません。これはXMLやHTMLが技術的に難しいということではありません。上で説明しましたように、第一ステップは人手で行われます。これを担当する執筆者・制作者は、現在、すでに一定のツールを使って一定の手順により作業を行っています。その作業のワークフローをそれまで慣れ親しんできた方法から変更するように説得するのが難しいのです。特定の企業が主体性をもって限られた数のドキュメントを制作しているテクニカルマニュアルなどの分野でさえもなかなかワークフローの転換は難しいのです。多品種少量制作の典型である商業書籍の出版や事務局が責任をもった意思決定をしにくい学会などはさらに難しくなります。発表の概要紹介」の論点について順番に検討してみる。今日は、HTMLを主なコンテンツ形式にすることを取り上げる。以下の原-番号は、先日のブログで段落に付加した番号である。format)とするとメリットが大きいと主張する。原-3.でHTML/CSSセントリックな組版ソフト、原-4.でブラウザ上で動くHTMLベースのJavaScript印刷レイアウトシステムについて解説する。原-2の主張は、ソリューションの中核であるコンテンツ形式としてHTMLを使うということであるので、HTMLをどのように入力するか、そのどのように加工・蓄積するか、どのように出力するかが検討項目となるはずだ。原-3、4ではHTMLを印刷することを議論しているのである。主なコンテンツ形式がHTMLである必要はなく、主なコンテンツ形式からHTMLに変換した上で印刷すれば良い。このように原-2の主張と原-3、4の主張とは一見関係ありそうだが別の話題である。分離して考えないと混乱してしまう。本発表はかなりミスリーディングな部分が多いが、そのひとつはここだ。HTMLを主なコンテンツの形式にすることさて、原-2のHTMLを主なコンテンツの形式にするという主張について考える。ある出版社が(原-1(1))と同じようにテキスト中心の内容を、印刷した本、電子書籍、Webなどのメディアで出版をめざすソリューションの開発を企画したとする。あなたが出版社の社長から新しい出版ソリューションの設計を依頼されたとしよう。そのときコンテンツの中核形式を何にするかは重要なポイントになる。現在のワークフローを分析する必要がある。原-1(1)の(a)~(d))に4つのワークフローの記述があるが、ここで、現在もっとも普及していると思われる、最初にInDesignで印刷本のための版を作るというフローの検討が抜けている。現状分析において、現在の主要ワークフローを無視してしまうというのは、ソリューションの提案を作るためにスタートから落第点だろう。次に、この原-2の冒頭の(1)項であるが、「出版の既存ソリューションは一つとして完全に動いていないし、自動化もされていない。)という主張は誤りである。この反例としては、CAS-UBを挙げるだけで足りる。DITA-Usersでも、この部分についての指摘があった[2]。ここでの議論を見ると、どうも著者達は自分が何を主張しているかを理解できていないように見える。原-2(2)では「HTMLを主なコンテンツ形式にすれば変換プロセスは少なくなるか、完全になくなるだろう。この発表では、XML[3]、XHTML、HTMLが出てくる。XMLを否定してこれからはHTMLだと主張したいようだが、そもそも用語の定義が曖昧である。原-1(2)には「XHTMLはXML準拠でないHTML5に置き換えられつつある。HTML5)という表現があるので、XHTMLを否定しているように見える。従って、主なコンテンツ形式は、HTML5であってXHTML5を含まないと推論できる。すると、原-2(2)(a)の主張は誤りである。EPUB3.0のコンテンツ文書はXHTML5であってHTML5ではない。このため「HTMLを主なコンテンツ形式にすると変換プロセスは多くなる。してみるとわかるとおり、本発表は技術的にずさんすぎる。技術論というよりプロパガンダであると言うのが適切だろう。Webベースのコンテンツソリューションの必要性」での主な論点であるHTML5を中核フォーマットとするワークフローが本当に最適なのかどうか、ここのところには大きな疑問がある。著者達を含め、HTML5+JavaScriptでXMLを置き換えることができるということを主張する論者が多い。確かに一部はそうかもしれない。すべてを置き換えるのはおそらく不可能だろう。systems)[4]のである。原-1、原-2では出版ワークフローの自動化を議論している。ワークフローの自動化を進める際に、HTML5+JavaScriptを採用するか、XML技術を採用するかは極めて大きな選択肢なのである。twitterやDITA-Usersでの議論を含めて判断すると、どうも、著者達は基本的な論点であるはずのところを全く理解できていないようだ。あたりで混乱が起きている。DITAを直接CSSでスタイル付けても無意味である。DITAのtopicをCSSで、直接、組版レイアウトするというのであれば、その発言者はDITAの組版について無知であるという推論が成り立つ。XMLとはなにかについて簡単な解説はXMLを参照。このようにXMLとは膨大な技術体系を意味するのであって、XHTMLやHTMLと比較できるものではない。この機会にオンラインストアを少し改善しました。第3巻』を10月下旬発売します。第4版』プリントオンデマンド版発売。技術書典5にも出品しますのでどうぞよろしくお願いします。簡単な解説10月8日(月)「アンテナハウスCAS電子出版」は、『技術書典5』に出典します。『XSL-FOの基礎』画像制作のこと。Word経由でインポートした画像は印刷品質の劣化が激しいため、第2版ではできるだけSVG形式に変更した件。EdgeのEPUB表示機能はなかなか良い。これからはEdgeだと言いたいところですが、しかし、残念な点もあります。FormatterClubセミナーでの、CAS-UBのスライドと動画を公開しました。