9月11日に電書協EPUB3制作ガイドのV1.0が公開された[1]。以下は、個人的に気になった点をリストしておきます。まだ他にも一杯あると思いますのでだんだん追加します。ここに書いたのは単なる個人的感想ですから、ご参考まで。

全体としては不必要な規制が多いという印象を受けます。こうした不必要な規制は標準のEPUB/XMLツールでは検証できないのですが、できあがったEPUBがガイド準拠であることをどうやって保証するのだろうか？まさか目視？それはないよね。

１．フォルダー構造とファイル名
[ガイドの記述]（p.20）
・素材を格納するフォルダの名前が指定されています。
・itemフォルダにすべての素材を含める。その下の、image、style、xhtmlの3つのフォルダにそれぞれ画像、CSS、xhtmlの３つのファイルを収めています。
・opfファイル名（standard.opf）、ナビゲーションファイル名（navigation-document.xhtml）が指定されています。

[コメント]
・EPUBの仕様ではファイル名やフォルダー名は特に指定されていません。すべてのリソースはopfファイルの中に記述し、またファイルの読む順序はspineで指定するなどOPFには必要十分な規定があります。それなのにガイドでさらに枠をはめているのは無用です。
・このために電書協専用の出力メニューを用意する必要があります。
・これを守らないとどうなるのでしょうか？
・準拠しているかどうかを検証するツールがないと判定できないと思います。

２．idの重複を避ける
[ガイドの記述]（p.67）
・idは、本来、各ページ（XHTMLファイル）ごとにユニークであれば構わないものですが、複数ファイルからなるEPUBデータの構成を鑑みて、ひとつの作品を通じてユニークな値であるものとします。

[コメント]
・ひとつの作品を通じてユニークな値にしなければいけない理由が理解できません。
・作品が多数のファイルから構成される場合、idが作品内でユニークかどうかをどうやって検証するんでしょう。検証ツールがあるのでしょうか？XML標準ではそんなツールはないと思います。

３. 文字コード
[ガイドの記述]（p.9）、（p.45）
・p.9では、少なくとも、以下の文字集合をサポートするものとする：JIS X0213:2004
・p.45には、JIS X0213:2004にない文字は外字画像化。

[コメント]
・p.9の記述とp.45の記述は一貫していません。しかし、将来の発展性とか表現の自由度を考えるとむしろ、外字のフォント埋め込み、あるいは、missing glyphを読者に伝える仕組みを用意する という選択もあると思います。
・[2012/9/13追記]これは、結局、フォント埋め込み以外に解決策がないように思います。フォント埋め込みは技術的には簡単なのでRSがサポートしないはずはないですが、むしろ、ライセンス許諾の問題です。

４．ソースの整形
[ガイドの記述]（p.22）
・divなどのブロックレベル的な要素では、必ず開始タグと閉じタグの直前直後にそれぞれ改行コードを入れるようにします。但し、p，h1～h6タグについては、開始タグの直後、閉じタグの直前には改行コードを入れないようにします。
・aの場合は、aがブロックレベル的要素かimgを囲むのでないかぎり、改行コードを入れないようにします。

[コメント]
・ソースの整形を厳密に規定しても、これを遵守するのは難しいと思います。遵守するメリットもないような。
・インラインタグの内部では改行が空白になってしまうので、不用意に改行を入れてはいけないと書くだけで良いのではないだろうか。
・いづれにせよこれを遵守しようとすると手作業では無理で専用のツールが必要でしょう。
・サンプルをみると、大よそその通りの整形がなされています。エライ！でもそんな必要ないんです。
・[9/12 10:03 追記]他の整形例にはこんなのもあります[3]。XMLオーサリングでエラーになるのは多くの場合タグのネスト関係。結局、タグの階層構造が問題になるので、階層をチェックする整形方法の方が有効だと思います。
・[9/12 11:50 追記]XMLのドキュメントが正しいかどうかをチェックするのはXMLパーサーを使います。EPUBCheckも内部にはXMLパーサー。改行によるテキストレベルの整形は、RSで見たとき空白が挿入される危険性を避ける注意事項以外にはあまり意味がないと思うのですが。
・[9/14 追記]XML文書を整形すると確かにソースのヒューマン・リーダビリティは高まります。しかし、このガイドで記述するような整形基準はみたことがない。そもそもXMLはプログラムで処理するものだし、リーダもプログラムなのでCSSで規定する以外の整形基準はリーダには影響を与えないのです。なのでソースのヒューマン・リーダビリティは、人間がソースをエディタで修正するときしか意味がありません。管理が簡単になることはないと思うのだけどね。

５．クラス属性
[ガイドの記述]（p.9）、（p.45）
・CSSのクラスの種類が大量に定義されています。
・[2012/9/13追記]XHTMLに規定されている要素であるsub、supをクラス属性で定義しています。

[コメント]
・要素の種類が少なくてもクラスの種類が山ほどあり、これを全部覚えて、オーサリングを手作業で行なうのは至難のように思います。
・結局、専用のツールが必要になるように思います。
・[2012/9/13追記]Web標準ではだめとされている手法というコメントがあった[4]。しかしなあ、というクラスが多い。クラス属性はEPUBCheckにかからないので、クラス属性をつかうと、XHTML構文に基づきながらも何でもありになってしまうのです。CAS-UBでも一部これを利用しているので、批判すると目くそが鼻くそを笑うという話になってしまいますが。

■感想
・村田真さんによりますと、ガイドラインには「ガイドラインには大きく分けると、考えて自分で決めなさいというガイドライン、この通りにやればできるから考えるなというガイドラインがある」[2]とのことですが、どうもこのガイドラインは「自分で考えずにこの通りやりなさい」というものになります。で、この方針で生産性を上げようとすると、「電書協EPUB3」専用のツール（CAS-UBでは、文書型、専用編集メニュー、出力形式・生成フィルターの追加）が必要になります。ガイドに記述されていることの多くは技術的に見るとやる必要のないことなので、システム開発にコストがかかる割には、それによってできること（効用）が少なすぎるなあ…「電書協」対応ブランドをつけることぐらいしかシステム対応の意味がない…
・需要があれば作りますが、なんというか、どうでも良い瑣末なことばかりだ。あまり開発モチベーションが沸かないなあ。どうしてこんなくだらないことばかり決めるのがまったく理解できない。

[1] 「電書協EPUB 3 制作ガイド ver.1.0」
[2] https://twitter.com/muratamakoto/status/245544497704996864
[3] http://twitpic.com/atnh9a
[4] https://twitter.com/MurakamiShinyu/status/245738412496265217

□■□■□■□■□■□■ご案内□■□■□■□■□■□■

CASオンラインショップでCAS-UBのユーザー登録することで、誰でも30日間だけ無償でご利用いただくことができます。