だらだらまとめていたら北村さんが同様の記事を書いていたので、多少端折りました。でも長いな。
どこにどうコメントしていいのか分からないのでかいつまんで。
単なる XML 文書としての XHTML だとしても、やはり XHTML 1.1 DTD が DOCTYPE 宣言にて参照されている以上、™の実体が定義されている事に変わりはないわけだから。やはり Safari がおかしいんでわ。
以下、まず単なる XML 文書としての処理のおはなしっす。例によって仕様書を参照。
とっても重要なことですが、XML プロセサには妥当性を検証するプロセサとしないプロセサの二種類があります。そしてかつ、妥当性を検証しないプロセサは文書実体以外の文書の断片を読み込む必要はない
とされています。これは余計なトラフィックや処理を発生させないためです。
僕の知る限り、現時点の最新版の IE も Firefox も Safari も Opera も妥当性を検証しないプロセサ
です。したがって外部実体を取得する必然性はありません。Safari の解析は XML プロセサとしては至ってまっとうなものです。
ついでなので、メジャーどころの UA の XML プロセサの外部実体関連の実装を調べてみました (かなり適当にて注意、特に Opera は Win 版は異なってたりするかも)。
| Internet Explorer 6.? (Win) | Firefox 1.5 (Mac) | Opera 8.51 (Mac) | Safari 1.3.1 | |
|---|---|---|---|---|
| 妥当性の検証 | しない | しない | しない | しない |
| 外部実体の取得 | する (バグあり) | しない | しない | しない |
| 外部実体が存在する際の不明な実体参照の扱い | - | 誤り (レンダリング中止) | 空文字列に置換 | 誤り (空文字列に置換) |
| 公開識別子への対応 | なし | あり (XHTML, MathML) | あり (XHTML, ただし適当) | なし |
公開識別子への対応
というのは、具体的には文書型宣言で XHTML や MathML の公開識別子が指定されている場合に、対応する DTD を UA が内部的に持っているものに置き換えてしまうということです。仕様書の次の記述に則っています。
システム識別子以外に、外部実体は、公開識別子を含んでもよい。実体の内容を取り出す XML プロセサは、公開識別子及びシステム識別子並びにこの仕様の範囲外の付加的な情報をどのように組み合わせて、代わりの統一資源識別子 (URI) 参照の生成を試みてもよい。
ざっと調べた感じだと、例えば Firefox は W3C 勧告の各 XHTML の公開識別子をシステム識別子 resource://gre/res/dtd/xhtml11.dtd に結びつけて処理しています。Opera の場合はもう少し適当で、公開識別子に "XHTML" という文字列があれば XHTML 用の DTD (のようなもの?) を結びつけるようです。
念のため付け加えると、Firefox や Opera も、これらの「特に対応した」公開識別子で指定された以外の外部実体を参照することはありません。例えば、以下の XML 文書を解析させてみれば、これらの UA が外部実体を読み込んでいないことはよく分かると思います。
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE html SYSTEM "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd" >
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>外部実体テスト</title>
</head>
<body>
<p>©</p>
</body>
</html>一方 Safari は元々こういった例外的な扱いをしていないため、公開識別子に関わらず実体参照を誤りと見なしているというわけです。まあもっとも、Safari の XHTML への対応状況を見ると、a 要素はちゃんとリンクとして扱うし、img 要素は画像に置換するし、id 属性もフラグメントとして機能するので、文字実体が未定義なのは単なる実装漏れだとは思いますが。
あんまりだらだら書いてもあれなので以下まとめに入りますが、XML の実体参照というやつは色々と問題をはらんでいます。今回のケースのように、個々の DTD に対してアプリケーション側がいちいち対応しなければならないのというのがその最たるものです。もちろん IE のように毎回 DTD を読みに行くという解もありますが、個人的にはモジュール DTD をいちいち取得するのは輪を掛けて馬鹿馬鹿しいと思います (MSIE 用 XHTML 1.1 テスト文書 を IE でレンダリングするのに、どれほど無駄なトラフィックと時間とマシンパワーを要するかお試しあれ)。
そのような事情から、XML 方面の主流は「実体は極力使わないようにしよう」という方向に進んでいます。例えば現在策定中の XML 応用の仕様でも、DocBook 5.0 では文字実体の廃止が確定していますし (そもそも DTD が非標準スキーマ)、XHTML 2.0 でも Character entities: do we still need them? という議論が行われていました (こちらは結局存続する方向でまとまったようですが)。
そんなわけで、汎用性を考えるならなるべく実体は使わないことをお勧めします。そもそも UTF-8 なら直接記述できるわけですし、文字コードやツールの問題で入力不可能/困難な文字があるなら、そのときは対応する文字参照で記述する、というのが次善の策じゃないでしょうか。
# 以下余談。今回初めて知りましたが、XHTML 側の UA 適合条件はこんな感じです。
ユーザエージェントがその宣言を処理していない (定義済み実体以外の) 実体参照に遭遇した場合 (これはユーザエージェントがまだ読んでいない外部サブセットの中に宣言がある場合に起こりうる)、その実体参照は、その実体参照を作り上げている (アンパサンドで始まりセミコロンで終わる) キャラクタとしてレンダリングされるべきである。
XHTML 1.0 でも M12N でもこうなんですが、これはちょっと非 XML 的で、あまりよい定義ではないですね。この書き方だと外部実体を読むプロセサを持つ UA でも未知の実体参照をレンダリングすべきということになりますし。プロセサのエラー処理にまで影響を及ぼしかねないのはどうなんでしょう。前述の四つの UA の中の人たちも、HTML ならいざ知らず、さすがに XHTML にこういう処理を持ち込もうとは考えもしなかったんじゃないかしらん。
HTML 4.01 の datetime 属性は時分秒まで書かなければいけないのかというおはなし。例によって仕様書を参照 (HTML 4.01 (日本語訳) 6.11 日付と時刻)。
[ISO8601] では、日付と時刻の表現に関して、多くのオプションとバリエーションが認められている。本仕様のこの版では、プロファイル [DATETIME] で記述される一つの形式のみを正当な日付/時刻文字列として採用した。(DTD では %Datetime; と表す。)
で、具体的にその一つの形式
をYYYY-MM-DDThh:mm:ssTZD
としているわけです。ということで、HTML 4.01 の datetime 属性では時分秒及びタイムゾーンまで常に記述する必要があります。
もっとも、続いて註記があるように日付時刻文字列を生成するアプリケーションが秒数を取得できない場合、秒の値を「00」として構わない。(分や時間についても、必要であれば「00」としてよい。)
ということなので、時刻を書くのが面倒なら便宜上 2005-12-22T00:00:00+09:00 のように記述すれば問題ないと思います。
# エディタのツールで時刻まで挿入できるようにしておくと便利です、というのも一応書いておこう……。
ちなみに Modularization of XHTML™ 1.0 SE 草案の C.2.2. XHTML Datatypes でも、データ型 Datatime は XML Schema の dateTime です。もっとも XML Schema の dateTime は'-'? yyyy '-' mm '-' dd 'T' hh ':' mm ':' ss ('.' s+)? (zzzzzz)?
なので、小数秒を書くことができたり、タイムゾーンが省略可能だったりしますが。
神崎さんに対応していただきました。多謝。
一応律儀に全ての質問に答えてみたのですが、ちょっと冗長なので先に要点だけまとめておきます。なお、多くは「そう言われたらこう返したくなる」式の揚げ足取りで、必ずしも僕自身の考えではありません ;)
text/html で提供するのに HTML 4.01 でなく XHTML 1.0 を用いる理由は?A. ひとえに、XHTML 1.0 が XML 互換だからです。文書作成やその後の編集作業、あるいは再利用等を XML アプリケーションを用いて行えるのは、HTML 4.01 にはない XHTML 1.0 の利点です。
text/html を用いる理由は?A. 旧来の HTML UA との互換性のためです。
A. XHTML 1.0 は旧来の HTML と互換性を持てるように設計されていますので、互換性ガイドラインに従って作成された XHTML 1.0 文書は HTML UA で解釈できて当然じゃないでしょうか。
それにしても、XHTML 1.1 よりも XHTML 1.0 が推奨されてるなんて話はいったいどこから来たんですかね。おそらく、W3C が言うところの Latest Version of HTML: http://www.w3.org/TR/html
が XHTML 1.0 であって XHTML 1.1 でない、という話がこう飛躍したのだと思いますが、これは (真名垣さん自身が繰り返し述べているように) 単に XHTML 1.1 が HTML と非互換であるという理由によるものでしょう。
XHTML 1.0 は HTML でありうるけれども、XHTML 1.1 は HTML ではない (あくまで XHTML である)、というのが W3C の基本的な姿勢らしいというのは、いろんなところで言われていることです。
一応、以下に全回答を載せておきます。
W3C Recommendation 31 May 2001
とある通り、XHTML 1.1 は 2001-05-31 に W3C の推奨規格になっています。
XHTML は HTML が XML 適合になれば便利だ、という動機で策定されたものだと思いますので、HTML との互換性にこだわる人がいるのは当然じゃないでしょうか。
text/html で XHTML 1.0 準拠の文書を公開して、何か良い点はあるの?旧来の HTML UA でも解釈可能であることは利点でしょうね。
後者は XML 適合ですが前者は違います。
XML か否かというのは極めて大きな違いだと思いますが。
XML プロセサでの解析が可能になりました。
text/html で送信される XHTML 文書なんて、どうせ XML パーサは処理しないんでしょ?リモートではそうでしょう。もっとも、ローカルでは XML プロセサを使って処理している人もいるでしょうし、特に制作者でそういう人は多いと思いますが。
前記の回答を参照してください。
XHTML 1.0 に比較して、HTML 4.01 に準拠する利点が感じられません。
前記の回答を参照してください。
そもそも、あえて HTML 4.01 を採用する必然性はどこにあるんでしょうか。
HTML にも XHTML (の構文) にも準拠していることのどこら辺が矛盾なんでしょうか。
前記の通り、リモートではそうでしょう。
そういうのは文字通りの XHTML の担当でしょうね。
そうやって公開しているリソースもありますね。
text/html で送信するなら XHTML に準拠する価値は皆無なのだから HTML 4.01 にでも準拠すれば良いし、XHTML に準拠するのなら application/xhtml+xml、application/xml、text/xml で送信するべきではないの?前記の通り、XHTML であればローカルで様々な利点を享受できますので、そのような利点を拒否して HTML 4.01 に準拠する必然性は感じません。
それはそうと、XHTML に準拠するなら送信すべき MIME は application/xhtml+xml でしょう。深くは突っ込みませんが。
ruby 要素を使いたいから XHTML 1.1 に準拠するけど、でも旧来の HTML との互換性を確保したいから text/html で送信する」と言う人がいるけど、ruby 要素自体が、旧来の HTML との互換性に欠けている云う事に何故気付かないの?ruby が旧来の HTML と非互換であるというのは、多くの人は知っていると思いますが。そのような人たちが互換性を確保したいと思っているのは、旧来の HTML とではなく旧来の UA とでしょう。
XHTML 1.0 Strict と XHTML 1.1 の文法はほとんど変わりませんから、軽い一括置換で XHTML 1.1 に移行することもできます。付け加えるなら、XHTML 1.0 Strict の場合は XSLT でそういう作業を行うこともできますが、HTML 4.01 Strict の場合はそういうわけにはいきません。
どのレベルでの話かはともかく、おおむねその通りだと思います。
もっとも、そもそも HTML UA というのは本質的には SGML パーサを内蔵しているもので、SGML パーサというのはある程度 XML プロセサと互換性を持つものです。したがって、非互換である部分を排除した形式で文書を作成すれば、HTML UA で XHTML 文書を処理することも当然可能でしょう。
text/html) で XHTML 文書を公開するくらいなら最初から HTML に準拠すれば良いし、XML 適合になった XHTML が良いなら、XHTML 文書として処理される様な形態 (application/xhtml+xml、application/xml、text/xml) で公開するのが筋じゃないの?前記の通り、前半はメリット・デメリットを考慮して制作者がおのおの決定すべきことでしょう。
後半はその通りだと思います (まあ、text/xml はどうかな)。