RFC4287 日本語訳
4287 The Atom Syndication Format. M. Nottingham, Ed., R. Sayre, Ed.. December 2005. (Format: TXT=81922 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Nottingham, Ed. Request for Comments: 4287 R. Sayre, Ed. Category: Standards Track December 2005
ワーキンググループM.ノッティンガム、エドをネットワークでつないでください。コメントのために以下を要求してください。 4287 エドR.セアー、カテゴリ: 標準化過程2005年12月
The Atom Syndication Format
原子シンジケート組織化形式
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document specifies Atom, an XML-based Web content and metadata syndication format.
このドキュメントはAtom、XMLベースのウェブ内容、およびメタデータシンジケート組織化形式を指定します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Examples ...................................................3
1.2. Namespace and Version ......................................5
1.3. Notational Conventions .....................................5
2. Atom Documents ..................................................6
3. Common Atom Constructs ..........................................7
3.1. Text Constructs ............................................7
3.1.1. The "type" Attribute ................................8
3.2. Person Constructs .........................................10
3.2.1. The "atom:name" Element ............................10
3.2.2. The "atom:uri" Element .............................10
3.2.3. The "atom:email" Element ...........................10
3.3. Date Constructs ...........................................10
4. Atom Element Definitions .......................................11
4.1. Container Elements ........................................11
4.1.1. The "atom:feed" Element ............................11
4.1.2. The "atom:entry" Element ...........................13
4.1.3. The "atom:content" Element .........................14
4.2. Metadata Elements .........................................17
4.2.1. The "atom:author" Element ..........................17
4.2.2. The "atom:category" Element ........................18
4.2.3. The "atom:contributor" Element .....................18
1. 序論…3 1.1. 例…3 1.2. 名前空間とバージョン…5 1.3. 記号法のコンベンション…5 2. 原子ドキュメント…6 3. 一般的な原子構造物…7 3.1. テキスト構造物…7 3.1.1. 「タイプ」属性…8 3.2. 人の構造物…10 3.2.1. 「原子: 」 要素を命名してください…10 3.2.2. 「原子: uri」要素…10 3.2.3. 「原子: メールしてください」という要素…10 3.3. 構造物の日付を入れてください…10 4. 原子要素定義…11 4.1. コンテナ要素…11 4.1.1. 「原子: 食べてください」という要素…11 4.1.2. 「原子: エントリー、」 要素…13 4.1.3. 「原子: 」 要素を満足させてください…14 4.2. メタデータ要素…17 4.2.1. 「原子: 」 要素を書いてください…17 4.2.2. 「原子: カテゴリ、」 要素…18 4.2.3. 「原子: 貢献者、」 要素…18
Nottingham & Sayre Standards Track [Page 1] RFC 4287 Atom Format December 2005
ノッティンガムとセアー規格は原子形式2005年12月にRFC4287を追跡します[1ページ]。
4.2.4. The "atom:generator" Element .......................18
4.2.5. The "atom:icon" Element ............................19
4.2.6. The "atom:id" Element ..............................19
4.2.7. The "atom:link" Element ............................21
4.2.8. The "atom:logo" Element ............................23
4.2.9. The "atom:published" Element .......................23
4.2.10. The "atom:rights" Element .........................24
4.2.11. The "atom:source" Element .........................24
4.2.12. The "atom:subtitle" Element .......................25
4.2.13. The "atom:summary" Element ........................25
4.2.14. The "atom:title" Element ..........................25
4.2.15. The "atom:updated" Element ........................25
5. Securing Atom Documents ........................................26
5.1. Digital Signatures ........................................26
5.2. Encryption ................................................27
5.3. Signing and Encrypting ....................................28
6. Extending Atom .................................................28
6.1. Extensions from Non-Atom Vocabularies .....................28
6.2. Extensions to the Atom Vocabulary .........................28
6.3. Processing Foreign Markup .................................28
6.4. Extension Elements ........................................29
6.4.1. Simple Extension Elements ..........................29
6.4.2. Structured Extension Elements ......................29
7. IANA Considerations ............................................30
7.1. Registry of Link Relations ................................31
8. Security Considerations ........................................31
8.1. HTML and XHTML Content ....................................31
8.2. URIs ......................................................31
8.3. IRIs ......................................................31
8.4. Spoofing ..................................................31
8.5. Encryption and Signing ....................................32
9. References .....................................................32
9.1. Normative References ......................................32
9.2. Informative References ....................................34
Appendix A. Contributors ..........................................35
Appendix B. RELAX NG Compact Schema ...............................35
4.2.4. 「原子: ジェネレータ、」 要素…18 4.2.5. 「原子: アイコン、」 要素…19 4.2.6. 「原子: イド、」 要素…19 4.2.7. 「原子: リンクしてください」という要素…21 4.2.8. 「原子: ロゴ、」 要素…23 4.2.9. 「原子: 」 要素を発行します…23 4.2.10. 「原子: 」 要素をまっすぐにします…24 4.2.11. 「原子: 」 要素の出典を明示してください…24 4.2.12. 「原子: 」 要素に字幕をつけてください…25 4.2.13. 「原子: 概要、」 要素…25 4.2.14. 「原子: 」 要素を題をつけてください…25 4.2.15. 「原子: 」 要素をアップデートします…25 5. 原子ドキュメントを固定します…26 5.1. Digital署名…26 5.2. 暗号化…27 5.3. 署名して、暗号化します。28 6. 原子を広げています…28 6.1. 非原子ボキャブラリーからの拡大…28 6.2. 原子ボキャブラリーへの拡大…28 6.3. 外国マーク付けを処理します…28 6.4. 拡大要素…29 6.4.1. 単純拡大Elements…29 6.4.2. Extension Elementsを構造化します…29 7. IANA問題…30 7.1. リンク関係の登録…31 8. セキュリティ問題…31 8.1. HTMLとXHTML内容…31 8.2. URI…31 8.3. 虹彩…31 8.4. だまします…31 8.5. 暗号化と署名…32 9. 参照…32 9.1. 標準の参照…32 9.2. 有益な参照…34 付録A.貢献者…35付録B.はNGのコンパクトな図式を弛緩します…35
Nottingham & Sayre Standards Track [Page 2] RFC 4287 Atom Format December 2005
ノッティンガムとセアー規格は原子形式2005年12月にRFC4287を追跡します[2ページ]。
1. Introduction
1. 序論
Atom is an XML-based document format that describes lists of related information known as "feeds". Feeds are composed of a number of items, known as "entries", each with an extensible set of attached metadata. For example, each entry has a title.
原子は「給送」として知られている関連する情報のリストについて説明するXMLベースのドキュメント・フォーマットです。 給送は広げることができるセットの添付のメタデータでそれぞれ「エントリー」として知られている項目の数から構成されます。 例えば、各エントリーには、タイトルがあります。
The primary use case that Atom addresses is the syndication of Web content such as weblogs and news headlines to Web sites as well as directly to user agents.
使用がケースに入れるAtomが扱う予備選挙はウェブサイトへのウェブログやニュース見出しと直接ユーザエージェントへのウェブ内容のシンジケート組織化です。
1.1. Examples
1.1. 例
A brief, single-entry Atom Feed Document:
簡潔で、単一のエントリーのAtom Feed Document:
<?xml version="1.0" encoding="utf-8"?> <feed xmlns="http://www.w3.org/2005/Atom">
<?xmlバージョン=、「=「utf-8インチ?」をコード化する1インチ><給送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>
" http://example.org/ "/><タイトル>Example Feed</タイトル><リンクhref=<は>2003-12-13T18:30:02Z</アップデートされた><作者><名前>ジョン・ドウ</名の></作者><イド>つぼ:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</イド>をアップデートしました。
<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>
" http://example.org/2003/12/13/atom03 "/><イド>つぼ:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</イド><の>の<のタイトルの>Atomによる動力付きのRobots Run Amokエントリー</タイトル><リンクhref=<は>2003-12-13T18:30:02Z</アップデートされた><概要>Someテキスト</概要></エントリー>をアップデートしました。
</feed>
</給送>。
Nottingham & Sayre Standards Track [Page 3] RFC 4287 Atom Format December 2005
ノッティンガムとセアー規格は原子形式2005年12月にRFC4287を追跡します[3ページ]。
A more extensive, single-entry Atom Feed Document:
より多くの大規模で、単一のエントリーのAtom Feed Document:
<?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>
<?xmlバージョン=、「=「utf-8インチ?」をコード化する1インチ><給送xmlnsが等しい、「 http://www.w3.org/2005/Atom 「><タイトルタイプ=」テキスト、「マーク</タイトル><への>潜水がタイプ=に字幕をつける、「htmlに、「取り組みのずっと</emな>が入ったこの楽な</が>が<であると字幕をつけさせる>A<em>は>2005-07-31T12:29:29Z</アップデートされた><イド>タグをアップデートしました: 例」; org、2003:; 3 ><リンクrel=" http://example.org/ "/「自己」タイプ=「アプリケーション/原子+xml」href=" http://example.org/feed.atom "/>「アン」「代替の」タイプ=「テキスト/html」</イド><リンクrel=hreflang=href=<は>Copyright(c)2003を正します; 「マークPilgrim</権利><ジェネレータuri=" http://www.example.com/ "バージョン=「1インチの>Example Toolkit</ジェネレータ><エントリー><タイトル>Atom草稿-07スナップ</タイトル><リンクrel=」補欠」><リンクrel=タイプ=「テキスト/html」href=" http://example.org/2005/04/02/atom "/「包囲」タイプは「1337」href=" http://example.org/audio/ph34r_my_podcast.mp3 "/><イド>「オーディオ/mpeg」の長さ=タグと等しいです:; 例; org、2003、: 3.2397、</イド><は>2005-07-31T12: 29をアップデートしました: 29Z</アップデートされた><が>2003-12-13T08: 29:29-04:00</発行された>の<名前>マークPilgrim<作者></名の><uri>http: //example.org/</uri> <email>f8dy@example.com を発行した、lt;、/メール、gt;、lt;、/作者>。<貢献者><名前>サムRuby</名の></貢献者><貢献者><名前>ジョーグレゴリオ</名の></貢献者><content typeは"xhtml"xmlと等しいです: langは「アン」xmlと等しいです: =を基礎づけてください、「 http://diveintomark.org/ 、「><div xmlnsが等しい、「 http://www.w3.org/1999/xhtml 「><p><i>Update。」; Atom草稿は終わっています。</i></p></div></内容></エントリー></は>に食べさせます。
Nottingham & Sayre Standards Track [Page 4] RFC 4287 Atom Format December 2005
ノッティンガムとセアー規格は原子形式2005年12月にRFC4287を追跡します[4ページ]。
1.2. Namespace and Version
1.2. 名前空間とバージョン
The XML Namespaces URI [W3C.REC-xml-names-19990114] for the XML data format described in this specification is:
この仕様で説明されたXMLデータの形式のためのXML Namespaces URI[W3C. REC-xml名19990114]は以下の通りです。
http://www.w3.org/2005/Atom
http://www.w3.org/2005/Atom
For convenience, this data format may be referred to as "Atom 1.0". This specification uses "Atom" internally.
便利において、このデータの形式は「原子1インチ」と呼ばれるかもしれません。 この仕様は内部的に「原子」を使用します。
1.3. Notational Conventions
1.3. 記号法のコンベンション
This specification describes conformance in terms of two artifacts: Atom Feed Documents and Atom Entry Documents. Additionally, it places some requirements on Atom Processors.
この仕様は2個の人工物に関して順応について説明します: 原子給送ドキュメントと原子エントリードキュメント。 さらに、それはいくつかの要件をAtom Processorsに置きます。
This specification uses the namespace prefix "atom:" for the Namespace URI identified in Section 1.2, above. Note that the choice of namespace prefix is arbitrary and not semantically significant.
この仕様が名前空間接頭語を使用する、「原子:」 セクション1.2で特定されて、上のNamespace URIのために。 名前空間接頭語の選択が任意であって、意味的に重要でないことに注意してください。
Atom is specified using terms from the XML Infoset [W3C.REC-xml-infoset-20040204]. However, this specification uses a shorthand for two common terms: the phrase "Information Item" is omitted when naming Element Information Items and Attribute Information Items. Therefore, when this specification uses the term "element," it is referring to an Element Information Item in Infoset terms. Likewise, when it uses the term "attribute," it is referring to an Attribute Information Item.
原子は、XML Infoset[W3C. REC-xml-infoset-20040204]からの用語を使用することで指定されます。 しかしながら、この仕様は2回の一般的な期間、速記を使用します: 情報ItemsとAttribute情報ItemsとElementを命名するとき、「情報項目」という句は省略されます。したがって、この仕様が「要素」という用語を使用すると、それはInfoset用語によるElement情報Itemについて言及しています。同様に、「属性」という用語を使用すると、Attribute情報Itemについて言及しています。
Some sections of this specification are illustrated with fragments of a non-normative RELAX NG Compact schema [RELAX-NG]. However, the text of this specification provides the definition of conformance. A complete schema appears in Appendix B.
この仕様の数人のセクションが非標準のRELAX NG Compact図式[RELAX-NG]の断片で例証されます。 しかしながら、この仕様のテキストは順応の定義を提供します。 完全な図式はAppendix Bに現れます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119], as scoped to those conformance targets.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「[RFC2119]、「推薦され」て、「5月」の、そして、「任意」のNOTはそれらの順応目標に見られて、BCP14で説明されるように本書では解釈されることであるべきですか?
Nottingham & Sayre Standards Track [Page 5] RFC 4287 Atom Format December 2005
ノッティンガムとセアー規格は原子形式2005年12月にRFC4287を追跡します[5ページ]。
2. Atom Documents
2. 原子ドキュメント
This specification describes two kinds of Atom Documents: Atom Feed Documents and Atom Entry Documents.
この仕様は2種類のAtom Documentsについて説明します: 原子給送ドキュメントと原子エントリードキュメント。
An Atom Feed Document is a representation of an Atom feed, including metadata about the feed, and some or all of the entries associated with it. Its root is the atom:feed element.
Atom Feed DocumentはAtom給送の表現です、それに関連しているエントリーの給送に関するメタデータと、いくつかかすべてを含んでいて。 根は原子です: 給電素子。
An Atom Entry Document represents exactly one Atom entry, outside of the context of an Atom feed. Its root is the atom:entry element.
Atom Entry Documentはちょうど1つのAtomエントリー、Atom給送の文脈の外部を表します。 根は原子です: エントリー要素。
namespace atom = "http://www.w3.org/2005/Atom" start = atomFeed | atomEntry
名前空間原子=" http://www.w3.org/2005/Atom "始めはatomFeedと等しいです。| atomEntry
Both kinds of Atom Documents are specified in terms of the XML Information Set, serialized as XML 1.0 [W3C.REC-xml-20040204] and identified with the "application/atom+xml" media type. Atom Documents MUST be well-formed XML. This specification does not define a DTD for Atom Documents, and hence does not require them to be valid (in the sense used by XML).
Atom Documentsの両方の種類は、XML情報Setに関して指定されて、XML1.0[W3C. REC-xml-20040204]として連載されて、「アプリケーション/原子+xml」メディアタイプと同一視されています。 原子Documentsは整形式のXMLであるに違いありません。 この仕様は、Atom DocumentsのためにDTDを定義しないで、またしたがって、彼らが有効であることを必要としません(XMLによって使用された意味で)。
Atom allows the use of IRIs [RFC3987]. Every URI [RFC3986] is also an IRI, so a URI may be used wherever below an IRI is named. There are two special considerations: (1) when an IRI that is not also a URI is given for dereferencing, it MUST be mapped to a URI using the steps in Section 3.1 of [RFC3987] and (2) when an IRI is serving as an atom:id value, it MUST NOT be so mapped, so that the comparison works as described in Section 4.2.6.1.
原子はIRIs[RFC3987]の使用を許します。 また、あらゆるURI[RFC3986]がIRIであるので、IRIが以下でどこで命名されても、URIは使用されるかもしれません。 2つの特別な問題があります: (1) 「反-参照をつけ」るためにまたURIでないIRIを与えるとき、(2) [RFC3987]のセクション3.1でステップを使用して、IRIが原子として勤めているとき、それをURIに写像しなければなりません: イド値、そのようにそれを写像してはいけません、比較がセクション4.2.6で.1に説明されるように働くように
Any element defined by this specification MAY have an xml:base attribute [W3C.REC-xmlbase-20010627]. When xml:base is used in an Atom Document, it serves the function described in section 5.1.1 of [RFC3986], establishing the base URI (or IRI) for resolving any relative references found within the effective scope of the xml:base attribute.
この仕様で定義されたどんな要素もxmlを持っているかもしれません: 基本属性[W3C. REC-xmlbase-20010627]。 xml: ベースがAtom Documentで使用されるとき、.1セクション5.1[RFC3986]で説明された機能を果たします、xmlの有効な範囲の中で見つけられたどんな相対参照も決議するために、ベースURI(または、IRI)を確立して: 基本属性。
Any element defined by this specification MAY have an xml:lang attribute, whose content indicates the natural language for the element and its descendents. The language context is only significant for elements and attributes declared to be "Language- Sensitive" by this specification. Requirements regarding the content and interpretation of xml:lang are specified in XML 1.0 [W3C.REC-xml-20040204], Section 2.12.
この仕様で定義されたどんな要素もxmlを持っているかもしれません: lang属性。その内容は要素とそのdescendentsのために自然言語を示します。 この仕様で「言語敏感である」と申告された要素と属性だけに、言語文脈は重要です。 xml: langの内容と解釈に関する要件はXML1.0[W3C. REC-xml-20040204]、セクション2.12で指定されます。
Nottingham & Sayre Standards Track [Page 6] RFC 4287 Atom Format December 2005
ノッティンガムとセアー規格は原子形式2005年12月にRFC4287を追跡します[6ページ]。
atomCommonAttributes =
attribute xml:base { atomUri }?,
attribute xml:lang { atomLanguageTag }?,
undefinedAttribute*
undefinedAttribute*、atomCommonAttributes=はxml: ベースatomUriを結果と考えて、xml: lang atomLanguageTagを結果と考えます。
Atom is an extensible format. See Section 6 of this document for a full description of how Atom Documents can be extended.
原子は広げることができる形式です。 どうAtom Documentsを広げることができるかに関する余すところのない解説に関してこのドキュメントのセクション6を見てください。
Atom Processors MAY keep state sourced from Atom Feed Documents and combine them with other Atom Feed Documents, in order to facilitate a contiguous view of the contents of a feed. The manner in which Atom Feed Documents are combined in order to reconstruct a feed (e.g., updating entries and metadata, dealing with missing entries) is out of the scope of this specification.
原子ProcessorsはAtom Feed Documentsから状態に出典を明示し続けて、他のAtom Feed Documentsに彼らを結合するかもしれません、給送のコンテンツの隣接の図を容易にするために。 この仕様の範囲の外にAtom Feed Documentsが給送(例えば、なくなったエントリーに対処して、エントリーとメタデータをアップデートする)を再建するために結合されている方法があります。
3. Common Atom Constructs
3. 一般的な原子構造物
Many of Atom's elements share a few common structures. This section defines those structures and their requirements for convenient reference by the appropriate element definitions.
Atomの要素の多くがいくつかの一般的な構造を共有します。 このセクションは適切な要素定義で便利な参照のためのそれらの構造とそれらの要件を定義します。
When an element is identified as being a particular kind of construct, it inherits the corresponding requirements from that construct's definition in this section.
要素が特定の種類の構造物であるとして特定されるとき、それはこのセクションとのその構造物の定義から対応する要件を引き継ぎます。
Note that there MUST NOT be any white space in a Date construct or in any IRI. Some XML-emitting implementations erroneously insert white space around values by default, and such implementations will emit invalid Atom Documents.
少しの余白もDate構造物かどんなIRIにもあるはずがないことに注意してください。 いくつかのXMLを放っている実装がデフォルトで誤って値の周りの余白を挿入します、そして、そのような実装は無効のAtom Documentsを放つでしょう。
3.1. Text Constructs
3.1. テキスト構造物
A Text construct contains human-readable text, usually in small quantities. The content of Text constructs is Language-Sensitive.
Text構造物は通常少量に人間読み込み可能なテキストを含んでいます。 Text構造物の内容はLanguage機密です。
atomPlainTextConstruct =
atomCommonAttributes,
attribute type { "text" | "html" }?,
text
「テキスト」| atomPlainTextConstruct=atomCommonAttributes、属性タイプ"html?"、テキスト
atomXHTMLTextConstruct =
atomCommonAttributes,
attribute type { "xhtml" },
xhtmlDiv
atomXHTMLTextConstructはatomCommonAttributes、属性タイプ"xhtml"xhtmlDivと等しいです。
atomTextConstruct = atomPlainTextConstruct | atomXHTMLTextConstruct
atomTextConstructはatomPlainTextConstructと等しいです。| atomXHTMLTextConstruct
Nottingham & Sayre Standards Track [Page 7] RFC 4287 Atom Format December 2005
ノッティンガムとセアー規格は原子形式2005年12月にRFC4287を追跡します[7ページ]。
3.1.1. The "type" Attribute
3.1.1. 「タイプ」属性
Text constructs MAY have a "type" attribute. When present, the value MUST be one of "text", "html", or "xhtml". If the "type" attribute is not provided, Atom Processors MUST behave as though it were present with a value of "text". Unlike the atom:content element defined in Section 4.1.3, MIME media types [MIMEREG] MUST NOT be used as values for the "type" attribute on Text constructs.
テキスト構造物には、「タイプ」属性があるかもしれません。 存在しているとき、値は「テキスト」、"html"、または"xhtml"の1つでなければなりません。 「タイプ」属性が提供されないなら、まるでそれが「テキスト」の値について存在しているかのようにAtom Processorsは振る舞わなければなりません。 原子: セクション4.1.3、MIMEメディアで定義された満足している要素と異なって、Text構造物の「タイプ」属性に値としてタイプ[MIMEREG]を使用してはいけません。
3.1.1.1. Text
3.1.1.1. テキスト
Example atom:title with text content:
例の原子: テキスト内容があるタイトル:
...
<title type="text">
Less: <
</title>
...
... <タイトルタイプが等しい、「テキスト、「>Less:」 <</タイトル>…
If the value is "text", the content of the Text construct MUST NOT contain child elements. Such text is intended to be presented to humans in a readable fashion. Thus, Atom Processors MAY collapse white space (including line breaks) and display the text using typographic techniques such as justification and proportional fonts.
値が「テキスト」であるなら、Text構造物の内容は子供要素を含んではいけません。 そのようなテキストによって読み込み可能なファッションで人間に提示されることを意図します。 したがって、正当化やプロポーショナルフォントなどの印刷のテクニックを使用して、Atom Processorsは余白(ラインブレイクを含んでいる)を潰して、テキストを表示するかもしれません。
3.1.1.2. HTML
3.1.1.2. HTML
Example atom:title with HTML content:
例の原子: HTML内容があるタイトル:
...
<title type="html">
Less: <em> &lt; </em>
</title>
...
... <タイトルタイプが等しい、「html、「>Less:」 <em><。 </em></タイトル>…
If the value of "type" is "html", the content of the Text construct MUST NOT contain child elements and SHOULD be suitable for handling as HTML [HTML]. Any markup within MUST be escaped; for example, "<br>" as "<br>". HTML markup within SHOULD be such that it could validly appear directly within an HTML <DIV> element, after unescaping. Atom Processors that display such content MAY use that markup to aid in its display.
「タイプ」の値が"html"、Text構造物の内容が子供要素とSHOULDを含んではいけないということであるなら、HTML[HTML]として取り扱いに適してください。 中からどんなマークアップからも逃げなければなりません。 例えば、「<Br>」としての「<Br>。」 HTML<DIV>要素直接非エスケープしていた後にHTMLマーク付けは、確実に現れることができるためのSHOULDの中のそうです。 そのような内容を表示する原子Processorsは、ディスプレイで支援するのにそのマークアップを使用するかもしれません。
Nottingham & Sayre Standards Track [Page 8] RFC 4287 Atom Format December 2005
ノッティンガムとセアー規格は原子形式2005年12月にRFC4287を追跡します[8ページ]。
3.1.1.3. XHTML
3.1.1.3. XHTML
Example atom:title with XHTML content:
例の原子: XHTML内容があるタイトル:
...
<title type="xhtml" xmlns:xhtml="http://www.w3.org/1999/xhtml">
<xhtml:div>
Less: <xhtml:em> < </xhtml:em>
</xhtml:div>
</title>
...
... <タイトルタイプが"xhtml"xmlns: xhtml=と等しい、「 http://www.w3.org/1999/xhtml 、「><は: div>Lessをxhtmlします」。 <xhtml: em><</xhtml: em></xhtml: div></タイトル>…
If the value of "type" is "xhtml", the content of the Text construct MUST be a single XHTML div element [XHTML] and SHOULD be suitable for handling as XHTML. The XHTML div element itself MUST NOT be considered part of the content. Atom Processors that display the content MAY use the markup to aid in displaying it. The escaped versions of characters such as "&" and ">" represent those characters, not markup.
「タイプ」の値が"xhtml"、Text構造物の内容がただ一つのXHTML div要素[XHTML]とSHOULDであるに違いないということであるなら、XHTMLとして取り扱いに適してください。 内容の一部であるとXHTML div要素自体を考えてはいけません。 内容を表示する原子Processorsは、それを表示する際に支援するのにマークアップを使用するかもしれません。 “&"や">"などのキャラクタの逃げられたバージョンはマーク付けではなく、それらのキャラクタの代理をします。
Examples of valid XHTML content:
有効な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>
...
... <概要タイプが等しい、「xhtml、「><div xmlnsが等しい、「 http://www.w3.org/1999/xhtml 、「>Thisは<b>XHTML</b>内容です」。 </div></概要>… <概要タイプが等しい、「xhtml、「><xhtml:div xmlns:xhtmlが等しい、「 http://www.w3.org/1999/xhtml 、「>Thisは<xhtmlです: b>XHTML</xhtml: b>内容」 </xhtml: div></概要>…
The following example assumes that the XHTML namespace has been bound to the "xh" prefix earlier in the document:
以下の例は、より早くドキュメントで"xh"接頭語にXHTML名前空間を縛ってあると仮定します:
...
<summary type="xhtml">
<xh:div>
This is <xh:b>XHTML</xh:b> content.
</xh:div>
</summary>
...
... <概要タイプが等しい、「xhtmlに、「><xh: div>Thisは<xhです: b>XHTML</xh: b>内容」 </xh: div></概要>…
Nottingham & Sayre Standards Track [Page 9] RFC 4287 Atom Format December 2005
ノッティンガムとセアー規格は原子形式2005年12月にRFC4287を追跡します[9ページ]。
3.2. Person Constructs
3.2. 人の構造物
A Person construct is an element that describes a person, corporation, or similar entity (hereafter, 'person').
Person構造物は人、会社、または同様の実体(将来、'人')について説明する要素です。
atomPersonConstruct =
atomCommonAttributes,
(element atom:name { text }
& element atom:uri { atomUri }?
& element atom:email { atomEmailAddress }?
& extensionElement*)
atomPersonConstructはatomCommonAttributesと等しいです。(要素原子: 名前テキストと要素原子: uri atomUri要素原子: (メールatomEmailAddress)とextensionElement*)
This specification assigns no significance to the order of appearance of the child elements in a Person construct. Person constructs allow extension Metadata elements (see Section 6.4).
この仕様はPerson構造物の子供要素の外観の注文に意味を全く割り当てません。 人の構造物は拡大Metadata要素を許容します(セクション6.4を見てください)。
3.2.1. The "atom:name" Element
3.2.1. 「原子: 」 要素を命名してください。
The "atom:name" element's content conveys a human-readable name for the person. The content of atom:name is Language-Sensitive. Person constructs MUST contain exactly one "atom:name" element.
「という原子: 」 要素のものを命名してください内容は人のために人間読み込み可能な名前を伝えます。 原子の内容: 名前はLanguage敏感です。 人の構造物がちょうど1つを含まなければならない、「原子: 」 要素を命名してください。
3.2.2. The "atom:uri" Element
3.2.2. 「原子: uri」要素
The "atom:uri" element's content conveys an IRI associated with the person. Person constructs MAY contain an atom:uri element, but MUST NOT contain more than one. The content of atom:uri in a Person construct MUST be an IRI reference [RFC3987].
「原子: uri」要素の内容は人に関連しているIRIを運びます。 人の構造物は、原子: uri要素を含むかもしれませんが、1つ以上は含んではいけません。 原子の内容: Person構造物のuriはIRI参照であるに違いありません[RFC3987]。
3.2.3. The "atom:email" Element
3.2.3. 「原子: メールしてください」という要素
The "atom:email" element's content conveys an e-mail address associated with the person. Person constructs MAY contain an atom:email element, but MUST NOT contain more than one. Its content MUST conform to the "addr-spec" production in [RFC2822].
「原子: メールしてください」という要素の内容は人に関連しているEメールアドレスを伝えます。 人の構造物は、原子: メール要素を含むかもしれませんが、1つ以上は含んではいけません。 内容は[RFC2822]での「addr-仕様」生産に従わなければなりません。
3.3. Date Constructs
3.3. 日付の構造物
A Date construct is an element whose content MUST conform to the "date-time" production in [RFC3339]. In addition, an uppercase "T" character MUST be used to separate date and time, and an uppercase "Z" character MUST be present in the absence of a numeric time zone offset.
Date構造物は内容が[RFC3339]での「日付-時間」生産に従わなければならない要素です。 さらに、日時を切り離すのに大文字している「T」キャラクタを使用しなければなりません、そして、大文字している「Z」キャラクタは数値時間帯のオフセットがないとき出席しているに違いありません。
atomDateConstruct =
atomCommonAttributes,
xsd:dateTime
atomCommonAttributes、atomDateConstruct=xsd: dateTime
Nottingham & Sayre Standards Track [Page 10] RFC 4287 Atom Format December 2005
ノッティンガムとセアー規格は原子形式2005年12月にRFC4287を追跡します[10ページ]。
Such date values happen to be compatible with the following specifications: [ISO.8601.1988], [W3C.NOTE-datetime-19980827], and [W3C.REC-xmlschema-2-20041028].
そのような日付の値はたまたま以下の仕様と互換性があります: [ISO.8601.1988] [W3C.注意-datetime-19980827]、および[W3C. REC-xmlschema-2-20041028。]
Example Date constructs:
例の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>
<は>2003-12-13T18: 30をアップデートしました: 02Z</アップデートされた><は>2003-12-13T18: 30をアップデートしました: 02.25Z</アップデートされた><は>2003-12-13T18をアップデートしました: 30:02の+01:00</アップデートされた><は>2003-12-13T18: 30:02.25の+01:00</アップデートされた>をアップデートしました。
Date values SHOULD be as accurate as possible. For example, it would be generally inappropriate for a publishing system to apply the same timestamp to several entries that were published during the course of a single day.
SHOULDと値の日付を入れてください。できるだけ正確であってください。 例えば、一般に、出版システムが1日のコースの間に発行されたいくつかのエントリーに同じタイムスタンプを適用するのは、不適当でしょう。
4. Atom Element Definitions
4. 原子要素定義
4.1. Container Elements
4.1. コンテナ要素
4.1.1. The "atom:feed" Element
4.1.1. 「原子: 食べてください」という要素
The "atom:feed" element is the document (i.e., top-level) element of an Atom Feed Document, acting as a container for metadata and data associated with the feed. Its element children consist of metadata elements followed by zero or more atom:entry child elements.
「原子: 食べてください」という要素はAtom Feed Documentのドキュメント(すなわち、先端レベル)要素です、メタデータとデータのためのコンテナが給送と交際しながら行動して。 要素子供は、より多くの原子: ゼロがあとに続いたメタデータ要素かエントリー子供要素から成ります。
atomFeed =
element atom:feed {
atomCommonAttributes,
(atomAuthor*
& atomCategory*
& atomContributor*
& atomGenerator?
& atomIcon?
& atomId
& atomLink*
& atomLogo?
& atomRights?
& atomSubtitle?
& atomTitle
& atomUpdated
& extensionElement*),
atomEntry*
}
atomFeed=要素原子: 食べてください。{ atomCommonAttributes(atomAuthor*、atomCategory*、atomContributor*、およびatomGenerator? atomIcon-- atomId&atomLink*とatomLogo-- atomRights-- atomSubtitle-- atomTitle&atomUpdated&extensionElement*), atomEntry*
This specification assigns no significance to the order of atom:entry elements within the feed.
この仕様は意味を全く原子の注文に割り当てません: 給送の中のエントリー要素。
Nottingham & Sayre Standards Track [Page 11] RFC 4287 Atom Format December 2005
ノッティンガムとセアー規格は原子形式2005年12月にRFC4287を追跡します[11ページ]。
The following child elements are defined by this specification (note that the presence of some of these elements is required):
以下の子供要素はこの仕様で定義されます(これらのいくつかの要素の存在が必要であることに注意してください):
o atom:feed elements MUST contain one or more atom:author elements,
unless all of the atom:feed element's child atom:entry elements
contain at least one atom:author element.
o atom:feed elements MAY contain any number of atom:category
elements.
o atom:feed elements MAY contain any number of atom:contributor
elements.
o atom:feed elements MUST NOT contain more than one atom:generator
element.
o atom:feed elements MUST NOT contain more than one atom:icon
element.
o atom:feed elements MUST NOT contain more than one atom:logo
element.
o atom:feed elements MUST contain exactly one atom:id element.
o atom:feed elements SHOULD contain one atom:link element with a rel
attribute value of "self". This is the preferred URI for
retrieving Atom Feed Documents representing this Atom feed.
o atom:feed elements MUST NOT contain more than one atom:link
element with a rel attribute value of "alternate" that has the
same combination of type and hreflang attribute values.
o atom:feed elements MAY contain additional atom:link elements
beyond those described above.
o atom:feed elements MUST NOT contain more than one atom:rights
element.
o atom:feed elements MUST NOT contain more than one atom:subtitle
element.
o atom:feed elements MUST contain exactly one atom:title element.
o atom:feed elements MUST contain exactly one atom:updated element.
o 原子: 給電素子は1つ以上の原子を含まなければなりません: 作者要素; 原子のすべて: 給電素子の子供原子: エントリー要素は少なくとも1つの原子を含んでいます: 作者要素でないなら、o原子: 給電素子はいろいろな原子を含むかもしれません: カテゴリ要素o原子: 給電素子はいろいろな原子を含むかもしれません: 貢献者要素o原子: 給電素子は1つ以上の原子を含んではいけません: ジェネレータ要素; o原子: 給電素子は1つ以上の原子を含んではいけません: アイコン要素o原子: 給電素子は1つ以上の原子を含んではいけません: ロゴ要素o原子: 給電素子はちょうど1つの原子を含まなければなりません: イド要素o原子: 給電素子SHOULDは1つの原子を含んでいます: 「自己」のrel属性値に要素をリンクしてください。 これは、このAtom給送を表すAtom Feed Documentsを検索するための都合のよいURIです。o原子: 給電素子は1つ以上の原子を含んではいけません: hreflang属性値タイプの同じ組み合わせを持っている「補欠」とo原子のrel属性値に要素をリンクしてください: 給電素子は追加原子を含むかもしれません: 上で説明されたものを超えて要素をリンクしてください; o原子: 給電素子は1つ以上の原子を含んではいけません: 権利要素o原子: 給電素子は1つ以上の原子を含んではいけません: 要素o原子に字幕をつけてください: 給電素子はちょうど1つの原子を含まなければなりません: タイトル要素o原子: 給電素子はちょうど1つの原子を含まなければなりません: 要素をアップデートします。
If multiple atom:entry elements with the same atom:id value appear in an Atom Feed Document, they represent the same entry. Their atom:updated timestamps SHOULD be different. If an Atom Feed Document contains multiple entries with the same atom:id, Atom Processors MAY choose to display all of them or some subset of them. One typical behavior would be to display only the entry with the latest atom:updated timestamp.
複数の原子: 同じ原子: イド値に従ったエントリー要素がAtom Feed Documentに現れるなら、彼らは同じエントリーを表します。 それらの原子: アップデートされたタイムスタンプSHOULD、異なってください。 Atom Feed Documentが同じ原子: イドによる多回入国を含んでいるなら、Atom Processorsは、彼らのすべてか彼らの何らかの部分集合を表示するのを選ぶかもしれません。 1つの典型的な振舞いは最新の原子によるエントリーだけを表示するだろうことです: タイムスタンプをアップデートします。
4.1.1.1. Providing Textual Content
4.1.1.1. 原文の内容を提供します。
Experience teaches that feeds that contain textual content are in general more useful than those that do not. Some applications (one example is full-text indexers) require a minimum amount of text or (X)HTML to function reliably and predictably. Feed producers should be aware of these issues. It is advisable that each atom:entry element contain a non-empty atom:title element, a non-empty
経験は、一般に、原文の内容を含む給送がそうであることを教えます。そうしないそれらより役に立ちます。 いくつかのアプリケーション(1つの例が全文索引作成者である)が、最小の量のテキストか(X)HTMLが確かに予想どおりに機能するのを必要とします。 給送プロデューサーはこれらの問題を意識しているべきです。 各原子: エントリー要素が非空の状態で非空の原子: タイトル要素、aを含むのは、賢明です。
Nottingham & Sayre Standards Track [Page 12] RFC 4287 Atom Format December 2005
ノッティンガムとセアー規格は原子形式2005年12月にRFC4287を追跡します[12ページ]。
atom:content element when that element is present, and a non-empty atom:summary element when the entry contains no atom:content element. However, the absence of atom:summary is not an error, and Atom Processors MUST NOT fail to function correctly as a consequence of such an absence.
原子: エントリーであるときに、非空の原子: 概要要素は原子を全く含んでいません: その要素であることのときに、満足している要素は存在しています、そして、満足している要素。 しかしながら、原子の不在: 概要は誤りではありません、そして、Atom Processorsは必ずそのような不在の結果として正しく機能しなければなりません。
4.1.2. The "atom:entry" Element
4.1.2. 「原子: エントリー」、要素
The "atom:entry" element represents an individual entry, acting as a container for metadata and data associated with the entry. This element can appear as a child of the atom:feed element, or it can appear as the document (i.e., top-level) element of a stand-alone Atom Entry Document.
エントリーに関連している要素がコンテナとして機能する個人出場者を表す「原子: エントリー」メタデータとデータ。 この要素が原子: 給電素子の子供として現れることができますか、またはそれはスタンドアロンのAtom Entry Documentのドキュメント(すなわち、先端レベル)要素として現れることができます。
atomEntry =
element atom:entry {
atomCommonAttributes,
(atomAuthor*
& atomCategory*
& atomContent?
& atomContributor*
& atomId
& atomLink*
& atomPublished?
& atomRights?
& atomSource?
& atomSummary?
& atomTitle
& atomUpdated
& extensionElement*)
}
要素atomEntry=原子: エントリー{ atomCommonAttributes(atomAuthor*、atomCategory*、およびatomContent? atomContributor*、atomId&atomLink*、およびatomPublished-- atomRights-- atomSource-- atomSummary-- atomTitle&atomUpdated&extensionElement*) }
This specification assigns no significance to the order of appearance of the child elements of atom:entry.
この仕様は原子の子供要素の外観の注文に意味を全く割り当てません: エントリー。
The following child elements are defined by this specification (note that it requires the presence of some of these elements):
以下の子供要素はこの仕様で定義されます(これらのいくつかの要素を存在に要求することに注意してください):
o atom:entry elements MUST contain one or more atom:author elements,
unless the atom:entry contains an atom:source element that
contains an atom:author element or, in an Atom Feed Document, the
atom:feed element contains an atom:author element itself.
o atom:entry elements MAY contain any number of atom:category
elements.
o atom:entry elements MUST NOT contain more than one atom:content
element.
o atom:entry elements MAY contain any number of atom:contributor
elements.
o 原子: 給電素子は原子を含んでいます: 作者要素自体、エントリー要素は1つ以上の原子を含まなければなりません: 要素を書いてください、原子: エントリーが原子を含んでいない場合: 原子を含むソース要素: 要素かAtom Feed Documentの原子を書いてください: o原子: エントリー要素はいろいろな原子を含むかもしれません: カテゴリ要素o原子: エントリー要素は1つ以上の原子を含んではいけません: 満足している要素o原子: エントリー要素はいろいろな原子を含むかもしれません: 貢献者要素。
Nottingham & Sayre Standards Track [Page 13] RFC 4287 Atom Format December 2005
ノッティンガムとセアー規格は原子形式2005年12月にRFC4287を追跡します[13ページ]。
o atom:entry elements MUST contain exactly one atom:id element.
o atom:entry elements that contain no child atom:content element
MUST contain at least one atom:link element with a rel attribute
value of "alternate".
o atom:entry elements MUST NOT contain more than one atom:link
element with a rel attribute value of "alternate" that has the
same combination of type and hreflang attribute values.
o atom:entry elements MAY contain additional atom:link elements
beyond those described above.
o atom:entry elements MUST NOT contain more than one atom:published
element.
o atom:entry elements MUST NOT contain more than one atom:rights
element.
o atom:entry elements MUST NOT contain more than one atom:source
element.
o atom:entry elements MUST contain an atom:summary element in either
of the following cases:
* the atom:entry contains an atom:content that has a "src"
attribute (and is thus empty).
* the atom:entry contains content that is encoded in Base64;
i.e., the "type" attribute of atom:content is a MIME media type
[MIMEREG], but is not an XML media type [RFC3023], does not
begin with "text/", and does not end with "/xml" or "+xml".
o atom:entry elements MUST NOT contain more than one atom:summary
element.
o atom:entry elements MUST contain exactly one atom:title element.
o atom:entry elements MUST contain exactly one atom:updated element.
o 原子: エントリー要素はちょうど1つの原子を含まなければなりません: イド要素o原子: 子供原子がありません: 満足している要素を含むエントリー要素は少なくとも1つの原子を含まなければなりません: 「補欠」 o原子のrel属性値に要素をリンクしてください: エントリー要素は1つ以上の原子を含んではいけません: タイプとhreflang属性値の同じ組み合わせを持っている「補欠」のrel属性値に要素をリンクしてください; エントリー要素は追加原子を含むかもしれません: 上で説明されたものを超えて要素をリンクしてください。o原子: o原子: エントリー要素は1つ以上の原子を含んではいけません: 発行された要素o原子: エントリー要素は1つ以上の原子を含んではいけません: 権利要素o原子: エントリー要素は1つ以上の原子を含んではいけません: ソース要素o原子: エントリー要素は以下のケースのどちらかに原子: 概要要素を含まなければなりません: * 原子: エントリーは原子を含んでいます: "src"属性(そして、その結果、空である)がある内容。 * 原子: エントリーはBase64でコード化される内容を含んでいます。 「すなわち、原子の「タイプ」属性: 内容はMIMEメディアタイプ[MIMEREG]です、XMLメディアタイプ[RFC3023]でなく、また「テキスト/」で始まらないで、また」 /xmlで」 」 + xmlを終わらせないのを除いて」。o原子: エントリー要素は1つ以上の原子を含んではいけません: 概要要素o原子: エントリー要素はちょうど1つの原子を含まなければなりません: タイトル要素o原子: エントリー要素はちょうど1つの原子を含まなければなりません: 要素をアップデートします。
4.1.3. The "atom:content" Element
4.1.3. 「原子: 」 要素を満足させてください。
The "atom:content" element either contains or links to the content of the entry. The content of atom:content is Language-Sensitive.
「原子: 」 どちらかが含む要素かエントリーの内容へのリンクを満足させてください。 原子の内容: 内容はLanguage機密です。
atomInlineTextContent =
element atom:content {
atomCommonAttributes,
attribute type { "text" | "html" }?,
(text)*
}
要素atomInlineTextContent=原子: 内容「テキスト」| atomCommonAttributes、属性タイプ"html?"、(テキスト)*
atomInlineXHTMLContent =
element atom:content {
atomCommonAttributes,
attribute type { "xhtml" },
xhtmlDiv
}
要素atomInlineXHTMLContent=原子: 内容atomCommonAttributes、属性タイプ"xhtml"xhtmlDiv
Nottingham & Sayre Standards Track [Page 14] RFC 4287 Atom Format December 2005
ノッティンガムとセアー規格は原子形式2005年12月にRFC4287を追跡します[14ページ]。
atomInlineOtherContent =
element atom:content {
atomCommonAttributes,
attribute type { atomMediaType }?,
(text|anyElement)*
}
要素atomInlineOtherContent=原子: 内容atomCommonAttributes、属性タイプatomMediaType--、(テキスト| anyElement)*
atomOutOfLineContent =
element atom:content {
atomCommonAttributes,
attribute type { atomMediaType }?,
attribute src { atomUri },
empty
}
要素atomOutOfLineContent=原子: 内容atomCommonAttributes、属性タイプatomMediaType--、src atomUriを結果と考えてください、そして、空になってください。
atomContent = atomInlineTextContent
| atomInlineXHTMLContent
| atomInlineOtherContent
| atomOutOfLineContent
atomContentはatomInlineTextContentと等しいです。| atomInlineXHTMLContent| atomInlineOtherContent| atomOutOfLineContent
4.1.3.1. The "type" Attribute
4.1.3.1. 「タイプ」属性
On the atom:content element, the value of the "type" attribute MAY be one of "text", "html", or "xhtml". Failing that, it MUST conform to the syntax of a MIME media type, but MUST NOT be a composite type (see Section 4.2.6 of [MIMEREG]). If neither the type attribute nor the src attribute is provided, Atom Processors MUST behave as though the type attribute were present with a value of "text".
原子: 満足している要素の上では、「タイプ」属性の値は「テキスト」、"html"、または"xhtml"の1つであるかもしれません。 それに失敗して、それは、MIMEメディアタイプの構文に従わなければなりませんが、合成型であるはずがありません(.6セクション4.2[MIMEREG]を見てください)。 タイプ属性もsrc属性も提供されないなら、まるでタイプ属性が「テキスト」の値について存在しているかのようにAtom Processorsは振る舞わなければなりません。
4.1.3.2. The "src" Attribute
4.1.3.2. "src"属性
atom:content MAY have a "src" attribute, whose value MUST be an IRI reference [RFC3987]. If the "src" attribute is present, atom:content MUST be empty. Atom Processors MAY use the IRI to retrieve the content and MAY choose to ignore remote content or to present it in a different manner than local content.
原子: 内容には、値がIRI参照でなければならない[RFC3987]"src"属性があるかもしれません。 "src"属性が存在しているなら、原子: 内容は空であるに違いありません。 原子Processorsは、国内部品調達率より内容を検索するのにIRIを使用して、リモート内容を無視するか、または異なった方法でそれを提示するのを選ぶかもしれません。
If the "src" attribute is present, the "type" attribute SHOULD be provided and MUST be a MIME media type [MIMEREG], rather than "text", "html", or "xhtml". The value is advisory; that is to say, when the corresponding URI (mapped from an IRI, if necessary) is dereferenced, if the server providing that content also provides a media type, the server-provided media type is authoritative.
"src"属性が存在しているなら、「タイプ」属性SHOULDは提供されて、「テキスト」、"html"、または"xhtml"よりむしろMIMEメディアタイプ[MIMEREG]であるに違いありません。 値は顧問です。 また、内容がメディアタイプ、サーバで提供されたメディアにタイプを提供するならサーバが正式であるなら対応するURI(IRIから、必要なら、写像される)がすなわち、「反-参照をつけ」られると。
Nottingham & Sayre Standards Track [Page 15] RFC 4287 Atom Format December 2005
ノッティンガムとセアー規格は原子形式2005年12月にRFC4287を追跡します[15ページ]。
4.1.3.3. Processing Model
4.1.3.3. 処理モデル
Atom Documents MUST conform to the following rules. Atom Processors MUST interpret atom:content according to the first applicable rule.
原子Documentsは以下の規則に従わなければなりません。 原子Processorsは原子を解釈しなければなりません: 最初の適切な規則に従った内容。
1. If the value of "type" is "text", the content of atom:content
MUST NOT contain child elements. Such text is intended to be
presented to humans in a readable fashion. Thus, Atom Processors
MAY collapse white space (including line breaks), and display the
text using typographic techniques such as justification and
proportional fonts.
1. 「タイプ」の値が「テキスト」であるなら、原子の内容: 内容は子供要素を含んではいけません。 そのようなテキストによって読み込み可能なファッションで人間に提示されることを意図します。 したがって、Atom Processorsは余白を潰すかもしれません、そして、(ラインブレイクを含んでいて)正当化やプロポーショナルフォントなどの印刷のテクニックを使用することでテキストを表示してください。
2. If the value of "type" is "html", the content of atom:content
MUST NOT contain child elements and SHOULD be suitable for
handling as HTML [HTML]. The HTML markup MUST be escaped; for
example, "<br>" as "<br>". The HTML markup SHOULD be such
that it could validly appear directly within an HTML <DIV>
element. Atom Processors that display the content MAY use the
markup to aid in displaying it.
2. 原子の内容: 内容は「タイプ」の値が"html"であるなら、子供要素とSHOULDを含んではいけません。HTML[HTML]として取り扱いに適してください。 HTMLマークアップから逃げなければなりません。 例えば、「<Br>」としての「<Br>。」 HTMLマーク付けSHOULDは、確実に現れることができるためのそうです。HTML<DIV>要素の直接中で。 内容を表示する原子Processorsは、それを表示する際に支援するのにマークアップを使用するかもしれません。
3. If the value of "type" is "xhtml", the content of atom:content
MUST be a single XHTML div element [XHTML] and SHOULD be suitable
for handling as XHTML. The XHTML div element itself MUST NOT be
considered part of the content. Atom Processors that display the
content MAY use the markup to aid in displaying it. The escaped
versions of characters such as "&" and ">" represent those
characters, not markup.
3. 「タイプ」の値は"xhtml"です、原子の内容: 内容がただ一つのXHTML div要素[XHTML]とSHOULDであるに違いないなら、XHTMLとして取り扱いに適してください。 内容の一部であるとXHTML div要素自体を考えてはいけません。 内容を表示する原子Processorsは、それを表示する際に支援するのにマークアップを使用するかもしれません。 “&"や">"などのキャラクタの逃げられたバージョンはマーク付けではなく、それらのキャラクタの代理をします。
4. If the value of "type" is an XML media type [RFC3023] or ends
with "+xml" or "/xml" (case insensitive), the content of
atom:content MAY include child elements and SHOULD be suitable
for handling as the indicated media type. If the "src" attribute
is not provided, this would normally mean that the "atom:content"
element would contain a single child element that would serve as
the root element of the XML document of the indicated type.
4. 「「タイプ」の値がXMLメディアタイプ[RFC3023]であるか」 + xmlがある終わりが」 」 /xmlであるなら」(大文字と小文字を区別しない)、原子の内容: 内容は子供要素とSHOULDを含むかもしれません。示されたメディアがタイプするように取り扱いに適してください。 "src"属性が提供されないなら、通常、これは、表示のXMLドキュメントの要素が根として機能するただ一つの子供要素に含む「原子: 内容」要素がタイプされることを意味するでしょう。
5. If the value of "type" begins with "text/" (case insensitive),
the content of atom:content MUST NOT contain child elements.
5. 「テキスト/」が(大文字と小文字を区別しない)で「タイプ」の値が始まるなら、原子の内容: 内容は子供要素を含んではいけません。
6. For all other values of "type", the content of atom:content MUST
be a valid Base64 encoding, as described in [RFC3548], section 3.
When decoded, it SHOULD be suitable for handling as the indicated
media type. In this case, the characters in the Base64 encoding
MAY be preceded and followed in the atom:content element by white
space, and lines are separated by a single newline (U+000A)
character.
6. 「タイプ」の他の値、原子のすべての内容のために: 内容は[RFC3548]で説明されるようにセクション3をコード化する有効なBase64であるに違いありません。 いつが解読したか、そして、それはSHOULDです。示されたメディアがタイプするように取り扱いに適してください。 この場合、余白は、原子: 満足している要素でBase64コード化におけるキャラクタに先行されていて、ついて来るかもしれません、そして、系列はただ一つのニューライン(U+000A)キャラクタによって切り離されます。
Nottingham & Sayre Standards Track [Page 16] RFC 4287 Atom Format December 2005
ノッティンガムとセアー規格は原子形式2005年12月にRFC4287を追跡します[16ページ]。
4.1.3.4. Examples
4.1.3.4. 例
XHTML inline:
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>
...
... <content type=、「xhtml、「><div xmlnsが等しい、「 http://www.w3.org/1999/xhtml 、「>Thisは<b>XHTML</b>内容です」。 </div></内容>… <content type=、「xhtml、「><xhtml:div xmlns:xhtmlが等しい、「 http://www.w3.org/1999/xhtml 、「>Thisは<xhtmlです: b>XHTML</xhtml: b>内容」 </xhtml: div></内容>…
The following example assumes that the XHTML namespace has been bound to the "xh" prefix earlier in the document:
以下の例は、より早くドキュメントで"xh"接頭語にXHTML名前空間を縛ってあると仮定します:
...
<content type="xhtml">
<xh:div>
This is <xh:b>XHTML</xh:b> content.
</xh:div>
</content>
...
... <content type=、「xhtmlに、「><xh: div>Thisは<xhです: b>XHTML</xh: b>内容」 </xh: div></内容>…
4.2. Metadata Elements
4.2. メタデータ要素
4.2.1. The "atom:author" Element
4.2.1. 「原子: 」 要素を書いてください。
The "atom:author" element is a Person construct that indicates the author of the entry or feed.
原子: 」 要素を書いてください。「Personはエントリーの作者を示す構造物であるか食べてください。
atomAuthor = element atom:author { atomPersonConstruct }
要素atomAuthor=原子: 作者atomPersonConstruct
If an atom:entry element does not contain atom:author elements, then the atom:author elements of the contained atom:source element are considered to apply. In an Atom Feed Document, the atom:author elements of the containing atom:feed element are considered to apply to the entry if there are no atom:author elements in the locations described above.
原子: エントリー要素が原子: 作者要素を含んでいないなら、原子: 含まれた原子: ソース要素の作者要素が適用すると考えられます。 Atom Feed Document、原子の中で: 原子がありません: 作者要素が上で説明された位置にあれば、含んでいる原子: 給電素子の作者要素がエントリーに適用すると考えられます。
Nottingham & Sayre Standards Track [Page 17] RFC 4287 Atom Format December 2005
ノッティンガムとセアー規格は原子形式2005年12月にRFC4287を追跡します[17ページ]。
4.2.2. The "atom:category" Element
4.2.2. 「原子: カテゴリ」、要素
The "atom:category" element conveys information about a category associated with an entry or feed. This specification assigns no meaning to the content (if any) of this element.
エントリーか給送に関連しているカテゴリの要素が運ぶ「原子: カテゴリ」情報。 この仕様はこの要素の内容(もしあれば)に意味を割り当てません。
atomCategory =
element atom:category {
atomCommonAttributes,
attribute term { text },
attribute scheme { atomUri }?,
attribute label { text }?,
undefinedContent
}
要素atomCategory=原子: カテゴリundefinedContent、atomCommonAttributes(属性用語テキスト)は体系atomUri(属性はテキストを分類する)を結果と考えます。
4.2.2.1. The "term" Attribute
4.2.2.1. 属性という「用語」
The "term" attribute is a string that identifies the category to which the entry or feed belongs. Category elements MUST have a "term" attribute.
属性という「用語」はエントリーか給送が属するカテゴリを特定するストリングです。 カテゴリ要素には、「用語」属性がなければなりません。
4.2.2.2. The "scheme" Attribute
4.2.2.2. 「体系」属性
The "scheme" attribute is an IRI that identifies a categorization scheme. Category elements MAY have a "scheme" attribute.
「体系」属性は分類体系を特定するIRIです。 カテゴリ要素には、「体系」属性があるかもしれません。
4.2.2.3. The "label" Attribute
4.2.2.3. 「ラベル」属性
The "label" attribute provides a human-readable label for display in
end-user applications. The content of the "label" attribute is
Language-Sensitive. Entities such as "&" and "<" represent
their corresponding characters ("&" and "<", respectively), not
markup. Category elements MAY have a "label" attribute.
「ラベル」属性は人間読み込み可能なラベルをエンドユーザアプリケーションにおけるディスプレイに提供します。 「ラベル」属性の内容はLanguage機密です。 "&"や"<"などの実体はマーク付けではなく、彼らの対応する性格(それぞれ“&"と"<")の代理をします。 カテゴリ要素には、「ラベル」属性があるかもしれません。
4.2.3. The "atom:contributor" Element
4.2.3. 「原子: 貢献者」、要素
The "atom:contributor" element is a Person construct that indicates a person or other entity who contributed to the entry or feed.
「原子: 貢献者、」 要素が人を示すPerson構造物であるかまたは他の実体は、だれがエントリーに貢献したか、そして、給送です。
atomContributor = element atom:contributor { atomPersonConstruct }
要素atomContributor=原子: 貢献者atomPersonConstruct
4.2.4. The "atom:generator" Element
4.2.4. 「原子: ジェネレータ」、要素
The "atom:generator" element's content identifies the agent used to generate a feed, for debugging and other purposes.
要素の内容がデバッグと他の目的のために給送を生成するために使用されるエージェントを特定する「原子: ジェネレータ。」
Nottingham & Sayre Standards Track [Page 18] RFC 4287 Atom Format December 2005
ノッティンガムとセアー規格は原子形式2005年12月にRFC4287を追跡します[18ページ]。
atomGenerator = element atom:generator {
atomCommonAttributes,
attribute uri { atomUri }?,
attribute version { text }?,
text
}
要素atomGenerator=原子: ジェネレータatomCommonAttributes、属性のuri atomUri--、属性バージョンテキスト?、テキスト
The content of this element, when present, MUST be a string that is a
human-readable name for the generating agent. Entities such as
"&" and "<" represent their corresponding characters ("&" and
"<" respectively), not markup.
存在しているとき、この要素の内容は生成しているエージェントのための人間読み込み可能な名前であるストリングであるに違いありません。 "&"や"<"などの実体が彼らの対応する性格の代理をする、(“&"と"<"、それぞれ)、マーク付けでない。
The atom:generator element MAY have a "uri" attribute whose value MUST be an IRI reference [RFC3987]. When dereferenced, the resulting URI (mapped from an IRI, if necessary) SHOULD produce a representation that is relevant to that agent.
原子: ジェネレータ要素には、値がIRI参照でなければならない[RFC3987]"uri"属性があるかもしれません。 「反-参照をつけ」られると、結果として起こるURI(IRIから、必要なら、写像される)SHOULDはそのエージェントに関連している表現を作成します。
The atom:generator element MAY have a "version" attribute that indicates the version of the generating agent.
原子: ジェネレータ要素には、生成しているエージェントのバージョンを示す「バージョン」属性があるかもしれません。
4.2.5. The "atom:icon" Element
4.2.5. 「原子: アイコン」、要素
The "atom:icon" element's content is an IRI reference [RFC3987] that identifies an image that provides iconic visual identification for a feed.
要素のものが満足させる「原子: アイコン」は給送のための聖像の視覚識別を提供するイメージを特定するIRI参照[RFC3987]です。
atomIcon = element atom:icon {
atomCommonAttributes,
(atomUri)
}
要素atomIcon=原子: アイコンatomCommonAttributes、(atomUri)
The image SHOULD have an aspect ratio of one (horizontal) to one (vertical) and SHOULD be suitable for presentation at a small size.
イメージSHOULDは、小型で1つ(垂直な)への1つ(水平面)とSHOULDのアスペクトレシオがプレゼンテーションに適しているのを持っています。
4.2.6. The "atom:id" Element
4.2.6. 「原子: イド」、要素
The "atom:id" element conveys a permanent, universally unique identifier for an entry or feed.
エントリーか給送のための要素が運ぶ「原子: イド」a永久的で、一般にユニークな識別子。
atomId = element atom:id {
atomCommonAttributes,
(atomUri)
}
要素atomId=原子: イドatomCommonAttributes、(atomUri)
Its content MUST be an IRI, as defined by [RFC3987]. Note that the definition of "IRI" excludes relative references. Though the IRI might use a dereferencable scheme, Atom Processors MUST NOT assume it can be dereferenced.
[RFC3987]によって定義されるように内容はIRIであるに違いありません。 「イリ」の定義が相対参照を除くことに注意してください。 IRIは「反-参照をつけ-可能」体系を使用するかもしれませんが、Atom Processorsは、それに「反-参照をつけ」ることができると仮定してはいけません。
Nottingham & Sayre Standards Track [Page 19] RFC 4287 Atom Format December 2005
ノッティンガムとセアー規格は原子形式2005年12月にRFC4287を追跡します[19ページ]。
When an Atom Document is relocated, migrated, syndicated, republished, exported, or imported, the content of its atom:id element MUST NOT change. Put another way, an atom:id element pertains to all instantiations of a particular Atom entry or feed; revisions retain the same content in their atom:id elements. It is suggested that the atom:id element be stored along with the associated resource.
再刊されるか、エクスポートされるか、またはインポートされて、Atom Documentが移動して、移行して、同時に配給されているとき、原子の内容: イド要素は変化してはいけません。 別の方法、原子を置いてください: イド要素は特定のAtomエントリーか給送のすべての具体化に関係します。 改正はそれらの原子の中で同じ内容を保有します: イド要素。 原子: イド要素が関連リソースと共に保存されることが提案されます。
The content of an atom:id element MUST be created in a way that assures uniqueness.
原子の内容: ユニークさを保証する方法でイド要素を作成しなければなりません。
Because of the risk of confusion between IRIs that would be equivalent if they were mapped to URIs and dereferenced, the following normalization strategy SHOULD be applied when generating atom:id elements:
同等物は、彼らであるならURIに写像されて、「反-参照をつけ」られました、以下の正常化戦略SHOULDということであるIRIsの間の混乱のリスクのために、原子: イド要素を生成するときには、適用されてください:
o Provide the scheme in lowercase characters.
o Provide the host, if any, in lowercase characters.
o Only perform percent-encoding where it is essential.
o Use uppercase A through F characters when percent-encoding.
o Prevent dot-segments from appearing in paths.
o For schemes that define a default authority, use an empty
authority if the default is desired.
o For schemes that define an empty path to be equivalent to a path
of "/", use "/".
o For schemes that define a port, use an empty port if the default
is desired.
o Preserve empty fragment identifiers and queries.
o Ensure that all components of the IRI are appropriately character
normalized, e.g., by using NFC or NFKC.
o 小文字のキャラクタo Provideの体系にホストを提供してください; デフォルトが望まれているならパーセントコード化経路デフォルト権威を定義するo For体系に現れるのからのo Preventドットセグメントであるときに. o UseがFキャラクタを通してAを大文字して、使用が空の権威であることが不可欠であるところでOnlyが小文字のキャラクタoでパーセントコード化をいくらか実行するなら; キャラクタは正常にしました、例えば、NFCかNFKCを使用することによって。」 . イリのすべてのコンポーネントがポートを定義して、質問oが空の部分識別子を保存するか、そして、oが確実にする人影のないポートを使用する体系のためのoですが、「」 /の経路に相当しているように人影のない経路を定義するo For体系」は適切に」 /を使用します。デフォルトは望まれています。
4.2.6.1. Comparing atom:id
4.2.6.1. 原子を比較します: イド
Instances of atom:id elements can be compared to determine whether an entry or feed is the same as one seen before. Processors MUST compare atom:id elements on a character-by-character basis (in a case-sensitive fashion). Comparison operations MUST be based solely on the IRI character strings and MUST NOT rely on dereferencing the IRIs or URIs mapped from them.
原子のインスタンス: エントリーか給送が以前見られた1つと同じであるかどうか決定するためにイド要素を比較できます。 プロセッサは原子を比較しなければなりません: キャラクタごとのベース(大文字と小文字を区別するファッションによる)のイド要素。 比較操作は、唯一IRI文字列に基づかなければならなくて、IRIsかURIがそれらから写像した「反-参照をつけ」を当てにしてはいけません。
As a result, two IRIs that resolve to the same resource but are not character-for-character identical will be considered different for the purposes of identifier comparison.
キャラクタのためのキャラクタの同じ意志ではなく、結果、しかし同じリソースへの決心がそうである2IRIsとして、識別子比較の目的のために異なると考えられてください。
For example, these are four distinct identifiers, despite the fact that they differ only in case:
例えば、これらは4つの異なった識別子であり、中だけで異なるという事実にもかかわらず、以下をケースに入れてください。
Nottingham & Sayre Standards Track [Page 20] RFC 4287 Atom Format December 2005
ノッティンガムとセアー規格は原子形式2005年12月にRFC4287を追跡します[20ページ]。
http://www.example.org/thing
http://www.example.org/Thing
http://www.EXAMPLE.org/thing
HTTP://www.example.org/thing
http://www.example.org/thing http://www.example.org/Thing http://www.EXAMPLE.org/thing HTTP://www.example.org/もの
Likewise, these are three distinct identifiers, because IRI %-escaping is significant for the purposes of comparison:
同様に、IRI%エスケープが比較の目的のために重要であるので、これらは3つの異なった識別子です:
http://www.example.com/~bob
http://www.example.com/%7ebob
http://www.example.com/%7Ebob
http://www.example.com/~bob http://www.example.com/%7ebob http://www.example.com/%7Ebob
4.2.7. The "atom:link" Element
4.2.7. 「原子: リンクしてください」という要素
The "atom:link" element defines a reference from an entry or feed to a Web resource. This specification assigns no meaning to the content (if any) of this element.
「原子: リンクしてください」という要素はエントリーか給送からウェブリソースまでの参照を定義します。 この仕様はこの要素の内容(もしあれば)に意味を割り当てません。
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
}
要素atomLink=原子: リンクしてください。atomCommonAttributes(属性href atomUri)はrelにatomNCName| atomUriを--タイプatomMediaTypeを結果と考えて、hreflangにatomLanguageTagを結果と考えてください、属性タイトルテキスト--結果と考えます、属性長さのテキスト?、undefinedContent
4.2.7.1. The "href" Attribute
4.2.7.1. "href"属性
The "href" attribute contains the link's IRI. atom:link elements MUST have an href attribute, whose value MUST be a IRI reference [RFC3987].
"href"属性はリンクのIRIを含んでいます。原子: リンク要素には、値がIRI参照でなければならない[RFC3987]href属性がなければなりません。
4.2.7.2. The "rel" Attribute
4.2.7.2. "rel"属性
atom:link elements MAY have a "rel" attribute that indicates the link relation type. If the "rel" attribute is not present, the link element MUST be interpreted as if the link relation type is "alternate".
原子: リンク要素には、リンク関係タイプを示す"rel"属性があるかもしれません。 "rel"属性が存在していないなら、まるでリンク関係タイプが「代替のであるかの」ようにリンク要素を解釈しなければなりません。
The value of "rel" MUST be a string that is non-empty and matches either the "isegment-nz-nc" or the "IRI" production in [RFC3987]. Note that use of a relative reference other than a simple name is not allowed. If a name is given, implementations MUST consider the link relation type equivalent to the same name registered within the IANA
"rel"の値は非空であり、[RFC3987]で"isegment-nz-nc"か「イリ」生産のどちらかに合っているストリングでなければなりません。 単純名以外の相対参照の使用が許されていないことに注意してください。 名前を与えるなら、実装は、リンク関係タイプがIANAの中に登録された同じ名前に同等であると考えなければなりません。
Nottingham & Sayre Standards Track [Page 21] RFC 4287 Atom Format December 2005
ノッティンガムとセアー規格は原子形式2005年12月にRFC4287を追跡します[21ページ]。
Registry of Link Relations (Section 7), and thus to the IRI that would be obtained by appending the value of the rel attribute to the string "http://www.iana.org/assignments/relation/". The value of "rel" describes the meaning of the link, but does not impose any behavioral requirements on Atom Processors.
Link Relations(セクション7)と、そして、その結果、ストリング" http://www.iana.org/assignments/relation/ "にrel属性の値を追加することによって入手されるIRIへの登録。 "rel"の値は、リンクの意味について説明しますが、どんな行動の要件もAtom Processorsに課しません。
This document defines five initial values for the Registry of Link Relations:
このドキュメントはLink RelationsのRegistryのために5つの初期の値を定義します:
1. The value "alternate" signifies that the IRI in the value of the
href attribute identifies an alternate version of the resource
described by the containing element.
1. 値の「補欠」は、href属性の値におけるIRIが含んでいる要素によって説明されたリソースの代替のバージョンを特定するのを意味します。
2. The value "related" signifies that the IRI in the value of the
href attribute identifies a resource related to the resource
described by the containing element. For example, the feed for a
site that discusses the performance of the search engine at
"http://search.example.com" might contain, as a child of
atom:feed:
2. 「関係づけられた」値は、href属性の値におけるIRIが含んでいる要素によって説明されたリソースに関連するリソースを特定するのを意味します。 例えば、" http://search.example.com "でサーチエンジンの性能について議論するサイトへの給送は原子: 給送の子供として以下を含むかもしれません。
<link rel="related" href="http://search.example.com/"/>
<リンクrel=はhref=" http://search.example.com/ "/>を「関係づけました」。
An identical link might appear as a child of any atom:entry whose
content contains a discussion of that same search engine.
同じリンクはどんな原子の子供としても現れるかもしれません: 内容がその同じサーチエンジンの議論を含むエントリー。
3. The value "self" signifies that the IRI in the value of the href
attribute identifies a resource equivalent to the containing
element.
3. 値の「自己」は、href属性の値におけるIRIが含んでいる要素に同等なリソースを特定するのを意味します。
4. The value "enclosure" signifies that the IRI in the value of the
href attribute identifies a related resource that is potentially
large in size and might require special handling. For atom:link
elements with rel="enclosure", the length attribute SHOULD be
provided.
4. 値の「包囲」は、href属性の値におけるIRIがサイズで潜在的に大きく、特別な取り扱いを必要とするかもしれない関連するリソースを特定するのを意味します。 原子のために: relがあるリンク要素は「包囲」、長さ属性SHOULDと等しいです。提供します。
5. The value "via" signifies that the IRI in the value of the href
attribute identifies a resource that is the source of the
information provided in the containing element.
5. を通して値、「」 href属性の値におけるIRIが含んでいる要素に提供された情報の源であるリソースを特定するのを意味します。
4.2.7.3. The "type" Attribute
4.2.7.3. 「タイプ」属性
On the link element, the "type" attribute's value is an advisory media type: it is a hint about the type of the representation that is expected to be returned when the value of the href attribute is dereferenced. Note that the type attribute does not override the actual media type returned with the representation. Link elements MAY have a type attribute, whose value MUST conform to the syntax of a MIME media type [MIMEREG].
リンク要素では、「タイプ」属性の値は顧問メディアタイプです: それはhref属性の値が「反-参照をつけ」られるとき、返されると予想される表現のタイプに関するヒントです。 タイプ属性がタイプが表現と共に返した実際のメディアをくつがえさないことに注意してください。 リンク要素には、値がMIMEメディアタイプ[MIMEREG]の構文に従わなければならないタイプ属性があるかもしれません。
Nottingham & Sayre Standards Track [Page 22] RFC 4287 Atom Format December 2005
ノッティンガムとセアー規格は原子形式2005年12月にRFC4287を追跡します[22ページ]。
4.2.7.4. The "hreflang" Attribute
4.2.7.4. "hreflang"属性
The "hreflang" attribute's content describes the language of the resource pointed to by the href attribute. When used together with the rel="alternate", it implies a translated version of the entry. Link elements MAY have an hreflang attribute, whose value MUST be a language tag [RFC3066].
"hreflang"属性の内容はhref属性によって示されたリソースの言語を説明します。 rel=「補欠」と共に使用されると、それはエントリーの翻訳されたバージョンを含意します。 リンク要素には、値が言語タグでなければならない[RFC3066]hreflang属性があるかもしれません。
4.2.7.5. The "title" Attribute
4.2.7.5. 「タイトル」属性
The "title" attribute conveys human-readable information about the
link. The content of the "title" attribute is Language-Sensitive.
Entities such as "&" and "<" represent their corresponding
characters ("&" and "<", respectively), not markup. Link elements
MAY have a title attribute.
「タイトル」属性はリンクに関する人間が読める情報を伝えます。 「タイトル」属性の内容はLanguage機密です。 "&"や"<"などの実体はマーク付けではなく、彼らの対応する性格(それぞれ“&"と"<")の代理をします。 リンク要素には、タイトル属性があるかもしれません。
4.2.7.6. The "length" Attribute
4.2.7.6. 「長さ」属性
The "length" attribute indicates an advisory length of the linked content in octets; it is a hint about the content length of the representation returned when the IRI in the href attribute is mapped to a URI and dereferenced. Note that the length attribute does not override the actual content length of the representation as reported by the underlying protocol. Link elements MAY have a length attribute.
「長さ」属性は八重奏における、繋がっている内容の顧問長さを示します。 それはhref属性におけるIRIがURIに写像されて、「反-参照をつけ」られるとき返された表現のコンテンツの長さに関するヒントです。 長さ属性が基本的なプロトコルによって報告されるように表現の実際のコンテンツの長さをくつがえさないことに注意してください。 リンク要素には、長さ属性があるかもしれません。
4.2.8. The "atom:logo" Element
4.2.8. 「原子: ロゴ」、要素
The "atom:logo" element's content is an IRI reference [RFC3987] that identifies an image that provides visual identification for a feed.
要素のものが満足させる「原子: ロゴ」は給送のための視覚識別を提供するイメージを特定するIRI参照[RFC3987]です。
atomLogo = element atom:logo {
atomCommonAttributes,
(atomUri)
}
要素atomLogo=原子: ロゴatomCommonAttributes、(atomUri)
The image SHOULD have an aspect ratio of 2 (horizontal) to 1 (vertical).
イメージSHOULDは2対1(水平な)のアスペクトレシオを(垂直)であるのに持っています。
4.2.9. The "atom:published" Element
4.2.9. 「原子:、」 要素を発行します。
The "atom:published" element is a Date construct indicating an instant in time associated with an event early in the life cycle of the entry.
「原子: 発行されて、」 要素はイベントに関連している時間でエントリーのライフサイクルに早い状態で瞬間を示すDate構造物です。
atomPublished = element atom:published { atomDateConstruct }
atomPublished=要素原子:、発行atomDateConstruct
Nottingham & Sayre Standards Track [Page 23] RFC 4287 Atom Format December 2005
ノッティンガムとセアー規格は原子形式2005年12月にRFC4287を追跡します[23ページ]。
Typically, atom:published will be associated with the initial creation or first availability of the resource.
原子: 発行されて、通常、リソースの初期の作成か最初の有用性に関連しているために望んでください。
4.2.10. The "atom:rights" Element
4.2.10. 「原子: 権利」、要素
The "atom:rights" element is a Text construct that conveys information about rights held in and over an entry or feed.
「原子: 権利、」 要素は給送とエントリーか給送の上に保持された権利に関して情報を伝達するText構造物です。
atomRights = element atom:rights { atomTextConstruct }
要素atomRights=原子: 権利atomTextConstruct
The atom:rights element SHOULD NOT be used to convey machine-readable licensing information.
原子: 権利要素SHOULD NOT、使用されて、機械可読な認可情報を伝えてください。
If an atom:entry element does not contain an atom:rights element, then the atom:rights element of the containing atom:feed element, if present, is considered to apply to the entry.
存在していて、原子: エントリー要素が原子: 権利要素を含んでいないなら、原子: 含んでいる原子: 給電素子の権利要素がエントリーに適用すると考えられます。
4.2.11. The "atom:source" Element
4.2.11. 「原子: 」 要素の出典を明示してください。
If an atom:entry is copied from one feed into another feed, then the source atom:feed's metadata (all child elements of atom:feed other than the atom:entry elements) MAY be preserved within the copied entry by adding an atom:source child element, if it is not already present in the entry, and including some or all of the source feed's Metadata elements as the atom:source element's children. Such metadata SHOULD be preserved if the source atom:feed contains any of the child elements atom:author, atom:contributor, atom:rights, or atom:category and those child elements are not present in the source atom:entry.
原子: エントリーが1つの給送から別の給送にコピーされるなら、ソース原子: 給送のメタデータ(原子のすべての子供要素: 原子以外の給送: エントリー要素)はコピーされたエントリーの中に原子: ソース子供要素を加えることによって、保存されるかもしれません、それが原子としてエントリーと、ソース給送のMetadata要素のいくつかかすべてを含む際に既に存在していないなら: ソース要素の子供。 そのようなメタデータSHOULD、ソース原子: 給送が子供要素のどれかを含んでいるなら保存されて、原子: 作者か、原子: 貢献者か、原子: 権利か、原子: カテゴリとそれらの子供要素がソース原子の中に出席していません: エントリーということになってください。
atomSource =
element atom:source {
atomCommonAttributes,
(atomAuthor*
& atomCategory*
& atomContributor*
& atomGenerator?
& atomIcon?
& atomId?
& atomLink*
& atomLogo?
& atomRights?
& atomSubtitle?
& atomTitle?
& atomUpdated?
& extensionElement*)
}
要素atomSource=原子: ソース{ atomCommonAttributes(atomAuthor*、atomCategory*、atomContributor*、およびatomGenerator? atomIcon-- atomId-- atomLink*とatomLogo-- atomRights-- atomSubtitle-- atomTitle-- atomUpdatedされています extensionElement*) }
Nottingham & Sayre Standards Track [Page 24] RFC 4287 Atom Format December 2005
ノッティンガムとセアー規格は原子形式2005年12月にRFC4287を追跡します[24ページ]。
The atom:source element is designed to allow the aggregation of entries from different feeds while retaining information about an entry's source feed. For this reason, Atom Processors that are performing such aggregation SHOULD include at least the required feed-level Metadata elements (atom:id, atom:title, and atom:updated) in the atom:source element.
原子: ソース要素は、エントリーのソース給送の情報を保有している間、異なった給送からエントリーの集合を許容するように設計されています。 この理由で、そのような集合SHOULDを実行しているAtom Processorsが少なくとも必要な給送レベルMetadata要素を含んでいる、(原子: イド、原子: タイトル、および原子:、アップデート、)、原子: ソース要素で。
4.2.12. The "atom:subtitle" Element
4.2.12. 「原子: 」 要素に字幕をつけてください。
The "atom:subtitle" element is a Text construct that conveys a human- readable description or subtitle for a feed.
原子: 」 要素に字幕をつけてください。「人間を運ぶText構造物は読み込み可能な記述であるかaのために給送に字幕をつけてください。
atomSubtitle = element atom:subtitle { atomTextConstruct }
atomSubtitleは要素原子と等しいです:、字幕をつける。atomTextConstruct
4.2.13. The "atom:summary" Element
4.2.13. 「原子: 概要」、要素
The "atom:summary" element is a Text construct that conveys a short summary, abstract, or excerpt of an entry.
「原子: 概要、」 要素はエントリーの要約、要約、または抜粋を伝えるText構造物です。
atomSummary = element atom:summary { atomTextConstruct }
要素atomSummary=原子: 概要atomTextConstruct
It is not advisable for the atom:summary element to duplicate atom:title or atom:content because Atom Processors might assume there is a useful summary when there is none.
Atom Processorsが、なにもないとき、役に立つ概要があると仮定するかもしれないので、原子: 概要要素が原子: タイトルか原子: 内容をコピーするのは、賢明ではありません。
4.2.14. The "atom:title" Element
4.2.14. 「原子: 」 要素を題をつけてください。
The "atom:title" element is a Text construct that conveys a human- readable title for an entry or feed.
原子: 」 要素を題をつけてください。「人間を運ぶText構造物はエントリーのための読み込み可能なタイトルであるか食べてください。
atomTitle = element atom:title { atomTextConstruct }
要素atomTitle=原子: タイトルatomTextConstruct
4.2.15. The "atom:updated" Element
4.2.15. 「原子:、」 要素をアップデートします。
The "atom:updated" element is a Date construct indicating the most recent instant in time when an entry or feed was modified in a way the publisher considers significant. Therefore, not all modifications necessarily result in a changed atom:updated value.
「原子: アップデートして、」 要素は時間内にの最新の瞬間にエントリーか給送がいつ出版社が重要であると考える方法で変更されたかを示すDate構造物です。 したがって、すべてではなく、変更は必ず変えられた原子をもたらします: 値をアップデートします。
atomUpdated = element atom:updated { atomDateConstruct }
atomUpdated=要素原子:、アップデートatomDateConstruct
Publishers MAY change the value of this element over time.
出版社は時間がたつにつれて、この要素の価値を変えるかもしれません。
Nottingham & Sayre Standards Track [Page 25] RFC 4287 Atom Format December 2005
ノッティンガムとセアー規格は原子形式2005年12月にRFC4287を追跡します[25ページ]。
5. Securing Atom Documents
5. 原子ドキュメントを固定します。
Because Atom is an XML-based format, existing XML security mechanisms can be used to secure its content.
AtomがXMLベースの形式であるので、内容を保証するのに既存のXMLセキュリティー対策を使用できます。
Producers of feeds and/or entries, and intermediaries who aggregate feeds and/or entries, may have sound reasons for signing and/or encrypting otherwise-unprotected content. For example, a merchant might digitally sign a message that contains a discount coupon for its products. A bank that uses Atom to deliver customer statements is very likely to want to sign and encrypt those messages to protect their customers' financial information and to assure the customer of their authenticity. Intermediaries may want to encrypt aggregated feeds so that a passive observer cannot tell what topics the recipient is interested in. Of course, many other examples exist as well.
給送、そして/または、エントリーのプロデューサーと、集合が食べさせる仲介者、そして/または、エントリーには、そうでなければ、保護のない内容を署名する、そして/または、暗号化する確実な根拠のある理由があるかもしれません。 例えば、商人は製品のために割引券を含むメッセージにデジタルに署名するかもしれません。 顧客声明を提供するのにAtomを使用する銀行は、彼らの顧客の財務情報を保護して、それらの信憑性を顧客に保証するそれらのメッセージに署名して、非常に暗号化したそうです。 仲介者は、受け身の観察者が、受取人がどんな話題に興味を持っているかわからないように、集められた給送を暗号化したがっているかもしれません。 もちろん、また、他の多くの例が存在しています。
The algorithm requirements in this section pertain to the Atom Processor. They require that a recipient, at a minimum, be able to handle messages that use the specified cryptographic algorithms. These requirements do not limit the algorithms that the sender can choose.
このセクションのアルゴリズム要件はAtom Processorに関係します。 彼らは、受取人が最小限で指定された暗号アルゴリズムを使用するメッセージを扱うことができるのを必要とします。これらの要件は送付者が選ぶことができるアルゴリズムを制限しません。
5.1. Digital Signatures
5.1. デジタル署名
The root of an Atom Document (i.e., atom:feed in an Atom Feed Document, atom:entry in an Atom Entry Document) or any atom:entry element MAY have an Enveloped Signature, as described by XML- Signature and Syntax Processing [W3C.REC-xmldsig-core-20020212].
Atom Document(すなわち、原子: Atom Feed Document、原子の中の給送: Atom Entry Documentのエントリー)の根かどんな原子も: エントリー要素にはEnveloped Signatureがあるかもしれません、XML署名とSyntax Processing[W3C. REC-xmldsigコア20020212]によって説明されるように。
Atom Processors MUST NOT reject an Atom Document containing such a signature because they are not capable of verifying it; they MUST continue processing and MAY inform the user of their failure to validate the signature.
原子Processorsは彼らがそれについて確かめることができないのでそのような署名を含むAtom Documentを拒絶してはいけません。 彼らは、処理し続けなければならなくて、彼らが署名を有効にしないことについてユーザに知らせるかもしれません。
In other words, the presence of an element with the namespace URI "http://www.w3.org/2000/09/xmldsig#" and a local name of "Signature" as a child of the document element MUST NOT cause an Atom Processor to fail merely because of its presence.
言い換えれば、名前空間URI" http://www.w3.org/2000/09/xmldsig# "がある要素の存在とドキュメント要素の子供としての「署名」の地方名は単に存在で原子プロセッサに失敗してはいけません。
Other elements in an Atom Document MUST NOT be signed unless their definitions explicitly specify such a capability.
彼らの定義が明らかにそのような能力を指定しないなら、Atom Documentの他の要素に署名してはいけません。
Section 6.5.1 of [W3C.REC-xmldsig-core-20020212] requires support for Canonical XML [W3C.REC-xml-c14n-20010315]. However, many implementers do not use it because signed XML documents enclosed in other XML documents have their signatures broken. Thus, Atom Processors that verify signed Atom Documents MUST be able to
.1セクション6.5[W3C. REC-xmldsigコア20020212]がCanonical XML[W3C. REC-xml-c14n-20010315]に支持を要します。 しかしながら、他のXMLドキュメントに同封された署名しているXMLドキュメントが彼らの署名を壊されるので、多くのimplementersはそれを使用しません。 したがって、署名しているAtom Documentsについて確かめるAtom Processorsはできるに違いありません。
Nottingham & Sayre Standards Track [Page 26] RFC 4287 Atom Format December 2005
ノッティンガムとセアー規格は原子形式2005年12月にRFC4287を追跡します[26ページ]。
canonicalize with the exclusive XML canonicalization method identified by the URI "http://www.w3.org/2001/10/xml-exc-c14n#", as specified in Exclusive XML Canonicalization [W3C.REC-xml-exc-c14n-20020718].
canonicalizeする、排他的なXML Canonicalization[W3C. REC-xml-exc-c14n-20020718]で指定されるようにURI" http://www.w3.org/2001/10/xml-exc-c14n# "によって特定された排他的なXML canonicalizationメソッドで。
Intermediaries such as aggregators may need to add an atom:source element to an entry that does not contain its own atom:source element. If such an entry is signed, the addition will break the signature. Thus, a publisher of individually-signed entries should strongly consider adding an atom:source element to those entries before signing them. Implementers should also be aware of the issues concerning the use of markup in the "xml:" namespace as it interacts with canonicalization.
アグリゲータなどの仲介者は、それ自身の原子を含まないエントリーに原子: ソース要素を加える必要があるかもしれません: ソース要素。 そのようなエントリーが署名されると、追加は署名を壊すでしょう。 したがって、個別に署名しているエントリーの出版社は、原子を加えると強く考えるべきです: それらに署名する前のそれらのエントリーへのソース要素。 また、Implementersも問題がマーク付けの使用にかかわるのを意識しているべきである、「xml:」 それとしての名前空間はcanonicalizationと対話します。
Section 4.4.2 of [W3C.REC-xmldsig-core-20020212] requires support for DSA signatures and recommends support for RSA signatures. However, because of the much greater popularity in the market of RSA versus DSA, Atom Processors that verify signed Atom Documents MUST be able to verify RSA signatures, but do not need be able to verify DSA signatures. Due to security issues that can arise if the keying material for message authentication code (MAC) authentication is not handled properly, Atom Documents SHOULD NOT use MACs for signatures.
.2セクション4.4[W3C. REC-xmldsigコア20020212]が、DSA署名に支持を要して、RSA署名のサポートを推薦します。 しかしながら、RSA対DSAの市場のはるかにすごい人気のために、署名しているAtom Documentsについて確かめるAtom ProcessorsはRSA署名について確かめることができなければなりませんが、必要性はDSA署名は確かめることができませんか? メッセージ確認コード(MAC)認証のための合わせることの材料が適切に扱われないなら起こることができる安全保障問題のため、Atom Documents SHOULDは署名にMACsを使用しません。
5.2. Encryption
5.2. 暗号化
The root of an Atom Document (i.e., atom:feed in an Atom Feed Document, atom:entry in an Atom Entry Document) MAY be encrypted, using the mechanisms described by XML Encryption Syntax and Processing [W3C.REC-xmlenc-core-20021210].
Atom Document(すなわち、原子: Atom Feed Document、原子の中の給送: Atom Entry Documentのエントリー)の根は暗号化されるかもしれません、XML Encryption SyntaxとProcessing[W3C. REC-xmlencコア20021210]によって説明されたメカニズムを使用して。
Section 5.1 of [W3C.REC-xmlenc-core-20021210] requires support of TripleDES, AES-128, and AES-256. Atom Processors that decrypt Atom Documents MUST be able to decrypt with AES-128 in Cipher Block Chaining (CBC) mode.
[W3C. REC-xmlencコア20021210]のセクション5.1はTripleDES、AES-128、およびAES-256のサポートを必要とします。 Atom Documentsを解読するProcessorsがAES-128と共にCipher Block Chaining(CBC)モードで解読することができなければならない原子。
Encryption based on [W3C.REC-xmlenc-core-20021210] does not ensure integrity of the original document. There are known cryptographic attacks where someone who cannot decrypt a message can still change bits in a way where part or all the decrypted message makes sense but has a different meaning. Thus, Atom Processors that decrypt Atom Documents SHOULD check the integrity of the decrypted document by verifying the hash in the signature (if any) in the document, or by verifying a hash of the document within the document (if any).
[W3C. REC-xmlencコア20021210]に基づく暗号化は正本の保全を確実にしません。 暗号の攻撃はメッセージを解読することができないだれかはそれでも部分かすべての解読されたメッセージが異なった意味を理解できますが、持っている方法による変更ビットを知ることができるところで知られています。 したがって、ドキュメントで署名におけるハッシュについて確かめるか(もしあれば)、またはドキュメントの中にドキュメントのハッシュについて確かめることによって(もしあれば)、Atom Documents SHOULDを解読するAtom Processorsが解読されたドキュメントの保全をチェックします。
Nottingham & Sayre Standards Track [Page 27] RFC 4287 Atom Format December 2005
ノッティンガムとセアー規格は原子形式2005年12月にRFC4287を追跡します[27ページ]。
5.3. Signing and Encrypting
5.3. 署名と暗号化
When an Atom Document is to be both signed and encrypted, it is generally a good idea to first sign the document, then encrypt the signed document. This provides integrity to the base document while encrypting all the information, including the identity of the entity that signed the document. Note that, if MACs are used for authentication, the order MUST be that the document is signed and then encrypted, and not the other way around.
Atom Documentが署名されて、暗号化されることになっているとき、一般に、最初に、書類に署名して、次に、署名しているドキュメントを暗号化するのは、名案です。 これはすべての情報を暗号化している間、保全を元にした文書に供給します、書類に署名した実体のアイデンティティを含んでいて。 MACsが認証に使用されるならオーダーが書類が署名されて、次に、暗号化されますが、逆が暗号化されないということであるに違いないことに注意してください。
6. Extending Atom
6. 原子を広げています。
6.1. Extensions from Non-Atom Vocabularies
6.1. 非原子ボキャブラリーからの拡大
This specification describes Atom's XML markup vocabulary. Markup
from other vocabularies ("foreign markup") can be used in an Atom
Document. Note that the atom:content element is designed to support
the inclusion of arbitrary foreign markup.
この仕様はAtomのXMLマーク付けボキャブラリーについて説明します。 Atom Documentで他のボキャブラリー(「外国マーク付け」)からのマーク付けを使用できます。 原子: 満足している要素が任意の外国マーク付けの包含をサポートするように設計されていることに注意してください。
6.2. Extensions to the Atom Vocabulary
6.2. 原子ボキャブラリーへの拡大
The Atom namespace is reserved for future forward-compatible revisions of Atom. Future versions of this specification could add new elements and attributes to the Atom markup vocabulary. Software written to conform to this version of the specification will not be able to process such markup correctly and, in fact, will not be able to distinguish it from markup error. For the purposes of this discussion, unrecognized markup from the Atom vocabulary will be considered "foreign markup".
Atom名前空間はAtomの今後の前進コンパチブル改正のために予約されます。 この仕様の将来のバージョンは新しい要素と属性をAtomマーク付けボキャブラリーに追加するかもしれません。 仕様のこのバージョンに従うために書かれたソフトウェアは、正しくそのようなマーク付けを処理できないで、事実上、マーク付け誤りとそれを区別できないでしょう。 この議論の目的のために、Atomボキャブラリーからの認識されていないマーク付けは「外国マーク付け」であると考えられるでしょう。
6.3. Processing Foreign Markup
6.3. 外国マーク付けを処理します。
Atom Processors that encounter foreign markup in a location that is legal according to this specification MUST NOT stop processing or signal an error. It might be the case that the Atom Processor is able to process the foreign markup correctly and does so. Otherwise, such markup is termed "unknown foreign markup".
この仕様通りに法的な位置で外国マーク付けに遭遇する原子Processorsは処理するのを止めてはいけませんし、また誤りに合図してはいけません。 Atom Processorが正しく外国マークアップを処理できて、そうするのは、事実であるかもしれません。 さもなければ、そのようなマークアップは「未知の外国マーク付け」と呼ばれます。
When unknown foreign markup is encountered as a child of atom:entry, atom:feed, or a Person construct, Atom Processors MAY bypass the markup and any textual content and MUST NOT change their behavior as a result of the markup's presence.
未知の外国マークアップが原子: エントリー、原子: 給送、またはPerson構造物の子供として遭遇するとき、Atom Processorsはマークアップとどんな原文の内容も迂回させるかもしれなくて、マーク付けの存在の結果、彼らの振舞いを変えてはいけません。
When unknown foreign markup is encountered in a Text Construct or atom:content element, software SHOULD ignore the markup and process any text content of foreign elements as though the surrounding markup were not present.
未知の外国マークアップがText Constructか原子: 満足している要素で遭遇するとき、ソフトウェアSHOULDはマークアップを無視して、まるで周囲のマークアップが存在していないかのように外国要素のどんなテキスト内容も処理します。
Nottingham & Sayre Standards Track [Page 28] RFC 4287 Atom Format December 2005
ノッティンガムとセアー規格は原子形式2005年12月にRFC4287を追跡します[28ページ]。
6.4. Extension Elements
6.4. 拡大要素
Atom allows foreign markup anywhere in an Atom document, except where it is explicitly forbidden. Child elements of atom:entry, atom:feed, atom:source, and Person constructs are considered Metadata elements and are described below. Child elements of Person constructs are considered to apply to the construct. The role of other foreign markup is undefined by this specification.
それが明らかに禁じられるところを除いて、原子はAtomドキュメントでどこでも外国マーク付けを許容します。 原子: エントリーの子供要素、原子: 給送、原子: ソース、およびPerson構造物は、Metadata要素であると考えられて、以下で説明されます。 Person構造物の子供要素が構造物に適用すると考えられます。 他の外国マーク付けの役割はこの仕様で未定義です。
6.4.1. Simple Extension Elements
6.4.1. 単純拡大Elements
A Simple Extension element MUST NOT have any attributes or child elements. The element MAY contain character data or be empty. Simple Extension elements are not Language-Sensitive.
Simple Extension要素には、どんな属性や子供要素もあってはいけません。 要素は、キャラクタデータを含んでいるか、または空であるかもしれません。 簡単なExtension要素はLanguage敏感ではありません。
simpleExtensionElement =
element * - atom:* {
text
}
simpleExtensionElementは要素*と等しいです--原子: *テキスト
The element can be interpreted as a simple property (or name/value pair) of the parent element that encloses it. The pair consisting of the namespace-URI of the element and the local name of the element can be interpreted as the name of the property. The character data content of the element can be interpreted as the value of the property. If the element is empty, then the property value can be interpreted as an empty string.
それを同封する親元素の簡単な特性(または、名前/値の組)として要素を解釈できます。 特性の名前として要素の名前空間URIと要素の地方名から成る組は解釈できます。 属性の価値として要素のキャラクタデータ内容を解釈できます。 要素が空であるなら、空のストリングとして資産価値を解釈できます。
6.4.2. Structured Extension Elements
6.4.2. 構造化されたExtension Elements
The root element of a Structured Extension element MUST have at least one attribute or child element. It MAY have attributes, it MAY contain well-formed XML content (including character data), or it MAY be empty. Structured Extension elements are Language-Sensitive.
Structured Extension要素の根の要素には、少なくとも1つの属性か子供要素がなければなりません。 それには、属性があるかもしれませんか、整形式のXML内容を含むかもしれませんか(キャラクタデータを含んでいて)、またはそれは空であるかもしれません。 構造化されたExtension要素はLanguage敏感です。
structuredExtensionElement =
element * - atom:* {
(attribute * { text }+,
(text|anyElement)*)
| (attribute * { text }*,
(text?, anyElement+, (text|anyElement)*))
}
structuredExtensionElementは要素*と等しいです--原子: *(*テキストを結果と考えてください、+、(テキスト| anyElement) *)|、(*テキストを結果と考えてください、*、(テキスト?、anyElement+、(テキスト| anyElement) *)
The structure of a Structured Extension element, including the order of its child elements, could be significant.
子供要素の注文を含むStructured Extension要素の構造は重要であるかもしれません。
Nottingham & Sayre Standards Track [Page 29] RFC 4287 Atom Format December 2005
ノッティンガムとセアー規格は原子形式2005年12月にRFC4287を追跡します[29ページ]。
This specification does not provide an interpretation of a Structured Extension element. The syntax of the XML contained in the element (and an interpretation of how the element relates to its containing element) is defined by the specification of the Atom extension.
この仕様はStructured Extension要素の解釈を提供しません。 要素(そして、要素が、要素を含むのにどう関連するかに関する解釈)に含まれたXMLの構文はAtom拡張子の仕様で定義されます。
7. IANA Considerations
7. IANA問題
An Atom Document, when serialized as XML 1.0, can be identified with the following media type:
XML1.0として連載されると、以下のメディアタイプとAtom Documentを同一視できます:
MIME media type name: application
MIME subtype name: atom+xml
Mandatory parameters: None.
Optional parameters:
"charset": This parameter has semantics identical to the charset
parameter of the "application/xml" media type as specified in
[RFC3023].
Encoding considerations: Identical to those of "application/xml" as
described in [RFC3023], Section 3.2.
Security considerations: As defined in this specification.
In addition, as this media type uses the "+xml" convention, it
shares the same security considerations as described in [RFC3023],
Section 10.
Interoperability considerations: There are no known interoperability
issues.
Published specification: This specification.
Applications that use this media type: No known applications
currently use this media type.
MIMEメディア型名: アプリケーションMIME「副-タイプ」は以下を命名します。 原子+xml Mandatoryパラメタ: なし。 任意のパラメタ: "charset": このパラメタには、[RFC3023]の指定されるとして「アプリケーション/xml」メディアタイプのcharsetパラメタと同じ意味論があります。 問題をコード化します: [RFC3023]、セクション3.2で説明される「アプリケーション/xml」のものと同じです。 セキュリティ問題: この仕様に基づき定義されるように。 「このメディアとして、さらに、用途をタイプしてください、」 +は」 コンベンションをxmlして、[RFC3023]で説明されるのと同じセキュリティ問題を共有します、セクション10。 相互運用性問題: 相互運用性問題は知られていません。 広められた仕様: この仕様。 このメディアタイプを使用するアプリケーション: どんな知られているアプリケーションも現在、このメディアタイプを使用しません。
Additional information:
追加情報:
Magic number(s): As specified for "application/xml" in [RFC3023],
Section 3.2.
File extension: .atom
Fragment identifiers: As specified for "application/xml" in
[RFC3023], Section 5.
Base URI: As specified in [RFC3023], Section 6.
Macintosh File Type code: TEXT
Person and email address to contact for further information: Mark
Nottingham <mnot@pobox.com>
Intended usage: COMMON
Author/Change controller: IESG
マジックナンバー(s): [RFC3023]の「アプリケーション/xml」に指定されるように、セクション3.2です。 ファイル拡張子: .atom Fragment識別子: [RFC3023]の「アプリケーション/xml」に指定されるように、セクション5です。 URIを基礎づけてください: [RFC3023]で指定されるように、セクション6です。 マッキントッシュFile Typeコード: 詳細のために連絡するTEXT PersonとEメールアドレス: Nottingham <mnot@pobox.com をマークしてください、gt;、意図している用法: COMMON Author/変化コントローラ: IESG
Nottingham & Sayre Standards Track [Page 30] RFC 4287 Atom Format December 2005
ノッティンガムとセアー規格は原子形式2005年12月にRFC4287を追跡します[30ページ]。
7.1. Registry of Link Relations
7.1. リンク関係の登録
This registry is maintained by IANA and initially contains five values: "alternate", "related", "self", "enclosure", and "via". New assignments are subject to IESG Approval, as outlined in [RFC2434]. Requests should be made by email to IANA, which will then forward the request to the IESG, requesting approval. The request should use the following template:
この登録は、IANAによって維持されて、初めは、5つの値を含みます: そして、「代替の」、「関連する」「自己」、「包囲」、「を通して」 新しい課題は[RFC2434]に概説されているようにIESG Approvalを受けることがあります。 メールで要求をIANAにするべきです。(次に、承認を要求して、IANAは要求をIESGに転送するでしょう)。 要求は以下のテンプレートを使用するべきです:
o Attribute Value: (A value for the "rel" attribute that conforms to
the syntax rule given in Section 4.2.7.2)
o Description:
o Expected display characteristics:
o Security considerations:
o 値を結果と考えてください: (当然のことコネセクション4.2.7の.2をシンタックス・ルールに従わせる"rel"属性のための値) o 記述: o 予想されたディスプレイの特性: o セキュリティ問題:
8. Security Considerations
8. セキュリティ問題
8.1. HTML and XHTML Content
8.1. HTMLとXHTML内容
Text constructs and atom:content allow the delivery of HTML and XHTML. Many elements in these languages are considered 'unsafe' in that they open clients to one or more types of attack. Implementers of software that processes Atom should carefully consider their handling of every type of element when processing incoming (X)HTML in Atom Documents. See the security sections of [RFC2854] and [HTML] for guidance.
原子: テキスト構造物と内容はHTMLとXHTMLの配送を許します。 1つ以上のタイプの攻撃にクライアントを開くので、これらの言語の多くの要素が'危険である'と考えられます。 Atom Documentsの入って来る(X)HTMLを処理するとき、Atomを処理するソフトウェアのImplementersは慎重に彼らのすべてのタイプの要素の取り扱いを考えるはずです。 指導に関して[RFC2854]と[HTML]のセキュリティ部を見てください。
Atom Processors should pay particular attention to the security of the IMG, SCRIPT, EMBED, OBJECT, FRAME, FRAMESET, IFRAME, META, and LINK elements, but other elements might also have negative security properties.
原子ProcessorsはIMG、SCRIPT、EMBED、OBJECT、FRAME、FRAMESET、IFRAME、META、およびLINK要素のセキュリティに関する特別の注意を向けるはずですが、他の要素には、また、否定的セキュリティの特性があるかもしれません。
(X)HTML can either directly contain or indirectly reference executable content.
(X) HTMLは、直接実行可能な内容に含んでいるか、または間接的に参照をつけることができます。
8.2. URIs
8.2. URI
Atom Processors handle URIs. See Section 7 of [RFC3986].
原子ProcessorsはURIを扱います。 [RFC3986]のセクション7を見てください。
8.3. IRIs
8.3. 虹彩
Atom Processors handle IRIs. See Section 8 of [RFC3987].
原子ProcessorsはIRIsを扱います。 [RFC3987]のセクション8を見てください。
8.4. Spoofing
8.4. スプーフィング
Atom Processors should be aware of the potential for spoofing attacks where the attacker publishes an atom:entry with the atom:id value of an entry from another feed, perhaps with a falsified atom:source
攻撃者が原子: エントリーのイド値で別の給送から原子: エントリーを発行するところで原子Processorsはスプーフィング攻撃の可能性を意識しているべきです、改竄された原子: 恐らくソースと共に
Nottingham & Sayre Standards Track [Page 31] RFC 4287 Atom Format December 2005
ノッティンガムとセアー規格は原子形式2005年12月にRFC4287を追跡します[31ページ]。
element duplicating the atom:id of the other feed. For example, an Atom Processor could suppress display of duplicate entries by displaying only one entry from a set of entries with identical atom:id values. In that situation, the Atom Processor might also take steps to determine whether the entries originated from the same publisher before considering them duplicates.
原子をコピーする要素: もう片方の給送のイド。 例えば、Atom Processorは同じ原子による1セットのエントリーから1つのエントリーだけを表示することによって、写しエントリーのディスプレイを抑圧できるでしょう: イド値。 また、その状況で、Atom Processorは、エントリーがそれらが写しであると考える前に同じ出版社から発したかどうか決定するために手を打つかもしれません。
8.5. Encryption and Signing
8.5. 暗号化と署名
Atom Documents can be encrypted and signed using [W3C.REC-xmlenc-core-20021210] and [W3C.REC-xmldsig-core-20020212], respectively, and are subject to the security considerations implied by their use.
原子Documentsはそれぞれ[W3C. REC-xmlencコア20021210]と[W3C. REC-xmldsigコア20020212]を使用することで暗号化して、署名することができて、彼らの使用で含意されたセキュリティ問題を受けることがあります。
Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality.
デジタル署名は認証、メッセージの保全、および非拒否を発生源の証拠に提供します。 暗号化はデータの機密性を提供します。
9. References
9. 参照
9.1. Normative References
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>.
[HTML]RaggettとD.とHors、A.とI.ジェイコブズ、「HTML4.01仕様」、W3C REC REC-html401-19991224 1999年12月、<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.
解放された[MIMEREG]とN.とJ.Klensin、「メディアは仕様と登録手順をタイプする」BCP13、RFC4288、2005年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[RFC2822] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。
[RFC2854] Connolly, D. and L. Masinter, "The 'text/html' Media
Type", RFC 2854, June 2000.
[RFC2854] コノリーとD.とL.Masinter、htmlテキスト/'メディアタイプ」、RFC2854、2000年6月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001.
[RFC3023] ムラタとM.と聖ローラン、S.とD.コーン、「XMLメディアタイプ」、RFC3023、2001年1月。
[RFC3066] Alvestrand, H., "Tags for the Identification of
Languages", BCP 47, RFC 3066, January 2001.
[RFC3066] Alvestrand、H.、「言語の識別のためのタグ」、BCP47、RFC3066、2001年1月。
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, July 2002.
[RFC3339]Klyne(G.とC.ニューマン)は「インターネットで以下の日付を入れて、調節します」。 「タイムスタンプ」、RFC3339、2002年7月。
Nottingham & Sayre Standards Track [Page 32] RFC 4287 Atom Format December 2005
ノッティンガムとセアー規格は原子形式2005年12月にRFC4287を追跡します[32ページ]。
[RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 3548, July 2003.
[RFC3548]Josefsson、2003年7月のS.、「Base16、Base32、およびBase64データEncodings」RFC3548。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC3986] バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、STD66、RFC3986、2005年1月。
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005.
[RFC3987] DuerstとM.とM.Suignard、「国際化しているリソース識別子(虹彩)」、RFC3987、2005年1月。
[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-20040204]Yergeau、F.、パオリ、J.、T.、およびE.Maler、「拡張マークアップ言語(XML)1.0(第3版)」をSperberg-マックィーン、C.はいななかせます、W3C REC REC-xml-20040204、2004年2月、<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-c14n-20010315]ボワイエ、J.、「正準なXML、バージョン1インチ、W3C REC REC-xml- c14n-20010315 2001年3月、<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-exc-c14n-20020718] イーストレーク、D.、ボワイエ、J.、およびJ.Reagle、「排他的なXML Canonicalizationバージョン1インチ、W3C REC REC-xml-exc-c14n20020718の2002年7月<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-infoset-20040204] カウァンとJ.とR.トビン、「XML一組の情報(第2版)」、W3C REC REC-xml-infoset-20040204、<http://www.w3.org/TR/2004/REC-xml-infoset-20040204 2004年2月の>。
[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-xml名19990114] オランダ人とD.とロバの鳴き声、T.とA.俗人、「XMLの名前空間」W3C REC REC-xml名19990114、1999年1月、<http://www.w3.org/TR/1999/REC-xml名前-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-xmlbase-20010627] 沼地、J.、「XML基地」、W3C REC REC-xmlbase-20010627、<http://www.w3.org/TR/2001/REC-xmlbase-20010627 2001年6月の>。
[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 REC-xmldsigコア20020212、<http://www.w3.org/TR/2002/REC-xmldsig2002年2月の[W3C. REC-xmldsigコア20020212]の独奏、D.、Reagle、J.、D.イーストレーク、および「XML-署名構文と処理」、--20020212>の芯を取ってください。
Nottingham & Sayre Standards Track [Page 33] RFC 4287 Atom Format December 2005
ノッティンガムとセアー規格は原子形式2005年12月にRFC4287を追跡します[33ページ]。
[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>.
W3C REC REC-xmlencコア20021210、<http://www.w3.org/TR/2002/REC-xmlenc2002年12月の[W3C. REC-xmlencコア20021210]のReagle、J.、D.イーストレーク、および「XML暗号化構文と処理」、--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>.
[XHTML] AltheimとM.とBoumphreyとF.とマッキャロンとS.とドゥーリーとS.とSchnitzenbaumer、S.とT.Wugofski、「XHTML[TM]の変調」W3C REC REC-xhtml変調20010410、2001年4月(<http://www.w3.org/TR/2001/REC-xhtml変調-20010410>)。
9.2. Informative References
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.
[ISO、.8601、.1988、]、国際標準化機構、「データ要素と置き換え形式--情報交換--日付と回の表現」、ISO Standard8601(1988年6月)
[RELAX-NG] Clark, J., "RELAX NG Compact Syntax", December 2001,
<http://www.oasis-open.org/committees/relax-ng/
compact-20021121.html>.
[RELAX-NG] クラーク、J.、「RELAX NGのコンパクトな構文」2001年12月のngを弛緩しているか、コンパクトな<http://www.oasis-open.org/委員会/20021121.htmlの>。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[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.注意-datetime-19980827] ヴォルフとM.とC.ウィックスティード、「日時の形式」、W3Cは注意-datetime-19980827、1998年8月、<注意http://www.w3.org/TR/1998/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>.
[W3C. REC-xmlschema-2-20041028] Malhotra、A.、およびP.ビロン、「XML図式第2部:」 「データ型式第2版」、W3C REC REC-xmlschema-2-20041028、<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028 2004年10月の>。
Nottingham & Sayre Standards Track [Page 34] RFC 4287 Atom Format December 2005
ノッティンガムとセアー規格は原子形式2005年12月にRFC4287を追跡します[34ページ]。
Appendix A. Contributors
付録A.貢献者
The following people contributed to preliminary versions of this document: Tim Bray, Mark Pilgrim, and Sam Ruby. Norman Walsh provided the Relax NG schema. The content and concepts within are a product of the Atom community and the Atompub Working Group.
以下の人々はこのドキュメントの準備段階に貢献しました: ティムBray、マーク巡礼者、およびサムRuby。 ノーマン・ウォルシュはRelax NG図式を提供しました。 内容と概念は中のAtom共同体とAtompub作業部会の製品です。
The Atompub Working Group has dozens of very active contributors who proposed ideas and wording for this document, including:
Atompub作業部会には、このドキュメント、包含のために考えと言葉遣いを提案した何十人もの非常に活発な貢献者があります:
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, and Bob Wyman.
ダニー・エアーズ、ジェームスAylett、ロジャーBenningfield、アルブBersvendsenティムBray、ダンBrickley、トーマスBroyer、ロビンCover、ビルde hOra、マーチンDuerst、ロイFielding、ジョー・グレゴリオ、ビョルンHoehrmann、ポール・ホフマン、アンはケステレンをバンに積みます、ブレットLindsley、Dareオバサンジョ、デヴィッドOrchard、アリストテレスPagaltzis; ジョン機甲師団、グラハムParks(デーヴPawson)はエリックScheid、ブレント・巡礼者、デヴィッド・パウエル、ジュリアンReschke、フィルRingnalda、Antone Roundy、サムRuby、シモンズ、アンリSivonen、レイSlakinski、ジェームス・スネル、ヘンリーStory、Asbjorn Ulsberg、ウォルター・アンダーウッド、ノーマン・ウォルシュ、デーヴ・ワイナー、およびボブ・ワイマンにマークします。
Appendix B. RELAX NG Compact Schema
付録B.はNGのコンパクトな図式を弛緩します。
This appendix is informative.
この付録は有益です。
The Relax NG schema explicitly excludes elements in the Atom namespace that are not defined in this revision of the specification. Requirements for Atom Processors encountering such markup are given in Sections 6.2 and 6.3.
Relax NG図式は明らかにAtom名前空間における仕様のこの改正で定義されない要素を除きます。 セクション6.2と6.3でそのようなマーク付けに遭遇するAtom Processorsのための要件を与えます。
# -*- rnc -*- # RELAX NG Compact Syntax Grammar for the # Atom Format Specification Version 11
# -*- #Atom Format Specificationバージョン11のためのrnc-*#RELAX NG Compact Syntax Grammar
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 = ""
" http://www.w3.org/2005/Atom "名前空間xhtml=" http://www.w3.org/1999/xhtml "名前空間原子=名前空間sが" http://www.ascc.net/xml/schematron "名前空間地方の=と等しい、「」
start = atomFeed | atomEntry
=atomFeedを始動してください。| atomEntry
# Common attributes
# 一般的な属性
atomCommonAttributes =
attribute xml:base { atomUri }?,
attribute xml:lang { atomLanguageTag }?,
undefinedAttribute*
undefinedAttribute*、atomCommonAttributes=はxml: ベースatomUriを結果と考えて、xml: lang atomLanguageTagを結果と考えます。
# Text Constructs
# テキスト構造物
Nottingham & Sayre Standards Track [Page 35] RFC 4287 Atom Format December 2005
ノッティンガムとセアー規格は原子形式2005年12月にRFC4287を追跡します[35ページ]。
atomPlainTextConstruct =
atomCommonAttributes,
attribute type { "text" | "html" }?,
text
「テキスト」| atomPlainTextConstruct=atomCommonAttributes、属性タイプ"html?"、テキスト
atomXHTMLTextConstruct =
atomCommonAttributes,
attribute type { "xhtml" },
xhtmlDiv
atomXHTMLTextConstructはatomCommonAttributes、属性タイプ"xhtml"xhtmlDivと等しいです。
atomTextConstruct = atomPlainTextConstruct | atomXHTMLTextConstruct
atomTextConstructはatomPlainTextConstructと等しいです。| atomXHTMLTextConstruct
# Person Construct
# 人の構造物
atomPersonConstruct =
atomCommonAttributes,
(element atom:name { text }
& element atom:uri { atomUri }?
& element atom:email { atomEmailAddress }?
& extensionElement*)
atomPersonConstructはatomCommonAttributesと等しいです。(要素原子: 名前テキストと要素原子: uri atomUri要素原子: (メールatomEmailAddress)とextensionElement*)
# Date Construct
# 日付の構造物
atomDateConstruct =
atomCommonAttributes,
xsd:dateTime
atomCommonAttributes、atomDateConstruct=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
s: 統治してください。=をatomFeedした、[[文脈は「原子: 食べてください」というsと等しいです:、断言、[テストが「原子: (原子: エントリー[(原子: 作者)でない])ではなく作者」と等しい、「原子: 給送には原子: 作者がいなければならない、すべて」、~「原子では、: エントリー子供では、原子: 作者がいる」] 要素原子: 食べてください、atomCommonAttributes、(atomAuthor*、atomCategory*、atomContributor*、atomGenerator(atomIcon)、およびatomId
Nottingham & Sayre Standards Track [Page 36] RFC 4287 Atom Format December 2005
ノッティンガムとセアー規格は原子形式2005年12月にRFC4287を追跡します[36ページ]。
& atomLink*
& atomLogo?
& atomRights?
& atomSubtitle?
& atomTitle
& atomUpdated
& extensionElement*),
atomEntry*
}
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?
& atomSummary?
& atomTitle
atomEntryはsと等しいです: 規則文脈は「原子: エントリー」と等しいです。s: テスト=「原子: 「原子: エントリーには、少なくとも1つの原子がなければなりません: 要素をリンクしてください」という「'補欠のrel属性'がある」 ~「原子: linknot(@rel)」~='代替の' link@rel 「原子: 内容」~」~. s: 規則文脈=「原子: エントリー」という「原子: 内容」がsであると断言してください:. . /原子: テスト=「原子: 作者か」 ~」が作者であるか」 原子: ソース/原子: 作者が「原子: エントリーには、原子: 作者がいなければなりません。」であると断言してください。「~「給送はそうしないかどうか」、要素原子: エントリー、atomCommonAttributes、(atomAuthor*、atomCategory*、atomContent?&atomContributor*、atomId&atomLink*、atomPublished(atomRights)、atomSource(atomSummary)、およびatomTitle
Nottingham & Sayre Standards Track [Page 37] RFC 4287 Atom Format December 2005
ノッティンガムとセアー規格は原子形式2005年12月にRFC4287を追跡します[37ページ]。
& atomUpdated
& extensionElement*)
}
atomUpdatedされるのとextensionElement*) }
# atom:content
# 原子: 内容
atomInlineTextContent =
element atom:content {
atomCommonAttributes,
attribute type { "text" | "html" }?,
(text)*
}
要素atomInlineTextContent=原子: 内容「テキスト」| atomCommonAttributes、属性タイプ"html?"、(テキスト)*
atomInlineXHTMLContent =
element atom:content {
atomCommonAttributes,
attribute type { "xhtml" },
xhtmlDiv
}
要素atomInlineXHTMLContent=原子: 内容atomCommonAttributes、属性タイプ"xhtml"xhtmlDiv
atomInlineOtherContent =
element atom:content {
atomCommonAttributes,
attribute type { atomMediaType }?,
(text|anyElement)*
}
要素atomInlineOtherContent=原子: 内容atomCommonAttributes、属性タイプatomMediaType--、(テキスト| anyElement)*
atomOutOfLineContent =
element atom:content {
atomCommonAttributes,
attribute type { atomMediaType }?,
attribute src { atomUri },
empty
}
要素atomOutOfLineContent=原子: 内容atomCommonAttributes、属性タイプatomMediaType--、src atomUriを結果と考えてください、そして、空になってください。
atomContent = atomInlineTextContent
| atomInlineXHTMLContent
| atomInlineOtherContent
| atomOutOfLineContent
atomContentはatomInlineTextContentと等しいです。| atomInlineXHTMLContent| atomInlineOtherContent| atomOutOfLineContent
# atom:author
# 原子: 作者
atomAuthor = element atom:author { atomPersonConstruct }
要素atomAuthor=原子: 作者atomPersonConstruct
# atom:category
# 原子: カテゴリ
atomCategory =
element atom:category {
atomCategoryは要素原子: カテゴリと等しいです。
Nottingham & Sayre Standards Track [Page 38] RFC 4287 Atom Format December 2005
ノッティンガムとセアー規格は原子形式2005年12月にRFC4287を追跡します[38ページ]。
atomCommonAttributes,
attribute term { text },
attribute scheme { atomUri }?,
attribute label { text }?,
undefinedContent
}
undefinedContent、atomCommonAttributes(属性用語テキスト)は体系atomUri(属性はテキストを分類する)を結果と考えます。
# atom:contributor
# 原子: 貢献者
atomContributor = element atom:contributor { atomPersonConstruct }
要素atomContributor=原子: 貢献者atomPersonConstruct
# atom:generator
# 原子: ジェネレータ
atomGenerator = element atom:generator {
atomCommonAttributes,
attribute uri { atomUri }?,
attribute version { text }?,
text
}
要素atomGenerator=原子: ジェネレータatomCommonAttributes、属性のuri atomUri--、属性バージョンテキスト?、テキスト
# atom:icon
# 原子: アイコン
atomIcon = element atom:icon {
atomCommonAttributes,
(atomUri)
}
要素atomIcon=原子: アイコンatomCommonAttributes、(atomUri)
# atom:id
# 原子: イド
atomId = element atom:id {
atomCommonAttributes,
(atomUri)
}
要素atomId=原子: イドatomCommonAttributes、(atomUri)
# atom:logo
# 原子: ロゴ
atomLogo = element atom:logo {
atomCommonAttributes,
(atomUri)
}
要素atomLogo=原子: ロゴatomCommonAttributes、(atomUri)
# atom:link
# 原子: リンクしてください。
atomLink =
element atom:link {
atomCommonAttributes,
attribute href { atomUri },
attribute rel { atomNCName | atomUri }?,
atomLinkは要素原子と等しいです: リンクしてください、atomCommonAttributes(属性href atomUri)はrelにatomNCName| atomUriを結果と考えますか?
Nottingham & Sayre Standards Track [Page 39] RFC 4287 Atom Format December 2005
ノッティンガムとセアー規格は原子形式2005年12月にRFC4287を追跡します[39ページ]。
attribute type { atomMediaType }?,
attribute hreflang { atomLanguageTag }?,
attribute title { text }?,
attribute length { text }?,
undefinedContent
}
タイプatomMediaTypeを--hreflang atomLanguageTag(属性はテキストを題をつける)を結果と考えてください、属性長さのテキスト--結果と考えてください、undefinedContent
# atom:published
# 原子:、発行
atomPublished = element atom:published { atomDateConstruct }
atomPublished=要素原子:、発行atomDateConstruct
# atom:rights
# 原子: 権利
atomRights = element atom:rights { atomTextConstruct }
要素atomRights=原子: 権利atomTextConstruct
# atom:source
# 原子: ソース
atomSource =
element atom:source {
atomCommonAttributes,
(atomAuthor*
& atomCategory*
& atomContributor*
& atomGenerator?
& atomIcon?
& atomId?
& atomLink*
& atomLogo?
& atomRights?
& atomSubtitle?
& atomTitle?
& atomUpdated?
& extensionElement*)
}
要素atomSource=原子: ソース{ atomCommonAttributes(atomAuthor*、atomCategory*、atomContributor*、およびatomGenerator? atomIcon-- atomId-- atomLink*とatomLogo-- atomRights-- atomSubtitle-- atomTitle-- atomUpdatedされています extensionElement*) }
# atom:subtitle
# 原子:、字幕をつける。
atomSubtitle = element atom:subtitle { atomTextConstruct }
atomSubtitleは要素原子と等しいです:、字幕をつける。atomTextConstruct
# atom:summary
# 原子: 概要
atomSummary = element atom:summary { atomTextConstruct }
要素atomSummary=原子: 概要atomTextConstruct
# atom:title
# 原子: タイトル
atomTitle = element atom:title { atomTextConstruct }
要素atomTitle=原子: タイトルatomTextConstruct
# atom:updated
# 原子:、アップデート
Nottingham & Sayre Standards Track [Page 40] RFC 4287 Atom Format December 2005
ノッティンガムとセアー規格は原子形式2005年12月にRFC4287を追跡します[40ページ]。
atomUpdated = element atom:updated { atomDateConstruct }
atomUpdated=要素原子:、アップデートatomDateConstruct
# Low-level simple types
# 低レベルである純真なタイプ
atomNCName = xsd:string { minLength = "1" pattern = "[^:]*" }
atomNCName=xsd: ストリングminLengthが等しい、「1インチが=を型に基づいて作る、「[^:、]、*、」、」
# Whatever a media type is, it contains at least one slash
atomMediaType = xsd:string { pattern = ".+/.+" }
# メディアタイプが何であっても、それは少なくとも1スラッシュatomMediaType=xsd: ストリングを含んでいます。「パターンが」 . + /+と等しい、」
# As defined in RFC 3066
atomLanguageTag = xsd:string {
pattern = "[A-Za-z]{1,8}(-[A-Za-z0-9]{1,8})*"
}
# RFC3066で定義されるように、atomLanguageTagはxsd: ストリングと等しいです。=を型に基づいて作ってください、「1、[A-Za-z]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
# 自由。 それのもの、完全に明確でないIRIは#xsdに収まります: したがって、anyURIが、ここでそれを抑制するのをどのように試みるのをやめようかを=atomUriテキスト
# Whatever an email address is, it contains at least one @
atomEmailAddress = xsd:string { pattern = ".+@.+" }
# Eメールアドレスが何であっても、それは少なくとも1@のatomEmailAddress=xsd: ストリングを含んでいます。{ pattern = ".+@.+" }
# Simple Extension
# 単純拡大
simpleExtensionElement =
element * - atom:* {
text
}
simpleExtensionElementは要素*と等しいです--原子: *テキスト
# Structured Extension
# 構造化された拡大
structuredExtensionElement =
element * - atom:* {
(attribute * { text }+,
(text|anyElement)*)
| (attribute * { text }*,
(text?, anyElement+, (text|anyElement)*))
}
structuredExtensionElementは要素*と等しいです--原子: *(*テキストを結果と考えてください、+、(テキスト| anyElement) *)|、(*テキストを結果と考えてください、*、(テキスト?、anyElement+、(テキスト| anyElement) *)
# Other Extensibility
# 他の伸展性
extensionElement =
simpleExtensionElement | structuredExtensionElement
extensionElementはsimpleExtensionElementと等しいです。| structuredExtensionElement
undefinedAttribute =
attribute * - (xml:base | xml:lang | local:*) { text }
undefinedAttributeは属性*と等しいです--(xml: ベース|xml:lang|ローカル:*)テキスト
undefinedContent = (text|anyForeignElement)*
undefinedContentは*と等しいです(テキスト| anyForeignElement)。
Nottingham & Sayre Standards Track [Page 41] RFC 4287 Atom Format December 2005
ノッティンガムとセアー規格は原子形式2005年12月にRFC4287を追跡します[41ページ]。
anyElement =
element * {
(attribute * { text }
| text
| anyElement)*
}
anyElementは要素*と等しいです。(属性*テキスト| テキスト| anyElement)*
anyForeignElement =
element * - atom:* {
(attribute * { text }
| text
| anyElement)*
}
anyForeignElementは要素*と等しいです--原子: *(属性*テキスト| テキスト| anyElement)*
# XHTML
# XHTML
anyXHTML = element xhtml:* {
(attribute * { text }
| text
| anyXHTML)*
}
anyXHTMLは要素xhtmlと等しいです: *(属性*テキスト| テキスト| anyXHTML)*
xhtmlDiv = element xhtml:div {
(attribute * { text }
| text
| anyXHTML)*
}
xhtmlDiv=要素xhtml: div(属性*テキスト| テキスト| anyXHTML)*
# EOF
# EOF
Authors' Addresses
作者のアドレス
Mark Nottingham (editor)
マーク・ノッティンガム(エディタ)
EMail: mnot@pobox.com URI: http://www.mnot.net/
メール: mnot@pobox.com ユリ: http://www.mnot.net/
Robert Sayre (editor)
ロバート・セアー(エディタ)
EMail: rfsayre@boswijck.com URI: http://boswijck.com
メール: rfsayre@boswijck.com ユリ: http://boswijck.com
Nottingham & Sayre Standards Track [Page 42] RFC 4287 Atom Format December 2005
ノッティンガムとセアー規格は原子形式2005年12月にRFC4287を追跡します[42ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Nottingham & Sayre Standards Track [Page 43]
ノッティンガムとセアー標準化過程[43ページ]
一覧
スポンサーリンク
