[8] 本項は RDFa を解釈する側の処理方法について、仕様書をできるだけ好意的に解釈しようと試みるものです。 RDFa の仕様書は 00年代 W3C レベルの品質でしか無いので、 相互運用可能なレベルで実装できる程度に理解するのは難しいです。
[2] 適合 RDFa 処理器は、 RDFa 仕様書に従って RDF 三項組を取り出す処理器です。
[6] 適合RDFa利用者エージェントとの関係は明示されていません。
[240] HTML+RDFa 仕様書は、 XHTML+RDFa 1.0 が text/html
で提供されることがあるとして、 text/html
であるにも関わらず xmlns
属性を処理する方法と適合性をなぜか規定しています。
[17] RDFa が含まれる文書を処理してグラフを取り出すものを RDFa 処理器といいます。
[15] RDFa の処理は文書木に対する探索として定義されています。文書オブジェクトから順に子要素を文書順にたどって処理していきます。 >>16
[11] 適合RDFa処理器は処理の結果として出力グラグと処理器グラグを応用に提供しなければなりません。 >>5
[12] 出力グラフは、 RDFa 1.1 の処理モデルにより得られたすべての三項組からなるRDFグラグです。 >>5
[13] 処理器グラフは、RDFa処理器が報告したエラー、警告、情報を集めたものです。 >>5
[129] RDFa処理器が Webアプリケーションとして実装されている場合には rdfagraph
という query parameter でどのグラフを得たいかを指定することになっています >>16。
[167] 適合利用者エージェントには次の2要件が課されています。
[171] あいかわらず「必須とされたすべての機能」などという曖昧な要件を課しています。
[175] RDFa処理器との関係はやはり不明確です。 RDFa Core 1.1 の実装が RDFa処理器、 XHTML+RDFa 1.1 の実装が利用者エージェントと呼ばれているようですが・・・。
[177] RDFa処理器には次の要件が課されています >>176。
[180] 利用者エージェントには次の要件が課されています >>176。
[184] 処理器と利用者エージェントで別になっているのは、ごくわずかなレンダリング機能しか備えないものなど、 RDFa処理器として妥当であっても HTML 5.0 処理器として妥当でないものがあり得るからとされています >>176。
[185] 実際には HTML5 はむしろそのようなツールの類であっても適合性を主張できるようにむしろ慎重に定義されており、 HTML5 に対する無理解に由来する誤った規定のように思えます。仮に >>184 の主張が正しいとしたところで、 RDFa に対する適合性の一部として HTML5 への適合性を要求する必要性は見当たらず、 なぜ敢えて2つの適合水準を設けているのか不可解です。
[186] >>178 と >>182 は同じですが、 >>179 と >>183 は異なっています。この違いが意図的なものなのかどうかはわかりませんが、 隣同士の章でそれほど離れておらず、違いの説明まで書かれている要件に誤って混入した規定とも思えません。 >>182 の通り HTML+RDFa と RDFa 本体の機能に一部矛盾があると解釈すると、 >>178 と >>179 が同時に満たせるのか (適合するRDFa処理器が存在できるのか) が気になります。
[18] RDFa 1.1 の処理は評価文脈を使って行われます。 開始時には初期文脈が使われ、子要素の評価の際はそれぞれのために作られた評価文脈が使われます。 >>16
[154] RDFa Core 1.1 本体仕様には明記されていませんが、初期文脈は複数あって順番に適用するということがあり得るようです。 (>>145, >>191)
[131] このホスト言語による初期文脈の定義については、 構文解析器はそれをハードコードしても構いませんし、外部の文書として読み込む形にしても構いません。 その外部の文書は、 RDFaホスト言語として承認されたものを使い、 RDFa 仕様書で規定された語彙により記述されなければならない >>130 とされています。 いずれにせよよく知られた安定した初期文脈の定義は埋め込んでいるべきです >>130。
[23] RDFa の属性はホスト言語によっては省くことができますが、 その場合当該属性に関する処理は行いません >>16。
[27] CURIE を含む属性の処理については、 CURIE の項をご覧ください。 CURIE 等が非妥当である場合その値が無視されると規定されており、その結果属性が空とみなされることもあります。 空と属性が存在しないのは別の状態のようです。
[25] 現在要素に対する RDFa の処理は次のように行われます >>16。
[125] XML+RDFa では xml:base
も使われることになっていますが (>>137)、
この処理ではなぜか使われていません。
[149] 鬼畜なことに >>148 で XHTML+RDFa において、 >>197 で HTML+RDFa において一部の処理が猿パッチされています。
[155] この処理では datatype
属性の値によって分岐するところがありますが、
XHTML+RDFa 1.1 の Metainformation Attributes Module では datatype
の既定値が xs:string
とされています。これらの規定の整合性がない気がしますがどうなっているのかは不明です。
[10] RDFa処理器は XML+RDFa文書を次の初期文脈により処理します >>133。
application/xml
などと application/xhtml+xml
などを区別するのは一般的な Webブラウザーの処理モデルと異なっています。また RDFa+XHTML
などの処理とこの XML+RDFa の処理が衝突するおそれもあるはずですが、何も説明がありません。[151] RDFa処理器は html
要素の version
属性が使われている時にその値を調べなければなりません。 XHTML+RDFa
の版として定義されているものであれば、その版の処理規則を用いなければなりません。
そうでないか、 version
属性がない場合は、 XHTML+RDFa
の最新版を使わなければなりません。 >>143
[142] XHTML+RDFa 1.1 文書は次のように処理されます >>143。
[224] HTML文書に要素の入れ子関係がおかしいものがあれば、 RDFa の処理の前に修正するべきです >>188。
[189] HTML+RDFa 1.1 に適合する文書は RDFa Core 1.1 と次の例外に従い処理します >>188。
[201] >>192 でなぜか XHTML の時だけ xml:base
が適用されるとなっていますが、
HTML5 には (不適合ながら) HTML でも xml:base
は有効とされているのに、
なぜそれを参照せずに独自に定義するのか謎です。
[202] >>193 も HTML5 の定義を参照せずになぜ同じようなことを規定しているのか謎です。
しかもなぜか処理の規定の中で lang
と xml:lang
の値が同じでなければならないと言及されていますが、本来は文書の適合性として規定されるべきものです。
編集が雑すぎます。また HTML5 の同様の規定ではASCII大文字小文字不区別で同じとされていますが、
こちらにはそのような記述がなく、意図的なのかどうかはわかりませんが RDFa の方がより制限が厳しくなっています。
[226] また HTML+RDFa 1.1 仕様書の別項には言語について HTML5 の仕様書に従わなければならないとの記述があり、
>>193 と矛盾しています。更に著者に対しては、 MIME型が事前にわからない時は
lang
と xml:lang
の両方を同じ値にするべきとしています。 >>188
text/html
しか使われていない)、事前にわからないならその他にも考えなければならないことが沢山ありすぎるので、
敢えて言語だけ言及する必要性があるのかどうか。[228] >>226 の矛盾というのは、HTML5 の言語は Content-Language
も考慮する点です。
これについて注記では、 JavaScript ベースの (クライアント側の) RDFa の実装がこれにアクセスできないため不適合な実装となり、
そのため著者ができるだけ lang
属性を使うのがよい
>>188 とされています。
[203] >>195 の DOCTYPE
の規定は実際仕様書に DOCTYPE
の例示がありますが、それをどう解釈するべきかは不明です。一字一句そのままだと解釈するよりはスペースの違いなどは無視するべきと思いますが、
システム識別子が相対URLの場合どう比較するべきなのかなどまったく言及がなく、曖昧すぎます。
[205] >>196 では DOCTYPE
も version
もなければ HTML+RDFa 1.1
としており、 >>199 では version
がなければ RDFa 1.1 の最新版としており、
これが同じものなのかどうか不明です。そもそも RDFa 1.1 の最新版とは何を指すのか不明です。
[206] DOCTYPE
と version
が矛盾している時にどう処理するべきかは不明です。
[219] >>209 は HTML+RDFa でのみ規定する必要性が感じられませんが、なぜ RDFa Core 1.1 でなく HTML+RDFa で追加されているのか謎です。
[220] >>210 は HTML の本来の rel
属性と衝突することを防ぐためでしょうが、
HTML で問題になるなら XHTML+RDFa でも問題だったはずで、なぜ XHTML+RDFa だけ追加されているのか謎です。
[221] >>212 や >>217 は time
要素を自然に利用する方法として有用でしょうが、
なぜ time
要素でだけ特別な仕組みが追加され、 meter
要素や input
要素や img
要素で HTML
の要素の意味に応じた特別な仕組みが追加されていないのか謎です。
[222] >>215 は RDF 側が XML Schema のデータ型を使っていることからこのような規定になっているのでしょうが、
time
要素の内容や datetime
属性の値の定義は厳密にはこれと一致しません。
HTML5 の処理モデルに従って解釈した値を XML Schema に適合する形で直列化したものをリテラル値として使うのではなく、
このようなアドホックな HTML の解釈を求めるのは不適切でしょう。また「リテラル値」や
「テキスト値」や「テキストに直列化」といった用語の意味は推測はできますが、正確さに欠けています。
[223] >>212、>>217、>>218 は W3C Process 上の理由により規定でなく参考とされています。 (HTML+RDFa 1.1 の項を参照。) ですからこの部分の規定には従わなくても適合することになりますが、本当にそれでいいのでしょうか。
[244] IRI写像の処理 (>>30) では、本来の名前空間属性を処理した後、null名前空間で局所名が
xmlns:
ではじまるものを名前空間属性であったものとみなして処理します >>242。
[229] HTML+RDFa 1.1 でデータ型が XMLLiteral
のとき、次のようにして XML
に変換しなければなりません >>188。
[237] >>230 は HTML5 側で実装依存の項目がいくつかありますが、どのオプションを使うかは特に言及されていません。
[235] >>234 で大文字を小文字に変換するようですが、どの変換方法かは明記されていません。
[236] >>234 では元々 xmlns
で宣言されていたものだけでなく、
prefix
で宣言されていたものも xmlns
として出力するようです。本当に大丈夫なのでしょうかね。
[238] 入力が構文解析直後の文書でなくスクリプトで変更された文書なら、 大文字の名前空間接頭辞に依存した内容も含まれているかもしれませんが・・・。
[239] HTML要素では本来 xmlns
属性を指定しても無視されますが、 RDFa
では HTML+RDFa の規定によりIRI写像に反映されます。それが >>234 により xmlns
として出てくることになります。
[241] この他に HTML における xmlns
の解釈に関するびっくりする規定があります。 xmlns
の項を参照してください。
[245] RDFa と同じく XHTML2 から独立した XHTMLモジュールの1つである Role Attribute 1.0 仕様書は、
role
属性に関する RDFa処理器が行う処理を定義しています。
[247] RDFa処理器は role
属性を組み込んだホスト言語の文書を処理する場合、
role
属性から三項組を生成して構いません。その場合次のようにしなければなりません。
>>246
[158] RDFa Core 1.1 は初期文脈として http://www.w3.org/2011/rdfa-context/rdfa-1.1
を使っており、 XHTML+RDFa 1.1 は追加の初期文脈として
http://www.w3.org/2011/rdfa-context/xhtml-rdfa-1.1
を使っています。
これら URL は RDFa Core 1.1 と XHTML+RDFa 1.1 でそれぞれ URL のみ規定されていて、
その内容は随時更新されているようです。
[159] >>156 には RDF 界隈でよく使われる接頭辞と名前空間URLの対応関係が定義されています。
[160] >>156 と >>157 では語が定義されています。元々 rel
属性として使われていたものが選ばれているようです。
[161] 現時点で >>156 には describedby
、 license
、
role
が、 >>157 には HTML4 のリンク型と meta
,
license
, icon
, p3pv1
が含まれています。
license
は両方に含まれています。 >>156 は XHTML Vocabulary
と IANA登録簿の両方を参照しており、 >>157 は XHTML Vocabulary だけを参照しています。
両者が同じものなのかどうか、重複していて問題ないのかどうかは不明です。[162] どちらも W3C の文書で定義されているものという一応の基準はあるようですが、 どのような手続きで追加されるのか、どういう基準で振り分けられているのかなどは不明です。 ほとんどの値は出典が XHTML Vocabulary になっていますが、そこに含まれているすべてが >>156 と >>157 にも含まれているというわけでもありません。
[164] RDFa と GRDDL は直接関係ありませんが、 http://www.w3.org/2011/rdfa-context/xhtml-rdfa-1.1
を head
要素の profile
属性に指定することで、GRDDL
的に RDFa から RDF に変換できるようになるとされています。
[9] Some minor changes on the RDFa context document (Ivan Herman著, ) <https://lists.w3.org/Archives/Public/public-rdfa/2017Jan/0000.html>