閉じる

Atom Publishing Protocol 日本語訳

この文書は RFC 5023 The Atom Publishing Protocol を, BCP78によって付託された権利に基づいて日本語に翻訳したものです。
翻訳には誤りがある可能性があります。この翻訳の正確性は保証しません。

翻訳についてのお問合せ先:(SSL対応フォーム) (非SSL対応フォーム)

翻訳者一覧
株式会社リコー
山本陽平
日野原寛
高桑寿一
中川勝樹
沖田邦夫
井上浩一
兵清弘
リコーソフトウエア株式会社
福田朋紀
更新履歴
2008-01-07
日外アソシエーツ株式会社 久我様の指摘を受け 9.7 の訳文をわかりやすく、11.2 の抜けを修正
2007-12-06
9.6、9.7.1、9.7.2、10 の誤記、表記ぶれを修正
2007-11-08
エヌ・ティ・ティ・コミュニケーションズ株式会社 朝倉様の指摘を受け 9.3/9.4 の誤訳を修正
2007-11-05
エヌ・ティ・ティ・コミュニケーションズ株式会社 朝倉様の指摘を受け 9.6.1 の抜けを修正
Network Working GroupJ. Gregorio, Ed.
Request for Comments: 5023Google
Category: Standards TrackB. de hOra, Ed.
NewBay Software
October 2007

Atom 出版プロトコル

このメモの位置付け

この文書は、インターネットコミュニティに向けて、インターネットの標準規格プロトコルを規定し、改良のための議論と提案を求めるものである。本プロトコルの標準化の進捗、および位置づけは、"Internet Official Protocol Standards" (STD 1) の最新版を参照されたい。このメモの配布に制限はない。

概要

Atom 出版プロトコル(AtomPub)は Web リソースを出版・編集するためのアプリケーションレベルのプロトコルである。このプロトコルは、Atom でフォーマットされた表現を HTTP で送受信することを基盤に置いている。 Atom フォーマットは、Atom 配信フォーマットで文書化されている。

目次

1. はじめに

Atom 出版プロトコルは HTTP [RFC2616] と XML 1.0 [REC-xml] を使って Web リソースを出版・編集 するためのアプリケーションレベルのプロトコルである。 このプロトコルは Web リソースの生成をサポートし、以下の機能を提供する。

Atom 出版プロトコルはクライアントからのリクエストの処理について、サー バに広い自由度が与えられているという点で、現在の他の多くのプロトコ ルとは異っている。詳細は 4.4 節を参照のこと。

2. 表記規約

この文書中のキーワード、「必須 MUST」「必須 MUST NOT」「必須 REQUIRED」「必須 SHALL」「必須 SHALL NOT」「要請 SHOULD」「要請 SHOULD NOT」「要請 RECOMMENDED」「可能 MAY」「可能 OPTIONAL」は、RFC 2119 に従って解釈すること。(訳注: RFC-2119j(内田訳)より拝借)

2.1 XMLに関する規約

2.1.1 情報項目への参照

Atom プロトコル文書フォーマットは XML 情報セット [REC-xml-infoset] の用語で特定され、XML 1.0 [REC-xml] として書き出される。

情報セットの用語のうち、「要素情報項目」と「属性情報項目」はそれぞれ「要素」、「属性」と省略して表現される。すなわち、本仕様において「要素」という用語が使用された場合には要素情報項目を表し、「属性」という用語が使用された場合には「要素情報項目を表す。

2.1.2 RELAX NG スキーマ

本仕様のいくつかの部分において、規定外の RELAX NG コンパクトスキーマ [RNC] の一部で図示することがある。本仕様中の文章によって厳密な定義を提供する。完全なスキーマは付録 B に登場する。

2.1.3 "xml:base" と "xml:lang" の使用

本仕様中で定義される XML 要素は、 "xml:base" 属性 [REC-xmlbase] を持っていてもよい(MAY)。xml:base が使用される際には、 xml:base 属性の影響範囲内にある関連する参照を解決するために基本 URI (または IRI, International Resource Identifier [RFC3987])を構築することで、「URI Generic Syntax」 [RFC3986] の 5.1.1 節で説明されている機能を提供する。

本仕様で定義されるあらゆる要素は、 "xml:lang" 属性を持っていてもよく(MAY)、その内容は要素とその子孫に使われる自然言語を示す。内容と "xml:lang" の解釈についての要求仕様は XML 1.0 [REC-xml] の 2.12 節にある。

3. 用語

便宜上、このプロトコルを "Atom プロトコル" もしくは "AtomPub" と表してもよいこととする。 この仕様で用いられる用語を以下に示す:

4. プロトコルモデル

Atom プロトコルは HTTP を使ったリソースの出版と編集のための操作を明確にする。Atom プロトコルはそれらのリソースの状態とメタデータを記述するために Atom 形式の表現を 利用する。Atom プロトコルはリソースの集合が組織化される方法を定義し、そしてそれらのリソースの発見やグループ分け、そして分類のサポートをするためのフォーマットを明確にする。

4.1 同一性と名前付け

Atom プロトコル文書はリソースを特定するために URI [RFC3986] と同様に、IRI [RFC3987] の使用を許可する。文書の中の IRI は HTTP によって使われる前に、[RFC3987] の 3.1 節で定義されている手続きに従い、はじめに URI に変換される。仕様に従って、その変換は可能な限り遅くに適用されるべきである(SHOULD)。変換はリソースの生成を意味しない。その IRI と 変換された URI は同じリソースを指す。

Atom プロトコルは交換される表現のフォーマットと、表現の中に埋め込まれる IRI に対して実行され得る操作を明確にする一方、Atom プロトコルは使われる URI の形式は強制しない。HTTP [RFC2616] は各サーバの URI 空間をサーバが管理することを明確にしているが、Atom プロトコルは管理の制約をさらに課すことはない。

4.2 文書とリソースの階層化

コレクションに記載される IRI を持つリソースはメンバリソースと呼ぶ。Atom プロトコルは二種類のメンバリソース、エントリリソースとメディアリソースを定義する。エントリリソースは Atom エントリ文書 [RFC4287] として表される。メディアリソースはどんなメディアタイプの表現でも持つことができる。メディアリソースはメディアリンクエントリと呼ばれるエントリを使ったコレクションの中に記述される。この図は Atom プロトコル内のリソースの分類を示す。

            メンバリソース
                   |
            -----------------
           |                 |
     エントリリソース    メディアリソース
           |
    メディアリンクエントリ

Atom プロトコルは両方の種類のメンバリソースの管理と組織化のためにコレクションリソースを定義する。コレクションは Atom フィード文書として表される。コレクションフィード内のエントリはコレクションのメンバリソースの IRI とメタデータを含む。コレクションフィードはエントリをいくつも含めることができる。そのエントリはコレクションの全てのメンバを表しているかもしれないし、あるいはそれらの順序付けられた部分集合かもしれない(10.1 節参照)。下のコレクションの図には、二つのエントリがある。一つ目はエントリリソースの IRI を含んでいる。二つ目はメディアリソースに対するメタデータを含むメディアリソースとメディアリンクエントリの両方の IRI を含んでいる。

 コレクション
    |
    o- エントリ
    |    |
    |    o- メンバエントリ IRI (エントリリソース)
    |
    o- エントリ
         | 
         o- メンバエントリ IRI (メディアリンクエントリ)
         | 
         o- メディア IRI        (メディアリソース)

Atom プロトコルはコレクションに対して使われたフィードとその他の Atom フィードとの間に区別はしない。この仕様においてフィードがコレクションフィードであることを示すために提供する唯一のメカニズムはサービス文書中にフィードのIRIが存在することである。

サービス文書はサーバが定義したコレクションのグループを表し、リソース作成や編集のプロセスを初期化するために使われる。これらのコレクションのグループはワークスペースと呼ばれる。ワークスペースは名前をもつが、IRI を持たず、特別な処理モデルを持たない。サービス文書はコレクションが受け入れるであろうメディアタイプやカテゴリーを示すことができる。下の図では、二つのワークスペースがあり、 それぞれでコレクションに対するIRI 、受け入れ可能なメディアタイプ、そしてカテゴリを記述している。

 サービス
    o- ワークスペース
    |    |
    |    o- コレクション
    |         |
    |         o- IRI, カテゴリ, メディアタイプ
    |
    o- ワークスペース
         |
         o- コレクション
              |
              o- IRI, カテゴリ, メディアタイプ

4.3 管理と出版

Atom 出版プロトコルはメンバリソースを操作するために次の HTTP メソッドを使う。

Atom プロトコルはエントリとメディアのリソースの作成、編集、削除のみを対象としている。コレクション操作の結果として他のリソースも作成、編集、削除され得るが、それらのリソースやメディアタイプ、及びそれらに対する Atom プロトコル操作の影響については本仕様の範囲外である。

クライアント/サーバの相互作用のすべては HTTP で定義されるので、[RFC2616] は本仕様で対象外のあらゆる領域について参考にされるべきである。

4.4 クライアント実装の考慮点

Atom プロトコルはサーバの動作にわずかな制限しか課さない。もしここで制約が明確にされない場合、特にクライアントによって送られた Atom エントリの操作周りで、サーバの挙動が異なることが予想される。例えば、本仕様はコレクションに対して GET と POST に関しては予想される動作を定義しているが、PUT、DELETE、PROPPATCH、またはその他のメソッドが禁止であることを意味しない。単にこれらのメソッドに対するサーバのレスポンスを定義していないだけである。同様に、いくつかの HTTP ステータスコードしか明示的に言及されていないが、クライアントはサーバからのあらゆるステータスコードを扱うよう準備すべきである。サーバは送信されたコンテンツに対して、受諾、拒否、遅延、管理、検閲、再整形、変換、再配置、再分類するかどうか選択できる。これらの選択のうちいくつかは、クライアントのリクエストへのレスポンスとして、ただちにクライアントに戻される。他の選択については、フィードや発行されたエントリとして後で明確になるかもしれない。二つの異なる出版されたサイトに対する同種のリクエストは、異なる HTTP レスポンスやフィード、エントリのコンテンツとなることができる。

結果として、クライアントソフトウェアは、自身の送信の結果サーバが決定するものを受け入れるために、柔軟に書かれていなければならない。 それゆえに、本仕様または HTTP [RFC2616] で明示的に禁止されていないサーバのレスポンスまたはコンテンツの修正が許される。

5. プロトコルの動作

以下の相互関係図には特定の HTTP ステータスコードが示されているが、AtomPub クライアントはいかなるステータスコードも扱えるように準備されているべきである(SHOULD)。たとえば、メンバ URI への PUT の成功として返すことのできる"204 No Content"ステータスコードも扱えるべきである。

5.1 サービス文書の取得

クライアント                                サーバ
  |                                           |
  |  1.) サービス文書の URI を GET            |
  |------------------------------------------>|
  |                                           |
  |  2.) 200 Ok                               |
  |      サービス文書                         |
  |<------------------------------------------|
  |                                           |
  1. クライアントは GET リクエストをサービス文書の URI に送る。
  2. サーバはコレクションのグループの IRI やそれらのサーバがサポートするコレクションのケーパビリティを列挙したサービス文書を返す。サービス文書の内容は認証証明を含む(もちろんそれだけに限らない)クライアントリクエストの状態によって変化する。

5.2 コレクションメンバの列挙

コレクションメンバ一覧を得るため、クライアントは GET リクエストをコレクションの URI に送る。サーバはメンバリソースの IRI を持つエントリを有する Atom フィード文書を返す。返された Atom フィード文書にはコレクションのメンバの一部だけが記述されていても、全部が記述されていても構わない(MAY)。

クライアント                    サーバ
  |                                |
  |  1.) コレクションの URI を GET |
  |------------------------------->|
  |                                |
  |  2.) 200 Ok                    |
  |      Atom フィード文書         |
  |<-------------------------------|
  |                                |
  1. クライアントはコレクションの URI に GET リクエストを送る。
  2. サーバは、コレクションメンバの IRI を持つ Atom フィード文書を返す。

5.3 リソースの生成

クライアント                                サーバ
  |                                            |
  |  1.) コレクションの URI へメンバ表現を POST|
  |------------------------------------------->|
  |                                            |
  |  2.) 201 Created                           |
  |      Location: メンバエントリの URI        |
  |<-------------------------------------------|
  |                                            |
  1. クライアントはコレクションの URI にメンバ表現を POST する。
  2. メンバリソースの生成が成功した場合、サーバはステータスコード 201 と新しく生成されたエントリリソースの IRI を含む Location ヘッダを返す。メディアリソースも同様に生成していてよく、その IRI もエントリリソースを通じて見つけることができる。詳しくは 9.6 節を参照のこと。

5.4 リソースの編集

ひとたびリソースが生成され、そのメンバ URI がわかれば、URI はリソースの取得、編集、削除に用いることができる。11 節では編集目的で Atom プロトコルで使用される Atom 配信フォーマットの拡張を説明する。

5.4.1 リソースの取得

クライアント                                サーバ
  |                                           |
  |  1.) メンバの URI を GET                  |
  |------------------------------------------>|
  |                                           |
  |  2.) 200 Ok                               |
  |      メンバ表現                           |
  |<------------------------------------------|
  |                                           |
  1. クライアントはメンバリソースの URI に GET リクエストを送り、リソース表現を取得する。
  2. サーバはメンバリソースの表現を返す。

5.4.2 リソースの編集

クライアント                                サーバ
  |                                              |
  |  1.) コレクションの URI へメンバ表現を PUT   |
  |--------------------------------------------->|
  |                                              |
  |  2.) 200 Ok                                  |
  |<---------------------------------------------|
  |                                              |
  1. クライアントは PUT リクエストを送り、メンバリソースの表現を保存する。
  2. リクエストが成功すると、サーバはステータスコード 200 を返す。

5.4.3 リソースの削除

クライアント                                サーバ
  |                                           |
  |  1.) メンバの URI を DELETE               |
  |------------------------------------------>|
  |                                           |
  |  2.) 200 Ok                               |
  |<------------------------------------------|
  |                                           |
  1. クライアントは DELETE リクエストをメンバリソースの URI に送る。
  2. 削除が成功すると、サーバはステータスコード 200 を返す。

メディアリソースの削除は異なる手法を取る。詳しくは9.4節を参照のこと。

5.5 HTTP レスポンスコードの使用

Atom プロトコルは HTTP で定義されているレスポンスステータスコードを操作の成功や失敗を示すために用いる。HTTP 仕様 [RFC2616]をそれぞれのステータスコードの詳細な定義の参考とすること。HTTP 仕様に従い、HTTPの 4xx と 5xx の レスポンスエンティティは人間可読なエラーの説明を含むべきである(SHOULD)ことに注意して実装することが求められる。

6. プロトコル文書

6.1 文書型

本仕様ではカテゴリ文書とサービス文書の二つの文書型を定義する。

カテゴリ文書(7 節)はカテゴリの一覧を含む。 その一覧は Atom 配信フォーマット ([RFC4287]の 4.2.2 節参照)の"atom:category" 要素を用いて指定する。

サービス文書(8 節)は利用可能なコレクションをワークスペースとして グループ化する。

これらの文書に対する名前空間名 [REC-xml-names] は以下である。

http://www.w3.org/2007/app

Atom 出版プロトコルのXML文書は [REC-xml-names] の 7 節で定められる 名前空間整形式(namespace-well-formed)でなければならない(MUST)。

本仕様では "app:" というプレフィックスを名前空間名として用いる。"atom:" というプレフィックスは Atom 配信フォーマット [RFC4287] の名前空間名で ある"http://www.w3.org/2005/Atom" を表すために用いる。 これらの名前空間プレフィックスは意味的に重要ではない。

本仕様は Atom プロトコル文書のいかなる DTD も規定しない。 従って、 [REC-xml] の意味において妥当(valid)であることを要求しない。

6.2 文書の拡張性

Atom 出版プロトコル文書中の認識できないマークアップは、Atom 配信フォーマット [RFC4287] の6 節で定義された外部マークアップと見なされる。 外部マークアップは明示的に禁止されていない限り、カテゴリ文書または サービス文書のどこででも使うことができる。 処理系は外部マークアップを読み込んだ場合でも処理を停止してはいけない (MUST NOT)し、エラーを通知してもいけない(MUST NOT)。クライアントがその ような文書を送信する場合、外部マークアップを保って行わなければならない(MUST)。

名前空間名"http://www.w3.org/2007/app"は将来の互換性のある版の カテゴリ文書およびサービス文書のために予約されている。 この将来の版には本仕様を満たした処理系が認識不可能な要素や属性の追加を含むかもしれない。 名前空間"http://www.w3.org/2007/app"に属するそのような認識できないマークアップは外部マークアップとして扱われなければならない(MUST)。

7. カテゴリ文書

カテゴリ文書は Atom 配信フォーマット [RFC4287] の "atom:category" 要素を使って記述 されたカテゴリ群のリストである。 カテゴリ文書はサービス文書にも出現でき、そこではコレクションで許可されているカテゴ リを示す(8.3.6 節参照)。

カテゴリ文書は "application/atomcat+xml" メディアタイプで識別される (16.1 節参照)。

7.1 例

<?xml version="1.0" ?>
<app:categories
    xmlns:app="http://www.w3.org/2007/app"
    xmlns:atom="http://www.w3.org/2005/Atom"
    fixed="yes" scheme="http://example.com/cats/big3">
  <atom:category term="animal" />
  <atom:category term="vegetable" />
  <atom:category term="mineral" />
</app:categories>

このカテゴリ文書は term が 'animal', 'vegetable', 'mineral' の atom:category 要素を含んでいる。どのカテゴリも [RFC4287] で定義されて いる "label" 属性は使っていない。これらは全て app:categories 要素で宣言 されている "http://example.com/cats/big3" "scheme" 属性を継承している。 それゆえ、'mineral' カテゴリが Atom エントリやフィード文書上に出現する ときは、以下のように出現するだろう。

<atom:category scheme="http://example.com/cats/big3" term="mineral"/>

7.2 要素定義

7.2.1 "app:categories" 要素

カテゴリ文書のルートは "app:categories" 要素である。app:categories 要素 は、ゼロ個以上の Atom 配信フォーマット [RFC4287] 名前空間 ("http://www.w3.org/2005/Atom") に属する atom:category 要素を含むことができ る。

"scheme" 属性を持たない atom:category 子要素は、 その親の app:categories の属性を継承する。 "scheme" 属性を持つ atom:category 子要素はその親の app:categories の属 性を継承しない。

atomCategory =
   element atom:category {
      atomCommonAttributes,
      attribute term { text },
      attribute scheme { atomURI }?,
      attribute label { text }?,
      undefinedContent
   }

appInlineCategories =
   element app:categories {
       attribute fixed { "yes" | "no" }?,
       attribute scheme { atomURI }?,
       (atomCategory*,
       undefinedContent)
   }

appOutOfLineCategories =
   element app:categories {
       attribute href { atomURI },
       undefinedContent
   }

appCategories = appInlineCategories | appOutOfLineCategories
7.2.1.1 app:categories の属性

app:categories 要素は "yes" または "no" という値を取る "fixed" 属性を含 むことができる。"fixed" 属性はカテゴリのリストが固定(fixed)されている かどうかを示す。"fixed" 属性がない場合は、"fixed" 属性の値が "no" であ るのと等価である。

もう一つの方法として、app:categories 要素はカテゴリ文書を識別する URI 参照を値に持つ "href" 属性を含んでもよい(MAY)。もし "href" 属性が提供さ れたら、 app:categories 要素は空であり(MUST)かつ "fixed" や "scheme" 属性を持ってはならない(MUST NOT)。

8. サービス文書

コレクションを利用するに当たり、クライアントはその所在と能力を知る必要がある。サービス文書はそれを発見する一助となるよう設計されている。

サービス文書を発見する方法は本仕様では定義されない。

サービス文書のメディアタイプは "application/atomsvc+xml" となる(16.2節参照)。

8.1 ワークスペース

サービス文書はコレクションをワークスペースとして扱う。ワークスペースの作成や削除のような操作は本仕様では定義されない。本仕様ではワークスペースに対して意味を与えない。すなわち、ワークスペースはいかなる特定の処理条件も提示しない。

サーバは複数のワークスペースを扱えなくてもよい。加えて、ひとつのワークスペース中に複数のコレクションが出現してもよい(MAY)。

8.2 例

<?xml version="1.0" encoding='utf-8'?>
<service xmlns="http://www.w3.org/2007/app"
         xmlns:atom="http://www.w3.org/2005/Atom">
  <workspace>
    <atom:title>Main Site</atom:title>
    <collection
        href="http://example.org/blog/main" >
      <atom:title>My Blog Entries</atom:title>
      <categories
         href="http://example.com/cats/forMain.cats" />
    </collection>
    <collection
        href="http://example.org/blog/pic" >
      <atom:title>Pictures</atom:title>
      <accept>image/png</accept>
      <accept>image/jpeg</accept>
      <accept>image/gif</accept>
    </collection>
  </workspace>
  <workspace>
    <atom:title>Sidebar Blog</atom:title>
    <collection
        href="http://example.org/sidebar/list" >
      <atom:title>Remaindered Links</atom:title>
      <accept>application/atom+xml;type=entry</accept>
      <categories fixed="yes">
        <atom:category
          scheme="http://example.org/extra-cats/"
          term="joke" />
        <atom:category
          scheme="http://example.org/extra-cats/"
          term="serious" />
      </categories>
    </collection>
  </workspace>
</service>

上のサービス文書は二つのワークスペースについて記述している。一つ目のワークスペースは "Main Site" と呼ばれ、 "My Blog Entries" と "Pictures" という二つのコレクションを含み、その IRI はそれぞれ "http://example.org/blog/main" と "http://example.org/blog/pic" である。"Pictures" というコレクションは、新しいメディアリソースを作るためにクライアントが送信することのできる画像ファイルの種類を示す三つの "accept" 要素を持つ(メディアリソースに関連付けられた項目については 9.6 節で論じられる)。

二つ目のワークスペースは "Sidebar Blog" と呼ばれ、 "Remaindered Links" という一つのコレクションを持ち、その IRI は "http://example.org/sidebar/list" である。このコレクションは "application/atom+xml;type=entry" という内容の "accept" 要素を持ち、クライアントから Atom のエントリを受け取れることを示している。

これら二つのエントリコレクションのどちらにも含まれる "categories" 要素はメンバエントリが持ち得るカテゴリのリストを提供する。 "My Blog Entries" コレクションにおいては、持ち得るカテゴリのリストは "href" 属性を通じて得られる。 "Sidebar Blog" コレクションはサービス文書内でカテゴリリストを提供しているが、固定されたリストを提供しており、エントリが POST されるサーバからのリクエストはこれら二つのカテゴリのみを使用することを示している。

8.3 要素定義

8.3.1 "app:service" 要素

サービス文書のルートは "app:service" 要素である。

app:service 要素は 一つ以上のワークスペースと関連するサービス情報のコンテナである。 app:servcie 要素は一つ以上の app:workspace 要素を含む必要がある(MUST)。

namespace app = "http://www.w3.org/2007/app"
start = appService

appService =
  element app:service {
     appCommonAttributes,
     ( appWorkspace+
       & extensionElement* )
  }

8.3.2 "app:workspace" 要素

ワークスペースはサーバで定義されたコレクションのグループである。 "app:workspace" 要素は 編集可能なリソースのコレクションを記述するゼロ個以上の app:collection 要素を含む。

appWorkspace =
  element app:workspace {
     appCommonAttributes,
     ( atomTitle
       & appCollection*
       & extensionSansTitleElement* )
  }
atomTitle = element atom:title { atomTextConstruct }
8.3.2.1 "atom:title" 要素

app:workspace 要素は人間に可読なワークスペースの題名を与える "atom:title" 要素([RFC4287] で定義されている)を一つ含まなければならない(MUST)。

8.3.3 "app:collection" 要素

"app:collection" 要素はコレクションを記述する。 app:collection 要素は atom:title 要素を一つ含まなければならない(MUST)。

app:collection 要素は そのコレクションが許容する表現の型を示す app:accept 要素を任意の数 含むかもしれない(MAY)。

app:collection 要素は app:categories 要素を任意の数 含むかもしれない(MAY)。

appCollection =
  element app:collection {
     appCommonAttributes,
     attribute href { atomURI  },
     ( atomTitle
       & appAccept*
       & appCategories*
       & extensionSansTitleElement* )
  }
8.3.3.1 href 属性

app:collection 要素は コレクションの IRI を値に持つ "href" 属性を含まなければならない(MUST)。

8.3.3.2 "atom:title" 要素

"atom:title" 要素は [RFC4287] で定義され、人間に可読なコレクションの題 名を与える。

8.3.4 "app:accept" 要素

"app:accept" 要素の内容の値は [RFC2616] で定義されるメディアレンジであ る。メディアレンジは コレクションに POST できる 表現の型を指定する。

app:accept 要素は HTTP の Accept リクエストヘッダ [RFC2616] に似ている。 app:accept ではメディアタイプパラメタが許可されているが、 app:accept には優先順位の概念がない。 すなわち、[RFC2616] の 14.1 節で定められている "accept-params" または "q" 引数は有効でない。

app:accept 要素のメディアレンジにある空白([REC-xml] で定義されている) は重要でなく、無視されなければならない(MUST)。

"application/atom+xml;type=entry" という値は メディアレンジの app:accept リストに出現するかもしれない(MAY)。 これはそのコレクションに Atom エントリ文書を POST できることを示す。 app:accept 要素がない場合は、クライアントは "application/atom+xml;type=entry" という内容の app:accept 要素が一つあ るのと同様に扱うべきである(SHOULD)。

空の app:accept 要素が存在する場合は、 クライアントはそのコレクションが新しいエントリの生成をサポートしていな いと推定すべきである(SHOULD)。

appAccept =
  element app:accept {
        appCommonAttributes,
        ( text? )
  }

8.3.5 Atom フィードでの利用

app:collection 要素は Atom フィード文書の atom:feed または app:source 要素の子要素として現われるかもしれない(MAY)。 app:collection 要素の内容は フィードにどんな新しいエントリを追加できるかを示す。 atom:feed または atom:source 要素に出現する app:collection 要素は [RFC4287] の6節で定義される外部マークアップとみなされる。

8.3.6 "app:categories" 要素

"app:categories" 要素は コレクションのメンバに適用できる カテゴリのリストを提供する。 app:categories の詳細な定義は 7.2.1 節を参照のこと。

サーバは カテゴリリストにないカテゴリのメンバの作成または保存を拒否するかもしれない(MAY)。 カテゴリ集合が固定(fixed)されていないコレクションは カテゴリリストにないカテゴリのメンバーであったとしても、 拒否するべきではない(SHOULD NOT)。 app:categories 要素がない場合は コレクションのカテゴリ処理が明記されていない ことを意味する。 カテゴリを含まない固定された(fixed)カテゴリリストは カテゴリデータを許容しないコレクションであることを示す。

9. リソースの生成と編集

9.1 メンバ URI

メンバ URI は、クライアントが HTTP の GET、PUT、DELETE を用いてメンバソースの検索・編集・削除を行うことを許可する。エントリリソースは、Atom エントリ文書として表される。

メンバ URI は、二箇所に出現する。以下の 9.2 節で述べるように、POST によりリソースが正常に作成されたときに Location ヘッダで返される。また、 "edit" リンク関係を持った atom:link 要素として、コレクションフィードのエントリ内に出現する。

メンバエントリは、メンバ URI を示す "edit" リンク関係を持った atom:link 要素を含むべきである(SHOULD)。

9.2 POST によるリソースの作成

コレクションにメンバを追加するために、クライアントはコレクションの URI に対して POST リクエストを送る。

メンバ作成が成功したことは、201 ("Created") のレスポンスコードで示される。 コレクションが 201 のステータスコードで応答する際には、レスポンスボディも返すべきである(SHOULD)。そのレスポンスボディは、新しく作成されたリソースを表現する Atom エントリ文書でなければならない(MUST)。 サーバは POST されたエントリを自由に変えることができるため、例えば atom:id 要素の内容を変更すると、エントリを返すことで、新しいエントリをクライアントとサーバのビューで相互に関係付けられるのでクライアントにとって有益である。

メンバリソースが作成されたとき、そのメンバエントリの URI はコレクションのレスポンス内の Location ヘッダで返されなければならない(MUST)。

作成リクエストが Atom エントリ文書を含んでおり、そしてその後のサーバからのレスポンスが文字列として Location ヘッダに合う Content-Location ヘッダを含んでいるなら、クライアントはレスポンスエンティティを新しく作成されたエントリの完全な表現であると解釈する権限をもつ。Content-Location ヘッダと異なる場合、クライアントは、返されたエンティティが作成されたリソースの完全な表現であると推測してはならない(MUST NOT)。

POST により送信されたリクエストボディは、Atom エントリである必要はない。例えば、画像や動画であるかもしれない。コレクションは、POST されたエンティティのメディアタイプがそのコレクションで許可されていない、またはサポートされていないということを示すために 415 ("Unsupported Media Type")のステータスコードを持つレスポンスを返しても良い(MAY)。そうしたコンテンツの作成時の問題についての議論は、9.6節を参照のこと。

9.2.1 例

下記では、クライアントがコレクション URI を利用して Atom エントリ表現を含む POST リクエストを送信している。

POST /edit/ HTTP/1.1
Host: example.org
User-Agent: Thingio/1.0
Authorization: Basic ZGFmZnk6c2VjZXJldA==
Content-Type: application/atom+xml;type=entry
Content-Length: nnn
Slug: First Post

<?xml version="1.0"?>
<entry xmlns="http://www.w3.org/2005/Atom">
  <title>Atom-Powered Robots Run Amok</title>
  <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
  <updated>2003-12-13T18:30:02Z</updated>
  <author><name>John Doe</name></author>
  <content>Some text.</content>
</entry>

サーバは、201 のステータスコードで作成成功を伝える。 レスポンスは、Atom エントリのメンバエントリ URI を示す Location: ヘッダと、 レスポンスボディにそのエントリの表現を含んでいる。

HTTP/1.1 201 Created
Date: Fri, 7 Oct 2005 17:17:11 GMT
Content-Length: nnn
Content-Type: application/atom+xml;type=entry;charset="utf-8"
Location: http://example.org/edit/first-post.atom
ETag: "c180de84f991g8"  

<?xml version="1.0"?>
<entry xmlns="http://www.w3.org/2005/Atom">
  <title>Atom-Powered Robots Run Amok</title>
  <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
  <updated>2003-12-13T18:30:02Z</updated>
  <author><name>John Doe</name></author>
  <content>Some text.</content>
  <link rel="edit"
   href="http://example.org/edit/first-post.atom"/>
</entry>

コレクションにより作成され返されたエントリは、クライアントにより POST されたエントリと異なるかもしれない。サーバは、atom:id、atom:updated、atom:author の値のようなエントリ中の様々な要素の値を変えて良い(MAY)し、 他の要素や属性を削除したり追加したり、または要素の内容や属性の値を変えても良い(MAY)。

9.3 PUTによるリソースの編集

メンバリソースを編集するには、クライアントはメンバ URI に対して [RFC2616] で定められた PUT リクエストを送る。

メンバエントリやメディアリンクエントリの編集に伴う意図しないデータ消失を避けるため に、Atom プロトコルクライアントは意図的に変更されていないメタデータを維持しなければならない(SHOULD)。 それには [RFC4287] の 6 節に定められた未知の外部マークアップも含まれる。

9.4 DELETEによるリソースの削除

メンバリソースを削除するには、クライアントはメンバ URI に対して [RFC2616] で定められた DELETE リクエストを送る。 メディアリンクエントリが削除された場合、結果として対応するメディアリソースも削除されるべきである(SHOULD)。

9.5 キャッシュとエンティティタグ

実装者は、キャッシュ制御に注意を払い、リソースの編集においてHTTPに備わったメカニズム、 特に[NOTE-detect-lost-update]で概説するエンティティタグを利用することが推奨される。 サーバが仲介者にキャッシュを許している場合、クライアントが GET を用いてコレクションメンバの最新の表現を得られることは保障されない。

9.5.1 例

以下のように、クライアントは POST を用いてメンバエントリを作成する。

POST /myblog/entries HTTP/1.1
Host: example.org
Authorization: Basic ZGFmZnk6c2VjZXJldA==
Content-Type: application/atom+xml;type=entry
Content-Length: nnn
Slug: First Post
  
<xml version="1.0" >
<entry xmlns="http://www.w3.org/2005/Atom">
  <title>Atom-Powered Robots Run Amok</title>
  <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
  <updated>2007-02-123T17:09:02Z</updated>
  <author><name>Captain Lansing</name></author>
  <content>It's something moving... solid metal</content>
</entry>

サーバはステータスコード 201 で作成が成功したことを通知し、レスポンスに Etag ヘッダを含めて返す。 ここではサーバが Content-Location ヘッダと Location ヘッダに同じ値を返しているので、 返されたエントリの表現は新しく作成されたエントリの完全な表現であると解釈することができる。( 9.2 節参照)

HTTP/1.1 201 Created
Date: Fri, 23 Feb 2007 21:17:11 GMT
Content-Length: nnn
Content-Type: application/atom+xml;type=entry
Location: http://example.org/edit/first-post.atom
Content-Location: http://example.org/edit/first-post.atom
ETag: "e180ee84f0671b1"  
  
<xml version="1.0" >
<entry xmlns="http://www.w3.org/2005/Atom">
  <title>Atom-Powered Robots Run Amok</title>
  <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
  <updated>2007-02-123T17:09:02Z</updated>
  <author><name>Captain Lansing</name></author>
  <content>It's something moving... solid metal</content>
</entry>

クライアントは必要に応じて、その後に [RFC2616] で定義されている "Conditional-Get" を構成するために、返された Etag の値を利用することができる。 この場合、編集に先立って、クライアントは If-None-Match: ヘッダを利用して Etag の値を送る。

GET /edit/first-post.atom HTTP/1.1
Host: example.org
Authorization: Basic ZGFmZnk6c2VjZXJldA==
If-None-Match: "e180ee84f0671b1"

もしエントリが変更されていないなら、レスポンスはステータスコード 304 ("Not Modified")である。 これによってクライアントは、編集の時点において、自身がいまだにエントリの最新の表現を保持していると判定できる。

HTTP/1.1 304 Not Modified
Date: Sat, 24 Feb 2007 13:17:11 GMT

編集の後、クライアントはエントリを PUT し、Etag エンティティの値を If-Match: ヘッダで送ることにより、 Etag エンティティの値がサーバのものと一致する場合にエントリを受け入れるよう、サーバに知らせることができる。

PUT /edit/first-post.atom HTTP/1.1
Host: example.org
Authorization: Basic ZGFmZnk6c2VjZXJldA==
Content-Type: application/atom+xml;type=entry
Content-Length: nnn
If-Match: "e180ee84f0671b1" 

<xml version="1.0" >
<entry xmlns="http://www.w3.org/2005/Atom">
  <title>Atom-Powered Robots Run Amok</title>
  <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
  <updated>2007-02-24T16:34:06Z</updated>
  <author><name>Captain Lansing</name></author>
  <content>Update: it's a hoax!</content>
</entry>

しかしサーバはすでにクライアントのものより新しいコピーを受け取っており、ステータスコード 412 ("Precondition Failed")で応答する。

HTTP/1.1 412 Precondition Failed
Date: Sat, 24 Feb 2007 16:34:11 GMT

これによりクライアントはサーバがより新しいバージョンのエントリを受け取っており、送ったエントリを格納することを許可することはないということを知らされる。

9.6 メディアリソースとメディアリンクエントリー

クライアントはエントリリソースと同じく、メディアリソースをコレクションに POST することができる。サーバがそのリクエストを受け入れると、サーバは二つのリ ソースを作らなくてはいけない(MUST)。一つはリクエストで送られたエンティティに対応する メディアリソースと呼ばれるものであり、そして、それに関連付けられたメンバエントリでメディアリンクエントリと呼ばれるものである。メディアリンクエントリは Atom エントリとして表現され、 コレクションの中に出現する。

メディアリンクエントリはメタデータと(テキストでないかもしれない)メディア リソースの IRI を含む。このようにメディアリンクエントリはメディアリソースと独立して検索と変更に利用できるメタデータになる。

8.3.4 節で記述されているように、サーバはサービス文書内の app:accept 要素 を使って、受け入れるメディアタイプを通知できる。

作成リクエストに対する成功レスポンスは Location ヘッダにメディアリンクエントリの URI を含まなければならない(MUST)。メディアリンクエントリはメディアリソース IRI を含む "edit-media" のリンク関係を持つ atom:link を含むべきである(SHOULD)。メディアリンクエントリは "src" 属性を持つ atom:content 要素を持たなければならない(MUST)。"src" 属性の値は新たに作成されたメディアリソースのための IRI である。atom:content 要素の "src" 属性の IRI がメディアリソース IRI と同じであってもよい(OPTIONAL)。例えば、"src" 属性の値はメディアリソース IRI の代わりに、静的なキャッシュかあるいは分散ネットワークのコンテンツであるかもしれない。

実装者は、Atom エントリは atom:summary 要素を含まなければならない(MUST)と [RFC4287] が定めていることに注意することを求められている。従って、メディアリンクエントリの生成が成功した場合、サーバは POST されたエンティティ、あるいは他のあらゆるソースから導出された内容を持つ atom:summary 要素を(atom:id や atom:author 、そして atom:title といった他のあらゆる必須要素と同様に)入れることを選択してもよい(MAY)。サーバはこれらの要素に対してサーバが選択した値をクライアントが変更するのを許可しないかもしれない。

リソース生成に対して、本仕様では Atom メディアタイプ("application/atom+xml")として明示された Atom エントリエンティティか非 Atom メディアタイプとして明示された非 Atom エンティティを POST された本文に持つような場合だけを定義する。クライアントが Atom エントリをコレクションに POST しているとき、"application/atom+xml" か "application/atom+xml;type=entry" のいずれかのメディアタイプを使ってよい。本仕様ではリクエストの意味や、POST されたメディアタイプが "application/atom+xml" であるが本文は Atom エントリ以外の何かであるような場合のサーバの振る舞いを特定しない。特に、"application/atom+xml" を使って Atom フィード文書をコレクションに POST したときに何が起こるかは定義されない。

Atom プロトコルは、生成時も編集時も、同じリソースに対して多重の表現を生成することの意味を特定しない(例えば、同じ画像の PNG と JPG)。

9.6.1 例

以下では、クライアントが PNG 画像を受け付けるコレクションの URI に PNG 画像を含む POST リクエストを送っている。

POST /edit/ HTTP/1.1
Host: media.example.org
Content-Type: image/png
Slug: The Beach
Authorization: Basic ZGFmZnk6c2VjZXJldA==
Content-Length: nnn

...binary data... 

サーバはステータスコード 201 で作成成功を通知する。レスポンスはメディアリンクエントリのメンバ URI を指す Location ヘッダと、レスポンスの本文の中のエントリの表現を含む。メディアリンクエントリは "src" 属性をもつ content 要素を含む。メディアリンクエントリは、メディアリソースを変更するために使われる IRI を特定する "edit-media" のリンク関係の link 要素も含む。

HTTP/1.1 201 Created
Date: Fri, 7 Oct 2005 17:17:11 GMT
Content-Length: nnn
Content-Type: application/atom+xml;type=entry;charset="utf-8"
Location: http://example.org/media/edit/the_beach.atom

<?xml version="1.0"?>
<entry xmlns="http://www.w3.org/2005/Atom">
  <title>The Beach</title>
  <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
  <updated>2005-10-07T17:17:08Z</updated>
  <author><name>Daffy</name></author>
  <summary type="text" />
  <content type="image/png"
     src="http://media.example.org/the_beach.png"/>
  <link rel="edit-media"
     href="http://media.example.org/edit/the_beach.png" />
  <link rel="edit"
     href="http://example.org/media/edit/the_beach.atom" />
</entry>

その後、クライアントはメディアリンクエントリの "edit-media" リンク関係で示される URI を用いて、新しい PNG 画像を含む PUT リクエストを送る:

PUT /edit/the_beach.png HTTP/1.1
Host: media.example.org
Content-Type: image/png
Authorization: Basic ZGFmZnk6c2VjZXJldA==
Content-Length: nnn

...binary data... 

サーバは 200 のステータスコードで編集成功を通知する。

HTTP/1.1 200 Ok
Date: Fri, 8 Oct 2006 17:17:11 GMT
 

クライアントは写真のメタデータを編集できる。はじめにメディアリンクエントリを GET する:

GET /media/edit/the_beach.atom HTTP/1.1
Host: example.org
Authorization: Basic ZGFmZnk6c2VjZXJldA==

メディアリンクエントリが返される。

HTTP/1.1 200 Ok 
Date: Fri, 7 Oct 2005 17:18:11 GMT
Content-Length: nnn
Content-Type: application/atom+xml;type=entry;charset="utf-8"
ETag: "c181bb840673b5"  

<?xml version="1.0"?>
<entry xmlns="http://www.w3.org/2005/Atom">
  <title>The Beach</title>
  <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
  <updated>2005-10-07T17:17:08Z</updated>
  <author><name>Daffy</name></author>
  <summary type="text" />
  <content type="image/png"
     src="http://media.example.org/the_beach.png"/>
  <link rel="edit-media"
     href="http://media.example.org/edit/the_beach.png" />
  <link rel="edit"
     href="http://example.org/media/edit/the_beach.atom" />
</entry>

メタデータは更新できる。サマリを追加するこのケースでは、サーバに PUT する。

PUT /media/edit/the_beach.atom HTTP/1.1
Host: example.org
Authorization: Basic ZGFmZnk6c2VjZXJldA==
Content-Type: application/atom+xml;type=entry
Content-Length: nnn
If-Match: "c181bb840673b5"  

<?xml version="1.0"?>
<entry xmlns="http://www.w3.org/2005/Atom">
  <title>The Beach</title>
  <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
  <updated>2005-10-07T17:17:08Z</updated>
  <author><name>Daffy</name></author>
  <summary type="text">
      A nice sunset picture over the water.
  </summary>
  <content type="image/png"
     src="http://media.example.org/the_beach.png"/>
  <link rel="edit-media"
     href="http://media.example.org/edit/the_beach.png" />
  <link rel="edit"
     href="http://example.org/media/edit/the_beach.atom" />
</entry>

更新が成功した。

HTTP/1.1 200 Ok 
Date: Fri, 7 Oct 2005 17:19:11 GMT
Content-Length: 0 

複数のメディアリソースはコレクションに追加できる。

POST /edit/ HTTP/1.1
Host: media.example.org
Content-Type: image/png
Slug: The Pier 
Authorization: Basic ZGFmZnk6c2VjZXJldA==
Content-Length: nnn

...binary data... 

リソースの作成が成功した。

HTTP/1.1 201 Created
Date: Fri, 7 Oct 2005 17:17:11 GMT
Content-Length: nnn
Content-Type: application/atom+xml;type=entry;charset="utf-8"
Location: http://example.org/media/edit/the_pier.atom

<?xml version="1.0"?>
<entry xmlns="http://www.w3.org/2005/Atom">
  <title>The Pier</title>
  <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efe6b</id>
  <updated>2005-10-07T17:26:43Z</updated>
  <author><name>Daffy</name></author>
  <summary type="text" />
  <content type="image/png"
     src="http://media.example.org/the_pier.png"/>
  <link rel="edit-media"
     href="http://media.example.org/edit/the_pier.png" />
  <link rel="edit"
     href="http://example.org/media/edit/the_pier.atom" />
</entry>

クライアントは二つの新しいメディアリソースを参照するブログのエントリコレクションに新しい Atom エントリを作成できる。

POST /blog/ HTTP/1.1
Host: example.org
Content-Type: application/atom+xml;type=entry 
Slug: A day at the beach 
Authorization: Basic ZGFmZnk6c2VjZXJldA==
Content-Length: nnn

<?xml version="1.0"?>
<entry xmlns="http://www.w3.org/2005/Atom">
  <title>A fun day at the beach</title>
  <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6b</id>
  <updated>2005-10-07T17:40:02Z</updated>
  <author><name>Daffy</name></author>
  <content type="xhtml">
      <xhtml:div xmlns:xhtml="http://www.w3.org/1999/xhtml">
          <xhtml:p>We had a good day at the beach.
              <xhtml:img alt="the beach"
                  src="http://media.example.org/the_beach.png"/>
          </xhtml:p>
          <xhtml:p>Later we walked down to the pier.
              <xhtml:img  alt="the pier"
                  src="http://media.example.org/the_pier.png"/>
          </xhtml:p>
      </xhtml:div>
  </content>
</entry>

リソースの作成が成功した。

HTTP/1.1 200 Ok 
Date: Fri, 7 Oct 2005 17:20:11 GMT
Content-Length: nnn
Content-Type: application/atom+xml;type=entry;charset="utf-8"
Location: http://example.org/blog/atom/a-day-at-the-beach.atom

<?xml version="1.0"?>
<entry xmlns="http://www.w3.org/2005/Atom">
  <title>A fun day at the beach</title>
  <id>http://example.org/blog/a-day-at-the-beach.xhtml</id>
  <updated>2005-10-07T17:43:07Z</updated>
  <author><name>Daffy</name></author>
  <content type="xhtml">
      <xhtml:div xmlns:xhtml="http://www.w3.org/1999/xhtml">
          <xhtml:p>We had a good day at the beach.
              <xhtml:img alt="the beach"
                 src="http://media.example.org/the_beach.png"/>
          </xhtml:p>
          <xhtml:p>Later we walked down to the pier.
              <xhtml:img alt="the pier"
                 src="http://media.example.org/the_pier.png"/>
          </xhtml:p>
      </xhtml:div>
  </content>
  <link rel="edit"
    href="http://example.org/blog/edit/a-day-at-the-beach.atom"/>
  <link rel="alternate" type="text/html"
    href="http://example.org/blog/a-day-at-the-beach.html"/>
</entry>

返ってきたエントリは、作成された関連のある HTML ページを指している "alternate" の関係を持つ link を含んでいることに注意すること。

9.7 Slug ヘッダ

Slug は HTTP エンティティヘッダであり、コレクションに POST が行われるときのこのヘッダの存在は、これから作成されるエントリないしメディアリソースを参照するために通常使用される URI の一部としてそのヘッダの値を使ってほしい、というクライアントの要求を示す。

新しく作成されたリソースのメンバ URI を作るとき、サーバは Slug ヘッダの値を使ってもよい(MAY)。たとえば、最後の URI セグメントにその値の中の単語の一部、あるいはすべてを使う。また、atom:id を作成するとき、あるいはメディアリンクエントリのタイトルとしてその値を使ってもよい(MAY)(9.6 節参照)。

サーバは Slug エンティティヘッダを無視することを選択してもよい(MAY)。サーバはそれを使う前に、ヘッダの値を変えるかもしれない(MAY)。たとえば、サーバはある文字を取り除くか、あるいは強調されていない文字を強調された文字に置き換えるか、あるいは下線をスペースで置き換えるかもしれない。

9.7.1. Slug ヘッダ構文

Slug ヘッダの構文は [RFC2616] の 2.1 節で定義されている拡張 BNF 文法を使って定義される。

LWS      = <defined in Section 2.2 of [RFC2616]>
slugtext = %x20-7E | LWS
Slug     = "Slug" ":" *slugtext

フィールドの値は含まれる文字シーケンスの UTF-8 エンコーディングのパーセントエンコードされた値である(パーセントエンコーディングの定義は [RFC3986] の 2.1 節を参照。また、UTF-8 エンコーディングの定義は [RFC3629] を参照)。

実装ノート:文字シーケンスからフィールド値を生成するために、はじめに UTF-8 エンコーディングを使ってエンコードし、それから %20-24 と %26-7E の範囲以外の全てのオクテットをパーセントエンコーディングを使ってエンコードする(%25 が抜けているのは、%25 が "%" の ASCII エンコーディングだからである)。フィールド値を再構成するには、はじめにパーセントエンコーディングを戻し、それから結果のオクテットシーケンスに UTF-8 デコード処理を行う。

9.7.2 例

ユニコード文字 U+00E8 (グレイブアクセント記号のついた小文字のローマ字 e)を表現するためにパーセントエンコーディングを使った Slug ヘッダの例を示す:

POST /myblog/entries HTTP/1.1
Host: example.org
Content-Type: image/png
Slug: The Beach at S%C3%A8te
Authorization: Basic ZGFmZnk6c2VjZXJldA==
Content-Length: nnn

...binary data... 

エントリリソースの作成に適用した Slug ヘッダの例として 9.2.1 節を参照のこと。

10. コレクションの列挙

コレクションリソースはコレクションに含まれるメンバの IRI を含むエントリを持つ Atom フィード文書形式の表現を提供しなければならない(MUST)。 コレクションフィードと他の種類のフィードに差異はない。 一つのフィードが講読目的のための「公開」フィードとコレクションフィード の両方として振る舞うかもしれない。

フィード文書中のそれぞれのエントリは "edit" 関係(11.1 節参照)の atom:link 要素を持つべきである(SHOULD)。

返却された結果フィード中のエントリは その "app:edited" プロパティで、最も最近編集されたエントリが文書順で最 初にくるように順序付けられているべきである(SHOULD)。 app:edited の値は HTTP の Last-Modified: ヘッダと等価ではなく、 キャッシュされたレスポンスの新鮮さを決定するためには使えない。

クライアントは、返却結果フィード中の Atom エントリは エントリリソースの完全な表現だと仮定してはならない(MUST NOT)。 メンバエントリを編集する前にその URI を GET すべきである(SHOULD)。 エントリ取得時におけるキャッシュコントロール命令の影響についての議論は 9.5 節を参照のこと。

10.1 コレクションの部分的リスト

コレクションは非常に多くのリソースを含むことができる。 Web スパイダや Web ブラウザのようなクライアントは GET のレスポンスがコレクション中の全てのエントリを含んでいたら 苦しめられるかもしれない。 サーバでも同様にバンド幅を浪費し、レスポンス生成が処理できないくらいの時間がかかるかもしれない。 このような理由で、 サーバは コレクションへの GET リクエストに対して部分的なコレクションメンバと (存在すれば)次の部分的なフィードへのリンクを含むフィード文書を返すかもしれない(MAY)。 最初に返されるこのような部分的なリストは 最も最近編集されたメンバリソースを 含まなければならない(MUST)。 また、"href" 属性の値がコレクションの次の部分的なリストの URI である "next" 関係の atom:link を持たなければならない(MUST)。 この次の部分的なリストは 次に編集された時間が新しいメンバの集合(もし存在するなら続く部分的なリストの atom:link も)を 含むだろう。

"next" 関係に加えて、部分的なリストフィードは コレクション中のエントリの完全なリストを ナビゲートすることに利用できる "rel" 属性の値が "previous"、"fist"、"last" の link 要素を含むかもしれない(MAY)。

たとえば、 クライアントに メンバエントリのコレクションの URI "http://example.org/entries/go" が提供されると仮定しよう。 このサーバは十個以上のエントリを含んでいるフィード文書を生成しない方 針である。 このコレクションの Atom フィード文書は 最初の部分的な十件のリンクされたフィード文書 となる。 "first" 関係は 最初のフィード文書を参照し、 "last" 関係は最後のフィード文書を参照するだろう。 それぞれの文書内で、"next" と "previous" リンク関係はそれぞれ次にくる文書と前の文書を参照する。

<feed xmlns="http://www.w3.org/2005/Atom">
  <link rel="first"
        href="http://example.org/entries/go" />
  <link rel="next"
        href="http://example.org/entries/2" />
  <link rel="last"
        href="http://example.org/entries/10" />
  ...
</feed>

"http://example.org/entries/2" にある部分的なリストフィードの "previous" と "next" リンク要素は次のようになる。

<feed xmlns="http://www.w3.org/2005/Atom">
  <link rel="first"
        href="http://example.org/entries/go" />
  <link rel="previous"
        href="http://example.org/entries/go" />
  <link rel="next"
        href="http://example.org/entries/3" />
  <link rel="last"
        href="http://example.org/entries/10" />
  ...
</feed>

10.2 "app:edited" 要素

"app:edited" 要素は([RFC4287] で定義される)日付コンストラクトであり、 その内容はエントリが編集された最終時刻を示す。 もしエントリが編集されていなかったら、app:edited の内容で示される時刻 は作成時刻になる。 コレクション文書中の Atom エントリ要素は app:edited 要素を持つべきで ある(SHOULD)。Atom エントリ要素は一つより多くの app:edited 要素を含んでは ならない(MUST NOT)。

appEdited = element app:edited ( atomDateConstruct )

サーバはエントリリソースまたは関連付けられたメディアリソースが編集されるたびに この要素の値を変更するべきである(SHOULD)。

11. Atom フォーマットのリンク関係の拡張

11.1 "edit" リンク関係

本仕様では Atom レジストリのリンク関係に "edit" という値を追加する ([RFC4287] の 7.1 節参照)。 "edit" という値はhref 属性の値が編集できるメンバエントリの IRI であることを指定する。 atom:entry 中で出現したとき、href の IRI は そのエントリで表現されるリソースの読出し、更新、削除に使用できる。 atom:entry は一つより多くの "edit" リンク関係を含んではならない(MUST NOT)。

11.2 "edit-media" リンク関係

本仕様では Atom レジストリのリンク関係に "edit-media" という値を追加する ([RFC4287] の 7.1 節参照)。 atom:entry 中で出現したとき、href の IRI は そのエントリに関連付けられたメディアリソースの修正に使用できる。

atom:entry 要素はゼロ個以上の "edit-media" リンク関係を含むことができる(MAY)。 atom:entry 要素は 同じ "type" 属性と "hreflang" 属性の値を持った "rel" 属性の値が "edit-media" の atom:link 要素を複数含んではならない(MUST NOT)。 同じエントリ中の全ての "edit-media" リンク関係は同じリソースを参照する。 もしクライアントが一つのエントリ中で複数の "edit-media" リンク関係に遭遇したら、 "type" と "hreflang" のクライアントの設定でリンクを選択すべきである(SHOULD)。 もしクライアントが一つのエントリ中で複数の "edit-media" リンク関係に遭 遇し、"type" と "hreflang" の設定を持たなかったら クライアントは文書順で最初の "edit-media" リンク関係を選択すべきである(SHOULD)。

12. Atom フォーマット type パラメタ

Atom 配信フォーマット [RFC4287] は Atom フィードと Atom エントリ文書を識別するための "application/atom+xml" メディアタイプを定義する。 これまでの実装経験から Atom フィードとエントリ文書は異った処理モデルを持つことができ、 二つを区別することが必要な状況がある ということが実証されている。 本仕様では、この二つのタイプの Atom 文書を区別するために利用される 任意の "type" パラメタを定義する。

12.1 "type" パラメタ

本仕様は "application/atom+xml" メディアタイプと共に利用できる "type" という新 しいパラメタを定義する。 "type" パラメタは値として "entry" または "feed" を持つ。

パラメタ名も値も大文字小文字を区別しない。

"entry" という値はそのメディアタイプが Atom エントリ文書を識別することを示す。 その文書のルート要素は atom:entry でなければならない(MUST)。

"feed" という値はそのメディアタイプが Atom フィード文書を識別することを示す。 その文書のルート要素は atom:feed でなければならない(MUST)。

指定されない場合は、 そのタイプは不明であると仮定され、 Atom プロセッサに Atom 文書のタイプを決定するために文書のルート要素を分析することを要求する。

12.1.1 適合性

新しい仕様では "type" パラメタを Atom 文書タイプを識別するために使用するよう要求するかもしれない(MAY)。 Atom エントリ文書の提供者は 義務があるかどうかにかかわらず "type" パラメタを使うべきである(SHOULD)。 Atom フィード文書の提供者は "type" パラメタを使うかもしれない(MAY)。

"type" パラメタを認識しない Atom プロセッサは その値を無視し、文書タイプを決定するためにルート要素を調べなければならない(MUST)。

"type" パラメタを認識する Atom プロセッサは type パラメタの値と実際の文書のルート要素の型の 不一致を検知しレポートするべきである(SHOULD)。

13. Atom 出版制御

本仕様では、出版制御のために、 [RFC4287] の6節で定義される Atom フォーマットの構造化拡張を "http://www.w3.org/2007/app" の名前空間で定義する。

13.1 "app:control" 要素

namespace app = "http://www.w3.org/2007/app"

pubControl =
   element app:control {
   atomCommonAttributes,
   pubDraft?
   & extensionElement
}
pubDraft =
  element app:draft { "yes" | "no" }

"app:control" 要素は Atom 出版プロトコルを使って作成または更新される atom:entry の子要素として出現するかもしれない(MAY)。 app:control 要素は一つのエントリ中で必ず一つだけ出現しなければならない(MUST)。 app:control 要素は [RFC4287] の6節で定義される外部マークアップと考えられる。

app:control 要素とその子要素は Atom フィードまたはエントリ文書に含まれるかもしれない。

app:control 要素は以下で定義される "app:draft" 要素一つと、 [RFC4287] の6節で定義される拡張要素を含むことができる。

13.1.1 "app:draft" 要素

"app:draft" 要素の包含は、クライアントによる メンバリソースの可視性の制御の要求を現わす。 app:draft 要素はサーバによって無視されるかもしれない。

app:control 要素中の app:draft 要素の数はゼロまたは1である。 app:draft 要素の内容は "yes" または "no" でなければならない(MUST)。 もし要素が "no" を含んでいたら、 これはクライアントがメンバリソースを公然と公開することを要求していることを示す。 もし app:draft 要素が出現しない場合は、 この拡張をサポートするサーバは app:draft 要素が "no" を含んで送信されたもの として振る舞わなければならない(MUST)。

14. Atom 出版プロトコルのセキュリティ

Atom 出版プロトコルは HTTP を基盤としている。 HTTP のための認証要求は [RFC2616] の 11 節で取り上げられている。

不明であったり、権限を与えられていないクライアントによる POST や編集を避けるため、認証メカニズムを使用することが推奨されている (RECOMMENDED) が要求されてはいない。認証を用いない場合、クライアントとサーバは、なりすまし、サービス拒否、改ざんといった攻撃を受けやすい。しかしながら状況によっては、許容できるリスクである場合もある。

配備される認証の種類はサーバ運営者に依存する。クライアントは、サーバ構成によって変化する認証スキームの問題に直面することになる。最小限、クライアントとサーバの実装は、HTTP Basic 認証 [RFC2617] と、 [RFC2818] で記述されている HTTP 上で TLS を用いる規約をサポートする TLS 1.0 またはその後継バージョン(たとえば[RFC4346])を用いた接続とを併用する設定ができなくてはならない (MUST) 。

認証メカニズムの選択は相互運用性に影響を与える。前述の最小レベルのセキュリティ ( TLS と Basic 認証の併用) は、本仕様の発行時におけるインターネットアプリケーションの場合には良い慣習であると考えられ、かつ、相互運用性のための基準を確立する上で十分である。実装者は、配備時に等価もしくはそれ以上と見なされる代替メカニズムを調査して使用することが期待される。クライアント側は、配備可能な新しい認証スキームで実装されることが推奨される (RECOMMENDED) 。

本プロトコルは HTTP 応答ステータスコードをリクエスト結果を報告するための基本的な手段として用いるため、サーバは、権限が無い、もしくは認証に失敗したリクエストに対して適切な 4xx HTTP レスポンスコードをレスポンスとして返すとよい。

15. セキュリティについての考慮事項

Atom 出版プロトコルは HTTP を基盤とするため、 [RFC2616] の 15 節で示されているセキュリティについての考慮事項に従う。

本節で列挙する脅威は HTTP 上で動作する多くのプロトコルにあてはまる。 Atompub ワーキンググループは、(14 節で説明した) TLS 接続で認証された HTTP を実行することで得られる防御は、本節中で列挙する攻撃によって発生する問題の多くを軽減する上で十分であると判断した。

15.1 サービス拒否

Atom 出版プロトコルのサーバ実装は、悪意のあるクライアントが過度にサーバリソース (CPU 、メモリ、ディスク等) を消費できないことを確実にするために、適切な予防策を講じる必要がある。

15.2 リプレイ攻撃

Atom 出版プロトコルのサーバ実装はリプレイ攻撃の影響を受けやすい。特に、本仕様は二重リクエストの検知方法を定義しない。偶然による二重リクエスト送信は、故意や悪意のあるリプレイ攻撃との区別ができない。

15.3 なりすまし攻撃

Atom 出版プロトコルの実装は様々ななりすまし攻撃の影響を受けやすい。悪意のあるクライアントは、文書中の任意の場所に不正な情報を含めた Atom エントリを送信する可能性がある。

15.4 リンクされたリソース

Atom フィード文書とエントリ文書は [REC-xml] の 4.2.2 節で定義される XML 外部実体を含むことができる。 Atom 実装は、外部実体をロードすることを要求されない。外部実体は、任意のネットワーク操作と同様にセキュリティ上の懸念事項であり、 Atom 文書のセマンティクスを改ざんすることが可能である。 atom:link や atom:content 等の Atom 要素によってリンクされたリソースにも同様の問題が存在する。

15.5 デジタル署名と暗号化

Atom エントリ文書とフィード文書は、 XML デジタル署名 [REC-xmldsig-core] を含んだり、[RFC4287] の 5 節で定義されている XML 暗号 [REC-xmlenc-core] を用いて暗号化されていても構わない。 Atom 文書中の署名と暗号化された要素の扱いについては、 [RFC4287] の 5 節と 6.3 節で議論されている。

サーバとクライアントのいずれも、エントリやフィードの暗号化やデジタル署名をサポートする義務はないが、インストール先によっては、クライアント又はサーバが Atom プロトコルで交換される文書を署名または暗号化することを要求される可能性は確かに存在する。

なぜならサーバは、エントリ文書を出版する前にその内容を修正する事が許される(そしていくつかの場合では期待される)ので、エントリ中の署名は、エントリを送りつけられたサーバにとってだけ有益なものになる可能性がある。クライアントは第三者が見たときに、あるいはたとえサーバがクライアントの署名を出版するとしても、署名が妥当であると仮定することはできない。

サーバは、クライアントが適用した署名をはがしたり、はがした後に公開鍵で再署名したり、エントリに対してさらに公開鍵で署名したりすることが許される。第三者にとって、サーバによって適用された署名は、[RFC4287] で示される様に、他の誰かからの署名と同じ意味である。正当なものである事を検証できない署名に対して第三者が翻訳を試みるのを避けるために、クライアントによって署名されたあるエントリ文書の一部が変更されたことに気がついているサーバは、エントリを出版する前に署名をはがすことが推奨される (RECOMMENDED) 。

15.6 URI と IRI

Atom 出版プロトコル実装は URI と IRI を処理する。これらの処理と利用に関連したセキュリティについての考慮事項は [RFC3986] の 7 節と [RFC3987] の 8 節を参照のこと。

Atom 出版プロトコルは、URI の生成に関する制御はサーバに委ねている。新しい URI を生成する事を目的としてクライアントから得たデータを用いることは、それがいかなるデータであれ、次節で述べられる考慮事項と同様のことを考える必要がある。

15.7 コードインジェクションとクロスサイトスクリプティング

Atom フィード文書とエントリ文書は、同一コンテクストで実行可能なコードを含む様々な種類のコンテンツを含むことができる。悪意のあるクライアントがコレクション文書のエントリまたはメディアリソースにコードを挿入することによって、サーバや他のクライアントに対して攻撃を試みることもあり得る。

サーバ実装は、クライアントが提供したコンテンツが安全であることを、コンテンツを受理したり、処理・出版する前に検証することが強く推奨される。

XHTML と HTML コンテンツの安全性に関する更なる情報については [RFC4287] の 8.1 節を参照のこと。

16. IANAについての考慮事項

本仕様は、[RFC4288] で述べられている登録メカニズムに従った二つの新しいメディアタイプ、[RFC3864] で述べられている登録メカニズムに従った新しいメッセージヘッダ、そして [RFC4287] で述べられている登録メカニズムに従った二つの新しいリンク関係を使用する。

16.1 'application/atomcat+xml' の Content-Type 登録

Atom 出版プロトコルカテゴリ文書は、XML 1.0 でシリアライズされる時、以下のメディアタイプで識別され得る:

MIME メディアタイプ名:
application
MIME サブタイプ名:
atomcat+xml
必須パラメータ:
なし。
オプションパラメータ:
"charset":
このパラメータは、[RFC3023] で規定される "application/xml" メディアタイプの charset パラメータを識別する意味を持つ。
エンコーディングに関する考慮事項:
[RFC3023] の 3.2 節で述べられている "application/xml" と同様。
セキュリティに関する考慮事項:
RFC 5023 で定義される 加えて、本メディアタイプは "+xml" 規約を用いるので、 [RFC3023] の 10 節中で示されるものと同じセキュリティに関する考慮事項を共有する。
相互運用性に関する考慮事項:
相互運用性に関する既知の課題はない。
公開された仕様:
RFC 5023
本メディアタイプを使うアプリケーション:
現在、本メディアタイプを用いる既知のアプリーケーションは存在しない。
追加情報:
マジックナンバー:
[RFC3023] の 3.2 節で "application/xml" について定める通りとする。
ファイル拡張子:
.atomcat
フラグメント識別子:
[RFC3023] の 5 節で "application/xml" について定める通りとする。
ベース URI:
[RFC3023] の 6 節で定める通りとする。
Macintosh ファイルタイプコード:
TEXT
詳細な情報に関する問い合わせ先の名前とメールアドレス:
Joe Gregorio <joe@bitworking.org>
意図する使用法:
一般的
著者 / 変更制御者:
IETF (iesg@ietf.org) Internet Engineering Task Force

16.2 'application/atomsvc+xml' の Content-Type 登録

Atom 出版プロトコルサービス文書は、XML 1.0 でシリアライズされる時、以下のメディアタイプで識別され得る:

MIME メディアタイプ名:
application
MIME サブタイプ名:
atomsvc+xml
必須パラメータ:
なし。
オプションパラメータ:
"charset":
このパラメータは、[RFC3023] で規定される "application/xml" メディアタイプの charset パラメータを識別する意味を持つ。
エンコーディングに関する考慮事項:
[RFC3023] の 3.2 節で述べられている "application/xml" と同様。
セキュリティに関する考慮事項:
RFC 5023 で定義される。 加えて、本メディアタイプは "+xml" 規約を用いるので、 [RFC3023] の 10 節中で示されるものと同じセキュリティに関する考慮事項を共有する。
相互運用性に関する考慮事項:
相互運用性に関する既知の課題はない。
公開された仕様:
RFC 5023
本メディアタイプを使うアプリケーション:
現在、本メディアタイプを用いる既知のアプリーケーションは存在しない。
追加情報:
マジックナンバー:
[RFC3023] の 3.2 節で "application/xml" について定める通りとする。
ファイルの拡張子:
.atomsvc
フラグメント識別子:
[RFC3023] の 5 節で "application/xml" について定める通りとする。
ベース URI:
[RFC3023] の 6 節で定める通りとする。
Macintosh ファイルタイプコード:
TEXT
詳細な情報に関する問い合わせ先の名前とメールアドレス:
Joe Gregorio <joe@bitworking.org>
意図する使用法:
一般的
著者 / 変更制御者:
IETF (iesg@ietf.org) Internet Engineering Task Force

16.3 'SLUG' のヘッダ属性登録

ヘッダフィールド名:
SLUG
利用可能なプロトコル:
http [RFC2616]
ステータス:
標準。
著者 / 変更制御者:
IETF (iesg@ietf.org) Internet Engineering Task Force
仕様書:
RFC 5023

関連情報:

16.4 "edit" リンク関係の登録

属性値:
edit
説明:
編集可能なメンバエントリの URI 。 atom:entry 中に出現する時、その href 属性で表される IRI は、そのエントリによって表現されるリソースを取得、更新または削除するために用いることができる。
期待される表示上の特徴:
未定義; この関係は、バックグラウンド処理のため、または値を表示しない拡張機能を提供するために用いることができる。
セキュリティに関する考慮事項:
自動化されたエージェントは、この関係が複数の管理領域を横断する場合(例えば、 URI が現在の文書のものとは異なる権限を持つ場合)に注意すべきである。

16.5 "edit-media" リンク関係の登録

属性値:
edit-media
説明:
編集可能なメディアリソースの URI 。 atom:entry 中に出現する時、その href 属性で表される IRI は、そのエントリに関連のあるメディアリソースを取得、更新または削除するために用いることができる。
期待される表示上の特徴:
未定義; この関係は、バックグラウンド処理のため、または値を表示しない拡張機能を提供するために用いることができる。
セキュリティに関する考慮事項:
自動化されたエージェントは、この関係が複数の管理領域を横断する場合(例えば、 URI が現在の文書のものとは異なる権限を持つ場合)に注意すべきである。

16.6 Atomフォーマットのメディアタイプパラメータ

IANA は 'application/atom+xml' メディアタイプの登録情報に、本仕様へのリファレンスを追加した。

17. 文献

17.1 引用文献

[REC-xml] Yergeau, F., Paoli, J., Bray, T., Sperberg-McQueen, C., and E. Maler, "Extensible Markup Language (XML) 1.0 (Fourth Edition)", World Wide Web Consortium Recommendation REC-xml-20060816, August 2006, <http://www.w3.org/TR/2006/REC-xml-20060816>.
[REC-xml-infoset] Cowan, J. and R. Tobin, "XML Information Set (Second Edition)", World Wide Web Consortium Recommendation REC-xml-infoset-20040204, February 2004, <http://www.w3.org/TR/2004/REC-xml-infoset-20040204>.
[REC-xml-names] Hollander, D., Bray, T., Tobin, R., and A. Layman, "Namespaces in XML 1.0 (Second Edition)", World Wide Web Consortium Recommendation REC-xml-names-20060816, August 2006, <http://www.w3.org/TR/2006/REC-xml-names-20060816>.
[REC-xmlbase] Marsh, J, "XML Base", W3C REC W3C.REC-xmlbase-20010627, June 2001. <http://www.w3.org/TR/2001/REC-xmlbase-20010627>
[REC-xmldsig-core] Solo, D., Reagle, J., and D. Eastlake, "XML-Signature Syntax and Processing", World Wide Web Consortium Recommendation REC-xmldsig-core-20020212, February 2002, <http://www.w3.org/TR/2002/REC-xmldsig-core-20020212>.
[REC-xmlenc-core] Eastlake, D. and J. Reagle, "XML Encryption Syntax and Processing", World Wide Web Consortium Recommendation REC-xmlenc-core-20021210, December 2002, <http://www.w3.org/TR/2002/REC-xmlenc-core-20021210>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2617] Franks, J., Hallam-Baker, P.M., Hostetler, J.L., Lawrence, S.D., Leach, P.J., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[RFC4287] Nottingham, M. and R. Sayre, "The Atom Syndication Format", RFC 4287, December 2005.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.

17.2 参考文献

[NOTE-detect-lost-update] Nielsen, H.F. and D. LaLiberte, "Editing the Web: Detecting the Lost Update Problem Using Unreserved Checkout", World Wide Web Consortium NOTE NOTE-detect-lost-update, May 1999, <http://www.w3.org/1999/04/Editing/>.
[REC-webarch] Walsh, N and I Jacobs, "Architecture of the World Wide Web, Volume One", W3C REC REC-webarch-20041215, December 2004, <http://www.w3.org/TR/2004/REC-webarch-20041215>.
[RNC] Clark, J., "RELAX NG Compact Syntax", December 2001, <http://www.oasis-open.org/committees/relax-ng/compact-20021121.html>.

A. 貢献者

このコンテンツとコンセプトは Atom コミュニティと Atompub ワーキンググループの成果である。

B. RELAX NG コンパクトスキーマ

この付録は参考である。

Relax NG スキーマは この仕様のこのバージョンで定義されていない Atom プロトコル名前空間の要素を明示的に除外する。 Atom プロトコルプロセッサがそのようなマークアップを読み込んだ場合の要求は [RFC4287] の 6.2 節と 6.3 節にある。

サービス文書のスキーマ:

  # -*- rnc -*-
  # Atom プロトコルの RELAX NG Compact Syntax Grammar
  
  namespace app = "http://www.w3.org/2007/app"
  namespace atom = "http://www.w3.org/2005/Atom"
  namespace xsd = "http://www.w3.org/2001/XMLSchema"
  namespace xhtml = "http://www.w3.org/1999/xhtml"
  namespace local = ""
  
  start = appService
  
  # common:attrs
  
  atomURI = text
  
  appCommonAttributes =
     attribute xml:base { atomURI }?,
     attribute xml:lang { atomLanguageTag  }?,
     attribute xml:space {"default"|"preserved"}?,
     undefinedAttribute*
  
  
  atomCommonAttributes = appCommonAttributes
  
  undefinedAttribute =
    attribute * - (xml:base | xml:space  | xml:lang | local:*) { text } 
  
  atomLanguageTag = xsd:string {
     pattern = "([A-Za-z]{1,8}(-[A-Za-z0-9]{1,8})*)?"
  } 
  
  atomDateConstruct =
      appCommonAttributes,
      xsd:dateTime
  
  # app:service
  
  appService =
     element app:service {
        appCommonAttributes,
        ( appWorkspace+
          & extensionElement* )
     }
  
  # app:workspace
  
  appWorkspace =
     element app:workspace {
        appCommonAttributes,
        ( atomTitle
          & appCollection*
          & extensionSansTitleElement* )
     }
  
  atomTitle = element atom:title { atomTextConstruct }
  
  # app:collection
  
  appCollection =
     element app:collection {
        appCommonAttributes,
        attribute href { atomURI  },
        ( atomTitle
          & appAccept*
          & appCategories*
          & extensionSansTitleElement* )
     }
  
  # app:categories
  
  atomCategory =
      element atom:category {
         atomCommonAttributes,
         attribute term { text },
         attribute scheme { atomURI }?,
         attribute label { text }?,
         undefinedContent
      }
  
  appInlineCategories =
      element app:categories {
          attribute fixed { "yes" | "no" }?,
          attribute scheme { atomURI }?,
          (atomCategory*,
          undefinedContent)
      }
  
  appOutOfLineCategories =
      element app:categories {
          attribute href { atomURI },
          undefinedContent
      }
  
  appCategories = appInlineCategories | appOutOfLineCategories
  
  # app:accept
  
  appAccept =
     element app:accept {
           appCommonAttributes,
           ( text? )
     }
  
   # 単純な拡張
  
  simpleSansTitleExtensionElement =
     element * - (app:*|atom:title) {
        text
     }

  
  simpleExtensionElement =
     element * - (app:*) {
        text
     }
  
  
  # 構造化された拡張
  
  structuredSansTitleExtensionElement =
     element * - (app:*|atom:title) {
        (attribute * { text }+,
           (text|anyElement)*)
      | (attribute * { text }*,
         (text?, anyElement+, (text|anyElement)*))
     }
  
  structuredExtensionElement =
     element * - (app:*) {
        (attribute * { text }+,
           (text|anyElement)*)
      | (attribute * { text }*,
         (text?, anyElement+, (text|anyElement)*))
     }
  
  # その他の拡張性
  
  extensionSansTitleElement =
   simpleSansTitleExtensionElement|structuredSansTitleExtensionElement
  
  
  extensionElement =
     simpleExtensionElement | structuredExtensionElement
  
  undefinedContent = (text|anyForeignElement)*
  
  # 拡張
  
  anyElement =
     element * {
        (attribute * { text }
         | text
         | anyElement)*
     }
  
  anyForeignElement =
      element * - app:* {
         (attribute * { text }
          | text
          | anyElement)*
      }
  
  atomPlainTextConstruct =
      atomCommonAttributes,
      attribute type { "text" | "html" }?,
      text 
  
  atomXHTMLTextConstruct =
      atomCommonAttributes,
      attribute type { "xhtml" },
      xhtmlDiv
  
  atomTextConstruct = atomPlainTextConstruct | atomXHTMLTextConstruct
  
  anyXHTML = element xhtml:* {
      (attribute * { text }
       | text
       | anyXHTML)*
  }
  
  xhtmlDiv = element xhtml:div {
    (attribute * { text }
     | text
     | anyXHTML)*
  }
  
  # EOF

カテゴリ文書のスキーマ:

  # -*- rnc -*-
  # Atom プロトコルの RELAX NG Compact Syntax Grammar
  
  namespace app = "http://www.w3.org/2007/app"
  namespace atom = "http://www.w3.org/2005/Atom"
  namespace xsd = "http://www.w3.org/2001/XMLSchema"
  namespace local = ""
  
  start = appCategories
  
  atomCommonAttributes =
     attribute xml:base { atomURI }?,
     attribute xml:lang { atomLanguageTag }?,
     undefinedAttribute*
  
  undefinedAttribute =
    attribute * - (xml:base | xml:lang | local:*) { text }
  
  atomURI = text
  
  atomLanguageTag = xsd:string {
     pattern = "([A-Za-z]{1,8}(-[A-Za-z0-9]{1,8})*)?"
  }
  
  
  atomCategory =
      element atom:category {
         atomCommonAttributes,
         attribute term { text },
         attribute scheme { atomURI }?,
         attribute label { text }?,
         undefinedContent
      }
  
  appInlineCategories =
      element app:categories {
          attribute fixed { "yes" | "no" }?,
          attribute scheme { atomURI }?,
          (atomCategory*,
          undefinedContent)
      }
  
  appOutOfLineCategories =
      element app:categories {
          attribute href { atomURI },
          (empty)
      }
  
  appCategories = appInlineCategories | appOutOfLineCategories
  
  
  # 拡張性
  
  undefinedContent = (text|anyForeignElement)*
  
  anyElement =
     element * {
        (attribute * { text }
         | text
         | anyElement)*
     }
  
  anyForeignElement =
      element * - atom:* {
         (attribute * { text }
          | text
          | anyElement)*
      }
  
  # EOF

著者の連絡先

Joe Gregorio (editor)
Google
EMail:
URI: http://bitworking.org/
Bill de hOra (editor)
NewBay Software
EMail:
URI: http://dehora.net/

著作権の全文の表示

Copyright (C) The IETF Trust (2007).

この文書は、BCP 78 に含まれる権利、許可、制限に従い、その中で明示されるものを除いて、著者が全ての権利を保持する。

この文書とここに含まれる情報は、"あるがまま(AS IS)" である事をもとに提供され、投稿者や、(もしいるならば) その人物が代表する、あるいはその人物を後援する組織、インターネット学会、及び IETF は、明示的にも暗黙的にも、この情報の利用が、商用利用及び特定用途においていかなる権利もいかなる暗黙的保証も侵害していないという保証への制限を含め、全ての保証を放棄する。

知的財産

IETF は、この文書内に記述された技術の実装や使用に付随して主張されるいかなる知的所有権あるいは他の権利の正当性や範囲に関して、あるいはその様な権利の下でいかなる許可が利用可能であり、また利用不可能であるかの範囲に関して、いかなる立場も取らない。すなわち、そのような権利を識別するためのいかなる独立的調査を行った事も明言しない。 IETF 文書内の権利に関する IETF の手続き上の情報は、BCP 78BCP 79 にある。

IETF 事務局による知的所有権の開示のコピーや、利用可能とされるようなライセンスの保証や、この仕様書の実装者や利用者によってそのような所有者の権利の使用のために一般的なライセンスや許可を得るためになされた試みの結果は、http://www.ietf.org/ipr にある IETF オンライン IPR リポジトリから得る事ができる。

IETF は、この標準を実装するために必要な技術をカバーするためのあらゆる著作権、特許、特許の出願、あるいは他の所有権について明らかにする事に興味を持つ団体を募集している。IETFのietf-ipr@ietf.orgにその情報をお寄せいただきたい。