[6] 外来マーク付けは、 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.3 の atom:feed 要素と atom:entry
要素も、任意の名前空間の要素を子供として構わないとされていました
>>43。
[9] Atom処理器は、外来マーク付けが認められている場所で外来マーク付けを見つけても処理を停止してはなりませんし、誤りを通知してはなりません。 RFC 4287 6.3.
[3] 処理器は、外来マーク付けで処理を停止してはなりませんし、誤りを通知してはなりません。 AtomPub, >>23
[10] Atom処理器は外来マーク付けを処理できるかもしれませんが、処理できないものは未知外来マーク付けといいます。 RFC 4287 6.3.
[11] atom:entry 要素、 atom:feed
要素、Person construct の子要素の未知外来マーク付け、
at:deleted-entry 要素の子要素の未知外来マーク付けに関しては、
それらおよびその文字内容を読み飛ばして構わず、
マーク付けがあるからといって動作を変更してはなりません。
RFC 4287 6.3., >>23
[12] atom:content 要素や Text construct
で未知外来マーク付けがあったときは、そのマーク付けを無視してその文字内容だけがあったかのように処理するべきです。
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:feed、atom:entry、
atom:source、Person construct の各要素の子要素は
Metadata要素であり、単純拡張要素または構造化拡張要素です。
RFC 4287 6.4.
[15] RELAX NG スキーマ (参考) によると単純拡張要素と構造化拡張要素の総称が
extensionElement です。 RFC 4287 6.4.
(規定の部分では「拡張要素」の定義は明記されていません。)
[34] app:service 要素は RELAX NG スキーマ (参考) では
extensionElement を内容に持っています >>2 が、
仕様書本文で拡張要素を認めるとはされていません。
[30] app:control 要素も拡張要素を含めることができます >>2。
RELAX NG スキーマ (参考) でも extensionElement を認めています。
[38] Atom 本体では Atom名前空間、AtomPub では AtomPub名前空間の要素を除く要素が
extensionElement に含まれています。
[37] RELAX NG スキーマ (参考) によると app:workspace と
app:collection の内容として extensionSansTitleElement
を認めており、これは atom:title と AtomPub 要素を除く拡張要素を表しています >>2。
ただし仕様書本文で拡張要素を認めるとはされていません。
[42] >>24 の通りなぜか明記されていませんが、 at:deleted-entry 要素も拡張要素が使えるものとして扱うのが自然と思われます。
[25] 単純拡張要素と構造化拡張要素の違いは、子要素や属性があるか否かだけです。従って Atom 以外の名前空間の任意の要素が拡張要素たり得ます。 特定の要素が文脈によって単純拡張要素だったり構造化拡張要素だったりできるのかは明記されていませんが、 現時点では Atom 関連仕様でそのような例はないようです。
[18] 単純拡張要素は、 それが含まれる親要素の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] 構造化拡張要素の構造は、 子要素の順序も含み、意味を持つかもしれません。 RFC 4287 6.4.2.
[22] Atom では構造化拡張要素の解釈を定義しておらず、 要素内の構文やその解釈は Atom 拡張の仕様書によって定義されます。 RFC 4287 6.4.2.
[19] 構造化拡張要素の根要素は、最低1つ、属性か子要素を持たなければなりません。 構造化拡張要素は Language-Sensitive です。 RFC 4287 6.4.2.
[20] RELAX NG スキーマ (参考) 上の名前は
structuredExtensionElement です。
RFC 4287 6.4.2.
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>
atom:title要素はこれらの要素の子要素として使えることになっているので、 拡張要素からは除外されているようです。