XHTML と HTML5

HTML の歴史を振り返ると、HTML4 までの HTML は SGML を用いて定義されていたと言う。そこから、HTML5 にそのまま進化したのかというと、そうではなく、 XHTML という XML で定義された HTML が登場した。それが20世紀から21世紀に変わるころだったから、今から20年以上前である。
因みに、XML 自体 SGML を元に作られているらしいのだが、XHTML が登場した時は、HTML が XML で定義されたことによって、DTDXML Schema などのスキーマ定義言語で独自のスキーマを作ることによって、HTML 以外にも様々なマークアップ言語が開発されて利用されるようになるのではないかと期待したものである。
しかし、時代は必ずしもそういう方向に行かなかったように思う。XSL もそれほど普及しなかったと思うし、何より HTML が HTML5 という独自路線に進化した。SVG も MathML も XML の一種として XHTML と同等に扱われるというよりは、HTML に埋め込むという使い方に向かっているように見える。
HTML5.0 が勧告されたのが、2014年である。HTML をより汎用的に XML 文書のひとつとして捉えると言うのは理想主義だったのだろうか? ただ、XHTML が完全に廃れた訳ではなく、例えば EPUB の仕様の中などに残っている。

InDesign と XML(7)-書き出しオプションの「改行、空白、特殊文字を再マップ」-

InDesignXML の7回目。
InDesign から XML を書き出すときのオプションで「改行、空白、特殊文字を再マップ」というものがある。これを選択するのとしないのとで、何が違うのか。
InDesign のマニュアルを見ると「改行、空白および特殊文字を、その文字そのものではなく小数点エンティティとして書き出します。」と書いてある(本稿執筆時点での情報)。これは、意味がわからない。英語版のマニュアルを見ると、「小数点エンティティ」の部分が“decimal character entities”となっている。
“decimal character entities”が、XML の仕様的に正しい言い方なのかは疑問だが、文字参照を10進数でやることだとわかった。文字参照とは、その文字を直接書くのではなくて、“&#”に続けて10進数で Unicode のコードポイント続けて“;”または、“&#x”に続けて16進数で Unicode のコードポイント続けて“;”と表記する方法である。
実際に、「改行、空白、特殊文字を再マップ」を選択した場合と選択しなかった場合で結果を比較してみた。
すると、どういう訳か出力されたものに文字参照らしきものは見当たらない。いわゆる全角スペースも半角スペースもそのまま出力されている。しかし、違いがなかった訳ではなく、「改行、空白、特殊文字を再マップ」した場合は、改行が半角空白に、「改行、空白、特殊文字を再マップ」をしなかった場合は、改行が Unicode のコードポイント(16進数)で表せば 2029 という見慣れない文字に変換されていた。コードポイント 2029 の文字は、PARAGRAPH SEPARATOR と言うらしく、テキストエディタの種類やその設定によっては、ただの空白のように表示されるので気づかないかもしれない。以上は、UTF-8 で出力した場合の話である。
Shift_JIS で出力した場合、「改行、空白、特殊文字を再マップ」した場合は、改行が半角空白に、「改行、空白、特殊文字を再マップ」をしなかった場合は、改行が CR に変換された。これは、元のファイルの改行が、CR+LF であっても、LF であっても、同じ結果だった。
この疑問に対しては、以前 Adobe のサイトからダウンロードしておいた "Adobe InDesign CS3 and XML: A Technical Reference" という資料が役に立った。CS3 というところが古くて気になるが、やはり InDesignXML という組み合わせは下火なのだろうか? 現在、この資料にアクセスできるかも定かではない。
ともあれ、InDesign が言うところの「改行、空白、特殊文字」とは何なのか、どの文字が10進数の文字参照にマップされるのかは、この資料で明らかになった。
それによると、半角スペース、全角スペースは、そもそも「改行、空白、特殊文字」に入っていないので、そのままの文字で出力される。復帰(CR)、改行(LF)は、半角スペースに変換されるのだそうだ。そして、例えば、「“」(LEFT DOUBLE QUOTATION MARK)、「”」(RIGHT DOUBLE QUOTATION MARK)は、文字参照にマップされると書いてあったので、試してみたところ、それぞれ “” と10進数の文字参照で出力された。以上は、「改行、空白、特殊文字を再マップ」を選択した場合である。
「改行、空白、特殊文字を再マップ」を選択しなかった場合に、改行が PARAGRAPH SEPARATOR(UTF-8のとき)や CR (Shift_JIS のとき)に変換される理由は、上記の資料では解明できなかった。

InDesign と XML(6)-XSLT-

InDesignXML の6回目。
XSLT は、XML 文書を別の XML 文書(やその他の形式)に変換する言語であり、XSLT 自体 XML の文法に従っているという、理論的には魅力的な仕様となっている。
XSLT を処理する XSLT プロセッサは、無償で使えるものもあり、Java などのプログラミング言語からも使える。
よって、XSLT を使うのに InDesign に頼らなくても良いのだが、InDesign にも XSLT を処理する機能が備わっている。
InDesign における XSLT の使い道であるが、例えば、XHTML 形式のソースファイルを InDesign 用に自分で定義した XML 文書に変換することが考えられる。
InDesignXSLT を使うには、XML 文書を読み込む時の読み込みオプションで「XSLT を適用」を選択して、「参照」から XSLT ファイルのある場所を指定する。または、XML 文書の中にスタイルシート処理命令を書いておいて、「XSLT を適用」で「XMLスタイルシートを使用」を選択すると、スタイルシート処理命令の href に書かれた URIXSLT ファイルの場所として指定される。
すると、XSLT が適用されたものが読み込まれる。
構造ウィンドウメニューの「XML を書き出し」または、[ファイル]->[書き出し]から、構造ウィンドウに存在する XML 文書を書き出すことが出来るので、XSLT が適用された結果を出力して確認することが出来る。
XSLT は、ある意味、意欲的な仕様なのだが、生産性という面では疑問を感じるところもある。全ての変換を XSLT でやろうとすると、超絶技巧になってしまう。XML を扱う技術は XSLT 以外にもたくさんあるので、 XSLT を使った方が簡単な部分は XSLT を使い、それ以外の部分は他の技術を使うのがベストプラクティスではないかというのが、私の感想である。

InDesign と XML(5)-DTD による検証-

InDesignXML の5回目。
DTD は、XML 文書の構造を定義するスキーマ定義言語のひとつであり、DTD を使って XML 文書を検証することによって、妥当な XML 文書(valid XML document)であることを確認できる。
DTD による検証は、InDesign 以外でも出来るのだが、InDesign からも出来る。思わぬ間違いを防ぐために是非とも活用したい。
構造ウィンドウで、検証したい XML 文書が読み込まれていることを確認する。そして、DTD は、別ファイルで用意しておく。構造ウィンドウメニューで「文書型定義を読み込み」を選択して、その DTD ファイルを読み込む。
DTD ファイルは、InDesign に読み込まれるので(参照ではなく)、元の DTD ファイルに変更を加えても、読み込まれたファイルには変化はない。変更されたものを使いたい場合は、InDesign 側で古い DTD ファイルを削除して、新しいファイルを読み込む必要がある。
検証を実行するには、構造ウィンドウメニューで「ルート要素から検証」または「選択要素から検証」を選択する。ルートを含めた一つの XML 文書としての DTD を用意している場合は、「ルート要素から検証」を選択する。読み込んだ XML 文書がルート以下の要素となっており、その文書に対する DTD を用意している場合は、検証したい要素を選択した上で、「選択要素から検証」を選択する。
検証の結果、エラーが出た場合は、構造ウィンドウの下のほうに表示されるので、XML 文書を修正するなり、DTD を修正するなりする。
以上、DTD ファイルを別に用意した場合(外部サブセット)について説明したが、XML 文書内に記述した場合(内部サブセット)も、動作が確認できた。

InDesign と XML(4)-レイアウト-

InDesignXML の4回目。
追加モードで読み込んだ XML 文書をページにレイアウトする方法。
ページにレイアウトする前に、DTD による検証やタグとスタイルのマップなど、やっておきたいことはあるのだが、先ずは、レイアウトする方法を記しておく。
ページは、予め InDesign で作っておく。そして、構造ウィンドウからページへ要素をドラッグするだけである。
結合モードで XML 文書を読み込む場合、プレースホルダーを作っておいて自動的にレイアウトするという方法があるらしいが、今回は、その方式は採用しないので、その話は省略する。

YouTube のタグとハッシュタグ

YouTube の動画をアップする側の話である。YouTube Studio で動画アップロードしてタグを付けたのに、動画に反映されていないと思ったのは、私だけではないはずだ。
実は、タグは検索でヒットしやすくするために付けるものであり、タイトルの上に青い文字で表示されて、クリックできるのは、ハッシュタグである。
ハッシュタグは、動画のタイトルまたは説明に直接、"#"に続けて書く。注意する点としては、ハッシュタグにはスペースは入れられない(その時点でハッシュタグの区切りと見なされる)といったところである。
以上、YouTube のヘルプを見れば、ちゃんと書いてあったが、割と混乱しがちなタグとハッシュタグの話だった。

InDesign と XML(3)-構造ウィンドウ-

InDesignXML の第3回目。
構造ウィンドウである。その名の通り、XML 文書の構造がここに表示される。構造ウィンドウは、[表示]->[構造]->[構造を表示]を選択すると、現れる。
追加モードで XML 文書を読み込んだ場合、ひとつの要素として構造ウィンドウに追加されるわけだが、XML ドキュメントには必ず1個のルート要素がある。そこで、「選択構造要素へ読み込み」オプションをチェックしなければ、ルート要素の直接の子要素になる。
逆に言えば、構造ウィンドウで既存の要素を選択した上で「選択構造要素へ読み込み」オプションをチェックして XML 文書を読み込んだ場合、その要素の子要素として追加される。
構造ウィンドウでは、要素の操作や DTD を使った検証、属性の編集なども出来るのだが、それらの内のいくつかについては、回を改めて書いてみたいと思う。