extensionElement

外来マーク付け (Atom)

[6] 外来マーク付け (foreign markup) は、 Atom において Atom 以外のマーク付けを指します。

仕様書

文書の要件

[7] Atom文書外来マーク付けを含めることができます。特に atom:content 要素は任意の外来マーク付けを含められるようになっています。 RFC 4287 6.1.

[1] AtomPub文書中の認識できないマーク付けAtom 1.0外来マーク付けとみなします。外来マーク付けは、 分類文書サービス文書の中の明示的に禁じられていない任意の場所で用いることができます。 AtomPub

[24] at:deleted-entry 要素の仕様ではなぜか外来マーク付けの定義を引用せずに、 独自に同様の規定を持っています。 RELAX NG スキーマ上では anyElement とされているものがそれに相当する模様です。 at:deleted-entry 要素内では任意の要素属性を使うことができます >>23

[33] >>4 の通りAtom名前空間などの未定義の要素属性外来マーク付けとして処理されるようですが、 文書の適合性に関して任意の要素属性が認められると解釈していいものかどうかは不明です。 将来の拡張を仕様違反としない意図があるのかもしれませんが、そのような場合は仕様を改訂すれば良いはずです。 仮に仕様違反でないと解釈すると、文書適合性に意味があまりなくなってしまいます。

[35] テキストのみと認めると思われる要素内容として要素を含められるか否かについて、 ほとんどの箇所で明記されていません。 RELAX NG スキーマ (参考) としては認めていないことになっていますが、 規定として禁止されていません。

[44] Atom 0.3atom:feed 要素atom:entry 要素も、任意の名前空間要素子供として構わないとされていました >>43

処理モデル

[9] Atom処理器は、外来マーク付けが認められている場所で外来マーク付けを見つけても処理を停止してはなりませんし、誤りを通知してはなりませんRFC 4287 6.3.

[3] 処理器は、外来マーク付けで処理を停止してはなりませんし、誤りを通知してはなりませんAtomPub, >>23

[10] Atom処理器外来マーク付けを処理できるかもしれませんが、処理できないものは未知外来マーク付け (unknown foreign markup) といいます。 RFC 4287 6.3.

[11] atom:entry 要素atom:feed 要素Person construct子要素未知外来マーク付けat:deleted-entry 要素子要素未知外来マーク付けに関しては、 それらおよびその文字内容 (textual content) を読み飛ばして構わずマーク付けがあるからといって動作を変更してはなりませんRFC 4287 6.3., >>23

[12] atom:content 要素Text construct未知外来マーク付けがあったときは、そのマーク付けを無視してその文字内容 (textual content) だけがあったかのように処理するべきですRFC 4287 6.3.

[8] クライアント文書転送にあたって外来マーク付けを保持するべきですAtomPub

[4] http://www.w3.org/2005/Atom 名前空間http://www.w3.org/2007/app 名前空間は将来の拡張のために予約されていますが、 この名前空間要素属性であっても、 認識できないマーク付け外来マーク付けとして扱わなければなりません RFC 4287 6.2.、AtomPub

[32] http://purl.org/syndication/history/1.0 名前空間については、 外来マーク付けに相当するものを含め、仕様に含まれないものをどう処理するべきか言及すらされていません。

拡張要素

[13] 外部マーク付けは、特に禁じられている箇所以外の Atom文書のあらゆるところで認められていますが、 意味が定義されているのは >>14 の場合だけで、それ以外の外部マーク付け役割は未定義となっています。 RFC 4287 6.4.

[14] atom:feedatom:entryatom:sourcePerson construct の各要素子要素Metadata要素であり、単純拡張要素または構造化拡張要素です。 RFC 4287 6.4.

[15] RELAX NG スキーマ (参考) によると単純拡張要素構造化拡張要素の総称が extensionElement です。 RFC 4287 6.4. (規定の部分では「拡張要素 (extension element) 」の定義は明記されていません。)

[34] app:service 要素RELAX NG スキーマ (参考) では extensionElement内容に持っています >>2 が、 仕様書本文で拡張要素を認めるとはされていません。

[30] app:control 要素拡張要素を含めることができます >>2RELAX NG スキーマ (参考) でも extensionElement を認めています。

[38] Atom 本体では Atom名前空間AtomPub では AtomPub名前空間要素を除く要素extensionElement に含まれています。

[37] RELAX NG スキーマ (参考) によると app:workspaceapp:collection内容として extensionSansTitleElement を認めており、これは atom:titleAtomPub 要素を除く拡張要素を表しています >>2。 ただし仕様書本文で拡張要素を認めるとはされていません。

[39] atom:title 要素はこれらの要素子要素として使えることになっているので、 拡張要素からは除外されているようです。

[42] >>24 の通りなぜか明記されていませんが、 at:deleted-entry 要素拡張要素が使えるものとして扱うのが自然と思われます。

[25] 単純拡張要素構造化拡張要素の違いは、子要素属性があるか否かだけです。従って Atom 以外の名前空間の任意の要素拡張要素たり得ます。 特定の要素が文脈によって単純拡張要素だったり構造化拡張要素だったりできるのかは明記されていませんが、 現時点では Atom 関連仕様でそのような例はないようです。

単純拡張要素

意味

[18] 単純拡張要素 (Simple Extension element) は、 それが含まれる親要素の1つの特性 (名前の組) を表します。要素名前空間URL局所名の組が特性名前となります。 要素文字データ内容特性の値となります。 要素の場合、特性の値は空文字列です。 RFC 4287 6.4.1.

構文

[16] 単純拡張要素には、属性子要素があってはなりません文字データを含んでも構いませんし、 であっても構いませんLanguage-Sensitive ではありません。 RFC 4287 6.4.1.

[17] RELAX NG スキーマ上の名称は simpleExtensionElement であり、データ型text です。 RFC 4287 6.4.1.

構造化拡張要素

意味

[21] 構造化拡張要素 (Structured Extension element) の構造は、 子要素の順序も含み、意味を持つかもしれません。 RFC 4287 6.4.2.

[22] Atom では構造化拡張要素の解釈を定義しておらず、 要素内の構文やその解釈は Atom 拡張の仕様書によって定義されます。 RFC 4287 6.4.2.

構文

[19] 構造化拡張要素根要素は、最低1つ、属性子要素を持たなければなりません構造化拡張要素Language-Sensitive です。 RFC 4287 6.4.2.

[41] Language-Sensitive であるというよりあり得るというほうが実態には近いのでしょう。実際 >>28 を見るといずれもそれ自体は Language-Sensitive である意味がないように見えます。

[20] RELAX NG スキーマ (参考) 上の名前structuredExtensionElement です。 RFC 4287 6.4.2.

拡張要素の一覧

[26] 単純拡張要素には次のものがあります。

[27] fh:archive, fh:complete, app:edited拡張要素とは明記されていませんが、 構造上、単純拡張要素となっています。

[28] 構造化拡張要素には次のものがあります。

[29] thr:in-reply-to, thr:total, at:deleted-entry単純拡張要素構造化拡張要素Atom 関連仕様では明記されておらず、ただ単に拡張要素とされていますが、 どちらであるかは構造上自明です。

[40] Atom名前空間要素も、 AtomPub から見ると拡張要素に当たるようですが、 >>26>>28 では省略しています。

空要素

[36] Atom および関連仕様には空要素とみられるもの、空要素とされているものがありますが、 RELAX NG スキーマ (参考) としては undefinedContent とされていることがほとんどであり、また要素内容は未定義とされていることが多いです。 >>13 の通り外来マーク付けが認められているようですが、その意味は定義されていません。

[45] RFC 5854 - The Metalink Download Description Format ( ( 版)) <http://tools.ietf.org/html/rfc5854#section-5.3>