Network Working Group
Request for Comments: 4287
Category: Standards Track
M. Nottingham, Ed.
     R. Sayre, Ed.
     December 2005

Atom配信フォーマット

このメモの状態

この文章はインターネットコミュニティのためのインターネット標準化過程プロトコルを規定し、改良のための議論と提案を求めるものです。標準化状態とこのプロトコルの状態については"Internet Official Protocol Standards" (STD 1) の最新版を参照してください。このメモの配布は自由です。

著作権表示

Copyright (C) The Internet Society (2005).

概要

この文章は、XMLベースのウェブコンテンツでありメタデータ配信フォーマットであるAtomを規定します。

目次

1. はじめに

Atomは"フィード"として知られる関連する情報のリストを記述するXMLベースの文章フォーマットです。 フィードは、"エントリー"として知られるいくつかの項目で構成され、それぞれメタデータに対応した拡張可能なセットとともに構成されます。例えば、各エントリーは1つのタイトルを持っています。

Atomの主な用途として、ウェブログやニュースのヘッドラインのようなウェブコンテンツの配信を、直接ユーザエージェントに向けてだけではなく、ウェブサイトに対しても配信することが挙げられます。

1.1. 例

1つのエントリーからなる、簡単なAtomフィード文章は次のようになります。

   <?xml version="1.0" encoding="utf-8"?>
   <feed xmlns="http://www.w3.org/2005/Atom">

     <title>Example Feed</title>
     <link href="http://example.org/"/>
     <updated>2003-12-13T18:30:02Z</updated>
     <author>
       <name>John Doe</name>
     </author>
     <id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id>

     <entry>
       <title>Atom-Powered Robots Run Amok</title>
       <link href="http://example.org/2003/12/13/atom03"/>
       <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
       <updated>2003-12-13T18:30:02Z</updated>
       <summary>Some text.</summary>
     </entry>

   </feed>

1つのエントリーからなる、拡張したAtomフィード文章は次のようになります。

   <?xml version="1.0" encoding="utf-8"?>
   <feed xmlns="http://www.w3.org/2005/Atom">
     <title type="text">dive into mark</title>
     <subtitle type="html">
       A <em>lot</em> of effort
       went into making this effortless
     </subtitle>
     <updated>2005-07-31T12:29:29Z</updated>
     <id>tag:example.org,2003:3</id>
     <link rel="alternate" type="text/html"
      hreflang="en" href="http://example.org/"/>
     <link rel="self" type="application/atom+xml"
      href="http://example.org/feed.atom"/>
     <rights>Copyright (c) 2003, Mark Pilgrim</rights>
     <generator uri="http://www.example.com/" version="1.0">
       Example Toolkit
     </generator>
     <entry>
       <title>Atom draft-07 snapshot</title>
       <link rel="alternate" type="text/html"
        href="http://example.org/2005/04/02/atom"/>
       <link rel="enclosure" type="audio/mpeg" length="1337"
        href="http://example.org/audio/ph34r_my_podcast.mp3"/>
       <id>tag:example.org,2003:3.2397</id>
       <updated>2005-07-31T12:29:29Z</updated>
       <published>2003-12-13T08:29:29-04:00</published>
       <author>
         <name>Mark Pilgrim</name>
         <uri>http://example.org/</uri>
         <email>f8dy@example.com</email>
       </author>
       <contributor>
         <name>Sam Ruby</name>
       </contributor>
       <contributor>
         <name>Joe Gregorio</name>
       </contributor>
       <content type="xhtml" xml:lang="en"
        xml:base="http://diveintomark.org/">
         <div xmlns="http://www.w3.org/1999/xhtml">
           <p><i>[Update: The Atom draft is finished.]</i></p>
         </div>
       </content>
     </entry>
   </feed>

1.2. 名前空間とバージョン

本仕様書において、XMLデータフォーマット用のXML名前空間URI[W3C.REC-xml-names-19990114]は次のとおりです。

   http://www.w3.org/2005/Atom

便宜上、このデータフォーマットは"Atom 1.0"として参照されるかもしれません。本仕様書では、単に"Atom"として取り扱います。

1.3. 表記について

本仕様書は、Atomフィード文書とAtomエントリー文書の2つの構造体を使って適合性を説明します。加えて、Atomプロセッサにおけるいくつかの要求を出します。

本仕様書は、上記の1.2節におけるXML名前空間URIによって区別された、名前空間接頭辞"atom:"を使用します。 名前空間接頭辞の選択は任意であり、セマンティックな意味はないことに注意してください。

AtomはXML情報セット[W3C.REC-xml-infoset-20040204]に基づいた用語の使用を規定します。 しかしながら、本仕様書は2つの共通用語の簡略した表現、すなわち、要素情報項目と属性情報項目を記述するときに情報項目 (information item) は省略します。 従って、本仕様書が「要素」という用語を用いる場合、情報項目における要素情報項目を参照しています。同様に、「属性」という用語を用いる場合、情報項目における属性情報項目を参照しています。

本仕様書のいくつかの節は規範的でないRELAX NG[RELAX-NG]短縮スキーマの断片とともに説明されます。しかしながら、この仕様のテキストは一致した定義を与えます。完全なスキーマは付録Bに表します。

この文章におけるキーワードMUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, OPTIONALは適合範囲においてBCP14 [RFC2119]に記述されているとおりに解釈されるものとします。

2. Atom文章

本仕様書はAtomフィード文章とAtomエントリー文章の2種類のAtom文章を解説します。

Atomフィード文章は、フィードについてのメタデータとそれに関連するエントリーを含むAtomフィードを表したものです。Atomフィード文章のルートはatom:feed要素です。

Atomエントリー文章はAtomフィードのコンテキストの外側で、厳密に1つのAtomエントリーを表します。Atomエントリー文章のルート要素はatom:entryです。

   namespace atom = "http://www.w3.org/2005/Atom"
   start = atomFeed | atomEntry

どちらの種類のAtom文章もXML情報セットによって規定され、XML 1.0 [W3C.REC-xml-20040204]として取り扱われ、application/atom+xmlメディアタイプとして識別されます。Atom文章は整形式のXMLでなければなりません[MUST]。本仕様書はAtom文章用のDTDを定義しないために、Atom文章が(XMLで使われるという意味において)妥当であることを要求しません。

AtomはIRI [RFC3987]の使用を認めます。全てのURI [RFC3986] はIRIでもあるために、よってURIはどこでも、IRIが名前付けされた下で用いられても構いません。2つの特別な考慮すべきことがあります。(1)IRIがURIでもなく、間接参照として与えられたとき、IRIは[RFC3987]の3.1節の手順を用いてURIに変換されなければなろません[MUST]。(2)IRIがatom:idの値として出現したときに変換されてはなりません[MUST NOT]。これは、4.2.6.1節に説明されたものと同様な動作をするためです。

本仕様書によって定義される全ての要素はxml:base属性 [W3C.REC-xmlbase-20010627]を持つことができます[MAY]。xml:baseがAtom文章で用いられたとき、xml:baseは[RFC3986]の5.1.1節で解説された機能を提供し、全ての相対参照を解決するためにxml:base属性の有効な範囲内で基底URI(またはIRI)を確立します。

本仕様書によって定義された全ての要素は、xml:lang属性を持つことができます[MAY]。xml:lang属性の値はその要素と下位要素の自然言語を明示するものです。 その言語コンテキストは、本仕様書で"言語依存性がある"と宣言された要素と属性にとって重要です。値やxml:langの解釈に関しての要求はXML 1.0の[W3C.REC-xml-20040204] 2.12節で詳細が述べられています。

   atomCommonAttributes =
      attribute xml:base { atomUri }?,
      attribute xml:lang { atomLanguageTag }?,
      undefinedAttribute*

Atomは拡張可能なフォーマットです。Atom文章の拡張方法についての完全な説明は本仕様書の6節を参照してください。

Atomプロセッサは、入手したAtomフィード文書の状態の維持しても構いませんし[MAY]、フィードのコンテンツの連続的な表示を容易にするために、1つのAtomフィード文書を他のAtomフィード文章と結合しても構いません[MAY]。 Atomフィード文章がフィードを再構築するために結合する(例えば、エントリーとメタデータを更新し、欠損したエントリーを扱う)方法は本仕様書の範囲外です。

3. 共通のAtom構文

Atomの要素の多くは共通構文を共有することがあります。 この節は、適切な要素定義によって、都合のよい参照のための、共通構文の構造と要求を定義します。

ある要素が特定の種類の構文として識別されるとき、この節ではその要素は構文の定義から一致する要求を継承します。

Date構文やIRIにおいて、いかなる空白文字も存在してはならない[MUST NOT]ことに注意してください。いくつかのXMLジェネレーターの実装はデフォルトで値の周りに空白文字を誤って挿入し、妥当でないAtom文章を出力することがあります。

3.1. Text 構文

Text構文は通常少量の、人間可読なテキストを含みます。Text構文の内容は言語依存性があります。

   atomPlainTextConstruct =
      atomCommonAttributes,
      attribute type { "text" | "html" }?,
      text

   atomXHTMLTextConstruct =
      atomCommonAttributes,
      attribute type { "xhtml" },
      xhtmlDiv

   atomTextConstruct = atomPlainTextConstruct | atomXHTMLTextConstruct

3.1.1. type属性

Text構文はtype属性を持つことが出来ます[MAY]。現在、その値はtext,html,xhtmlのいずれか1つでなければなりません[MUST]。type属性が与えられないならば、Atomプロセッサは属性値をtextを持つものとして振舞わなければなりません[MUST]。4.1.3節で定義されているatom:content要素とは異なり、MIMEメディアタイプ[MIMEREG]がText構文においてtype属性のために用いられてはなりません[MUST NOT]。

3.1.1.1. text

atom:titleがtextを含む場合の例を示します。

   ...
   <title type="text">
     Less: &lt;
   </title>
   ...

type属性値がtextの場合、Text構文の内容が子要素を含んではなりません[MUST NOT]。そのようなtextは人間に可読な型として提供されることを意味します。したがって、Atomプロセッサは(改行を含む)空白をまとめたり、行末揃えやプロポーショナルフォントといった印刷技術を用いて文章を表示しても構いません[MAY]。

3.1.1.2. HTML

atom:titleがHTMLを含む場合の例を示します。

   ...
   <title type="html">
     Less: <em> &amp;lt; </em>
   </title>
   ...

type属性値がhtmlの場合、Text構文の内容は子要素を含んではならず[MUST NOT]、HTML[HTML]として適した取り扱いをすべきです[SHOULD]。全てのマークアップは例えば"&lt;br>"を"<br>"のようにエスケープされなければなりません[MUST]。HTMLマークアップは内部でアンエンケープされた後、HTML<DIV>要素の中で直接出現しても妥当なものであるべきです[SHOULD]。そのようなコンテンツを表示するAtomプロセッサは、表示のためにマークアップを解釈しても構いません[MAY]。

3.1.1.3. XHTML

atom:titleがXHTMLを含む場合の例を示します。

   ...
   <title type="xhtml" xmlns:xhtml="http://www.w3.org/1999/xhtml">
     <xhtml:div>
       Less: <xhtml:em> &lt; </xhtml:em>
     </xhtml:div>
   </title>
   ...

type属性値がxhtmlの場合、text構文の内容は1つのXHTML[XHTML]div要素を含まなければならず[MUST]、XHTMLとして適した取り扱いをすべきです[SHOULD]。XHTML div要素自身がコンテンツの一部分と解釈されてはなりません[MUST NOT]。Atomプロセッサは表示のためにマークアップを解釈しても構いません[MAY]。 "&" や ">"といったエスケープされた文字はマークアップでなく、文字そのものとして表します。

妥当なXHTMLを含む例は次のようになります。

   ...
   <summary type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
         This is <b>XHTML</b> content.
      </div>
   </summary>
   ...
   <summary type="xhtml">
      <xhtml:div xmlns:xhtml="http://www.w3.org/1999/xhtml">
         This is <xhtml:b>XHTML</xhtml:b> content.
      </xhtml:div>
   </summary>
   ...

次の例は文章内の前のほうでxh接頭辞とXHTML名前空間が結びつけたものと仮定します。

   ...
   <summary type="xhtml">
      <xh:div>
         This is <xh:b>XHTML</xh:b> content.
      </xh:div>
   </summary>
   ...

3.2. Person 構文

Person構文は人や会社または同様の実体(以降、単に人とします)を記述する要素です。

   atomPersonConstruct =
      atomCommonAttributes,
      (element atom:name { text }
       & element atom:uri { atomUri }?
       & element atom:email { atomEmailAddress }?
       & extensionElement*)

本仕様書は、Person構文において子要素の出現の順番に何の意味をも割り当てません。 Person構文は拡張メタデータ要素を許容します(6.4節参照)。

3.2.1. atom:name要素

atom:name要素の内容は人間可読な名前を伝えます。atom:name要素の内容は言語依存性があります。Person構文は必ず1つだけatom:name要素を含まなければなりません[MUST]。

3.2.2. atom:uri要素

atom:name要素の内容は人に関連したIRIを伝えます。Person構文はatom:name要素を含むことができます[MAY]が1つより多く含んではなりません[MUST NOT]。Person構文におけるatom:uriの内容はIRI参照[RFC3987]でなければなりません[MUST]。

3.2.3. atom:email要素

atom:name要素のコンテンツは人に関連したe-mailアドレスを伝えます。Person構文はatom:email要素を含むことができます[MAY]が1つより多く含んではなりません[MUST NOT]。atom:emailのコンテンツはRFC2822[RFC2822]におけるaddr-spec形式(※訳注 正当なe-mailアドレス)でなければなりません[MUST]。

3.3. Date構文

Date構文は1つの要素であり、その内容がRFC3339[RFC3339]におけるdate-time形式に準拠させなければなりません[MUST]。さらに、日付と時間を区切るための文字に大文字のTを使用しなければならず[MUST]、数値によるタイムゾーンオフセットがない場合は大文字のZが出現しなければなりません[MUST]。

   atomDateConstruct =
      atomCommonAttributes,
      xsd:dateTime

このような日付の値は[ISO.8601.1988]、[W3C.NOTE-datetime-19980827]、[W3C.REC-xmlschema-2-20041028]といった仕様と互換性があります。

Date 構文の例:

   <updated>2003-12-13T18:30:02Z</updated>
   <updated>2003-12-13T18:30:02.25Z</updated>
   <updated>2003-12-13T18:30:02+01:00</updated>
   <updated>2003-12-13T18:30:02.25+01:00</updated>

日付の値は可能な限り正確であるべきです[SHOULD]。例えば、あるパブリッシングシステムにおいて、同じタイムスタンプを1日の間に発行されたいくつものエントリに適用するのは、一般に不適当と言えるでしょう。

4. Atom 要素の定義

4.1. コンテナ要素

4.1.1. atom:feed要素

atom:feed要素は、Atomフィード文書のドキュメント(すなわちトップレベル)要素で、フィードに関連づけられたメタデータとデータのコンテナとして振舞います。 この要素の子要素は、メタデータ要素と0個以上のatom:entry子要素から構成されます。

   atomFeed =
      element atom:feed {
         atomCommonAttributes,
         (atomAuthor*
          & atomCategory*
          & atomContributor*
          & atomGenerator?
          & atomIcon?
          & atomId
          & atomLink*
          & atomLogo?
          & atomRights?
          & atomSubtitle?
          & atomTitle
          & atomUpdated
          & extensionElement*),
         atomEntry*
      }

本仕様書は、フィードにおけるatom:entry要素の順序に意味を割り当てません。

以下の子要素が本仕様書によって定義されます(いくつかの要素は必須であることに注意してください)。

もしAtomフィード文章において、同一のatom:idの値を持つ複数のatom:feed要素が出現するならば、それらは同一のエントリーであることを意味します。 これらのatom:updatedタイムスタンプは異なるべきです[SHOULD]。 もしAtomフィード文章が同一のatom:idとともに複数のエントリー含むなら、Atomプロセッサはエントリーのすべてかエントリーの一部を表示するかを選択することができます[MAY] 。 典型的な振る舞いの1つは、atom:updatedのタイムスタンプが最新のエントリーのみを表示するものです。

4.1.1.1. 原文コンテンツの供給

経験上、原文コンテンツを含むフィードは含まないものよりも一般的に有用です。 いくつかのアプリケーション(一つの例として全文検索)は確実かつ予想どおりの機能を果たすために、最低限のテキスト量または(X)HTMLを要求します。 フィードを提供する際にこれらのことを意識すべきです。 各atom:entry要素は、空要素でないatom:title要素であること、atom:content要素を含むならばこれも空要素でないこと、atom:content要素を含まないときatom:summaryが空要素でないことが望ましいです。 しかしながら、atom:summary要素が無いことはエラーではないので、Atomプロセッサはこのように要素が無いことのために正しく機能しないことがあってはなりません[MUST NOT]。

4.1.2. atom:entry要素

atom:entry要素は個々のエントリーを表し、メタデータとエントリーに関連したデータのコンテナとして振舞います。 この要素はatom:feed要素の子要素として出現することができますが、単独のAtomエントリー文章のドキュメント(トップレベル)要素として出現することもできます。

   atomEntry =
      element atom:entry {
         atomCommonAttributes,
         (atomAuthor*
          & atomCategory*
          & atomContent?
          & atomContributor*
          & atomId
          & atomLink*
          & atomPublished?
          & atomRights?
          & atomSource?
          & atomSummary?
          & atomTitle
          & atomUpdated
          & extensionElement*)
      }

本仕様書は、フィードにおけるatom:entry要素の子要素の順序に意味を割り当てません。

以下の子要素が本仕様書によって定義されます(いくつかの要素は必須であることに注意してください)。

4.1.3. atom:content要素

atom:content要素は、エントリーのコンテンツを含むかエントリーのコンテンツへのリンクをします。atom:content要素の内容は言語依存性があります。

   atomInlineTextContent =
      element atom:content {
         atomCommonAttributes,
         attribute type { "text" | "html" }?,
         (text)*
      }

   atomInlineXHTMLContent =
      element atom:content {
         atomCommonAttributes,
         attribute type { "xhtml" },
         xhtmlDiv
      }

   atomInlineOtherContent =
      element atom:content {
         atomCommonAttributes,
         attribute type { atomMediaType }?,
         (text|anyElement)*
      }

   atomOutOfLineContent =
      element atom:content {
         atomCommonAttributes,
         attribute type { atomMediaType }?,
         attribute src { atomUri },
         empty
      }

   atomContent = atomInlineTextContent
    | atomInlineXHTMLContent
    | atomInlineOtherContent
    | atomOutOfLineContent
4.1.3.1. type属性

atom:content要素において、type属性値はtext,html,xhtmlのいずれか1つを取ることができます[MAY]。そうでない場合には、type属性値はMIMEメディアタイプの文法に準拠しなければなりません[MUST]が、混合タイプは禁止されます[MUST NOT](4.2.6節の[MIMEREG]を参照のこと)。type属性とsrc属性のどちらも与えられない場合、Atomプロセッサはtype属性値にtextがあるものとして振舞わなければなりません[MUST]。

4.1.3.2. src属性

atom:contentはsrc属性を持つことができます[MAY]。その場合は属性値がIRI参照[RFC3987]でなければなりません[MUST]。src属性が存在するならば、atom:content要素は空要素でなければなりません[MUST]。Atomプロセッサはコンテンツを検索するためにIRIを用いるかもしれません[MAY]し、リモートコンテンツを無視する、もしくはローカルコンテンツと比べ異なる方法での提供を選択することができます[MAY]。

src属性があるならば、type属性は供給されるべきで[SHOULD]、text,html,xhtmlではないMIMEメディアタイプ[MIMEREG]でなければなりません[MUST]。この値は助言的なものです。すなわち、一致するURI(必要であれば変換されたIRI)が間接参照されるとき、コンテンツを提供するサーバもまたメディアタイプを提供するならば、サーバが提供するメディアタイプを優先すべきです。

4.1.3.3. 処理モデル

Atom文章は以下の規則に準拠しなければなりません[MUST]。Atomプロセッサは最初に適用できる規則によってatom:contentを解釈しなければなりません[MUST]。

  1. type属性値がtextの場合、atom:content要素のコンテンツは子要素を含んではなりません[MUST NOT]。そのようなテキストは人間に可読な型として提供されることを意味します。したがって、Atomプロセッサは(改行を含む)空白をまとめたり、行末揃えやプロポーショナルフォントといった印刷技術を用いて文章を表示しても構いません[MAY]。
  2. type属性値がhtmlの場合、atom:content要素のコンテンツは子要素を含んではならず[MUST NOT]、HTML [HTML]として扱うのに適したものであるべきです[SHOULD]。HTMLマークアップは、例えば&lt;br>を<br>のようにエスケープされなければなりません[MUST]。HTMLマークアップはHTML <DIV>要素の中で直接出現しても妥当であるようなものであるべきです[SHOULD]。そのようなコンテンツを表示するAtomプロセッサは、表示のためにマークアップを解釈しても構いません[MAY]。
  3. typeの属性値がxhtmlの場合、atom:content要素のコンテンツは1つのXHTML div要素を含まなければならず[MUST]、XHTMLとして適した取り扱いをすべきです[SHOULD]。XHTML div要素自身がコンテンツの一部分とみなされてはなりません[MUST NOT]。Atomプロセッサは表示のためにマークアップを解釈しても構いません[MAY]。"&" や ">"といったエスケープされた文字はマークアップでなく、文字そのものとして表します。
  4. typeの属性値がXMLメディアタイプ[RFC3023]である、または/xmlか+xml(大文字・小文字を問わない)で終わるならば、atom:content要素のコンテンツは子要素を含んでもよく[MAY]、示されたメディアタイプとして適切に扱うべきです[SHOULD]。src属性が提供されないならば、このことは通常atom:contentがtype属性で示されたXML文章のルート要素として供給する1つの子要素が含まれることを意味するでしょう。
  5. type属性値がtext/(大文字・小文字を問わない)で始まるならば、atom:content要素のコンテンツは子要素を含んではなりません[MUST NOT]。
  6. type属性値が上記以外であるとき、atom:content要素の内容は、RFC3548[RFC3548]の3節に示されるような妥当なBase64エンコードされたものでなければなりません[MUST]。デコードされたとき、示されたメディアタイプとして適切に扱うべきです[SHOULD]。この場合、先頭や末尾に空白文字を挿入した上でBase64エンコード化された文字をatom:content要素の内容としてもよく[MAY]、1つの改行文字(U+000A)によって行は分割されます。
4.1.3.4. 例

XHTMLインライン:

   ...
   <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
         This is <b>XHTML</b> content.
      </div>
   </content>
   ...
   <content type="xhtml">
      <xhtml:div xmlns:xhtml="http://www.w3.org/1999/xhtml">
         This is <xhtml:b>XHTML</xhtml:b> content.
      </xhtml:div>
   </content>
   ...

次の例は文章内の前のほうでxh接頭辞とXHTML名前空間が結びつけたものと仮定します。

   ...
   <content type="xhtml">
      <xh:div>
         This is <xh:b>XHTML</xh:b> content.
      </xh:div>
   </content>
   ...

4.2. メタデータ要素

4.2.1. atom:author要素

atom:author要素はエントリーまたはフィードの作者を示すPerson構文です。

   atomAuthor = element atom:author { atomPersonConstruct }

atom:entry要素がatom:author要素を含まないならば、atom:source要素に含まれるatom:author要素が適用されると考えられます。Atomフィード文章内で、atom:author要素が前述の場所に無ければ、atom:feed要素のatom:author要素が適用されたと見なします。

4.2.2. atom:category要素

atom:category要素は エントリーやフィードに関連したカテゴリーについての情報を伝えます。本仕様書はatom:category要素の内容に特に意味を割り当てません。

   atomCategory =
      element atom:category {
         atomCommonAttributes,
         attribute term { text },
         attribute scheme { atomUri }?,
         attribute label { text }?,
         undefinedContent
      }
4.2.2.1. term属性

term属性はエントリーまたはフィードの属するカテゴリを特定するための文字列です。atom:category要素はterm属性を持たなければなりません[MUST]。

4.2.2.2. scheme属性

scheme属性はカテゴリのスキームを特定するIRIです。atom:category要素はscheme属性を持つことができます[MAY]。

4.2.2.3. label属性

label属性はエンドユーザのアプリケーションで表示するための人間可読なラベルを提供します。label属性の内容は言語依存性があります。&amp;や&lt;といった実体参照はマークアップではなく対応する文字(それぞれ"&"と"<")を表します。atom:category要素はlabel属性を持つことができます[MAY]。

4.2.3. atom:contributor要素

atom:contributor要素はエントリーやフィードに貢献した人や実体を示すPerson構文です。

   atomContributor = element atom:contributor { atomPersonConstruct }

4.2.4. atom:generator要素

atom:generator要素の内容は、フィードを生成したエージェントを特定するためのものです。デバッグや他の目的のために用いられます。

   atomGenerator = element atom:generator {
      atomCommonAttributes,
      attribute uri { atomUri }?,
      attribute version { text }?,
      text
   }

この要素の内容が存在する場合は、生成エージェントの名前が人間可読な文字列でなければなりません[MUST]。&amp;や&lt;といった実体参照はマークアップではなく対応する文字(それぞれ&と<)を表します。

atom:generator要素はuri属性を持つことができます[MAY]が、その値はIRI参照[RFC3987]でなければなりません[MUST]。間接参照されたとき、結果として生じるURI(必要であるなら変換されたIRI)はエージェントに関連のある説明を生成すべきです[SHOULD]。

atom:generator要素は生成エージェントのバージョンを示すversion属性を持つことができます[MAY]。

4.2.5. atom:icon要素

atom:icon要素の内容は、フィードにアイコンを使った視覚的な識別子を提供するような画像を示すIRI参照[RFC3987]です。

   atomIcon = element atom:icon {
      atomCommonAttributes,
      (atomUri)
   }

画像は縦横比が1:1であるべき[SHOULD]で、表示に適した小さなサイズであるべきです[SHOULD]。

4.2.6. atom:id要素

atom:id要素は永続的であるような、エントリーやフィードのための普遍的で一意な識別子を伝えます。

   atomId = element atom:id {
      atomCommonAttributes,
      (atomUri)
   }

atom:id要素の内容はRFC3987[RFC3987]で定義されたIRIでなければなりません。IRIの定義が相対参照を除外していることに注意してください。IRIは間接参照可能なスキームを使うことができますが、Atomプロセッサは間接参照可能であることを仮定してはなりません[MUST NOT]。

Atom文章を再配置、移動、配信、再発行、エクスポート、もしくはインポートした場合でも、そのatom:id要素の内容を変更してはなりません[MUST NOT]。言い換えるならば、atom:id要素は特定のAtomエントリーまたはフィードのすべての実体に付属します。改訂版でもatom:id要素において同一の内容に保たれます。atom:id要素は関連リソースとともに保存されることが推奨されます。

atom:id要素の内容は一意であることが保証された方法で生成されなければなりません[MUST]。

等価なURIに変換されたIRIと間接参照の間に混乱の恐れがあるために、以下に挙げる正規化方針がatom:id要素生成時に適用されるべきです[SHOULD]。(訳注:以下に表れる用語についての詳細はURI[RFC3986]を参照)

4.2.6.1. atom:idの比較

atom:idの実体は、エントリーまたはフィードが以前のものと同一かどうかを判断するために比較されることがあります。プロセッサはatom:id要素を(大文字・小文字を区別して)1文字ごとに比較しなければなりません[MUST]。 比較作業はIRI文字列のみに基づかなければならず[MUST]、IRIの間接参照やそれらから変換されたURIに依存してはなりません[MUST NOT]。

その結果、 同一のリソースとして解決されるものの、文字ごとでは一致しない2つのIRIは識別子比較の目的では異なるものであるとみなすでしょう。

例えば、大文字小文字のみが異なるという事実にもかかわらず、これらは4つの異なった識別子です。

      http://www.example.org/thing
      http://www.example.org/Thing
      http://www.EXAMPLE.org/thing
      HTTP://www.example.org/thing

同様に、IRIパーセントエンコーディングは比較目的では意味を持つために、これらも3つの異なる識別子です。

      http://www.example.com/~bob
      http://www.example.com/%7ebob
      http://www.example.com/%7Ebob

4.2.7. atom:link要素

atom:link要素はエントリーやフィードからWebリソースへの参照を定義します。この仕様ではこの要素の内容に(もしあるならば)特に意味を割り当てません。

   atomLink =
      element atom:link {
         atomCommonAttributes,
         attribute href { atomUri },
         attribute rel { atomNCName | atomUri }?,
         attribute type { atomMediaType }?,
         attribute hreflang { atomLanguageTag }?,
         attribute title { text }?,
         attribute length { text }?,
         undefinedContent
      }
4.2.7.1. href属性

href属性はリンクのIRIを含みます。atom:link要素はhref属性を持たなければなりません[MUST]。属性値はIRI参照[RFC3987]でなければなりません[MUST]。

4.2.7.2. rel属性

atom:link要素はリンク関係タイプを示す1つのrel属性を持つことができます[MAY]。rel属性がないならば、link要素はリンク関係タイプはalternateとして解釈されなければなりません[MUST]。

rel属性値は空でなく、かつRFC3987[RFC3987]のisegment-nz-ncまたはIRI形式のどちらかに一致するような文字列でなければなりません[MUST] 。単一の名前ではない相対参照の仕様は許可されていないことに注意してください。もし名前が与えられた場合、実装はリンク関係タイプがIANAのLink Relationsレジストリ(7章)に登録された名前と等価であると考慮しなければならず[MUST]、よって、 文字列"http://www.iana.org/assignments/relation/"にrel属性値を追加することによって得られるだろうIRIと同等となります。rel属性値はリンクの意味を示しますが、Atomプロセッサにおけるどのような振る舞いの要求をも課すものではありません。

この文章はLink Relationsのレジストリに対して5つの初期値を定義します。

  1. 値alternateは、href属性値中に記述されるリソースの代替リソースであるIRIを意味します。
  2. 値relatedは、href属性値中に記述されるリソースと関連したリソースであるIRIを意味します。例えば、http://search.example.comのサーチエンジンのパフォーマンスを議論するサイトのフィードがatom:feedの子要素として

           <link rel="related" href="http://search.example.com/"/>
    

    を含むでしょう。

    これと一致するリンクは同じサーチエンジンに関する議論を含むような、任意のatom:entryの子要素としてとして出現するかもしれません。

  3. 値selfは、href属性値中に記述されているリソースと等価なリソースであるIRIを意味します。
  4. 値enclosureは、href属性値中に記述されているリソースで、潜在的なサイズの大きさがあり特別な扱いを必要とする関連リソースであるIRIを意味します。 rel="enclosure"を持つatom:link要素はlength属性を与えるべきです[SHOULD]。
  5. 値viaは、href属性値中に記述されているリソースで、要素に提供された情報源であるIRIを意味します。
4.2.7.3. type属性

link要素において、type属性値は助言的なメディアタイプです。 これは、href属性値が間接参照されるときに予想される戻り値のヒントにすぎません。 type属性は実際のメディアタイプを覆すことはないことに注意してください。 Link要素はtype属性を含むことができますが[MAY]、その値はMIMEメディアタイプ[MIMEREG]の文法に従わなければなりません[MUST]。

4.2.7.4. hreflang属性

hreflang属性の内容はhref属性によって示されたリソースの言語を説明します。rel="alternate"とともに使われるとき、それがエントリーの翻訳版であることを暗示します。 Link要素はhreflang属性を含むことができますが[MAY]、その値は言語コード[RFC3066]でなければなりません[MUST]。

4.2.7.5. title属性

title属性はリンクについて人間可読な情報を伝えます。title属性の内容は言語依存性があります。&amp;や&lt;といった実体参照はマークアップではなく対応する文字(それぞれ&と<)を表します。Link要素はtitle属性を持つことができます[MAY]。

4.2.7.6. length属性

length属性はリンクされたコンテンツのオクテット単位での助言的なサイズを示します。href属性のIRIがURIに変換され間接参照されるときに返されるコンテンツのサイズのヒントです。length属性は実際にプロトコルによって伝えられたコンテンツのサイズを覆すことはないことに注意してください。Link要素はlength属性を持つことができます[MAY]。

4.2.8. atom:logo要素

atom:logo要素の内容は、フィードにアイコンを使った視覚的な識別子を提供するような画像を示すIRI参照[RFC3987]です。

   atomLogo = element atom:logo {
      atomCommonAttributes,
      (atomUri)
   }

画像は縦横比1:2であるべきです[SHOULD]。

4.2.9. atom:published要素

atom:published要素はエントリーのライフサイクルにおける初期のイベントに関連付けられた瞬間を示すDate構文です。

   atomPublished = element atom:published { atomDateConstruct }

一般的に、atom:published要素はリソースが最初に生成されたときか、最初に利用可能になったときに関連付けられます。

4.2.10. atom:rights要素

atom:rights要素はエントリーやフィードに含まれる権利についての情報を伝えるText構文です。

   atomRights = element atom:rights { atomTextConstruct }

atom:rights要素は 機械可読なライセンス情報を伝えるために使われるべきではありません[SHOULD NOT]。

atom:entry要素にatom:rights要素がなく、atom:feed要素にatom:rights要素があるのであれば、その内容をエントリに適用することが考慮されます。

4.2.11. atom:source要素

atom:entry要素をあるフィードから別のフィードにコピーする場合、元のatom:feed要素のメタデータ(atom:feed要素のatom:entry要素以外のすべての子要素)は、atom:source要素の子要素として加えることで、複製されたエントリー内に保持することができ[MAY]、エントリー内に存在しない場合は、atom:source要素の子要素として一部または全部の元のフィードのメタデータを含むことができます[MAY]。 元のatom:feedがatom:author, atom:contributor, atom:rights, atom:categoryの子要素のいずれかを含み、それらの子要素が元のatom:entryに含まれない場合には、そのようなメタデータは保持されるべきです[SHOULD]。

   atomSource =
      element atom:source {
         atomCommonAttributes,
         (atomAuthor*
          & atomCategory*
          & atomContributor*
          & atomGenerator?
          & atomIcon?
          & atomId?
          & atomLink*
          & atomLogo?
          & atomRights?
          & atomSubtitle?
          & atomTitle?
          & atomUpdated?
          & extensionElement*)
      }

atom:source要素は、エントリーの元のフィードについての情報を保持したまま、異なるフィードからエントリーの収集ができるよう設計されています。こののため、そのような収集を行うAtomプロセッサは、atom:element要素内に少なくともフィードレベルの必須メタデータ要素(atom:id, atom:title, and atom:updated)を含めるべきです[SHOULD]。

4.2.12. atom:subtitle要素

atom:subtitle要素は人間可読なフィードの説明やサブタイトルを伝えるText構文です。

   atomSubtitle = element atom:subtitle { atomTextConstruct }

4.2.13. atom:summary要素

atom:summary要素はエントリーの短い要約や抜粋、引用を伝えるText構文です。

   atomSummary = element atom:summary { atomTextConstruct }

atom:summary要素がatom:title要素やatom:content要素を繰り返すことは望ましくありません。Atomプロセッサは有用な要約があるとみなすためからです。

4.2.14. atom:title要素

atom:title要素はエントリーやフィードの人間可読なタイトルを伝えるText構文です。

   atomTitle = element atom:title { atomTextConstruct }

4.2.15. atom:updated要素

atom:updated要素はフィードやエントリーが発行者が重要と考える変更がなされた瞬間の最新の時間を含むDate構文です。

   atomUpdated = element atom:updated { atomDateConstruct }

発行者は、時間とともにこの要素の値を変更しても構いません[MAY]。

5. Atom文章を安全にする

AtomはXMLベースのフォーマットであるので、その内容を守るために既存のXMLセキュリティー機構を使うことができます。

フィードやエントリーの提供者や、それらを集める仲介者は、保護されていないコンテンツに署名や暗号化するための正当な理由をもっているでしょう。 例えば、店主は製品の割引クーポンを含むメッセージを電子的な署名するかもしれません。顧客に請求書を届けるためにAtomを利用している銀行は、おそらく顧客の金融情報を保護するため、請求書の確実性を保証するために署名や暗号化をしたがるでしょう。仲介者は傍観者にどんなトピックに受取人が興味のあるかをわからないように収集したフィードを暗号化したがるかもしれません。 もちろん、ほかにも多くの例があります。

この章でのアルゴリズムの要求はAtomプロセッサに関連するものです。それらは、受取人は少なくとも、指定された暗号化アルゴリズムを扱うことができることを要求します。これらの要求は送信者が選択するアルゴリズムを制限しません。

5.1. 電子署名

Atom文章のルート(すなわち、Atomフィード文章のatom:feed要素、Atomエントリー文章のatom:entry要素)または任意のatom:entry要素はXML-Signature and Syntax Processing [W3C.REC-xmldsig-core-20020212] で示されるEnveloped Signatureを持っても構いません[MAY]

Atomプロセッサは検証できないという理由で署名を含むAtom文章を拒否してはなりません[MUST NOT]。処理を必ず実行し[MUST]、かつ署名の検証に失敗したとユーザに通知しても構いません[MAY]。

言い換えるならば、名前空間URIhttp://www.w3.org/2000/09/xmldsig#のある要素の存在と文書の子要素としての局所名"Signature"はそれが存在するという理由だけでAtomプロセッサに失敗を起こしてはなりません[MUST NOT]

Atom文章内の他の要素はそれらの定義が明示的に可能であると既定していない限り、署名されてはなりません[MUST NOT]

[W3C.REC-xmldsig-core-20020212]の6.5.1節はCanonical XML [W3C.REC-xml-c14n-20010315]のサポートを要求します。しかしながら、多くの実装は他のXML文章に含まれる署名されたXML文章が壊れているためにCanonical XMLを利用しません。したがって、署名されたAtom文章を検証するAtomプロセッサはExclusive XML Canonicalization [W3C.REC-xml-exc-c14n-20020718] で既定された、URIhttp://www.w3.org/2001/10/xml-exc-c14n#で特定される、排他的なXML正規化手法とともに正規化可能でなければなりません[MUST]。

収集者のような仲介者は、atom:source要素を自身に含まないエントリーにatom:source要素を追記することを必要とするかもしれません。そのようなエントリーが署名されているならば、追記によって署名は壊れるでしょう。このように、それぞれ署名されたエントリーの配信者は署名する前にatom:source要素をエントリーに加えることを強く検討すべきです。仲介者もまた、正規化に伴うxml:名前空間におけるマークアップの利用に関する問題を意識すべきです。

[W3C.REC-xmldsig-core-20020212]の4.4.2節はDSA署名のサポートを要求し、RSA署名のサポートを推奨します。しかしながら、市場においてDSAに対するRSAの人気が圧倒的に高いために、証明を検証するAtomプロセッサはRSA署名が検証可能でなければならず[MUST]、DSA署名を検証できる必要はありません。メッセージ検証コード(MAC)認証の鍵素材が正しく扱われなかったときに生じるセキュリティの問題のために、Atom文章はMAC署名を使うべきではありません[SHOULD NOT]。

5.2. 暗号化

Atom文章のルート(すなわち、Atomフィード文章でのatom:feed、Atomエントリ文章でのatom:entry)は、 XML Encryption Syntax and Processing [W3C.REC-xmlenc-core-20021210]で述べられている機構を使って暗号化することができます[MAY]。

[W3C.REC-xmlenc-core-20021210] の5.1章はTripleDES, AES-128, AES-256のサポートを要求します。Atom文章を解読するAtomプロセッサはAES-128をCipher Block Chaining (CBC)モードで解読できなければなりません[MUST]。

[W3C.REC-xmlenc-core-20021210] に基づいた暗号化は元の文章の完全であることを保証しません。復号した文章の一部または全部が意味を成すけれども、異なる意味となるような、メッセージを復号不可能な第三者がビットを書き換える暗号攻撃が知られています。したがって、Atom文章を復号するAtomプロセッサは、復号した文章の完全性を文章のの署名に含まれるハッシュ(あれば)や、文章にあるハッシュ(あれば)を検証することによって調べるべきです[SHOULD]。

5.3. 署名して暗号化する

Atom文章に署名と暗号化の両方をする場合、最初に文章を署名し、それから暗号化するのが一般的に良い考えです。文章を署名したエンティティの識別情報を含む、全ての情報の暗号化と同時に、もととなる文章との完全性がこれにより提供されます。もしMACが認証に使われる場合、その順序は、文章が署名された上で暗号化を行うというものでなければならず[MUST]、その他の方法であってはならないことに注意してください。

6. Atomの拡張

6.1. 非Atom語彙による拡張

この仕様は、AtomのXMLマークアップ語彙を記述します。Atom文章では、他の語彙(「外部マークアップ」)を使うことができます。atom:content要素は外部マークアップの属性を含むことをサポートするように設計されていることに注意してください。

6.2. Atom語彙への拡張

Atom名前空間は将来の前方互換のあるAtom改訂版のために予約されています。この仕様の将来の版はAtomマークアップ語彙として、新しい要素や属性を加えることができます。この仕様のこのバージョンに適合するよう書かれたソフトウェアは、そのようなマークアップを正確に処理することができないかもしれず、つまり、マークアップエラーと区別することができません。この議論によって、認識できないAtom語彙は「外部マークアップ」とみなされるでしょう。

6.3. 外部マークアップの処理

この仕様で正当とみなせる場所で外部マークアップに出くわしたAtomプロセッサは、処理を停止したりエラーを出してはなりません[MUST NOT]。Atomプロセッサはその外語マークアップを正しく処理できる場合もあります。さもなければ、そのようなマークアップは「不明な外部マークアップ」とします。

不明な外部マークアップがatom:entry要素かatom:feed要素もしくはPerson構文の子要素として出現したとき、Atomプロセッサはマークアップやテキストを無視してもよく[MAY]、マークアップの存在のためにAtomプロセッサの挙動を変えてはなりません[MUST NOT]。

不明な外部マークアップがText構文かatom:content要素として出現したとき、ソフトウェアはマークアップを無視し、テキスト内容を囲んでいる外部マークアップが無いかのように処理するべきです[SHOULD]。

6.4. 拡張要素

Atomでは明示的に禁止されたところを除いて、外部マークアップはAtom文章のどこでも許可されます。atom:entry、atom:feed、atom:source、Person構文の子要素はメタデータ要素とみなされ、以下で説明されます。Person構文の子要素は構文として適用されます。他の外部マークアップの役割はこの仕様では定義されません。

6.4.1. 単純拡張要素

単純拡張要素はすべての属性や子要素を持ってはなりません[MUST NOT]。この要素は文字データを含んでもよく[MAY]、でなければ空要素となります。単純拡張要素は言語依存性がありません。

   simpleExtensionElement =
      element * - atom:* {
         text
      }

この要素は、要素を囲む親要素の単純プロパティ(名前/値の組)として解釈されます。単純拡張要素の名前空間URIと局所名からなるこの組は、プロパティの名前と解釈されます。要素の文字データ内容はプロパティの値として解釈されます。空要素の場合、プロパティ値は空文字列として解釈されます。

6.4.2. 構造化拡張要素

構造化拡張要素のルート要素は少なくとも1つの属性か子要素を持たなければなりません[MUST]。この要素は属性を持ってもよく[MAY] 、整形式のXML内容 (文字データを含む)を含んでもよく、また空でも構いません[MAY]。構造化拡張要素は言語依存性があります。

   structuredExtensionElement =
      element * - atom:* {
         (attribute * { text }+,
            (text|anyElement)*)
       | (attribute * { text }*,
          (text?, anyElement+, (text|anyElement)*))
      }

子要素の順序を含むような構造化拡張要素の構造は、その順序に意味を持つ場合があります。

この仕様は構造化拡張要素の解釈を提供しません。要素に含まれるXMLの文法(や構造化拡張要素含む要素とどのように関連するかという解釈)はAtom拡張の仕様により定義されます。

7. IANAの考慮

XML 1.0として取り扱われるAtom文章は次のメディアタイプとともに識別されます。

MIMEメディアタイプ名:
application
MIMEサブタイプ名:
atom+xml
必須パラメータ:
なし
任意パラメータ:

charset: このパラメータはRFC3023[RFC3023]で定められたapplication/xmlメディアタイプと同一のcharsetパラメータのセマンティックを持ちます。

エンコードの考慮:[RFC3023]の3.2節で述べられたapplication/xmlに同じ。

セキュリティーの考慮:
この仕様で定義されている通り。加えて、このメディアタイプは+xmlの慣習を使っているために、[RFC3023]の10章で述べられたセキュリティーの考慮を含みます。
相互運用性の考慮:
相互運用性の考慮についての問題は知られていません。
発行された仕様:
この仕様。
このメディアタイプを使うアプリケーション:
現在このメディアタイプを利用する既知のアプリケーションはありません。
追加情報:

マジックナンバー:[RFC3023]の3.2節で定められたapplication/xmlの通り。

ファイル拡張子:.atom

フラグメント識別子:[RFC3023] の5節でapplication/xmlに対して定められた通り。

基底URI:[RFC3023] の6節で定められた通り。

マッキントッシュ・ファイルタイプコード:TEXT

より詳しい情報について連絡する人物および電子メールアドレス:
Mark Nottingham <mnot@pobox.com>
想定される利用法:
COMMON
著者/変更の管理人:
IESG

7.1. Link Relationsの登録

この登録はIANAにより保守され、また最初から"alternate", "related", "self", "enclosure", "via"の5つの値を含みます。 新しい割り当ては [RFC2434] に概略が述べられているようにIESGの承認が必要です。要求はIANAへの電子メールによって行なわれるべきであり、それによりリクエストをIESGへ転送し、承認を要求します。要求は以下のテンプレートを使うべきです。

8. セキュリティーの考慮

8.1. HTMLとXHTMLの内容

Text構文とatom:content要素はHTMLやXHTMLの配信を許可します。これら言語の多くの要素はクライアントをさまざまな攻撃に晒すために「安全ではない」と考えられます。 Atomを処理するソフトウェアの提供者はAtom文書における(X)HTMLを処理する場合、全種類の要素についてその取り扱いを注意深く考慮すべきです。ガイダンスとして[RFC2854]と[HTML]のセキュリティーに関する章を参照してください。

AtomプロセッサはIMG, SCRIPT, EMBED, OBJECT, FRAME, FRAMESET, IFRAME, META, LINK要素のセキュリティーについて特に注意を払うべきですが、他の要素もまたよくないセキュリティー特性を持つかもしれません。

(X)HTMLは実行可能な内容として直接含む、もしくは間接的に参照することができます。

8.2. URI

AtomプロセッサはURIを扱います。[RFC3986]の7章を参照してください。

8.3. IRI

AtomプロセッサはURIを扱います。[RFC3987]の8章を参照してください。

8.4. なりすまし

Atomプロセッサは攻撃者が 他のフィードに基づくエントリーのatom:id値をもったatom:entry、おそらく他のフィードのatom:idをコピーして偽造されたatom:source要素を伴ったものを発行するような、成りすまし攻撃の可能性について配慮すべきです。例えば、Atomプロセッサは同一のatom:id値をもつエントリーのうち、一つのエントリーのみを表示することによって 、重複したエントリーの表示を抑制することができます。そのような状況で、Atomプロセッサもまた コピーであると判断する前に、エントリーが同一の発行者によるものかどうか決定するための手段を取るかもしれません。

8.5. 暗号化と署名

Atom文章はそれぞれ[W3C.REC-xmlenc-core-20021210]や[W3C.REC-xmldsig-core-20020212]を使うことで、暗号化もしくは署名されることができ、またそれらの利用によりセキュリティーの考慮の対象となります。

電子署名は認証、メッセージの健全性、発信証明をともなう否認防止を提供します。 暗号化はデータの機密性を提供します。

9. 参考文書

9.1. 規範文書

[HTML]
Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01 Specification", W3C REC REC-html401-19991224, December 1999, <http://www.w3.org/TR/1999/REC-html401-19991224>.
[MIMEREG]
Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2822]
Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2854]
Connolly, D. and L. Masinter, "The 'text/html' Media Type", RFC 2854, June 2000.
[RFC3023]
Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3066]
Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[RFC3339]
Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
[RFC3548]
Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003.
[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.
[W3C.REC-xml-20040204]
Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T., and E. Maler, "Extensible Markup Language (XML) 1.0 (Third Edition)", W3C REC REC-xml-20040204, February 2004, <http://www.w3.org/TR/2004/REC-xml-20040204>.
[W3C.REC-xml-c14n-20010315]
Boyer, J., "Canonical XML Version 1.0", W3C REC REC-xml-c14n-20010315, March 2001, <http://www.w3.org/TR/2001/REC-xml-c14n-20010315>.
[W3C.REC-xml-exc-c14n-20020718]
Eastlake, D., Boyer, J., and J. Reagle, "Exclusive XML Canonicalization Version 1.0", W3C REC REC-xml-exc-c14n- 20020718, July 2002, <http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718>.
[W3C.REC-xml-infoset-20040204]
Cowan, J. and R. Tobin, "XML Information Set (Second Edition)", W3C REC REC-xml-infoset-20040204, February 2004, <http://www.w3.org/TR/2004/REC-xml-infoset-20040204>.
[W3C.REC-xml-names-19990114]
Hollander, D., Bray, T., and A. Layman, "Namespaces in XML", W3C REC REC-xml-names-19990114, January 1999, <http://www.w3.org/TR/1999/REC-xml-names-19990114>.
[W3C.REC-xmlbase-20010627]
Marsh, J., "XML Base", W3C REC REC-xmlbase-20010627, June 2001, <http://www.w3.org/TR/2001/REC-xmlbase-20010627>.
[W3C.REC-xmldsig-core-20020212]
Solo, D., Reagle, J., and D. Eastlake, "XML-Signature Syntax and Processing", W3C REC REC-xmldsig-core-20020212, February 2002, <http://www.w3.org/TR/2002/REC-xmldsig-core-20020212>.
[W3C.REC-xmlenc-core-20021210]
Reagle, J. and D. Eastlake, "XML Encryption Syntax and Processing", W3C REC REC-xmlenc-core-20021210, December 2002, <http://www.w3.org/TR/2002/REC-xmlenc-core-20021210>.
[XHTML]
Altheim, M., Boumphrey, F., McCarron, S., Dooley, S., Schnitzenbaumer, S., and T. Wugofski, "Modularization of XHTML[TM]", W3C REC REC-xhtml-modularization-20010410, April 2001, <http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410>.

9.2. 参照資料

[ISO.8601.1988]
International Organization for Standardization, "Data elements and interchange formats - Information interchange - Representation of dates and times", ISO Standard 8601, June 1988.
[RELAX-NG]
Clark, J., "RELAX NG Compact Syntax", December 2001, <http://www.oasis-open.org/committees/relax-ng/compact-20021121.html>.
[RFC2434]
Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[W3C.NOTE-datetime-19980827]
Wolf, M. and C. Wicksteed, "Date and Time Formats", W3C NOTE NOTE-datetime-19980827, August 1998, <http://www.w3.org/TR/1998/NOTE-datetime-19980827>.
[W3C.REC-xmlschema-2-20041028]
Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second Edition", W3C REC REC-xmlschema-2-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.

付録A. 貢献者

次の人々はこの文章の準備版で貢献しました:Tim Bray, Mark Pilgrim, Sam Ruby。Norman WalshはRelax NGを提供しました。内容とコンセプトはAtomコミュニティーとAtompub Working Groupの生産物です。

Atompub Working Groupは大変活発なアイデアやこの文章の表現のたくさんの貢献者を持っています。

Danny Ayers, James Aylett, Roger Benningfield, Arve Bersvendsen, Tim Bray, Dan Brickley, Thomas Broyer, Robin Cover, Bill de hOra, Martin Duerst, Roy Fielding, Joe Gregorio, Bjoern Hoehrmann, Paul Hoffman, Anne van Kesteren, Brett Lindsley, Dare Obasanjo, David Orchard, Aristotle Pagaltzis, John Panzer, Graham Parks, Dave Pawson, Mark Pilgrim, David Powell, Julian Reschke, Phil Ringnalda, Antone Roundy, Sam Ruby, Eric Scheid, Brent Simmons, Henri Sivonen, Ray Slakinski, James Snell, Henry Story, Asbjorn Ulsberg, Walter Underwood, Norman Walsh, Dave Winer, Bob Wyman.

付録B. RELAX NG 短縮スキーマ

この付録は参考です。

RELAX NGスキーマはこの仕様の改訂で定義されていないAtom名前空間における要素を明白に除外します。 Atomプロセッサがそのようなマークアップに出会ったときの要求は、6.2節と6.3節にあります。

   # -*- rnc -*-
   # RELAX NG Compact Syntax Grammar for the
   # Atom Format Specification Version 11

   namespace atom = "http://www.w3.org/2005/Atom"
   namespace xhtml = "http://www.w3.org/1999/xhtml"
   namespace s = "http://www.ascc.net/xml/schematron"
   namespace local = ""

   start = atomFeed | atomEntry

   # Common attributes

   atomCommonAttributes =
      attribute xml:base { atomUri }?,
      attribute xml:lang { atomLanguageTag }?,
      undefinedAttribute*

   # Text Constructs

   atomPlainTextConstruct =
      atomCommonAttributes,
      attribute type { "text" | "html" }?,
      text

   atomXHTMLTextConstruct =
      atomCommonAttributes,
      attribute type { "xhtml" },
      xhtmlDiv

   atomTextConstruct = atomPlainTextConstruct | atomXHTMLTextConstruct

   # Person Construct

   atomPersonConstruct =
      atomCommonAttributes,
      (element atom:name { text }
       & element atom:uri { atomUri }?
       & element atom:email { atomEmailAddress }?
       & extensionElement*)

   # Date Construct

   atomDateConstruct =
      atomCommonAttributes,
      xsd:dateTime

   # atom:feed

   atomFeed =
      [
         s:rule [
            context = "atom:feed"
            s:assert [
               test = "atom:author or not(atom:entry[not(atom:author)])"
               "An atom:feed must have an atom:author unless all "
               ~ "of its atom:entry children have an atom:author."
            ]
         ]
      ]
      element atom:feed {
         atomCommonAttributes,
         (atomAuthor*
          & atomCategory*
          & atomContributor*
          & atomGenerator?
          & atomIcon?
          & atomId
          & atomLink*
          & atomLogo?
          & atomRights?
          & atomSubtitle?
          & atomTitle
          & atomUpdated
          & extensionElement*),
         atomEntry*
      }

   # atom:entry

   atomEntry =
      [
         s:rule [
            context = "atom:entry"
            s:assert [
               test = "atom:link[@rel='alternate'] "
               ~ "or atom:link[not(@rel)] "
               ~ "or atom:content"
               "An atom:entry must have at least one atom:link element "
               ~ "with a rel attribute of 'alternate' "
               ~ "or an atom:content."
            ]
         ]
         s:rule [
            context = "atom:entry"
            s:assert [
               test = "atom:author or "
               ~ "../atom:author or atom:source/atom:author"
               "An atom:entry must have an atom:author "
               ~ "if its feed does not."
            ]
         ]
      ]
      element atom:entry {
         atomCommonAttributes,
         (atomAuthor*
          & atomCategory*
          & atomContent?
          & atomContributor*
          & atomId
          & atomLink*
          & atomPublished?
          & atomRights?
          & atomSource?
          & yatomSummary?
          & atomTitle
          & atomUpdated
          & extensionElement*)
      }

   # atom:content

   atomInlineTextContent =
      element atom:content {
         atomCommonAttributes,
         attribute type { "text" | "html" }?,
         (text)*
      }

   atomInlineXHTMLContent =
      element atom:content {
         atomCommonAttributes,
         attribute type { "xhtml" },
         xhtmlDiv
      }

   atomInlineOtherContent =
      element atom:content {
         atomCommonAttributes,
         attribute type { atomMediaType }?,
         (text|anyElement)*
      }

   atomOutOfLineContent =
      element atom:content {
         atomCommonAttributes,
         attribute type { atomMediaType }?,
         attribute src { atomUri },
         empty
      }

   atomContent = atomInlineTextContent
    | atomInlineXHTMLContent
    | atomInlineOtherContent
    | atomOutOfLineContent

   # atom:author

   atomAuthor = element atom:author { atomPersonConstruct }

   # atom:category

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

   # atom:contributor

   atomContributor = element atom:contributor { atomPersonConstruct }

   # atom:generator

   atomGenerator = element atom:generator {
      atomCommonAttributes,
      attribute uri { atomUri }?,
      attribute version { text }?,
      text
   }

   # atom:icon

   atomIcon = element atom:icon {
      atomCommonAttributes,
      (atomUri)
   }

   # atom:id

   atomId = element atom:id {
      atomCommonAttributes,
      (atomUri)
   }

   # atom:logo

   atomLogo = element atom:logo {
      atomCommonAttributes,
      (atomUri)
   }

   # atom:link

   atomLink =
      element atom:link {
         atomCommonAttributes,
         attribute href { atomUri },
         attribute rel { atomNCName | atomUri }?,
         attribute type { atomMediaType }?,
         attribute hreflang { atomLanguageTag }?,
         attribute title { text }?,
         attribute length { text }?,
         undefinedContent
      }

   # atom:published

   atomPublished = element atom:published { atomDateConstruct }

   # atom:rights

   atomRights = element atom:rights { atomTextConstruct }

   # atom:source

   atomSource =
      element atom:source {
         atomCommonAttributes,
         (atomAuthor*
          & atomCategory*
          & atomContributor*
          & atomGenerator?
          & atomIcon?
          & atomId?
          & atomLink*
          & atomLogo?
          & atomRights?
          & atomSubtitle?
          & atomTitle?
          & atomUpdated?
          & extensionElement*)
      }

   # atom:subtitle

   atomSubtitle = element atom:subtitle { atomTextConstruct }

   # atom:summary

   atomSummary = element atom:summary { atomTextConstruct }

   # atom:title

   atomTitle = element atom:title { atomTextConstruct }

   # atom:updated


   atomUpdated = element atom:updated { atomDateConstruct }

   # Low-level simple types

   atomNCName = xsd:string { minLength = "1" pattern = "[^:]*" }

   # Whatever a media type is, it contains at least one slash
   atomMediaType = xsd:string { pattern = ".+/.+" }

   # As defined in RFC 3066
   atomLanguageTag = xsd:string {
      pattern = "[A-Za-z]{1,8}(-[A-Za-z0-9]{1,8})*"
   }

   # Unconstrained; it's not entirely clear how IRI fit into
   # xsd:anyURI so let's not try to constrain it here
   atomUri = text

   # Whatever an email address is, it contains at least one @
   atomEmailAddress = xsd:string { pattern = ".+@.+" }

   # Simple Extension

   simpleExtensionElement =
      element * - atom:* {
         text
      }

   # Structured Extension

   structuredExtensionElement =
      element * - atom:* {
         (attribute * { text }+,
            (text|anyElement)*)
       | (attribute * { text }*,
          (text?, anyElement+, (text|anyElement)*))
      }

   # Other Extensibility

   extensionElement =
      simpleExtensionElement | structuredExtensionElement

   undefinedAttribute =
     attribute * - (xml:base | xml:lang | local:*) { text }

   undefinedContent = (text|anyForeignElement)*


   anyElement =
      element * {
         (attribute * { text }
          | text
          | anyElement)*
      }

   anyForeignElement =
      element * - atom:* {
         (attribute * { text }
          | text
          | anyElement)*
      }

   # XHTML

   anyXHTML = element xhtml:* {
      (attribute * { text }
       | text
       | anyXHTML)*
   }

   xhtmlDiv = element xhtml:div {
      (attribute * { text }
       | text
       | anyXHTML)*
   }

   # EOF

著者のアドレス

Mark Nottingham (editor)
EMail: mnot@pobox.com
URI: http://www.mnot.net/
Robert Sayre (editor)
EMail: rfsayre@boswijck.com
URI: http://boswijck.com

著作権表示全文

Copyright (C) The Internet Society (2005).

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

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

知的財産

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

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

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

謝辞

RFC Editer 機構の資金は、現在インターネット学会によって提供されています。