火曜日, 8月 25, 2009

【HTML5】 XMLシリアライゼーションの意味 このエントリーを含むはてなブックマーク


続・XMLなのかHTMLなのかそれが問題だ

 久しぶりにHTML5とXMLのネタ。私は1年前のこの記事において、HTML5で作成されたコンテンツが実質的にWelformedでなければ、Web世界の時計が大きく逆戻りすることになる、と主張した。ところが、あらためて最近のWeb事情、特にHTML5の記事を調査してみると、「むしろwelformedでない方がよい」といった感じで書かれているものが多く見つかるようになってきていて大変驚いた。今回は、HTML5のXML対応について、とりわけXHTML5とは何なのかについて述べてみたい。

“Misunderstanding Markup” 日本語訳

(訳:ぼくはXHTML構文が好きだ。なぜなら、そうやって学んだから。小文字で書くこと、引用符で括ること、brやimgにスラッシュを書くことに慣れているんだ。この書き方は、とても気持ちがいい。オバルチンを飲みながら、テレビでEvil Deadを見るような感じさ。でも、君はそうじゃないかもしれない。まるで叫んでるように見える大文字のタグや、スラッシュなしのimg, br要素、属性の省略表記が好きかもしれない。HTML 5だと、これらはぼくらの好きなように書けるんだ。“pave the cowpaths”っていう原則のおかげで、書く人のおまかせになるんだ。「お気に召すまま、お好きなように、好きなだけ、どうにでも」ってね。)



続・セマンティック・ウェブにXMLはいらない?

 セマンティック・ウェブは、ユニバーサルな情報空間を目指したバーナーズ=リーの考えを受けて、強靱で拡張性があり、適応性のある情報の基盤としてウェブを発展させるための目標の一つ。ウェブの目指すもの:W3Cの目標
 これまで、利用者が、ウェブ上のリソースを最大限に活用できるようなソフトウェア環境を構築するためには、XHTML化とRDFaなどのメタデータを使ったウェブの注釈が重要であるとされてきた。しかし、RDFaに代表される厳格なXMLベースのセマンティック・ウェブのアプローチはなかなか広まらず、最近では前述の記事のような「お気に召すまま」が流行っていることもあって、そのきざしすら感じられなくなってきているのが現状のようである。つまり、「貴族になって楽をしよう」で述べたボヘミアンの完全勝利。それは、MicroformatやHTML5のように、Webが実質的にXML以外の様々な表現や実装技術によって成り立っており、そもそもXMLで厳格にすべてを表現すること自体に無理があるのではないかという見方が主流となってきている背景がある。セマンティック・ウェブの目的だけ考えれば、データを取り出せて意味の疎通ができればよいのだから、必ずしもXMLでWelformedでなくてもよい。HTMLでは、どう処理するのかを規定されることに重きを置き、microformatsはXMLさえ前提にしていない。そう考えていくと、welformedかどうかは、結局のところ、XMLという1つの実装規約の範疇にすぎないという狭い議論に落とし込まれていく。関連記事

XHTML5って何?

 一方で、HTMLをデータとして処理したいという要求が大きいのも事実である。Reflex iTextは、テンプレートとしてHTMLを用いるが、これがXMLでなかったらパース処理に大変な苦労を強いられることになる。今後標準となると思われるHTML5についても同様で、テンプレートをHTML5にバージョンアップする際には、できることならXHTML表現を使いたいところである。
 そこで、XHTML5の明確な定義を調べることにしたのだが、これがとても曖昧で気持ち悪いのだ。その原因は、XHTML5のスキーマがないということ、それから、XHTML1.xと同じ名前空間を使っているということの2つである。こうなってくると、モジュール化して他のモジュールを自由に取り込めないのではないかとか、極端な話、XHTML1.xのボキャブラリ以外使えないのではないかとか不安にもなってくる。
 ちなみに、私と同じような疑問をもっている方もいるので抜粋して紹介したい。去年の記事なんでちょっと古いが、開発者の率直な意見をまとめてみた より。


what-wgが「HTML5はモジュールに分割せずモノリシックな規格を作る」って決めてしまったからなぁ…

<video src="video.ogv" xmlns:cc=" http://creativecommons.org/ns#"
rel="cc:license" resource=" http://creativecommons.org/licenses/by/2.1/jp/"/>
XHTML 5でこういうことができたらいいのになあ。video要素とRDFaを両方使うとオレオレXHTMLになってしまう。せっかくスキーマを取り払ったんだから、モジュール化して他のモジュールも自由に取り込めるような仕組みがいいと思う。

validatorにかけると
Error: Attribute rel not allowed on XHTML element video at this point.
などのエラーを返される。@relや@resourceをvideo要素に書くとHTML 5準拠にはならないんだよね。ブラウザでの表示やRDFの抽出はできるだろうから実際あまり問題はなさそうだけど、そのXHTML文書が準拠する仕様はどこにも存在しないってのは、ブラウザの独自拡張時代を思い出させてあまり好きではない。HTML 6あたりで「やっぱりCSSみたくモジュール化しよう」ってことになり、Multimedia ModuleとかMetainformation Attribute Moduleとかが定義されて、制作者はいろいろなモジュールの中から好きなものを選んで組み合わせて使えるようになったりしないかなあ。


HTML5がモジュール化しない理由とXML名前空間の試み

HTML5はモジュール化しないの?で述べられているように、HTML5はモジュール化しない。それは、HTML5から見れば、XMLは単なるシリアライズ表現の一つと位置づけているように、あくまでHTMLがもつ機能だけに焦点をあてた結果であるといえる。XHTML5はXMLに見えてXMLではない、というのは言いすぎかもしれないが、少なくとも、名前空間とスキーマを充実させてモジュール化し、必要に応じて組み合わせて利用するといった、ユニバーサルな情報空間構想の元に作られたものではないことは明らかである。XMLの生みの親である村田さんもこの構想について以下のように述べられている。しかし、2005年の時点ではまだ名前空間の試みがうまくいっていないことを吐露されてもいる。

お仕着せスキーマと誂えスキーマ

今後の方向は、お仕着せスキーマにちょっと手直しをして、従来は誂えスキーマでしか得られなかったような利点を
得ることだろう。名前空間も、もともとそのための試みで
あった(残念ながらうまく行っていない)。
XHTMLがモジュール化されたもの、
RELAX NGがスキーマのモジュール化を重視しているのも、
NVDLが名前空間による分割検証を提供しているのも、すべて
この方向を目指す試みである。あと10年もすれば、
お仕着せスキーマにちょっと手直しをするという方法が
有効かどうか結論が出るのだろう。


XMLシリアライゼーションの意味

XHTML5の疑問を解決すべく、メーリングリストに聞いてみることにした。
回答の要点は以下のとおり。

1) XHTML5の名前空間はXHTML1.1と同じものを使うがXHTML1.xとは区別される。ただし、両者を判別する方法は今のところない
2) HTML syntaxとXHTML syntaxは、HTML5 DOMのrepresentationであり、同じ要素をもつ

詳細は以下のとおり。
議論がずれることを恐れたので深く突っ込まなかったが、名前空間の意味と運用について、これほど解釈が違う人がいるとは思わなかった。


XHTML 2が打ち切りになったのは皆さんご存知だと思うのですが、以下の記事のなかで、XHTMLをHTMLのXMLシリアライゼーションとみなす、といった説明があります。

「W3CはXHTMLをHTMLのXMLシリアライゼーション(XML形式への変換)と見なしている。HTML
5仕様にXMLシリアライゼーションを含め,引き続きHTML WGで検討していく。」

http://itpro.nikkeibp.co.jp/article/NEWS/20090703/333143/

名前空間がXHTML1.xのままだとHTML5のタグを使えないものがあるので、完全なシリアライゼーションはできないと私は思います。

単純に、HTML5のままで、welformedなものをXHTML5と呼ぶと解釈したとしても、welformedかどうかを示すヘッダーなり何かがないと不都合です。(つまりXML宣言なんですけど)
その場合、名前空間はXHTML1.x以外の何かになると思われるのですが、最新のDraftにも新しい名前空間は見当たりません。

この話は以下にも書いているように、去年からずっと気になっているところなんですが、いまだにモヤモヤしています。

http://www.virtual-tech.net/blog/2008/08/html5-htmlxml.html
http://www.virtual-tech.net/blog/2008/09/html5-xml.html

また、弊社のReflex iTextのテンプレートの文法をHTML5にあわせるかどうか考え中なんですが、このテンプレートはXMLが前提なんでどうしたもんかと。
つまり、HTML5のタグを使いたいのだけど、welformedなHTML5であることを知ることができるのか、あるいは、HTMLとしてパースしないといけないのか、という点がはっきりしないのです。

このあたりで何かわかる方がいれば、ご意見を伺いたいのですが。

よろしくお願いします。


回答1


Y氏)
XML宣言が必要であることと、名前空間がこれまでのXHTMLと別になることの関連、またそれが「完全なシリアライゼーションにならない」にどう繋がるのかがよく分からないのですが、そこは置いといて。

HTML5で言うところの「XHTML」は、「well-formedなHTML5文書を、application/xhtml+xml または
application/xml で送出したもの」になります。
これが text/html で送出されている場合、それはXHTML5ではなく、HTML5になります。
「どう書いたか」ではなく「どう扱うのか」によって、HTMLとXHTMLという区別がつけられるわけです。

> また、弊社のReflex iTextのテンプレートの文法をHTML5にあわせるかどうか考え中なんですが、このテンプレートはXMLが前提なんでどうしたもんかと。
> つまり、HTML5のタグを使いたいのだけど、welformedなHTML5であることを知ることができるのか、あるいは、HTMLとしてパースしないといけ ないのか、という点がはっきりしないのです。

XMLのどの機能を利用しているかによって答えが変わるのですが、たとえば「
」のように空要素のXML的表現は、HTML構文でも利用できるように定義されています。

=====
私)

早速のご回答、ありがとうございます。

>具体的に何が利用できないか、教えていただけますか?
などは、XHTML1.0や1.1では使えないと思います。
使うためには別の名前空間が必要ですよね。

> HTML5で言うところの「XHTML」は、「well-formedなHTML5文書を、application/xhtml+xml または
> application/xml で送出したもの」になります。
> これが text/html で送出されている場合、それはXHTML5ではなく、HTML5になります。
> 「どう書いたか」ではなく「どう扱うのか」によって、HTMLとXHTMLという区別がつけられるわけです。
なるほど。たとえ中身がXMLであっても、「どう扱うのか」ということを、content-typeで区別しましょう、という話ですね。わかります。
では、application/xml
で送り出したXHTML5とは具体的には何になるのでしょうか。welformedなHTML5なのか、XHTML1.1なのか、あるいは、両方が可能なのか。それが知りたいのです。

それにこだわっているのは、要は、XMLパーサしかもっていない当方の実装上の都合だけなんですが、HTML5互換のXMLが扱えるか、もし、application/xmlで送り出すことで、welformedなHTML5を縛れるとすれば、簡単に目的を果たせて嬉しいんです。
=======
S氏)

ちょうど仕様を読み返しているところでしたので、ご質問を受けて、XHTMLに関して言及しているところも軽く読み直してみました。
正しく理解できているかどうかはわかりませんが・・・(^^;
もし間違いがあったら、皆さんご指摘お願いします。

で、ご質問の意図は以下のようなものかと捉えたのですが、いかがでしょうか?

1. ファイル形式がXHTML5か、XHTML1.xかを見分ける手段がないように思えるが、その通りか?
2. 名前空間がXHTML1.xと同じく「http://www.w3.org/1999/xhtml」のままでは、HTML5のボキャブラリを扱えないのではないか?

こういった意図のご質問だと仮定して、僕の意見を述べさせて頂きますと、

1に関してはその通りだと思います。名前空間も同じですし、配信時のContent-Typeも特殊なものではありませんし。

2に関しては、ボキャブラリを扱えるかどうかは実行系に依存するのではないでしょうか。XHTML1.0しか扱えないブラウザは新要素を取り扱えないでしょうし、今後出てくる新しいブラウザはそれらを扱えるようになる、と。

なので、僕はXHTML5というのは、竹嵜さんのおっしゃった

> 単純に、HTML5のままで、welformedなものをXHTML5と呼ぶ

と言うことで良いのかな、と思っています。
(もちろん、文字エンコーディングの指定方法とか、細かい部分は違うにせよ)

ちなみに、仕様(http://www.w3.org/TR/html5/introduction.html#relationship-to-xhtml-1.x)では

"This specification is intended to replace XHTML 1.0 as the normative
definition of the XML serialization of the HTML vocabulary"

意訳:この仕様(HTML5)は、HTMLボキャブラリをXMLシリアライゼーションするための標準定義である、XHTML 1.0の置き換えとして意図されている

と述べられてます。

その上で、
> また、弊社のReflex iTextのテンプレートの文法をHTML5にあわせるかどうか考え中なんですが、このテンプレートはXMLが前提なんでどうしたもんかと。

ちょっと、この部分の問題意識がとらえきれていないので、役に立つ意見になっているかどうかはわかりませんが・・・
何かの参考になれば幸いです。

=====
私)
質問の意図をまとめていただきありがとうございます。まったくそのとおりです。
ご回答内容で、だいぶ見えてきたのですが、新たな疑問もうかんでいます。将来的に、XHTML5の名前空間って何になるのだろう?、と。

>> 単純に、HTML5のままで、welformedなものをXHTML5と呼ぶ
> と言うことで良いのかな、と思っています。

> 2. 名前空間がXHTML1.xと同じく「http://www.w3.org/1999/xhtml」のままでは、HTML5のボキャブラリを扱えないのではないか?
>ボキャブラリを扱えるかどうかは実行系に依存するのではないでしょうか。

ということは、XHTML5は実質的に当面はXHTML1.xと同じ名前空間を使うということになりますね。XMLで新たなボキャブラリを追加する際に、名前空間を変えるべきかどうかは設計者によるといわれていますが、HTML5の要素が加わったXHTMLと、これまでのものとを区別できないのは、やはり不便な感があります。ああ、モヤモヤ。

http://www.ibm.com/developerworks/jp/xml/library/x-namcar/

「最終的には、XHTML 1.0のすべての範囲に1つの名前空間を使用する新たな仕様を発行することで、XHTMLワーキング・グループは軌道修正を行ないました。この教訓から多くを学ぶべきです。命名された物の間に本当に違いがある場合にのみ、XML名前空間を区別すべきでしょう。

残念ながら、物事に白黒をはっきりと付けられることは滅多にありません。新しいバージョンのボキャブラリが、新たな要素を追加するのはよくあることです。前のバージョンから持ち越された要素の意味は変更されていないかも知れないので、名前空間の変更は不適切であると思うかも知れません。しかし仮に、元の同じ名前空間を使用するとしたならば、新たなボキャブラリに追加された要素を元の名前空間内に設置するのも不適切であると思うでしょう。また、新たな要素のみに違う名前空間を使用するのは、とても賢明な選択とは言えません。結局、ボキャブラリで名前空間を改変するかどうかを判断する(自分自身の)判断力が必要です。」


回答2
N氏)

> 名前空間がXHTML1.xのままだとHTML5のタグを使えないものがあるので、完全なシリアライゼーションはできないと私は思います。
> また、弊社のReflex iTextのテンプレートの文法をHTML5にあわせるかどうか

誤解です。

おそらく、XMLの「名前空間」というのは要素のコレクションとその意味を規定するものである、とお考えなのではないでしょうか。

「XML名前空間の簡単な説明」で説明されているのですが、
http://www.kanzaki.com/docs/sw/names.html
実際には、「要素の分類・同定」以上の機能はありません。

そして、XHTML 1.xの http://www.w3.org/1999/xhtml という名前空間は、
「XHTML 1.xが主に使ってきた名前空間」であるだけで、
「XHTML 1.x だけの名前空間」ではありません。
実際、そのURLを開いてみると、いくつか規格がリストアップされています。

で、この中にHTML5が加わることが何を意味するかというと、例えば、
「XHTML1.0のp要素と、HTML5のp要素が、XMLとして同じ意味を持つ」
ということになります。
また、ご指摘のXHTML1.0になくて、HTML5にはあるsection要素等ですと、
名前空間を考えるまでもなく、XHTML1.0にはないので、ここでは問題ありません。

XHTML 2.0の場合は、XHTML 1.0から要素の意味を変更しようとしました。
その場合は同じ名前空間にあると区別ができないので、別の空間を用意することになります。
つまり、XHTML 1.0のp要素と、XHTML 2.0のp要素は別物、ということになります。

XMLだとちょっと考えづらくなってしまいますが、
CのAPIを想像するとわかりやすいのではないでしょうか。

XHTML 1.0にxhtml_foo(int a)という関数がありました。
XHTML 5.0では互換性を保つように作ったので名前はそのままにしました。
XHTML 2.0では引数aをlong型に変えました。
これをそのまま既存のライブラリと強引にリンクさせようとすると落っこちます。
なので、xhtml2_foo(long a)という名前に変えるわけです。

そんなわけなので、
> HTML5のボキャブラリをXHTML1.xに追加するという明確な定義ってありますかね?
「追加」する必要はありません、そのような機能は名前空間は持っていないんですよ。

> 考え中なんですが、このテンプレートはXMLが前提なんでどうしたもんかと。
> つまり、HTML5のタグを使いたいのだけど、welformedなHTML5であることを知ることができるのか、
> あるいは、HTMLとしてパースしないといけないのか、という点がはっきりしないのです。

これはConformance Requestにあるんですが、
http://dev.w3.org/html5/spec/Overview.html#conformance-requirements
XHTML syntaxのみという選択肢があります。
なので「XHTML syntaxしかサポートしない」と言ってしまえばそれでおしまいです。
HTML syntaxの文書はtext/htmlで送られることになっていますから、
これは非サポート、ということですね。
text/html以外は全てXHTML syntaxです。

さて、懸案のXHTML 1.xとの区別ですが、区別する必要はありません。
全てHTML5として処理してください、名前空間が同じというのはそういうことです。
もしもこれで問題が生じるならばそれはHTML5のバグですから、報告なさるのがよろしいかと思います。
=========
私)
ご丁寧なご指摘ありがとうございます。

>> 名前空間がXHTML1.xのままだとHTML5のタグを使えないものがあるので、完全なシリアライゼーションはできないと私は思います。

これはたしかに誤解ですね。XHTML1.x上位互換のXHTML5が定義されていて、名前空間がhttp://www.w3.org/1999/xhtml
であるという考え方をすれば、シリアライゼーションは可能だと思います。ただ、AtomにしてもRSSにしても、大きなバージョン変化があった際には、名前空間も変わるのが一般的だと思うので、下位互換性という理由があるにせよ、名前空間とはそういうものですというのは言いすぎのような気もしています。機能的な議論はあるのですが、実際の運用のところは、先ほどのメールの添付(http://www.ibm.com/developerworks/jp/xml/library/x-namcar/)のように、ケースに応じていろいろなんだと思います。
また、先ほどのメールにも書きましたが、そもそもXHTML5の定義って何なの?という根本的なところが私のなかで曖昧のまま残っていて、ドキュメントのなかにXHTML1.x以上の定義が見つけられなかったので、それ以上も以下もないという発想が元になったのも事実です。
新しいボキャブラリを含むXHTML5を定義したうえで同じ名前空間を使うのか、単なるXHTML1.1なのか、そこが知りたいポイントなのですが、まだしっくりきていません。

>そんなわけなので、
>> HTML5のボキャブラリをXHTML1.xに追加するという明確な定義ってありますかね?
>「追加」する必要はありません、そのような機能は名前空間は持っていないんですよ。

これは、名前空間の機能というより、XHTML5の定義というふうに解釈していただきたいですね。繰り返し恐縮ですが、XHTML5は、HTML5のボキャブラリをXHTML1.xに追加するような定義になっていますかね。(名前空間の話はもう忘れてください。純粋な定義の確認です。)
もしそうだとしたら、ドキュメントの具体的な箇所を教えていただけないでしょうか。白石さんからいただいた参照を見て、私もそうなんだろうなとは思っていますが、念のため。

>ちなみに、仕様(http://www.w3.org/TR/html5/introduction.html#relationship-to-xhtml-1.x)では

>"This specification is intended to replace XHTML 1.0 as the normative
>definition of the XML serialization of the HTML vocabulary"

>意訳:この仕様(HTML5)は、HTMLボキャブラリをXMLシリアライゼーションするための標準定義で>ある、XHTML 1.0の置き換えとして意図されている

>と述べられてます。
=======
> >> 名前空間がXHTML1.xのままだとHTML5のタグを使えないものがあるので、完全なシリアライゼーションはできないと私は思います。
>
> これはたしかに誤解ですね。XHTML1.x上位互換のXHTML5が定義されていて、名前空間がhttp://www.w3.org/1999/xhtml
> であるという考え方をすれば、シリアライゼーションは可能だと思います。

> ただ、AtomにしてもRSSにしても、大きなバージョン変化があった際には、

これらはHTMLとは事情が違うように思います。
RSSは0.9, 0.91, 1.0, 2.0, 0.92 全て互換性がありませんでした。
なので、名前空間が異なるのは当然でしょう。

Atomも上記のRSS達とは違うので名前空間が異なるのは必然です。
また、Atom 0.3 から 1.0 へもdraftから正式版への変更なので、変えるのは当然でしょう。
が、Atomの改定版が出た時にはHTML5と同じ悩みを持つことになるでしょう。
Atomの事情はよく知らないので想像になりますが、Atomは関連規格が多く、
それらの多くがAtomのnamespaceを指定している以上、変えられないのではないかとは想像しています。

> 下位互換性という理由があるにせよ、名前空間とはそういうものですというのは言いすぎのような気もしています。

下位互換性は名前空間を同じにするかどうか考える際の材料の一つになりますが、
実際にXMLの名前空間を見るときには考慮されません。

XMLの名前空間が持っているのは、
* 名前空間が同じ→同じ名前の要素は同じもの
* 名前空間が違う→全ての要素は全くの別物
ということだけだということです。
そして、ここで同じものならばXMLのレイヤーにおいては区別する手段を持たないということです。
(もちろんversion属性を追加してそこでもっと上のレイヤーで区別することは可能ですが)

これをふまえたうえで、名前空間を同じにするか別にするかは仕様策定者に委ねられているわけです。

> 機能的な議論はあるのですが、実際の運用のところは、先ほどのメールの添付
> (http://www.ibm.com/developerworks/jp/xml/library/x-namcar/)
> のように、ケースに応じていろいろなんだと思います。

うーん、ちょっとこの記事、もっといえば特に
> XHTMLワーキング・グループは、それぞれのXHTML DTDに対応する3つの別々の名前空間を
> 使用することを決定しました
のXHTML WGの人々はちょっと神経質すぎるように感じます。

名前空間はXMLのレイヤーにおいて同じ名前の要素を別物扱いさせる、ただそれだけの効果しかありません。
もっと具体的にいえば、XMLパーサが同じ名前の要素なのに別物扱いしてしまう、という意味になります。
XMLの上に構築された多くの仕様では、ここで別物扱いされると上のレイヤーで同一視することはなかなか困難な作業になります。

実際にその仕様が勧告され、その仕様に沿った文書が、過去の当該仕様に沿った文書や他の関連仕様とそれに沿った文書、
その仕様に沿ったアプリケーションや過去の仕様、関連仕様に沿ったアプリケーション、などなど、と協調して動こうという時にどう振舞ってほしいかを考えれば、おのずと答えは見えてくるのではないでしょうか。

Atomの方が例としてシンプルなのでこちらで話しますと、例えばAtom 2.0で名前区間を変えたとすると、既存のアプリケーションや関連仕様は全てバージョンアップしない限りAtom 2.0の文書を無視するわけです。
この壁を乗り越えるにはよっぽど派手な花火がないと難しいように思えます。

> また、先ほどのメールにも書きましたが、そもそもXHTML5の定義って何なの?という根本的なところが私のなかで曖昧のまま残っていて、

HTML5は今までのようにタグの寄り集まった文法ではなく、DOM (Document Object Model) で定義されています。
つまり、ある構造をもった文書を、ブラウザやその他のアプリケーションがどう表示・処理するかと、
そのの構造の文書どうシリアライズ―ありていにいえば文字列にダンプするかを定めているわけです。
で、ダンプの仕方はHTML syntaxとXHTML syntaxがある。
この点において、「HTML5」とは言いつつも、今までのSGMLの子孫であったHTMLやXML一族のXHTMLとは一線を画しています。

> ドキュメントのなかにXHTML1.x以上の定義が見つけられなかったので、
> それ以上も以下もないという発想が元になったのも事実です。

仕様上は以上でも以下でもありませんね。
同じ名前空間の中にいる兄弟と言ったところでしょうか。
で、たまたま(実際はもちろん意図的なんですが) (X)HTML5 は XHTML 1.x の要素集合をおおむね包含しているだけです。

> 新しいボキャブラリを含むXHTML5を定義したうえで同じ名前空間を使うのか、

「新しいボキャブラリ」をここでどのような意味で使っているのかが問題ではありますが、
推測するに、この認識が正解であるように思います。
で、
Q: 別物のはずなのになぜ同じ空間を用いるの?
A: 互換性のため
Q: 互換性のためなら同じ空間を使ってもいいの?
A: よい、だって別にしたからXHTML 2 は死んじゃったんだもの
Q: 同じ空間だと何か問題が起きるんじゃない?
A: 何も問題が起きないように頑張る
と、こうなるわけです。

どうも HTML 5 WG はそれなりに迷った末に同じ空間を用いることを決定したようですが、
現状の膨大なHTML/XHTMLの資産や、HTML5以前に行われた数々の試みがどうなったかを考えると、同じ空間をもちいるか、黙殺されるか、の二択でしかなかったと思います。

> 単なるXHTML1.1なのか、そこが知りたいポイントなのですが、まだしっくりきていません。

XHTML 1.1 は DOCTYPE 等一定の要件を定義していますが、XHTML5 はそれから外れています。
よって、XHTML5 は XHTML 1.1 ではありません。

> >そんなわけなので、
> >> HTML5のボキャブラリをXHTML1.xに追加するという明確な定義ってありますかね?
> >「追加」する必要はありません、そのような機能は名前空間は持っていないんですよ。
>
> これは、名前空間の機能というより、XHTML5の定義というふうに解釈していただきたいですね。繰り返し恐縮ですが、XHTML5は、HTML5のボキャブラリをXHTML1.xに追加するような定義になっていますかね。(名前空間の話はもう忘れてください。純粋な定義の確認です。)

XHTML 1.x と XHTML 5 は別の規格ですね。
XHTML 5 に沿ったアプリケーションが XHTML 1.1 の文書を解釈できるのは「たまたま」です。
もちろん、その「たまたま」を実現するために、名前空間を同じにするだけでなく、
各種の注釈で既存UAの動作を解説したりと、HTML 5 の策定者達が努力していることは言うまでもありません。
(もちろん、XML的には同じ名前空間の同じ要素を扱っているのだから互換性が期待されるわけですが)

=======
1.7 HTML vs XHTML
http://dev.w3.org/html5/spec/Overview.html#html-vs-xhtml
が直接の参照先かと思います.正確にはDOMもrepresentationの一つです.

また,根底部分の知識として,Architecture of the World Wide Webも一読の価値があるかと思います.
http://www.w3.org/TR/webarch/

======
> 1.7 HTML vs XHTML
> http://dev.w3.org/html5/spec/Overview.html#html-vs-xhtml
> が直接の参照先かと思います.

HTML syntax と XHTML syntax が the DOM に対して用意されている、というのはそこですね。

2.2.1 Dependencies
「The DOM is not just an API; the conformance criteria of HTML
implementations are defined, in this specification, in terms of
operations on the DOM.」
http://www.whatwg.org/specs/web-apps/current-work/#dependencies
で、「DOMで定義されている」というのはこの辺の話です。


0 件のコメント:

 
© 2006-2015 Virtual Technology
当サイトではGoogle Analyticsを使ってウェブサイトのトラフィック情報を収集しています。詳しくは、プライバシーポリシーを参照してください。