Network Working Group J. Gregorio, Ed.
Request for Comments: 5023 Google
Category: Standards Track B. de hOra, Ed.
NewBay Software
October 2007
Network Working Group J. Gregorio, Ed.
Request for Comments: 5023 Google
Category: Standards Track B. de hOra, Ed.
NewBay Software
October 2007
The Atom Publishing Protocol
Atom发布协议
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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
The Atom Publishing Protocol (AtomPub) is an application-level protocol for publishing and editing Web resources. The protocol is based on HTTP transfer of Atom-formatted representations. The Atom format is documented in the Atom Syndication Format.
Atom发布协议（AtomPublishing Protocol，AtomPub）是用于发布和编辑Web资源的应用程序级协议。该协议基于Atom格式表示的HTTP传输。Atom格式以Atom联合格式记录。
Table of Contents
目录
1. Introduction ....................................................4
2. Notational Conventions ..........................................4
2.1. XML-Related Conventions ....................................4
2.1.1. Referring to Information Items ......................4
2.1.2. RELAX NG Schema .....................................4
2.1.3. Use of "xml:base" and "xml:lang" ....................5
3. Terminology .....................................................5
4. Protocol Model ..................................................6
4.1. Identity and Naming ........................................6
4.2. Documents and Resource Classification ......................7
4.3. Control and Publishing .....................................8
4.4. Client Implementation Considerations .......................9
5. Protocol Operations .............................................9
5.1. Retrieving a Service Document .............................10
5.2. Listing Collection Members ................................10
5.3. Creating a Resource .......................................11
5.4. Editing a Resource ........................................11
5.4.1. Retrieving a Resource ..............................11
5.4.2. Editing a Resource .................................12
5.4.3. Deleting a Resource ................................12
5.5. Use of HTTP Response Codes ................................12
6. Protocol Documents .............................................13
6.1. Document Types ............................................13
6.2. Document Extensibility ....................................13
7. Category Documents .............................................14
7.1. Example ...................................................14
7.2. Element Definitions .......................................14
7.2.1. The "app:categories" Element .......................14
8. Service Documents ..............................................15
8.1. Workspaces ................................................16
8.2. Example ...................................................16
8.3. Element Definitions .......................................17
8.3.1. The "app:service" Element ..........................17
8.3.2. The "app:workspace" Element ........................18
8.3.3. The "app:collection" Element .......................18
8.3.4. The "app:accept" Element ...........................19
8.3.5. Usage in Atom Feed Documents .......................19
8.3.6. The "app:categories" Element .......................20
9. Creating and Editing Resources .................................20
9.1. Member URIs ...............................................20
9.2. Creating Resources with POST ..............................20
9.2.1. Example ............................................21
9.3. Editing Resources with PUT ................................22
9.4. Deleting Resources with DELETE ............................22
9.5. Caching and Entity Tags ...................................22
9.5.1. Example ............................................23
1. Introduction ....................................................4
2. Notational Conventions ..........................................4
2.1. XML-Related Conventions ....................................4
2.1.1. Referring to Information Items ......................4
2.1.2. RELAX NG Schema .....................................4
2.1.3. Use of "xml:base" and "xml:lang" ....................5
3. Terminology .....................................................5
4. Protocol Model ..................................................6
4.1. Identity and Naming ........................................6
4.2. Documents and Resource Classification ......................7
4.3. Control and Publishing .....................................8
4.4. Client Implementation Considerations .......................9
5. Protocol Operations .............................................9
5.1. Retrieving a Service Document .............................10
5.2. Listing Collection Members ................................10
5.3. Creating a Resource .......................................11
5.4. Editing a Resource ........................................11
5.4.1. Retrieving a Resource ..............................11
5.4.2. Editing a Resource .................................12
5.4.3. Deleting a Resource ................................12
5.5. Use of HTTP Response Codes ................................12
6. Protocol Documents .............................................13
6.1. Document Types ............................................13
6.2. Document Extensibility ....................................13
7. Category Documents .............................................14
7.1. Example ...................................................14
7.2. Element Definitions .......................................14
7.2.1. The "app:categories" Element .......................14
8. Service Documents ..............................................15
8.1. Workspaces ................................................16
8.2. Example ...................................................16
8.3. Element Definitions .......................................17
8.3.1. The "app:service" Element ..........................17
8.3.2. The "app:workspace" Element ........................18
8.3.3. The "app:collection" Element .......................18
8.3.4. The "app:accept" Element ...........................19
8.3.5. Usage in Atom Feed Documents .......................19
8.3.6. The "app:categories" Element .......................20
9. Creating and Editing Resources .................................20
9.1. Member URIs ...............................................20
9.2. Creating Resources with POST ..............................20
9.2.1. Example ............................................21
9.3. Editing Resources with PUT ................................22
9.4. Deleting Resources with DELETE ............................22
9.5. Caching and Entity Tags ...................................22
9.5.1. Example ............................................23
9.6. Media Resources and Media Link Entries ....................25
9.6.1. Examples ...........................................26
9.7. The Slug Header ...........................................30
9.7.1. Slug Header Syntax .................................31
9.7.2. Example ............................................31
10. Listing Collections ...........................................32
10.1. Collection Partial Lists .................................32
10.2. The "app:edited" Element .................................33
11. Atom Format Link Relation Extensions ..........................34
11.1. The "edit" Link Relation .................................34
11.2. The "edit-media" Link Relation ...........................34
12. The Atom Format Type Parameter ................................34
12.1. The "type" parameter .....................................34
12.1.1. Conformance .......................................35
13. Atom Publishing Controls ......................................35
13.1. The "app:control" Element ................................35
13.1.1. The "app:draft" Element ...........................36
14. Securing the Atom Publishing Protocol .........................36
15. Security Considerations .......................................37
15.1. Denial of Service ........................................37
15.2. Replay Attacks ...........................................37
15.3. Spoofing Attacks .........................................37
15.4. Linked Resources .........................................38
15.5. Digital Signatures and Encryption ........................38
15.6. URIs and IRIs ............................................38
15.7. Code Injection and Cross Site Scripting ..................39
16. IANA Considerations ...........................................39
16.1. Content-Type Registration for 'application/atomcat+xml' ..39
16.2. Content-Type Registration for 'application/atomsvc+xml' ..40
16.3. Header Field Registration for 'SLUG' .....................42
16.4. The Link Relation Registration "edit" ....................42
16.5. The Link Relation Registration "edit-media" ..............42
16.6. The Atom Format Media Type Parameter .....................43
17. References ....................................................43
17.1. Normative References .....................................43
17.2. Informative References ...................................44
Appendix A. Contributors ..........................................46
Appendix B. RELAX NG Compact Schema ...............................46
9.6. Media Resources and Media Link Entries ....................25
9.6.1. Examples ...........................................26
9.7. The Slug Header ...........................................30
9.7.1. Slug Header Syntax .................................31
9.7.2. Example ............................................31
10. Listing Collections ...........................................32
10.1. Collection Partial Lists .................................32
10.2. The "app:edited" Element .................................33
11. Atom Format Link Relation Extensions ..........................34
11.1. The "edit" Link Relation .................................34
11.2. The "edit-media" Link Relation ...........................34
12. The Atom Format Type Parameter ................................34
12.1. The "type" parameter .....................................34
12.1.1. Conformance .......................................35
13. Atom Publishing Controls ......................................35
13.1. The "app:control" Element ................................35
13.1.1. The "app:draft" Element ...........................36
14. Securing the Atom Publishing Protocol .........................36
15. Security Considerations .......................................37
15.1. Denial of Service ........................................37
15.2. Replay Attacks ...........................................37
15.3. Spoofing Attacks .........................................37
15.4. Linked Resources .........................................38
15.5. Digital Signatures and Encryption ........................38
15.6. URIs and IRIs ............................................38
15.7. Code Injection and Cross Site Scripting ..................39
16. IANA Considerations ...........................................39
16.1. Content-Type Registration for 'application/atomcat+xml' ..39
16.2. Content-Type Registration for 'application/atomsvc+xml' ..40
16.3. Header Field Registration for 'SLUG' .....................42
16.4. The Link Relation Registration "edit" ....................42
16.5. The Link Relation Registration "edit-media" ..............42
16.6. The Atom Format Media Type Parameter .....................43
17. References ....................................................43
17.1. Normative References .....................................43
17.2. Informative References ...................................44
Appendix A. Contributors ..........................................46
Appendix B. RELAX NG Compact Schema ...............................46
The Atom Publishing Protocol is an application-level protocol for publishing and editing Web Resources using HTTP [RFC2616] and XML 1.0 [REC-xml]. The protocol supports the creation of Web Resources and provides facilities for:
Atom发布协议是一种应用程序级协议，用于使用HTTP[RFC2616]和XML 1.0[REC XML]发布和编辑Web资源。该协议支持创建Web资源，并提供以下功能：
o Collections: Sets of Resources, which can be retrieved in whole or in part.
o 集合：可以全部或部分检索的资源集。
o Services: Discovery and description of Collections.
o 服务：发现和描述集合。
o Editing: Creating, editing, and deleting Resources.
o 编辑：创建、编辑和删除资源。
The Atom Publishing Protocol is different from many contemporary protocols in that the server is given wide latitude in processing requests from clients. See Section 4.4 for more details.
Atom发布协议不同于许多当代协议，因为服务器在处理来自客户端的请求时有很大的自由度。详见第4.4节。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Atom Protocol Document formats are specified in terms of the XML Information Set [REC-xml-infoset], serialized as XML 1.0 [REC-xml].
Atom协议文档格式是根据XML信息集[REC XML infoset]指定的，序列化为XML 1.0[REC XML]。
The Infoset terms "Element Information Item" and "Attribute Information Item" are shortened to "element" and "attribute" respectively. Therefore, when this specification uses the term "element", it is referring to an Element Information Item, and when it uses the term "attribute", it is referring to an Attribute Information Item.
信息集术语“元素信息项”和“属性信息项”分别缩短为“元素”和“属性”。因此，当本说明书使用术语“元素”时，它指的是元素信息项，当它使用术语“属性”时，它指的是属性信息项。
Some sections of this specification are illustrated with fragments of a non-normative RELAX NG Compact schema [RNC]. However, the text of this specification provides the definition of conformance. Complete schemas appear in Appendix B.
本规范的某些部分用非标准RELAX NG紧凑模式[RNC]的片段进行了说明。然而，本规范的文本提供了一致性的定义。完整的模式见附录B。
XML elements defined by this specification MAY have an "xml:base" attribute [REC-xmlbase]. When xml:base is used, it serves the function described in Section 5.1.1 of URI Generic Syntax [RFC3986], by establishing the base URI (or IRI, Internationalized Resource Identifier [RFC3987]) for resolving relative references found within the scope of the "xml:base" attribute.
本规范定义的XML元素可能具有“XML:base”属性[REC xmlbase]。使用xml:base时，它通过建立基本URI（或IRI，国际化资源标识符[RFC3987]）来解析“xml:base”属性范围内的相对引用，从而实现URI通用语法[RFC3986]第5.1.1节中描述的功能。
Any element defined by this specification MAY have an "xml:lang" attribute, whose content indicates the natural language for the element and its descendants. Requirements regarding the content and interpretation of "xml:lang" are specified in Section 2.12 of XML 1.0 [REC-xml].
本规范定义的任何元素都可能具有“xml:lang”属性，其内容表示元素及其子体的自然语言。xml 1.0[REC xml]第2.12节规定了有关“xml:lang”的内容和解释的要求。
For convenience, this protocol can be referred to as the "Atom Protocol" or "AtomPub". The following terminology is used by this specification:
为方便起见，该协议可称为“Atom协议”或“AtomPub”。本规范使用以下术语：
o URI - A Uniform Resource Identifier as defined in [RFC3986]. In this specification, the phrase "the URI of a document" is shorthand for "a URI which, when dereferenced, is expected to produce that document as a representation".
o URI—在[RFC3986]中定义的统一资源标识符。在本规范中，短语“文档的URI”是“一个URI的简写，该URI在被取消引用时，预期将生成该文档作为表示”。
o IRI - An Internationalized Resource Identifier as defined in [RFC3987]. Before an IRI found in a document is used by HTTP, the IRI is first converted to a URI. See Section 4.1.
o IRI-在[RFC3987]中定义的国际化资源标识符。在HTTP使用文档中找到的IRI之前，首先将IRI转换为URI。见第4.1节。
o Resource - A network-accessible data object or service identified by an IRI, as defined in [RFC2616]. See [REC-webarch] for further discussion on Resources.
o 资源-由IRI标识的网络可访问数据对象或服务，如[RFC2616]中所定义。有关资源的进一步讨论，请参见[REC webarch]。
o relation (or "relation of") - Refers to the "rel" attribute value of an atom:link element.
o relation（或“relation of”）—指原子的“rel”属性值：link元素。
o Representation - An entity included with a request or response as defined in [RFC2616].
o 表示-包含在[RFC2616]中定义的请求或响应中的实体。
o Collection - A Resource that contains a set of Member Resources. Collections are represented as Atom Feeds. See Section 9.
o 集合-包含一组成员资源的资源。集合表示为Atom提要。见第9节。
o Member (or Member Resource) - A Resource whose IRI is listed in a Collection by an atom:link element with a relation of "edit" or "edit-media". See Section 9.1. The protocol defines two kinds of Members:
o 成员（或成员资源）-其IRI由atom:link元素以“编辑”或“编辑媒体”关系列在集合中的资源。见第9.1节。协议定义了两类成员：
* Entry Resource - Members of a Collection that are represented as Atom Entry Documents, as defined in [RFC4287].
* 条目资源-集合中表示为Atom条目文档的成员，如[RFC4287]中所定义。
* Media Resource - Members of a Collection that have representations other than Atom Entry Documents.
* 媒体资源-具有除Atom条目文档以外的表示形式的集合成员。
o Media Link Entry - An Entry Resource that contains metadata about a Media Resource. See Section 9.6.
o 媒体链接条目-包含媒体资源元数据的条目资源。见第9.6节。
o Workspace - A named group of Collections. See Section 8.1.
o 工作区-集合的命名组。见第8.1节。
o Service Document - A document that describes the location and capabilities of one or more Collections, grouped into Workspaces. See Section 8.
o 服务文档—描述一个或多个集合（分组到工作区）的位置和功能的文档。见第8节。
o Category Document - A document that describes the categories allowed in a Collection. See Section 7.
o 类别文档-描述集合中允许的类别的文档。见第7节。
The Atom Protocol specifies operations for publishing and editing Resources using HTTP. It uses Atom-formatted representations to describe the state and metadata of those Resources. It defines how Collections of Resources can be organized, and it specifies formats to support their discovery, grouping and categorization.
Atom协议指定使用HTTP发布和编辑资源的操作。它使用Atom格式的表示来描述这些资源的状态和元数据。它定义了如何组织资源集合，并指定了支持资源发现、分组和分类的格式。
Atom Protocol documents allow the use of IRIs [RFC3987] as well as URIs [RFC3986] to identify Resources. Before an IRI in a document is used by HTTP, the IRI is first converted to a URI according to the procedure defined in Section 3.1 of [RFC3987]. In accordance with that specification, the conversion SHOULD be applied as late as possible. Conversion does not imply Resource creation -- the IRI and the URI into which it is converted identify the same Resource.
Atom协议文档允许使用IRIs[RFC3987]和URI[RFC3986]来标识资源。在HTTP使用文档中的IRI之前，首先根据[RFC3987]第3.1节中定义的过程将IRI转换为URI。根据该规范，应尽可能晚地进行转换。转换并不意味着资源创建——IRI和它转换成的URI标识相同的资源。
While the Atom Protocol specifies the formats of the representations that are exchanged and the actions that can be performed on the IRIs embedded in those representations, it does not constrain the form of the URIs that are used. HTTP [RFC2616] specifies that the URI space of each server is controlled by that server, and this protocol imposes no further constraints on that control.
虽然Atom协议指定了交换的表示的格式以及可以在嵌入这些表示中的IRI上执行的操作，但它并不限制所使用的URI的形式。HTTP[RFC2616]指定每个服务器的URI空间由该服务器控制，并且该协议不对该控制施加进一步的约束。
A Resource whose IRI is listed in a Collection is called a Member Resource. The protocol defines two kinds of Member Resources -- Entry Resources and Media Resources. Entry Resources are represented as Atom Entry Documents [RFC4287]. Media Resources can have representations in any media type. A Media Resource is described within a Collection using an Entry called a Media Link Entry. This diagram shows the classification of Resources within the Atom Protocol:
IRI列在集合中的资源称为成员资源。协议定义了两种成员资源——入口资源和媒体资源。条目资源表示为Atom条目文档[RFC4287]。媒体资源可以具有任何媒体类型的表示形式。使用称为媒体链接条目的条目在集合中描述媒体资源。此图显示了Atom协议中的资源分类：
Member Resources
|
-----------------
| |
Entry Resources Media Resources
|
Media Link Entry
Member Resources
|
-----------------
| |
Entry Resources Media Resources
|
Media Link Entry
The Atom Protocol defines Collection Resources for managing and organizing both kinds of Member Resource. A Collection is represented by an Atom Feed Document. A Collection Feed's Entries contain the IRIs of, and metadata about, the Collection's Member Resources. A Collection Feed can contain any number of Entries, which might represent all the Members of the Collection, or an ordered subset of them (see Section 10.1). In the diagram of a Collection below, there are two Entries. The first contains the IRI of an Entry Resource. The second contains the IRIs of both a Media Resource and a Media Link Entry, which contains the metadata for that Media Resource:
Atom协议定义了用于管理和组织这两种成员资源的集合资源。集合由Atom提要文档表示。集合提要的条目包含集合成员资源的IRI和元数据。集合提要可以包含任意数量的条目，这些条目可能表示集合的所有成员，或者它们的有序子集（请参见第10.1节）。在下面的集合图中，有两个条目。第一个包含条目资源的IRI。第二个包含媒体资源和媒体链接条目的IRI，其中包含该媒体资源的元数据：
Collection
|
o- Entry
| |
| o- Member Entry IRI (Entry Resource)
|
o- Entry
|
o- Member Entry IRI (Media Link Entry)
|
o- Media IRI (Media Resource)
Collection
|
o- Entry
| |
| o- Member Entry IRI (Entry Resource)
|
o- Entry
|
o- Member Entry IRI (Media Link Entry)
|
o- Media IRI (Media Resource)
The Atom Protocol does not make a distinction between Feeds used for Collections and other Atom Feeds. The only mechanism that this specification supplies for indicating that a Feed is a Collection Feed is the presence of the Feed's IRI in a Service Document.
Atom协议不区分用于集合的提要和其他Atom提要。本规范为指示提要是集合提要提供的唯一机制是在服务文档中存在提要的IRI。
Service Documents represent server-defined groups of Collections, and are used to initialize the process of creating and editing Resources. These groups of Collections are called Workspaces. Workspaces have names, but no IRIs, and no specified processing model. The Service Document can indicate which media types, and which categories, a Collection will accept. In the diagram below, there are two Workspaces each describing the IRIs, acceptable media types, and categories for a Collection:
服务文档表示服务器定义的集合组，用于初始化创建和编辑资源的过程。这些集合组称为工作空间。工作区有名称，但没有IRI，也没有指定的处理模型。服务文档可以指示集合将接受哪些媒体类型和类别。在下图中，有两个工作区，分别描述IRIs、可接受的媒体类型和集合的类别：
Service
o- Workspace
| |
| o- Collection
| |
| o- IRI, categories, media types
|
o- Workspace
|
o- Collection
|
o- IRI, categories, media types
Service
o- Workspace
| |
| o- Collection
| |
| o- IRI, categories, media types
|
o- Workspace
|
o- Collection
|
o- IRI, categories, media types
The Atom Publishing Protocol uses HTTP methods to author Member Resources as follows:
Atom发布协议使用HTTP方法编写成员资源，如下所示：
o GET is used to retrieve a representation of a known Resource.
o GET用于检索已知资源的表示形式。
o POST is used to create a new, dynamically named, Resource. When the client submits non-Atom-Entry representations to a Collection for creation, two Resources are always created -- a Media Entry for the requested Resource, and a Media Link Entry for metadata about the Resource that will appear in the Collection.
o POST用于创建动态命名的新资源。当客户端向集合提交非Atom条目表示以进行创建时，始终会创建两个资源—一个用于请求的资源的媒体条目，一个用于显示在集合中的资源元数据的媒体链接条目。
o PUT is used to edit a known Resource. It is not used for Resource creation.
o PUT用于编辑已知资源。它不用于创建资源。
o DELETE is used to remove a known Resource.
o 删除用于删除已知资源。
The Atom Protocol only covers the creating, editing, and deleting of Entry and Media Resources. Other Resources could be created, edited, and deleted as the result of manipulating a Collection, but the number of those Resources, their media types, and effects of Atom Protocol operations on them are outside the scope of this specification.
Atom协议仅涵盖条目和媒体资源的创建、编辑和删除。操作集合时可以创建、编辑和删除其他资源，但这些资源的数量、媒体类型以及Atom协议操作对它们的影响不在本规范的范围内。
Since all aspects of client-server interaction are defined in terms of HTTP, [RFC2616] should be consulted for any areas not covered in this specification.
由于客户机-服务器交互的所有方面都是根据HTTP定义的，因此本规范中未涉及的任何领域都应咨询[RFC2616]。
The Atom Protocol imposes few restrictions on the actions of servers. Unless a constraint is specified here, servers can be expected to vary in behavior, in particular around the manipulation of Atom Entries sent by clients. For example, although this specification only defines the expected behavior of Collections with respect to GET and POST, this does not imply that PUT, DELETE, PROPPATCH, and others are forbidden on Collection Resources -- only that this specification does not define what the server's response would be to those methods. Similarly, while some HTTP status codes are mentioned explicitly, clients ought to be prepared to handle any status code from a server. Servers can choose to accept, reject, delay, moderate, censor, reformat, translate, relocate, or re-categorize the content submitted to them. Only some of these choices are immediately relayed back to the client in responses to client requests; other choices may only become apparent later, in the feed or published entries. The same series of requests to two different publishing sites can result in a different series of HTTP responses, different resulting feeds, or different entry contents.
Atom协议对服务器的操作几乎没有限制。除非这里指定了约束，否则服务器的行为可能会有所不同，特别是在操作客户端发送的Atom条目时。例如，尽管该规范仅定义了集合在GET和POST方面的预期行为，但这并不意味着在集合资源上禁止PUT、DELETE、PROPPATCH和其他操作——只是该规范没有定义服务器对这些方法的响应。类似地，虽然明确提到了一些HTTP状态代码，但客户端应该准备好处理来自服务器的任何状态代码。服务器可以选择接受、拒绝、延迟、缓和、审查、重新格式化、翻译、重新定位或重新分类提交给它们的内容。只有这些选择中的一部分会立即中继回客户机以响应客户机请求；其他选择可能只会在以后的提要或发布的条目中变得明显。对两个不同发布站点的同一系列请求可能会导致一系列不同的HTTP响应、不同的结果提要或不同的条目内容。
As a result, client software has to be written flexibly to accept what the server decides are the results of its submissions. Any server response or server content modification not explicitly forbidden by this specification or HTTP [RFC2616] is therefore allowed.
因此，客户端软件必须灵活编写，以接受服务器决定的提交结果。因此，允许本规范或HTTP[RFC2616]未明确禁止的任何服务器响应或服务器内容修改。
While specific HTTP status codes are shown in the interaction diagrams below, an AtomPub client should be prepared to handle any status code. For example, a PUT to a Member URI could result in the return of a "204 No Content" status code, which still indicates success.
虽然下面的交互图中显示了特定的HTTP状态代码，但AtomPub客户端应该准备好处理任何状态代码。例如，对成员URI的PUT可能导致返回“204无内容”状态代码，这仍然表示成功。
Client Server
| |
| 1.) GET to Service Document URI |
|------------------------------------------>|
| |
| 2.) 200 Ok |
| Service Document |
|<------------------------------------------|
| |
Client Server
| |
| 1.) GET to Service Document URI |
|------------------------------------------>|
| |
| 2.) 200 Ok |
| Service Document |
|<------------------------------------------|
| |
1. The client sends a GET request to the URI of the Service Document.
1. 客户端向服务文档的URI发送GET请求。
2. The server responds with a Service Document enumerating the IRIs of a group of Collections and the capabilities of those Collections supported by the server. The content of this document can vary based on aspects of the client request, including, but not limited to, authentication credentials.
2. 服务器响应一个服务文档，该文档列举了一组集合的IRI以及服务器支持的这些集合的功能。本文档的内容可能因客户端请求的各个方面而有所不同，包括但不限于身份验证凭据。
To list the Members of a Collection, the client sends a GET request to the URI of a Collection. An Atom Feed Document is returned whose Entries contain the IRIs of Member Resources. The returned Feed may describe all, or only a partial list, of the Members in a Collection (see Section 10).
为了列出集合的成员，客户端向集合的URI发送GET请求。返回一个Atom提要文档，其条目包含成员资源的IRI。返回的提要可以描述集合中的所有成员，也可以仅描述部分成员列表（请参见第10节）。
Client Server
| |
| 1.) GET to Collection URI |
|------------------------------->|
| |
| 2.) 200 Ok |
| Atom Feed Document |
|<-------------------------------|
| |
Client Server
| |
| 1.) GET to Collection URI |
|------------------------------->|
| |
| 2.) 200 Ok |
| Atom Feed Document |
|<-------------------------------|
| |
1. The client sends a GET request to the URI of the Collection.
1. 客户端向集合的URI发送GET请求。
2. The server responds with an Atom Feed Document containing the IRIs of the Collection Members.
2. 服务器使用包含集合成员的IRI的Atom提要文档进行响应。
Client Server
| |
| 1.) POST to Collection URI |
| Member Representation |
|------------------------------------------>|
| |
| 2.) 201 Created |
| Location: Member Entry URI |
|<------------------------------------------|
| |
Client Server
| |
| 1.) POST to Collection URI |
| Member Representation |
|------------------------------------------>|
| |
| 2.) 201 Created |
| Location: Member Entry URI |
|<------------------------------------------|
| |
1. The client POSTs a representation of the Member to the URI of the Collection.
1. 客户端将成员的表示形式发布到集合的URI。
2. If the Member Resource was created successfully, the server responds with a status code of 201 and a Location header that contains the IRI of the newly created Entry Resource. Media Resources could have also been created and their IRIs can be found through the Entry Resource. See Section 9.6 for more details.
2. 如果成功创建了成员资源，服务器将使用状态代码201和包含新创建的条目资源的IRI的位置标头进行响应。还可以创建媒体资源，并且可以通过条目资源找到它们的IRI。详见第9.6节。
Once a Resource has been created and its Member URI is known, that URI can be used to retrieve, edit, and delete the Resource. Section 11 describes extensions to the Atom Syndication Format used in the Atom Protocol for editing purposes.
一旦资源被创建并且其成员URI已知，该URI就可以用于检索、编辑和删除资源。第11节描述了Atom协议中用于编辑目的的Atom联合格式的扩展。
Client Server
| |
| 1.) GET to Member URI |
|------------------------------------------>|
| |
| 2.) 200 Ok |
| Member Representation |
|<------------------------------------------|
| |
Client Server
| |
| 1.) GET to Member URI |
|------------------------------------------>|
| |
| 2.) 200 Ok |
| Member Representation |
|<------------------------------------------|
| |
1. The client sends a GET request to the URI of a Member Resource to retrieve its representation.
1. 客户端向成员资源的URI发送GET请求以检索其表示形式。
2. The server responds with the representation of the Member Resource.
2. 服务器以成员资源的表示形式进行响应。
Client Server
| |
| 1.) PUT to Member URI |
| Member Representation |
|------------------------------------------>|
| |
| 2.) 200 OK |
|<------------------------------------------|
Client Server
| |
| 1.) PUT to Member URI |
| Member Representation |
|------------------------------------------>|
| |
| 2.) 200 OK |
|<------------------------------------------|
1. The client sends a PUT request to store a representation of a Member Resource.
1. 客户端发送PUT请求以存储成员资源的表示形式。
2. If the request is successful, the server responds with a status code of 200.
2. 如果请求成功，服务器将使用状态代码200进行响应。
Client Server
| |
| 1.) DELETE to Member URI |
|------------------------------------------>|
| |
| 2.) 200 OK |
|<------------------------------------------|
| |
Client Server
| |
| 1.) DELETE to Member URI |
|------------------------------------------>|
| |
| 2.) 200 OK |
|<------------------------------------------|
| |
1. The client sends a DELETE request to the URI of a Member Resource.
1. 客户端向成员资源的URI发送删除请求。
2. If the deletion is successful, the server responds with a status code of 200.
2. 如果删除成功，服务器将以状态代码200进行响应。
A different approach is taken for deleting Media Resources; see Section 9.4 for details.
使用不同的方法删除媒体资源；详见第9.4节。
The Atom Protocol uses the response status codes defined in HTTP to indicate the success or failure of an operation. Consult the HTTP specification [RFC2616] for detailed definitions of each status code.
Atom协议使用HTTP中定义的响应状态代码来指示操作的成功或失败。有关每个状态代码的详细定义，请参阅HTTP规范[RFC2616]。
Implementers are asked to note that according to the HTTP specification, HTTP 4xx and 5xx response entities SHOULD include a human-readable explanation of the error.
要求实现者注意，根据HTTP规范，HTTP 4xx和5xx响应实体应该包含一个可读的错误解释。
This specification defines two kinds of documents -- Category Documents and Service Documents.
本规范定义了两类文档——类别文档和服务文档。
A Category Document (Section 7) contains lists of categories specified using the "atom:category" element from the Atom Syndication Format (see Section 4.2.2 of [RFC4287]).
类别文档（第7节）包含使用atom联合格式中的“atom:Category”元素指定的类别列表（见[RFC4287]第4.2.2节）。
A Service Document (Section 8) groups available Collections into Workspaces.
服务文档（第8节）将可用集合分组到工作区中。
The namespace name [REC-xml-names] for either kind of document is:
任何一种文档的命名空间名称[REC xml names]为：
http://www.w3.org/2007/app
http://www.w3.org/2007/app
Atom Publishing Protocol XML Documents MUST be "namespace-well-formed" as specified in Section 7 of [REC-xml-names].
Atom发布协议XML文档必须是[REC XML名称]第7节中指定的“名称空间格式良好”。
This specification uses the prefix "app:" for the namespace name. The prefix "atom:" is used for "http://www.w3.org/2005/Atom", the namespace name of the Atom Syndication Format [RFC4287]. These namespace prefixes are not semantically significant.
此规范使用前缀“app:”作为名称空间名称。前缀“atom:”用于http://www.w3.org/2005/Atom，Atom联合格式[RFC4287]的命名空间名称。这些名称空间前缀在语义上并不重要。
This specification does not define any DTDs for Atom Protocol formats, and hence does not require them to be "valid" in the sense used by [REC-xml].
本规范没有为Atom协议格式定义任何DTD，因此不要求它们在[REC xml]使用的意义上是“有效的”。
Unrecognized markup in an Atom Publishing Protocol document is considered "foreign markup" as defined in Section 6 of the Atom Syndication Format [RFC4287]. Foreign markup can be used anywhere within a Category or Service Document unless it is explicitly forbidden. Processors that encounter foreign markup MUST NOT stop processing and MUST NOT signal an error. Clients SHOULD preserve foreign markup when transmitting such documents.
Atom发布协议文档中未识别的标记被视为Atom联合格式[RFC4287]第6节中定义的“外来标记”。除非明确禁止，否则外来标记可以在类别或服务文档中的任何位置使用。遇到外来标记的处理器不得停止处理，也不得发出错误信号。客户在传输此类文档时应保留外来标记。
The namespace name "http://www.w3.org/2007/app" is reserved for forward-compatible revisions of the Category and Service Document types. This does not exclude the addition of elements and attributes that might not be recognized by processors conformant to this specification. Such unrecognized markup from the "http://www.w3.org/2007/app" namespace MUST be treated as foreign markup.
名称空间名称“http://www.w3.org/2007/app“保留用于类别和服务文档类型的向前兼容修订。这并不排除添加符合本规范的处理器可能无法识别的元素和属性。来自“”的此类无法识别的标记http://www.w3.org/2007/app“命名空间必须视为外部标记。
Category Documents contain lists of categories described using the "atom:category" element from the Atom Syndication Format [RFC4287]. Categories can also appear in Service Documents, where they indicate the categories allowed in a Collection (see Section 8.3.6).
类别文档包含使用atom联合格式[RFC4287]中的“atom:Category”元素描述的类别列表。类别也可以出现在服务文档中，它们表示集合中允许的类别（参见第8.3.6节）。
Category Documents are identified with the "application/atomcat+xml" media type (see Section 16.1).
类别文档用“application/atomcat+xml”媒体类型标识（见第16.1节）。
<?xml version="1.0" ?>
<app:categories
xmlns:app="http://www.w3.org/2007/app"
xmlns:atom="http://www.w3.org/2005/Atom"
fixed="yes" scheme="http://example.com/cats/big3">
<atom:category term="animal" />
<atom:category term="vegetable" />
<atom:category term="mineral" />
</app:categories>
<?xml version="1.0" ?>
<app:categories
xmlns:app="http://www.w3.org/2007/app"
xmlns:atom="http://www.w3.org/2005/Atom"
fixed="yes" scheme="http://example.com/cats/big3">
<atom:category term="animal" />
<atom:category term="vegetable" />
<atom:category term="mineral" />
</app:categories>
This Category Document contains atom:category elements, with the terms 'animal', 'vegetable', and 'mineral'. None of the categories use the "label" attribute defined in [RFC4287]. They all inherit the "http://example.com/cats/big3" "scheme" attribute declared on the app:categories element. Therefore if the 'mineral' category were to appear in an Atom Entry or Feed Document, it would appear as:
此类别文档包含atom:Category元素，其中包含术语“动物”、“植物”和“矿物”。所有类别均未使用[RFC4287]中定义的“标签”属性。他们都继承了"世界遗产",http://example.com/cats/big3在app:categories元素上声明的“scheme”属性。因此，如果“矿物”类别出现在Atom条目或提要文档中，它将显示为：
<atom:category scheme="http://example.com/cats/big3" term="mineral"/>
<atom:category scheme="http://example.com/cats/big3" term="mineral"/>
The root of a Category Document is the "app:categories" element. An app:categories element can contain zero or more atom:category elements from the Atom Syndication Format [RFC4287] namespace ("http://www.w3.org/2005/Atom").
类别文档的根是“app:categories”元素。app:categories元素可以包含来自atom联合格式[RFC4287]命名空间（“http://www.w3.org/2005/Atom").
An atom:category child element that has no "scheme" attribute inherits the attribute from its app:categories parent. An atom: category child element with an existing "scheme" attribute does not inherit the "scheme" value of its app:categories parent element.
没有“scheme”属性的atom:category子元素从其app:categories父元素继承该属性。具有现有“scheme”属性的atom:category子元素不会继承其app:categories父元素的“scheme”值。
atomCategory =
element atom:category {
atomCommonAttributes,
attribute term { text },
attribute scheme { atomURI }?,
attribute label { text }?,
undefinedContent
}
atomCategory =
element atom:category {
atomCommonAttributes,
attribute term { text },
attribute scheme { atomURI }?,
attribute label { text }?,
undefinedContent
}
appInlineCategories =
element app:categories {
attribute fixed { "yes" | "no" }?,
attribute scheme { atomURI }?,
(atomCategory*,
undefinedContent)
}
appInlineCategories =
element app:categories {
attribute fixed { "yes" | "no" }?,
attribute scheme { atomURI }?,
(atomCategory*,
undefinedContent)
}
appOutOfLineCategories =
element app:categories {
attribute href { atomURI },
undefinedContent
}
appOutOfLineCategories =
element app:categories {
attribute href { atomURI },
undefinedContent
}
appCategories = appInlineCategories | appOutOfLineCategories
appCategories=appInlineCategories | AppOutofInCategories
The app:categories element can contain a "fixed" attribute, with a value of either "yes" or "no", indicating whether the list of categories is a fixed or an open set. The absence of the "fixed" attribute is equivalent to the presence of a "fixed" attribute with a value of "no".
app:categories元素可以包含一个“fixed”属性，其值为“yes”或“no”，表示类别列表是固定的还是开放的。缺少“fixed”属性相当于存在值为“no”的“fixed”属性。
Alternatively, the app:categories element MAY contain an "href" attribute, whose value MUST be an IRI reference identifying a Category Document. If the "href" attribute is provided, the app: categories element MUST be empty and MUST NOT have the "fixed" or "scheme" attributes.
或者，app:categories元素可能包含一个“href”属性，其值必须是标识类别文档的IRI引用。如果提供了“href”属性，则app:categories元素必须为空，并且不能具有“fixed”或“scheme”属性。
For authoring to commence, a client needs to discover the capabilities and locations of the available Collections. Service Documents are designed to support this discovery process.
为了开始创作，客户机需要发现可用集合的功能和位置。服务文档旨在支持此发现过程。
How Service Documents are discovered is not defined in this specification.
本规范中未定义如何查找服务文档。
Service Documents are identified with the "application/atomsvc+xml" media type (see Section 16.2).
服务文档用“应用程序/atomsvc+xml”媒体类型标识（见第16.2节）。
A Service Document groups Collections into Workspaces. Operations on Workspaces, such as creation or deletion, are not defined by this specification. This specification assigns no meaning to Workspaces; that is, a Workspace does not imply any specific processing assumptions.
服务文档将集合分组到工作空间中。工作空间上的操作（如创建或删除）不在此规范中定义。本规范不赋予工作空间任何意义；也就是说，工作空间并不意味着任何特定的处理假设。
There is no requirement that a server support multiple Workspaces. In addition, a Collection MAY appear in more than one Workspace.
不要求服务器支持多个工作区。此外，集合可能出现在多个工作区中。
<?xml version="1.0" encoding='utf-8'?>
<service xmlns="http://www.w3.org/2007/app"
xmlns:atom="http://www.w3.org/2005/Atom">
<workspace>
<atom:title>Main Site</atom:title>
<collection
href="http://example.org/blog/main" >
<atom:title>My Blog Entries</atom:title>
<categories
href="http://example.com/cats/forMain.cats" />
</collection>
<collection
href="http://example.org/blog/pic" >
<atom:title>Pictures</atom:title>
<accept>image/png</accept>
<accept>image/jpeg</accept>
<accept>image/gif</accept>
</collection>
</workspace>
<workspace>
<atom:title>Sidebar Blog</atom:title>
<collection
href="http://example.org/sidebar/list" >
<atom:title>Remaindered Links</atom:title>
<accept>application/atom+xml;type=entry</accept>
<categories fixed="yes">
<atom:category
scheme="http://example.org/extra-cats/"
term="joke" />
<atom:category
scheme="http://example.org/extra-cats/"
term="serious" />
<?xml version="1.0" encoding='utf-8'?>
<service xmlns="http://www.w3.org/2007/app"
xmlns:atom="http://www.w3.org/2005/Atom">
<workspace>
<atom:title>Main Site</atom:title>
<collection
href="http://example.org/blog/main" >
<atom:title>My Blog Entries</atom:title>
<categories
href="http://example.com/cats/forMain.cats" />
</collection>
<collection
href="http://example.org/blog/pic" >
<atom:title>Pictures</atom:title>
<accept>image/png</accept>
<accept>image/jpeg</accept>
<accept>image/gif</accept>
</collection>
</workspace>
<workspace>
<atom:title>Sidebar Blog</atom:title>
<collection
href="http://example.org/sidebar/list" >
<atom:title>Remaindered Links</atom:title>
<accept>application/atom+xml;type=entry</accept>
<categories fixed="yes">
<atom:category
scheme="http://example.org/extra-cats/"
term="joke" />
<atom:category
scheme="http://example.org/extra-cats/"
term="serious" />
</categories>
</collection>
</workspace>
</service>
</categories>
</collection>
</workspace>
</service>
The Service Document above describes two Workspaces. The first Workspace is called "Main Site", and has two Collections called "My Blog Entries" and "Pictures", whose IRIs are "http://example.org/blog/main" and "http://example.org/blog/pic" respectively. The "Pictures" Collection includes three "accept" elements indicating the types of image files the client can send to the Collection to create new Media Resources (entries associated with Media Resources are discussed in Section 9.6).
上面的服务文档描述了两个工作区。第一个工作区称为“主站点”，有两个集合称为“我的博客条目”和“图片”，它们的虹膜是http://example.org/blog/main“和”http://example.org/blog/pic“分别。“图片”集合包括三个“接受”元素，指示客户端可以发送到集合以创建新媒体资源的图像文件类型（与媒体资源相关的条目在第9.6节中讨论）。
The second Workspace is called "Sidebar Blog" and has a single Collection called "Remaindered Links" whose IRI is "http://example.org/sidebar/list". The Collection has an "accept" element whose content is "application/atom+xml;type=entry", indicating it will accept Atom Entries from a client.
第二个工作区称为“侧边栏博客”，有一个名为“剩余链接”的集合，其IRI为http://example.org/sidebar/list". 集合有一个“accept”元素，其内容是“application/atom+xml；type=entry”，表示它将从客户端接受atom条目。
Within each of the two Entry Collections, the "categories" element provides a list of available categories for Member Entries. In the "My Blog Entries" Collection, the list of available categories is available through the "href" attribute. The "Sidebar Blog" Collection provides a category list within the Service Document, but states the list is fixed, signaling a request from the server that Entries be POSTed using only those two categories.
在两个条目集合中的每个集合中，“categories”元素为成员条目提供可用类别的列表。在“我的博客条目”集合中，可以通过“href”属性获得可用类别的列表。“边栏博客”集合在服务文档中提供了一个类别列表，但表示该列表是固定的，表示服务器请求只使用这两个类别发布条目。
The root of a Service Document is the "app:service" element.
服务文档的根是“app:Service”元素。
The app:service element is the container for service information associated with one or more Workspaces. An app:service element MUST contain one or more app:workspace elements.
app:service元素是与一个或多个工作区关联的服务信息的容器。app:service元素必须包含一个或多个app:workspace元素。
namespace app = "http://www.w3.org/2007/app"
start = appService
namespace app = "http://www.w3.org/2007/app"
start = appService
appService =
element app:service {
appCommonAttributes,
( appWorkspace+
& extensionElement* )
}
appService =
element app:service {
appCommonAttributes,
( appWorkspace+
& extensionElement* )
}
Workspaces are server-defined groups of Collections. The "app: workspace" element contains zero or more app:collection elements describing the Collections of Resources available for editing.
工作空间是服务器定义的集合组。“app:workspace”元素包含零个或多个app:collection元素，用于描述可供编辑的资源集合。
appWorkspace =
element app:workspace {
appCommonAttributes,
( atomTitle
& appCollection*
& extensionSansTitleElement* )
}
appWorkspace =
element app:workspace {
appCommonAttributes,
( atomTitle
& appCollection*
& extensionSansTitleElement* )
}
atomTitle = element atom:title { atomTextConstruct }
atomTitle = element atom:title { atomTextConstruct }
The app:workspace element MUST contain one "atom:title" element (as defined in [RFC4287]), giving a human-readable title for the Workspace.
app:workspace元素必须包含一个“atom:title”元素（如[RFC4287]中所定义），为工作区提供一个可读的标题。
The "app:collection" element describes a Collection. The app: collection element MUST contain one atom:title element.
“app:collection”元素描述一个集合。app:collection元素必须包含一个atom:title元素。
The app:collection element MAY contain any number of app:accept elements, indicating the types of representations accepted by the Collection. The order of such elements is not significant.
app:collection元素可以包含任意数量的app:accept元素，指示集合接受的表示类型。这些元素的顺序并不重要。
The app:collection element MAY contain any number of app:categories elements.
app:collection元素可以包含任意数量的app:categories元素。
appCollection =
element app:collection {
appCommonAttributes,
attribute href { atomURI },
( atomTitle
& appAccept*
& appCategories*
& extensionSansTitleElement* )
}
appCollection =
element app:collection {
appCommonAttributes,
attribute href { atomURI },
( atomTitle
& appAccept*
& appCategories*
& extensionSansTitleElement* )
}
The app:collection element MUST contain an "href" attribute, whose value gives the IRI of the Collection.
app:collection元素必须包含一个“href”属性，该属性的值给出集合的IRI。
The "atom:title" element is defined in [RFC4287] and gives a human-readable title for the Collection.
[RFC4287]中定义了“atom:title”元素，为集合提供了一个可读的标题。
The content of an "app:accept" element value is a media range as defined in [RFC2616]. The media range specifies a type of representation that can be POSTed to a Collection.
“app:accept”元素值的内容是[RFC2616]中定义的媒体范围。媒体范围指定可以发布到集合的表示形式的类型。
The app:accept element is similar to the HTTP Accept request-header [RFC2616]. Media type parameters are allowed within app:accept, but app:accept has no notion of preference -- "accept-params" or "q" arguments, as specified in Section 14.1 of [RFC2616] are not significant.
app:accept元素类似于HTTP accept请求头[RFC2616]。app:accept中允许使用媒体类型参数，但app:accept没有首选项的概念--[RFC2616]第14.1节中规定的“accept params”或“q”参数不重要。
White space (as defined in [REC-xml]) around the app:accept element's media range is insignificant and MUST be ignored.
app:accept元素的媒体范围周围的空白（定义见[REC xml]）无关紧要，必须忽略。
A value of "application/atom+xml;type=entry" MAY appear in any app: accept list of media ranges and indicates that Atom Entry Documents can be POSTed to the Collection. If no app:accept element is present, clients SHOULD treat this as equivalent to an app:accept element with the content "application/atom+xml;type=entry".
“application/atom+xml；type=entry”的值可能出现在任何app:accept媒体范围列表中，并指示可以将atom条目文档发布到集合中。如果不存在app:accept元素，客户端应将其视为等同于内容为“application/atom+xml；type=entry”的app:accept元素。
If one app:accept element exists and is empty, clients SHOULD assume that the Collection does not support the creation of new Entries.
如果存在一个app:accept元素且为空，则客户端应假定集合不支持创建新条目。
appAccept =
element app:accept {
appCommonAttributes,
( text? )
}
appAccept =
element app:accept {
appCommonAttributes,
( text? )
}
The app:collection element MAY appear as a child of an atom:feed or atom:source element in an Atom Feed Document. Its content identifies a Collection by which new Entries can be added to appear in the feed. When it appears in an atom:feed or atom:source element, the app: collection element is considered foreign markup as defined in Section 6 of [RFC4287].
app:collection元素可能在atom提要文档中显示为atom:feed或atom:source元素的子元素。其内容标识一个集合，通过该集合可以添加新条目以显示在提要中。当它出现在atom:feed或atom:source元素中时，app:collection元素被认为是[RFC4287]第6节中定义的外来标记。
The "app:categories" element provides a list of the categories that can be applied to the members of a Collection. See Section 7.2.1 for the detailed definition of app:categories.
“app:categories”元素提供可应用于集合成员的类别列表。app:类别的详细定义见第7.2.1节。
The server MAY reject attempts to create or store members whose categories are not present in its categories list. A Collection that indicates the category set is open SHOULD NOT reject otherwise acceptable members whose categories are not in its categories list. The absence of an app:categories element means that the category handling of the Collection is unspecified. A "fixed" category list that contains zero categories indicates the Collection does not accept category data.
服务器可能拒绝创建或存储其类别列表中不存在的成员的尝试。指示类别集已打开的集合不应拒绝类别不在其类别列表中的其他可接受成员。缺少app:categories元素意味着集合的类别处理未指定。包含零个类别的“固定”类别列表表示集合不接受类别数据。
The Member URI allows clients to retrieve, edit, and delete a Member Resource using HTTP's GET, PUT, and DELETE methods. Entry Resources are represented as Atom Entry documents.
成员URI允许客户端使用HTTP的GET、PUT和delete方法检索、编辑和删除成员资源。条目资源表示为Atom条目文档。
Member URIs appear in two places. They are returned in a Location header after successful Resource creation using POST, as described in Section 9.2 below. They can also appear in a Collection Feed's Entries, as atom:link elements with a link relation of "edit".
成员URI出现在两个地方。如下文第9.2节所述，使用POST成功创建资源后，它们将返回到位置标头中。它们也可以出现在集合提要的条目中，作为链接关系为“edit”的atom:link元素。
A Member Entry SHOULD contain such an atom:link element with a link relation of "edit", which indicates the Member URI.
成员条目应该包含这样一个atom:link元素，该元素的链接关系为“edit”，表示成员URI。
To add members to a Collection, clients send POST requests to the URI of the Collection.
要向集合添加成员，客户端将POST请求发送到集合的URI。
Successful member creation is indicated with a 201 ("Created") response code. When the Collection responds with a status code of 201, it SHOULD also return a response body, which MUST be an Atom Entry Document representing the newly created Resource. Since the server is free to alter the POSTed Entry, for example, by changing the content of the atom:id element, returning the Entry can be useful to the client, enabling it to correlate the client and server views of the new Entry.
成功创建成员用201（“已创建”）响应代码表示。当集合以201的状态代码响应时，它还应该返回一个响应主体，该主体必须是表示新创建的资源的Atom条目文档。由于服务器可以自由地更改发布的条目，例如，通过更改atom:id元素的内容，因此返回条目对客户机很有用，使其能够关联新条目的客户机和服务器视图。
When a Member Resource is created, its Member Entry URI MUST be returned in a Location header in the Collection's response.
创建成员资源时，必须在集合响应的位置标头中返回其成员条目URI。
If the creation request contained an Atom Entry Document, and the subsequent response from the server contains a Content-Location header that matches the Location header character-for-character, then the client is authorized to interpret the response entity as being a complete representation of the newly created Entry. Without a matching Content-Location header, the client MUST NOT assume the returned entity is a complete representation of the created Resource.
如果创建请求包含一个Atom条目文档，并且来自服务器的后续响应包含一个与位置头字符对应的内容位置头，则客户机有权将响应实体解释为新创建条目的完整表示。如果没有匹配的Content Location标头，客户端不能假定返回的实体是所创建资源的完整表示。
The request body sent with the POST need not be an Atom Entry. For example, it might be a picture or a movie. Collections MAY return a response with a status code of 415 ("Unsupported Media Type") to indicate that the media type of the POSTed entity is not allowed or supported by the Collection. For a discussion of the issues in creating such content, see Section 9.6.
随POST一起发送的请求主体不必是Atom条目。例如，它可能是一张图片或一部电影。集合可以返回状态代码为415（“不支持的媒体类型”）的响应，以指示集合不允许或不支持发布实体的媒体类型。有关创建此类内容的问题的讨论，请参见第9.6节。
Below, the client sends a POST request containing an Atom Entry representation using the URI of the Collection:
下面，客户端使用集合的URI发送包含Atom条目表示的POST请求：
POST /edit/ HTTP/1.1
Host: example.org
User-Agent: Thingio/1.0
Authorization: Basic ZGFmZnk6c2VjZXJldA==
Content-Type: application/atom+xml;type=entry
Content-Length: nnn
Slug: First Post
POST /edit/ HTTP/1.1
Host: example.org
User-Agent: Thingio/1.0
Authorization: Basic ZGFmZnk6c2VjZXJldA==
Content-Type: application/atom+xml;type=entry
Content-Length: nnn
Slug: First Post
<?xml version="1.0"?>
<entry xmlns="http://www.w3.org/2005/Atom">
<title>Atom-Powered Robots Run Amok</title>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
<updated>2003-12-13T18:30:02Z</updated>
<author><name>John Doe</name></author>
<content>Some text.</content>
</entry>
<?xml version="1.0"?>
<entry xmlns="http://www.w3.org/2005/Atom">
<title>Atom-Powered Robots Run Amok</title>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
<updated>2003-12-13T18:30:02Z</updated>
<author><name>John Doe</name></author>
<content>Some text.</content>
</entry>
The server signals a successful creation with a status code of 201. The response includes a Location header indicating the Member Entry URI of the Atom Entry, and a representation of that Entry in the body of the response.
服务器发出状态代码为201的成功创建信号。响应包括一个位置头，指示Atom条目的成员条目URI，以及该条目在响应主体中的表示。
HTTP/1.1 201 Created
Date: Fri, 7 Oct 2005 17:17:11 GMT
Content-Length: nnn
Content-Type: application/atom+xml;type=entry;charset="utf-8"
Location: http://example.org/edit/first-post.atom
ETag: "c180de84f991g8"
HTTP/1.1 201 Created
Date: Fri, 7 Oct 2005 17:17:11 GMT
Content-Length: nnn
Content-Type: application/atom+xml;type=entry;charset="utf-8"
Location: http://example.org/edit/first-post.atom
ETag: "c180de84f991g8"
<?xml version="1.0"?>
<entry xmlns="http://www.w3.org/2005/Atom">
<title>Atom-Powered Robots Run Amok</title>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
<updated>2003-12-13T18:30:02Z</updated>
<author><name>John Doe</name></author>
<content>Some text.</content>
<link rel="edit"
href="http://example.org/edit/first-post.atom"/>
</entry>
<?xml version="1.0"?>
<entry xmlns="http://www.w3.org/2005/Atom">
<title>Atom-Powered Robots Run Amok</title>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
<updated>2003-12-13T18:30:02Z</updated>
<author><name>John Doe</name></author>
<content>Some text.</content>
<link rel="edit"
href="http://example.org/edit/first-post.atom"/>
</entry>
The Entry created and returned by the Collection might not match the Entry POSTed by the client. A server MAY change the values of various elements in the Entry, such as the atom:id, atom:updated, and atom:author values, and MAY choose to remove or add other elements and attributes, or change element content and attribute values.
集合创建和返回的条目可能与客户端发布的条目不匹配。服务器可以更改条目中各种元素的值，例如atom:id、atom:updated和atom:author值，并且可以选择删除或添加其他元素和属性，或者更改元素内容和属性值。
To edit a Member Resource, a client sends a PUT request to its Member URI, as specified in [RFC2616].
要编辑成员资源，客户机向其成员URI发送PUT请求，如[RFC2616]中所述。
To avoid unintentional loss of data when editing Member Entries or Media Link Entries, an Atom Protocol client SHOULD preserve all metadata that has not been intentionally modified, including unknown foreign markup as defined in Section 6 of [RFC4287].
为避免在编辑成员条目或媒体链接条目时意外丢失数据，Atom协议客户端应保留所有未被有意修改的元数据，包括[RFC4287]第6节中定义的未知外部标记。
To delete a Member Resource, a client sends a DELETE request to its Member URI, as specified in [RFC2616]. The deletion of a Media Link Entry SHOULD result in the deletion of the corresponding Media Resource.
要删除成员资源，客户端将向其成员URI发送删除请求，如[RFC2616]中所述。删除媒体链接条目应导致删除相应的媒体资源。
Implementers are advised to pay attention to cache controls and to make use of the mechanisms available in HTTP when editing Resources, in particular, entity-tags as outlined in [NOTE-detect-lost-update]. Clients are not assured to receive the most recent representations of Collection Members using GET if the server is authorizing intermediaries to cache them.
建议实施者注意缓存控制，并在编辑资源时使用HTTP中可用的机制，特别是[NOTE detect lost update]中概述的实体标记。如果服务器授权中介缓存集合成员，则无法确保客户端使用GET接收集合成员的最新表示。
Below, the client creates a Member Entry using POST:
在下面，客户端使用POST创建成员条目：
POST /myblog/entries HTTP/1.1
Host: example.org
Authorization: Basic ZGFmZnk6c2VjZXJldA==
Content-Type: application/atom+xml;type=entry
Content-Length: nnn
Slug: First Post
POST /myblog/entries HTTP/1.1
Host: example.org
Authorization: Basic ZGFmZnk6c2VjZXJldA==
Content-Type: application/atom+xml;type=entry
Content-Length: nnn
Slug: First Post
<?xml version="1.0" ?>
<entry xmlns="http://www.w3.org/2005/Atom">
<title>Atom-Powered Robots Run Amok</title>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
<updated>2007-02-123T17:09:02Z</updated>
<author><name>Captain Lansing</name></author>
<content>It's something moving... solid metal</content>
</entry>
<?xml version="1.0" ?>
<entry xmlns="http://www.w3.org/2005/Atom">
<title>Atom-Powered Robots Run Amok</title>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
<updated>2007-02-123T17:09:02Z</updated>
<author><name>Captain Lansing</name></author>
<content>It's something moving... solid metal</content>
</entry>
The server signals a successful creation with a status code of 201, and returns an ETag header in the response. Because, in this case, the server returned a Content-Location header and Location header with the same value, the returned Entry representation can be understood to be a complete representation of the newly created Entry (see Section 9.2).
服务器发出状态代码为201的成功创建信号，并在响应中返回ETag头。因为在这种情况下，服务器返回了具有相同值的内容位置头和位置头，所以返回的条目表示可以理解为新创建条目的完整表示（参见第9.2节）。
HTTP/1.1 201 Created
Date: Fri, 23 Feb 2007 21:17:11 GMT
Content-Length: nnn
Content-Type: application/atom+xml;type=entry
Location: http://example.org/edit/first-post.atom
Content-Location: http://example.org/edit/first-post.atom
ETag: "e180ee84f0671b1"
HTTP/1.1 201 Created
Date: Fri, 23 Feb 2007 21:17:11 GMT
Content-Length: nnn
Content-Type: application/atom+xml;type=entry
Location: http://example.org/edit/first-post.atom
Content-Location: http://example.org/edit/first-post.atom
ETag: "e180ee84f0671b1"
<?xml version="1.0" ?>
<entry xmlns="http://www.w3.org/2005/Atom">
<title>Atom-Powered Robots Run Amok</title>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
<updated>2007-02-123T17:09:02Z</updated>
<author><name>Captain Lansing</name></author>
<content>It's something moving... solid metal</content>
</entry>
<?xml version="1.0" ?>
<entry xmlns="http://www.w3.org/2005/Atom">
<title>Atom-Powered Robots Run Amok</title>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
<updated>2007-02-123T17:09:02Z</updated>
<author><name>Captain Lansing</name></author>
<content>It's something moving... solid metal</content>
</entry>
The client can, if it wishes, use the returned ETag value to later construct a "Conditional GET" as defined in [RFC2616]. In this case, prior to editing, the client sends the ETag value for the Member using the If-None-Match header.
如果愿意，客户机可以使用返回的ETag值来构建[RFC2616]中定义的“条件GET”。在这种情况下，在编辑之前，客户端使用If None匹配头发送成员的ETag值。
GET /edit/first-post.atom HTTP/1.1
Host: example.org
Authorization: Basic ZGFmZnk6c2VjZXJldA==
If-None-Match: "e180ee84f0671b1"
GET /edit/first-post.atom HTTP/1.1
Host: example.org
Authorization: Basic ZGFmZnk6c2VjZXJldA==
If-None-Match: "e180ee84f0671b1"
If the Entry has not been modified, the response will be a status code of 304 ("Not Modified"). This allows the client to determine whether it still has the most recent representation of the Entry at the time of editing.
如果条目未被修改，则响应的状态代码为304（“未修改”）。这允许客户端确定在编辑时是否仍然具有条目的最新表示形式。
HTTP/1.1 304 Not Modified
Date: Sat, 24 Feb 2007 13:17:11 GMT
HTTP/1.1 304 Not Modified
Date: Sat, 24 Feb 2007 13:17:11 GMT
After editing, the client can PUT the Entry and send the ETag entity value in an If-Match header, informing the server to accept the entry on the condition that the entity value sent still matches the server's.
编辑后，客户端可以将条目放入If-Match头中并发送ETag实体值，通知服务器在发送的实体值仍然与服务器的匹配的情况下接受条目。
PUT /edit/first-post.atom HTTP/1.1
Host: example.org
Authorization: Basic ZGFmZnk6c2VjZXJldA==
Content-Type: application/atom+xml;type=entry
Content-Length: nnn
If-Match: "e180ee84f0671b1"
PUT /edit/first-post.atom HTTP/1.1
Host: example.org
Authorization: Basic ZGFmZnk6c2VjZXJldA==
Content-Type: application/atom+xml;type=entry
Content-Length: nnn
If-Match: "e180ee84f0671b1"
<?xml version="1.0" ?>
<entry xmlns="http://www.w3.org/2005/Atom">
<title>Atom-Powered Robots Run Amok</title>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
<updated>2007-02-24T16:34:06Z</updated>
<author><name>Captain Lansing</name></author>
<content>Update: it's a hoax!</content>
</entry>
<?xml version="1.0" ?>
<entry xmlns="http://www.w3.org/2005/Atom">
<title>Atom-Powered Robots Run Amok</title>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
<updated>2007-02-24T16:34:06Z</updated>
<author><name>Captain Lansing</name></author>
<content>Update: it's a hoax!</content>
</entry>
The server however has since received a more recent copy than the client's, and it responds with a status code of 412 ("Precondition Failed").
但是，服务器收到的副本比客户端的副本更新，并且它的响应状态代码为412（“前置条件失败”）。
HTTP/1.1 412 Precondition Failed
Date: Sat, 24 Feb 2007 16:34:11 GMT
HTTP/1.1 412 Precondition Failed
Date: Sat, 24 Feb 2007 16:34:11 GMT
This informs the client that the server has a more recent version of the Entry and will not allow the sent entity to be stored.
这会通知客户机服务器具有更新版本的条目，并且不允许存储发送的实体。
A client can POST Media Resources as well as Entry Resources to a Collection. If a server accepts such a request, then it MUST create two new Resources -- one that corresponds to the entity sent in the request, called the Media Resource, and an associated Member Entry, called the Media Link Entry. Media Link Entries are represented as Atom Entries, and appear in the Collection.
客户端可以将媒体资源和条目资源发布到集合中。如果服务器接受这样的请求，那么它必须创建两个新资源——一个对应于请求中发送的实体的资源，称为媒体资源，另一个关联的成员条目，称为媒体链接条目。媒体链接条目表示为Atom条目，并显示在集合中。
The Media Link Entry contains the metadata and IRI of the (perhaps non-textual) Media Resource. The Media Link Entry thus makes the metadata about the Media Resource separately available for retrieval and alteration.
媒体链接条目包含（可能是非文本的）媒体资源的元数据和IRI。因此，媒体链接条目使得关于媒体资源的元数据可单独用于检索和更改。
The server can signal the media types it will accept using the app: accept element in the Service Document, as specified in Section 8.3.4.
按照第8.3.4节的规定，服务器可以使用服务文档中的app:accept元素向其接受的媒体类型发送信号。
Successful responses to creation requests MUST include the URI of the Media Link Entry in the Location header. The Media Link Entry SHOULD contain an atom:link element with a link relation of "edit-media" that contains the Media Resource IRI. The Media Link Entry MUST have an atom:content element with a "src" attribute. The value of the "src" attribute is an IRI for the newly created Media Resource. It is OPTIONAL that the IRI of the "src" attribute on the atom:content element be the same as the Media Resource IRI. For example, the "src" attribute value might instead be a link into a static cache or content distribution network and not the Media Resource IRI.
对创建请求的成功响应必须在位置标头中包含媒体链接项的URI。媒体链接条目应包含一个atom:Link元素，该元素的链接关系为“edit Media”，其中包含媒体资源IRI。媒体链接项必须具有具有“src”属性的atom:content元素。“src”属性的值是新创建的媒体资源的IRI。atom:content元素上“src”属性的IRI与媒体资源IRI相同是可选的。例如，“src”属性值可能是指向静态缓存或内容分发网络的链接，而不是媒体资源IRI。
Implementers are asked to note that [RFC4287] specifies that Atom Entries MUST contain an atom:summary element. Thus, upon successful creation of a Media Link Entry, a server MAY choose to populate the atom:summary element (as well as any other mandatory elements such as atom:id, atom:author, and atom:title) with content derived from the POSTed entity or from any other source. A server might not allow a client to modify the server-selected values for these elements.
要求实现者注意，[RFC4287]指定Atom条目必须包含Atom:summary元素。因此，在成功创建媒体链接条目后，服务器可以选择使用从发布的实体或任何其他源派生的内容填充atom:summary元素（以及任何其他必需元素，如atom:id、atom:author和atom:title）。服务器可能不允许客户端修改服务器为这些元素选择的值。
For Resource creation, this specification only defines cases where the POST body has an Atom Entry entity declared as an Atom media type ("application/atom+xml"), or a non-Atom entity declared as a non-Atom media type. When a client is POSTing an Atom Entry to a Collection, it may use a media type of either "application/atom+xml" or "application/atom +xml;type=entry". This specification does not specify any request semantics or server behavior in the case where the POSTed media type is "application/atom+xml" but the body is something other than an Atom Entry. In particular, what happens on POSTing an Atom Feed Document to a Collection using the "application/ atom+xml" media type is undefined.
对于资源创建，本规范仅定义了POST主体具有声明为Atom媒体类型的Atom条目实体（“应用程序/Atom+xml”）或声明为非Atom媒体类型的非Atom实体的情况。当客户端向集合发布Atom条目时，它可以使用“application/Atom+xml”或“application/Atom+xml；type=Entry”的媒体类型。如果发布的媒体类型为“application/atom+xml”，但正文不是atom条目，那么本规范不会指定任何请求语义或服务器行为。特别是，未定义使用“application/Atom+xml”媒体类型将Atom提要文档发布到集合时发生的情况。
The Atom Protocol does not specify a means to create multiple representations of the same Resource (for example, a PNG and a JPG of the same image) either on creation or editing.
Atom协议没有指定在创建或编辑时创建同一资源的多个表示（例如，同一图像的PNG和JPG）的方法。
Below, the client sends a POST request containing a PNG image to the URI of a Collection that accepts PNG images:
下面，客户端向接受PNG图像的集合的URI发送包含PNG图像的POST请求：
POST /edit/ HTTP/1.1
Host: media.example.org
Content-Type: image/png
Slug: The Beach
Authorization: Basic ZGFmZnk6c2VjZXJldA==
Content-Length: nnn
POST /edit/ HTTP/1.1
Host: media.example.org
Content-Type: image/png
Slug: The Beach
Authorization: Basic ZGFmZnk6c2VjZXJldA==
Content-Length: nnn
...binary data...
…二进制数据。。。
The server signals a successful creation with a status code of 201. The response includes a Location header indicating the Member URI of the Media Link Entry and a representation of that entry in the body of the response. The Media Link Entry includes a content element with a "src" attribute. It also contains a link with a link relation of "edit-media", specifying the IRI to be used for modifying the Media Resource.
服务器发出状态代码为201的成功创建信号。响应包括指示媒体链接条目的成员URI的位置报头以及响应主体中该条目的表示。媒体链接条目包括一个具有“src”属性的内容元素。它还包含一个链接，链接关系为“编辑媒体”，指定用于修改媒体资源的IRI。
HTTP/1.1 201 Created
Date: Fri, 7 Oct 2005 17:17:11 GMT
Content-Length: nnn
Content-Type: application/atom+xml;type=entry;charset="utf-8"
Location: http://example.org/media/edit/the_beach.atom
HTTP/1.1 201 Created
Date: Fri, 7 Oct 2005 17:17:11 GMT
Content-Length: nnn
Content-Type: application/atom+xml;type=entry;charset="utf-8"
Location: http://example.org/media/edit/the_beach.atom
<?xml version="1.0"?>
<entry xmlns="http://www.w3.org/2005/Atom">
<title>The Beach</title>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
<updated>2005-10-07T17:17:08Z</updated>
<author><name>Daffy</name></author>
<summary type="text" />
<content type="image/png"
src="http://media.example.org/the_beach.png"/>
<link rel="edit-media"
href="http://media.example.org/edit/the_beach.png" />
<link rel="edit"
href="http://example.org/media/edit/the_beach.atom" />
</entry>
<?xml version="1.0"?>
<entry xmlns="http://www.w3.org/2005/Atom">
<title>The Beach</title>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
<updated>2005-10-07T17:17:08Z</updated>
<author><name>Daffy</name></author>
<summary type="text" />
<content type="image/png"
src="http://media.example.org/the_beach.png"/>
<link rel="edit-media"
href="http://media.example.org/edit/the_beach.png" />
<link rel="edit"
href="http://example.org/media/edit/the_beach.atom" />
</entry>
Later, the client sends a PUT request containing the new PNG using the URI indicated in the Media Link Entry's "edit-media" link:
稍后，客户端使用媒体链接条目的“编辑媒体”链接中指示的URI发送包含新PNG的PUT请求：
PUT /edit/the_beach.png HTTP/1.1
Host: media.example.org
Content-Type: image/png
Authorization: Basic ZGFmZnk6c2VjZXJldA==
Content-Length: nnn
PUT /edit/the_beach.png HTTP/1.1
Host: media.example.org
Content-Type: image/png
Authorization: Basic ZGFmZnk6c2VjZXJldA==
Content-Length: nnn
...binary data...
…二进制数据。。。
The server signals a successful edit with a status code of 200.
服务器发出状态代码为200的成功编辑信号。
HTTP/1.1 200 Ok
Date: Fri, 8 Oct 2006 17:17:11 GMT
HTTP/1.1 200 Ok
Date: Fri, 8 Oct 2006 17:17:11 GMT
The client can edit the metadata for the picture. First GET the Media Link Entry:
客户端可以编辑图片的元数据。首先获取媒体链接条目：
GET /media/edit/the_beach.atom HTTP/1.1
Host: example.org
Authorization: Basic ZGFmZnk6c2VjZXJldA==
GET /media/edit/the_beach.atom HTTP/1.1
Host: example.org
Authorization: Basic ZGFmZnk6c2VjZXJldA==
The Media Link Entry is returned.
将返回媒体链接条目。
HTTP/1.1 200 Ok
Date: Fri, 7 Oct 2005 17:18:11 GMT
Content-Length: nnn
Content-Type: application/atom+xml;type=entry;charset="utf-8"
ETag: "c181bb840673b5"
HTTP/1.1 200 Ok
Date: Fri, 7 Oct 2005 17:18:11 GMT
Content-Length: nnn
Content-Type: application/atom+xml;type=entry;charset="utf-8"
ETag: "c181bb840673b5"
<?xml version="1.0"?>
<entry xmlns="http://www.w3.org/2005/Atom">
<title>The Beach</title>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
<updated>2005-10-07T17:17:08Z</updated>
<author><name>Daffy</name></author>
<summary type="text" />
<content type="image/png"
src="http://media.example.org/the_beach.png"/>
<link rel="edit-media"
href="http://media.example.org/edit/the_beach.png" />
<link rel="edit"
href="http://example.org/media/edit/the_beach.atom" />
</entry>
<?xml version="1.0"?>
<entry xmlns="http://www.w3.org/2005/Atom">
<title>The Beach</title>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
<updated>2005-10-07T17:17:08Z</updated>
<author><name>Daffy</name></author>
<summary type="text" />
<content type="image/png"
src="http://media.example.org/the_beach.png"/>
<link rel="edit-media"
href="http://media.example.org/edit/the_beach.png" />
<link rel="edit"
href="http://example.org/media/edit/the_beach.atom" />
</entry>
The metadata can be updated, in this case to add a summary, and then PUT back to the server.
可以更新元数据，在本例中添加摘要，然后将其放回服务器。
PUT /media/edit/the_beach.atom HTTP/1.1
Host: example.org
Authorization: Basic ZGFmZnk6c2VjZXJldA==
Content-Type: application/atom+xml;type=entry
Content-Length: nnn
If-Match: "c181bb840673b5"
PUT /media/edit/the_beach.atom HTTP/1.1
Host: example.org
Authorization: Basic ZGFmZnk6c2VjZXJldA==
Content-Type: application/atom+xml;type=entry
Content-Length: nnn
If-Match: "c181bb840673b5"
<?xml version="1.0"?>
<entry xmlns="http://www.w3.org/2005/Atom">
<title>The Beach</title>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
<updated>2005-10-07T17:17:08Z</updated>
<author><name>Daffy</name></author>
<summary type="text">
A nice sunset picture over the water.
</summary>
<content type="image/png"
src="http://media.example.org/the_beach.png"/>
<link rel="edit-media"
href="http://media.example.org/edit/the_beach.png" />
<link rel="edit"
href="http://example.org/media/edit/the_beach.atom" />
</entry>
<?xml version="1.0"?>
<entry xmlns="http://www.w3.org/2005/Atom">
<title>The Beach</title>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
<updated>2005-10-07T17:17:08Z</updated>
<author><name>Daffy</name></author>
<summary type="text">
A nice sunset picture over the water.
</summary>
<content type="image/png"
src="http://media.example.org/the_beach.png"/>
<link rel="edit-media"
href="http://media.example.org/edit/the_beach.png" />
<link rel="edit"
href="http://example.org/media/edit/the_beach.atom" />
</entry>
The update was successful.
更新成功。
HTTP/1.1 200 Ok
Date: Fri, 7 Oct 2005 17:19:11 GMT
Content-Length: 0
HTTP/1.1 200 Ok
Date: Fri, 7 Oct 2005 17:19:11 GMT
Content-Length: 0
Multiple Media Resources can be added to the Collection.
可以将多个媒体资源添加到集合中。
POST /edit/ HTTP/1.1
Host: media.example.org
Content-Type: image/png
Slug: The Pier
Authorization: Basic ZGFmZnk6c2VjZXJldA==
Content-Length: nnn
POST /edit/ HTTP/1.1
Host: media.example.org
Content-Type: image/png
Slug: The Pier
Authorization: Basic ZGFmZnk6c2VjZXJldA==
Content-Length: nnn
...binary data...
…二进制数据。。。
The Resource is created successfully.
资源已成功创建。
HTTP/1.1 201 Created
Date: Fri, 7 Oct 2005 17:17:11 GMT
Content-Length: nnn
Content-Type: application/atom+xml;type=entry;charset="utf-8"
Location: http://example.org/media/edit/the_pier.atom
HTTP/1.1 201 Created
Date: Fri, 7 Oct 2005 17:17:11 GMT
Content-Length: nnn
Content-Type: application/atom+xml;type=entry;charset="utf-8"
Location: http://example.org/media/edit/the_pier.atom
<?xml version="1.0"?>
<entry xmlns="http://www.w3.org/2005/Atom">
<title>The Pier</title>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efe6b</id>
<updated>2005-10-07T17:26:43Z</updated>
<author><name>Daffy</name></author>
<summary type="text" />
<content type="image/png"
src="http://media.example.org/the_pier.png"/>
<link rel="edit-media"
href="http://media.example.org/edit/the_pier.png" />
<link rel="edit"
href="http://example.org/media/edit/the_pier.atom" />
</entry>
<?xml version="1.0"?>
<entry xmlns="http://www.w3.org/2005/Atom">
<title>The Pier</title>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efe6b</id>
<updated>2005-10-07T17:26:43Z</updated>
<author><name>Daffy</name></author>
<summary type="text" />
<content type="image/png"
src="http://media.example.org/the_pier.png"/>
<link rel="edit-media"
href="http://media.example.org/edit/the_pier.png" />
<link rel="edit"
href="http://example.org/media/edit/the_pier.atom" />
</entry>
The client can now create a new Atom Entry in the blog Entry Collection that references the two newly created Media Resources.
客户机现在可以在博客条目集合中创建一个新的Atom条目，该条目引用两个新创建的媒体资源。
POST /blog/ HTTP/1.1
Host: example.org
Content-Type: application/atom+xml;type=entry
Slug: A day at the beach
Authorization: Basic ZGFmZnk6c2VjZXJldA==
Content-Length: nnn
POST /blog/ HTTP/1.1
Host: example.org
Content-Type: application/atom+xml;type=entry
Slug: A day at the beach
Authorization: Basic ZGFmZnk6c2VjZXJldA==
Content-Length: nnn
<?xml version="1.0"?>
<entry xmlns="http://www.w3.org/2005/Atom">
<title>A fun day at the beach</title>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6b</id>
<updated>2005-10-07T17:40:02Z</updated>
<author><name>Daffy</name></author>
<content type="xhtml">
<xhtml:div xmlns:xhtml="http://www.w3.org/1999/xhtml">
<xhtml:p>We had a good day at the beach.
<xhtml:img alt="the beach"
src="http://media.example.org/the_beach.png"/>
</xhtml:p>
<xhtml:p>Later we walked down to the pier.
<xhtml:img alt="the pier"
src="http://media.example.org/the_pier.png"/>
</xhtml:p>
</xhtml:div>
</content>
</entry>
<?xml version="1.0"?>
<entry xmlns="http://www.w3.org/2005/Atom">
<title>A fun day at the beach</title>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6b</id>
<updated>2005-10-07T17:40:02Z</updated>
<author><name>Daffy</name></author>
<content type="xhtml">
<xhtml:div xmlns:xhtml="http://www.w3.org/1999/xhtml">
<xhtml:p>We had a good day at the beach.
<xhtml:img alt="the beach"
src="http://media.example.org/the_beach.png"/>
</xhtml:p>
<xhtml:p>Later we walked down to the pier.
<xhtml:img alt="the pier"
src="http://media.example.org/the_pier.png"/>
</xhtml:p>
</xhtml:div>
</content>
</entry>
The Resource is created successfully.
资源已成功创建。
HTTP/1.1 200 Ok
Date: Fri, 7 Oct 2005 17:20:11 GMT
Content-Length: nnn
Content-Type: application/atom+xml;type=entry;charset="utf-8"
Location: http://example.org/blog/atom/a-day-at-the-beach.atom
HTTP/1.1 200 Ok
Date: Fri, 7 Oct 2005 17:20:11 GMT
Content-Length: nnn
Content-Type: application/atom+xml;type=entry;charset="utf-8"
Location: http://example.org/blog/atom/a-day-at-the-beach.atom
<?xml version="1.0"?>
<entry xmlns="http://www.w3.org/2005/Atom">
<title>A fun day at the beach</title>
<id>http://example.org/blog/a-day-at-the-beach.xhtml</id>
<updated>2005-10-07T17:43:07Z</updated>
<author><name>Daffy</name></author>
<content type="xhtml">
<xhtml:div xmlns:xhtml="http://www.w3.org/1999/xhtml">
<xhtml:p>We had a good day at the beach.
<xhtml:img alt="the beach"
src="http://media.example.org/the_beach.png"/>
</xhtml:p>
<xhtml:p>Later we walked down to the pier.
<xhtml:img alt="the pier"
src="http://media.example.org/the_pier.png"/>
</xhtml:p>
</xhtml:div>
</content>
<link rel="edit"
href="http://example.org/blog/edit/a-day-at-the-beach.atom"/>
<link rel="alternate" type="text/html"
href="http://example.org/blog/a-day-at-the-beach.html"/>
</entry>
<?xml version="1.0"?>
<entry xmlns="http://www.w3.org/2005/Atom">
<title>A fun day at the beach</title>
<id>http://example.org/blog/a-day-at-the-beach.xhtml</id>
<updated>2005-10-07T17:43:07Z</updated>
<author><name>Daffy</name></author>
<content type="xhtml">
<xhtml:div xmlns:xhtml="http://www.w3.org/1999/xhtml">
<xhtml:p>We had a good day at the beach.
<xhtml:img alt="the beach"
src="http://media.example.org/the_beach.png"/>
</xhtml:p>
<xhtml:p>Later we walked down to the pier.
<xhtml:img alt="the pier"
src="http://media.example.org/the_pier.png"/>
</xhtml:p>
</xhtml:div>
</content>
<link rel="edit"
href="http://example.org/blog/edit/a-day-at-the-beach.atom"/>
<link rel="alternate" type="text/html"
href="http://example.org/blog/a-day-at-the-beach.html"/>
</entry>
Note that the returned Entry contains a link with a relation of "alternate" that points to the associated HTML page that was created -- this is not required by this specification, but is included to show the kinds of changes a server can make to an Entry.
请注意，返回的条目包含一个带有“alternate”关系的链接，该链接指向所创建的关联HTML页面——这不是本规范所要求的，但包含该链接是为了显示服务器可以对条目进行的更改类型。
Slug is an HTTP entity-header whose presence in a POST to a Collection constitutes a request by the client to use the header's value as part of any URIs that would normally be used to retrieve the to-be-created Entry or Media Resources.
Slug是一个HTTP实体头，其在集合的POST中的存在构成了客户端请求将头的值用作任何URI的一部分，该URI通常用于检索要创建的条目或媒体资源。
Servers MAY use the value of the Slug header when creating the Member URI of the newly created Resource, for instance, by using some or all of the words in the value for the last URI segment. Servers MAY also use the value when creating the atom:id, or as the title of a Media Link Entry (see Section 9.6).
服务器可以在创建新创建的资源的成员URI时使用Slug头的值，例如，通过使用最后一个URI段的值中的部分或全部字。服务器也可以在创建atom:id时使用该值，或将其用作媒体链接条目的标题（请参见第9.6节）。
Servers MAY choose to ignore the Slug entity-header. Servers MAY alter the header value before using it. For instance, a server might filter out some characters or replace accented letters with non-accented ones, replace spaces with underscores, change case, and so on.
服务器可以选择忽略Slug实体头。服务器可能会在使用前更改标头值。例如，服务器可能会过滤掉一些字符，或者用非重音字母替换重音字母，用下划线替换空格，更改大小写，等等。
The syntax of the Slug header is defined using the augmented BNF syntax defined in Section 2.1 of [RFC2616]:
Slug头的语法使用[RFC2616]第2.1节中定义的扩充BNF语法定义：
LWS = <defined in Section 2.2 of [RFC2616]>
slugtext = %x20-7E | LWS
Slug = "Slug" ":" *slugtext
LWS = <defined in Section 2.2 of [RFC2616]>
slugtext = %x20-7E | LWS
Slug = "Slug" ":" *slugtext
The field value is the percent-encoded value of the UTF-8 encoding of the character sequence to be included (see Section 2.1 of [RFC3986] for the definition of percent encoding, and [RFC3629] for the definition of the UTF-8 encoding).
字段值是要包括的字符序列的UTF-8编码的百分比编码值（百分比编码的定义见[RFC3986]第2.1节，UTF-8编码的定义见[RFC3629]）。
Implementation note: to produce the field value from a character sequence, first encode it using the UTF-8 encoding, then encode all octets outside the ranges %20-24 and %26-7E using percent encoding (%25 is the ASCII encoding of "%", thus it needs to be escaped). To consume the field value, first reverse the percent encoding, then run the resulting octet sequence through a UTF-8 decoding process.
实施说明：要从字符序列生成字段值，首先使用UTF-8编码对其进行编码，然后使用百分比编码对范围%20-24和%26-7E之外的所有八位字节进行编码（%25是“%”的ASCII编码，因此需要转义）。要使用字段值，首先反转百分比编码，然后通过UTF-8解码过程运行生成的八位字节序列。
Here is an example of the Slug header that uses percent-encoding to represent the Unicode character U+00E8 (LATIN SMALL LETTER E WITH GRAVE):
以下是使用百分比编码表示Unicode字符U+00E8（带GRAVE的拉丁文小写字母E）的Slug标头示例：
POST /myblog/entries HTTP/1.1
Host: example.org
Content-Type: image/png
Slug: The Beach at S%C3%A8te
Authorization: Basic ZGFmZnk6c2VjZXJldA==
Content-Length: nnn
POST /myblog/entries HTTP/1.1
Host: example.org
Content-Type: image/png
Slug: The Beach at S%C3%A8te
Authorization: Basic ZGFmZnk6c2VjZXJldA==
Content-Length: nnn
...binary data...
…二进制数据。。。
See Section 9.2.1 for an example of the Slug header applied to the creation of an Entry Resource.
参见第9.2.1节，了解用于创建入口资源的Slug头的示例。
Collection Resources MUST provide representations in the form of Atom Feed Documents whose Entries contain the IRIs of the Members in the Collection. No distinction is made between Collection Feeds and other kinds of Feeds -- a Feed might act both as a 'public' feed for subscription purposes and as a Collection Feed.
集合资源必须以Atom提要文档的形式提供表示，其条目包含集合中成员的IRI。集合提要和其他类型的提要之间没有区别——提要可以作为订阅目的的“公共”提要，也可以作为集合提要。
Each Entry in the Feed Document SHOULD have an atom:link element with a relation of "edit" (see Section 11.1).
提要文档中的每个条目都应该有一个atom:link元素，该元素具有“编辑”关系（参见第11.1节）。
The Entries in the returned Atom Feed SHOULD be ordered by their "app:edited" property, with the most recently edited Entries coming first in the document order. The app:edited value is not equivalent to the HTTP Last-Modified header and cannot be used to determine the freshness of cached responses.
返回的Atom提要中的条目应按其“app:edited”属性排序，最新编辑的条目排在文档顺序的第一位。app:edited值与HTTP Last Modified标头不等效，不能用于确定缓存响应的新鲜度。
Clients MUST NOT assume that an Atom Entry returned in the Feed is a full representation of an Entry Resource and SHOULD perform a GET on the URI of the Member Entry before editing it. See Section 9.5 for a discussion on the implications of cache control directives when obtaining entries.
客户机不能假设提要中返回的Atom条目是条目资源的完整表示，在编辑它之前，应该对成员条目的URI执行GET。有关获取条目时缓存控制指令含义的讨论，请参见第9.5节。
Collections can contain large numbers of Resources. A client such as a web spider or web browser might be overwhelmed if the response to a GET contained every Entry in a Collection -- in turn the server might also waste bandwidth and processing time on generating a response that cannot be handled. For this reason, servers MAY respond to Collection GET requests with a Feed Document containing a partial list of the Collection's members, and a link to the next partial list feed, if it exists. The first such partial list returned MUST contain the most recently edited member Resources and MUST have an atom:link with a "next" relation whose "href" value is the URI of the next partial list of the Collection. This next partial list will contain the next most recently edited set of Member Resources (and an atom:link to the following partial list if it exists).
集合可以包含大量的资源。如果对GET的响应包含在集合中的每个条目中，则web spider或web浏览器之类的客户端可能会不知所措——反过来，服务器也可能会在生成无法处理的响应时浪费带宽和处理时间。因此，服务器可能会使用包含集合成员部分列表的提要文档以及指向下一部分列表提要（如果存在）的链接来响应集合GET请求。返回的第一个这样的部分列表必须包含最近编辑的成员资源，并且必须有一个atom:link和一个“next”关系，其“href”值是集合的下一个部分列表的URI。下一个部分列表将包含下一个最近编辑的成员资源集（以及一个atom:链接到以下部分列表，如果它存在的话）。
In addition to the "next" relation, partial list feeds MAY contain link elements with "rel" attribute values of "previous", "first", and "last", that can be used to navigate through the complete set of entries in the Collection.
除了“下一个”关系外，部分列表提要还可能包含具有“previous”、“first”和“last”属性值的“rel”链接元素，这些元素可用于在集合中的完整条目集中导航。
For instance, suppose a client is supplied the URI "http://example.org/entries/go" of a Collection of Member Entries, where the server as a matter of policy avoids generating Feed Documents containing more than 10 Entries. The Atom Feed Document
例如，假设为客户机提供了URI“http://example.org/entries/go成员项集合，其中服务器根据策略避免生成包含10个以上项的提要文档。Atom提要文档
for the Collection will then represent the first partial list of a set of 10 linked Feed Documents. The "first" relation references the initial Feed Document in the set and the "last" relation references the final Feed Document in the set. Within each document, the "previous" and "next" link relations reference the preceding and subsequent documents.
因为集合将表示一组10个链接提要文档的第一部分列表。“first”关系引用集合中的初始提要文档，“last”关系引用集合中的最终提要文档。在每个文档中，“上一个”和“下一个”链接关系引用了前面和后面的文档。
<feed xmlns="http://www.w3.org/2005/Atom">
<link rel="first"
href="http://example.org/entries/go" />
<link rel="next"
href="http://example.org/entries/2" />
<link rel="last"
href="http://example.org/entries/10" />
...
</feed>
<feed xmlns="http://www.w3.org/2005/Atom">
<link rel="first"
href="http://example.org/entries/go" />
<link rel="next"
href="http://example.org/entries/2" />
<link rel="last"
href="http://example.org/entries/10" />
...
</feed>
The "previous" and "next" link elements for the partial list feed located at "http://example.org/entries/2" would look like this:
部分列表提要的“上一个”和“下一个”链接元素位于“http://example.org/entries/2“看起来是这样的：
<feed xmlns="http://www.w3.org/2005/Atom">
<link rel="first"
href="http://example.org/entries/go" />
<link rel="previous"
href="http://example.org/entries/go" />
<link rel="next"
href="http://example.org/entries/3" />
<link rel="last"
href="http://example.org/entries/10" />
...
</feed>
<feed xmlns="http://www.w3.org/2005/Atom">
<link rel="first"
href="http://example.org/entries/go" />
<link rel="previous"
href="http://example.org/entries/go" />
<link rel="next"
href="http://example.org/entries/3" />
<link rel="last"
href="http://example.org/entries/10" />
...
</feed>
The "app:edited" element is a Date construct (as defined by [RFC4287]), whose content indicates the last time an Entry was edited. If the entry has not been edited yet, the content indicates the time it was created. Atom Entry elements in Collection Documents SHOULD contain one app:edited element, and MUST NOT contain more than one.
“app:edited”元素是一个日期构造（由[RFC4287]定义），其内容表示上一次编辑条目的时间。如果条目尚未编辑，则内容将指示其创建的时间。集合文档中的Atom条目元素应包含一个app:edited元素，且不能包含多个。
appEdited = element app:edited ( atomDateConstruct )
appEdited=元素应用程序：已编辑（atomDateConstruct）
The server SHOULD change the value of this element every time an Entry Resource or an associated Media Resource has been edited.
每次编辑条目资源或关联的媒体资源时，服务器都应更改此元素的值。
This specification adds the value "edit" to the Atom Registry of Link Relations (see Section 7.1 of [RFC4287]). The value of "edit" specifies that the value of the href attribute is the IRI of an editable Member Entry. When appearing within an atom:entry, the href IRI can be used to retrieve, update, and delete the Resource represented by that Entry. An atom:entry MUST NOT contain more than one "edit" link relation.
本规范将值“edit”添加到链接关系的Atom注册表中（参见[RFC4287]第7.1节）。“编辑”的值指定href属性的值是可编辑成员条目的IRI。当出现在atom:条目中时，href IRI可用于检索、更新和删除该条目表示的资源。atom:条目不能包含多个“编辑”链接关系。
This specification adds the value "edit-media" to the Atom Registry of Link Relations (see Section 7.1 of [RFC4287]). When appearing within an atom:entry, the value of the href attribute is an IRI that can be used to modify a Media Resource associated with that Entry.
本规范将值“编辑媒体”添加到链接关系的Atom注册表中（参见[RFC4287]第7.1节）。当出现在atom:entry中时，href属性的值是一个IRI，可用于修改与该条目关联的媒体资源。
An atom:entry element MAY contain zero or more "edit-media" link relations. An atom:entry MUST NOT contain more than one atom:link element with a "rel" attribute value of "edit-media" that has the same "type" and "hreflang" attribute values. All "edit-media" link relations in the same Entry reference the same Resource. If a client encounters multiple "edit-media" link relations in an Entry then it SHOULD choose a link based on the client preferences for "type" and "hreflang". If a client encounters multiple "edit-media" link relations in an Entry and has no preference based on the "type" and "hreflang" attributes then the client SHOULD pick the first "edit-media" link relation in document order.
atom:entry元素可能包含零个或多个“编辑媒体”链接关系。atom:entry不能包含多个atom:link元素，该元素的“rel”属性值为“edit media”，具有相同的“type”和“hreflang”属性值。同一条目的所有“编辑媒体”链接关系都引用同一资源。如果客户机在条目中遇到多个“编辑媒体”链接关系，则应根据客户机对“类型”和“hreflang”的首选项选择链接。如果客户机在条目中遇到多个“编辑媒体”链接关系，并且没有基于“类型”和“hreflang”属性的首选项，则客户机应选择文档顺序中的第一个“编辑媒体”链接关系。
The Atom Syndication Format [RFC4287] defines the "application/ atom+xml" media type to identify both Atom Feed and Atom Entry Documents. Implementation experience has demonstrated that Atom Feed and Entry Documents can have different processing models and that there are situations where they need to be differentiated. This specification defines a "type" parameter used to differentiate the two types of Atom documents.
Atom联合格式[RFC4287]定义了“应用程序/Atom+xml”媒体类型，以标识Atom提要和Atom条目文档。实施经验表明，Atom提要和条目文档可以有不同的处理模型，并且在某些情况下需要区分它们。本规范定义了一个“type”参数，用于区分两种类型的Atom文档。
This specification defines a new "type" parameter for use with the "application/atom+xml" media type. The "type" parameter has a value of "entry" or "feed".
本规范定义了一个新的“type”参数，用于“application/atom+xml”媒体类型。“type”参数的值为“entry”或“feed”。
Neither the parameter name nor its value are case sensitive.
参数名称及其值都不区分大小写。
The value "entry" indicates that the media type identifies an Atom Entry Document. The root element of the document MUST be atom:entry.
值“entry”表示媒体类型标识Atom条目文档。文档的根元素必须是atom:entry。
The value "feed" indicates that the media type identifies an Atom Feed Document. The root element of the document MUST be atom:feed.
值“feed”表示媒体类型标识Atom提要文档。文档的根元素必须是atom:feed。
If not specified, the type is assumed to be unspecified, requiring Atom processors to examine the root element to determine the type of Atom document.
如果未指定，则假定该类型未指定，要求Atom处理器检查根元素以确定Atom文档的类型。
New specifications MAY require that the "type" parameter be used to identify the Atom Document type. Producers of Atom Entry Documents SHOULD use the "type" parameter regardless of whether or not it is mandatory. Producers of Atom Feed Documents MAY use the parameter.
新规范可能要求使用“type”参数来标识Atom文档类型。Atom条目文档的生产者应该使用“type”参数，不管它是否是强制性的。Atom提要文档的生产者可以使用该参数。
Atom processors that do not recognize the "type" parameter MUST ignore its value and examine the root element to determine the document type.
不识别“type”参数的Atom处理器必须忽略其值并检查根元素以确定文档类型。
Atom processors that do recognize the "type" parameter SHOULD detect and report inconsistencies between the parameter's value and the actual type of the document's root element.
识别“type”参数的Atom处理器应该检测并报告参数值与文档根元素的实际类型之间的不一致。
This specification defines an Atom Format Structured Extension, as defined in Section 6 of [RFC4287], for publishing control within the "http://www.w3.org/2007/app" namespace.
本规范定义了一个Atom格式结构化扩展，如[RFC4287]第6节所定义，用于在http://www.w3.org/2007/app“名称空间。
namespace app = "http://www.w3.org/2007/app"
namespace app = "http://www.w3.org/2007/app"
pubControl =
element app:control {
atomCommonAttributes,
pubDraft?
& extensionElement
}
pubControl =
element app:control {
atomCommonAttributes,
pubDraft?
& extensionElement
}
pubDraft =
element app:draft { "yes" | "no" }
pubDraft =
element app:draft { "yes" | "no" }
The "app:control" element MAY appear as a child of an atom:entry that is being created or updated via the Atom Publishing Protocol. The app:control element MUST appear only once in an Entry. The app: control element is considered foreign markup as defined in Section 6 of [RFC4287].
“app:control”元素可能显示为通过atom发布协议创建或更新的atom:entry的子元素。app:control元素在条目中只能出现一次。app:control元素被视为[RFC4287]第6节中定义的外来标记。
The app:control element and its child elements MAY be included in Atom Feed or Entry Documents.
app:control元素及其子元素可能包含在Atom提要或条目文档中。
The app:control element can contain an "app:draft" element as defined below, and it can contain extension elements as defined in Section 6 of [RFC4287].
app:control元素可以包含如下定义的“app:draft”元素，也可以包含[RFC4287]第6节中定义的扩展元素。
The inclusion of the "app:draft" element represents a request by the client to control the visibility of a Member Resource. The app:draft element MAY be ignored by the server.
包含“app:draft”元素表示客户端请求控制成员资源的可见性。服务器可能会忽略app:draft元素。
The number of app:draft elements in app:control MUST be zero or one. The content of an app:draft element MUST be one of "yes" or "no". If the element contains "no", this indicates a client request that the Member Resource be made publicly visible. If the app:draft element is not present, then servers that support the extension MUST behave as though an app:draft element containing "no" was sent.
app:control中的app:draft元素数必须为零或一。app:draft元素的内容必须是“是”或“否”之一。如果元素包含“否”，则表示客户端请求使成员资源公开可见。如果app:draft元素不存在，则支持该扩展的服务器必须表现为发送了包含“no”的app:draft元素。
The Atom Publishing Protocol is based on HTTP. Authentication requirements for HTTP are covered in Section 11 of [RFC2616].
Atom发布协议基于HTTP。[RFC2616]第11节介绍了HTTP的认证要求。
The use of authentication mechanisms to prevent POSTing or editing by unknown or unauthorized clients is RECOMMENDED but not required. When authentication is not used, clients and servers are vulnerable to trivial spoofing, denial-of-service, and defacement attacks. However, in some contexts, this is an acceptable risk.
建议使用身份验证机制来防止未知或未经授权的客户端发布或编辑，但不是必需的。不使用身份验证时，客户端和服务器容易受到普通欺骗、拒绝服务和破坏攻击。然而，在某些情况下，这是一种可接受的风险。
The type of authentication deployed is a local decision made by the server operator. Clients are likely to face authentication schemes that vary across server deployments. At a minimum, client and server implementations MUST be capable of being configured to use HTTP Basic Authentication [RFC2617] in conjunction with a connection made with TLS 1.0 [RFC2246] or a subsequent standards-track version of TLS (such as [RFC4346]), supporting the conventions for using HTTP over TLS described in [RFC2818].
部署的身份验证类型是由服务器操作员做出的本地决定。客户端可能面临不同服务器部署的身份验证方案。至少，客户机和服务器实现必须能够配置为结合TLS 1.0[RFC2246]或TLS后续标准跟踪版本（如[RFC4346]）的连接使用HTTP基本身份验证[RFC2617]，支持[RFC2818]中描述的通过TLS使用HTTP的约定。
The choice of authentication mechanism will impact interoperability. The minimum level of security referenced above (Basic Authentication with TLS) is considered good practice for Internet applications at the time of publication of this specification and sufficient for establishing a baseline for interoperability. Implementers are encouraged to investigate and use alternative mechanisms regarded as equivalently good or better at the time of deployment. It is RECOMMENDED that clients be implemented in such a way that new authentication schemes can be deployed.
身份验证机制的选择将影响互操作性。在本规范发布时，上述最低安全级别（TLS基本认证）被视为互联网应用的良好实践，足以建立互操作性基线。鼓励实施者调查并使用在部署时被认为相当好或更好的替代机制。建议以可以部署新身份验证方案的方式实现客户端。
Because this protocol uses HTTP response status codes as the primary means of reporting the result of a request, servers are advised to respond to unauthorized or unauthenticated requests using an appropriate 4xx HTTP response code (e.g., 401 "Unauthorized" or 403 "Forbidden") in accordance with [RFC2617].
由于该协议使用HTTP响应状态代码作为报告请求结果的主要手段，因此建议服务器根据[RFC2617]使用适当的4xx HTTP响应代码（例如401“未授权”或403“禁止”）响应未经授权或未经验证的请求。
The Atom Publishing Protocol is based on HTTP and thus subject to the security considerations found in Section 15 of [RFC2616].
Atom发布协议基于HTTP，因此需要遵守[RFC2616]第15节中的安全注意事项。
The threats listed in this section apply to many protocols that run under HTTP. The Atompub Working Group decided that the protection afforded by running authenticated HTTP under TLS (as described in Section 14) was sufficient to mitigate many of the problems presented by the attacks listed in this section.
本节列出的威胁适用于在HTTP下运行的许多协议。Atompub工作组认为，在TLS下运行经过身份验证的HTTP（如第14节所述）所提供的保护足以缓解本节所列攻击带来的许多问题。
Atom Publishing Protocol server implementations need to take adequate precautions to ensure malicious clients cannot consume excessive server resources (CPU, memory, disk, etc.).
Atom发布协议服务器实现需要采取足够的预防措施，以确保恶意客户端不会消耗过多的服务器资源（CPU、内存、磁盘等）。
Atom Publishing Protocol server implementations are susceptible to replay attacks. Specifically, this specification does not define a means of detecting duplicate requests. Accidentally sent duplicate requests are indistinguishable from intentional and malicious replay attacks.
Atom发布协议服务器实现容易受到重播攻击。具体而言，本规范未定义检测重复请求的方法。意外发送的重复请求与故意和恶意重播攻击无法区分。
Atom Publishing Protocol implementations are susceptible to a variety of spoofing attacks. Malicious clients might send Atom Entries containing inaccurate information anywhere in the document.
Atom发布协议实现容易受到各种欺骗攻击。恶意客户端可能会将包含不准确信息的Atom条目发送到文档中的任何位置。
Atom Feed and Entry Documents can contain XML External Entities as defined in Section 4.2.2 of [REC-xml]. Atom implementations are not required to load external entities. External entities are subject to the same security concerns as any network operation and can alter the semantics of an Atom document. The same issues exist for Resources linked to by Atom elements such as atom:link and atom:content.
Atom提要和条目文档可以包含[REC XML]第4.2.2节中定义的XML外部实体。加载外部实体不需要Atom实现。外部实体受到与任何网络操作相同的安全问题的影响，并且可以改变Atom文档的语义。对于由Atom元素链接到的资源，如Atom:link和Atom:content，也存在同样的问题。
Atom Entry and Feed Documents can contain XML Digital Signatures [REC-xmldsig-core] and can be encrypted using XML Encryption [REC-xmlenc-core] as specified in Section 5 of [RFC4287]. Handling of signatures and encrypted elements in Atom documents is discussed in Sections 5 and 6.3 of [RFC4287].
Atom条目和提要文档可以包含XML数字签名[REC xmldsig core]，并且可以使用[RFC4287]第5节中指定的XML加密[REC xmlenc core]进行加密。[RFC4287]第5节和第6.3节讨论了Atom文档中签名和加密元素的处理。
Neither servers nor clients are under any obligation to support encryption and digital signature of Entries or Feeds, although it is certainly possible that in some installations, clients or servers might require signing or encrypting of the documents exchanged in the Atom Protocol.
服务器和客户端都没有义务支持条目或提要的加密和数字签名，尽管在某些安装中，客户端或服务器可能需要对在Atom协议中交换的文档进行签名或加密。
Because servers are allowed (and in some cases, expected) to modify the contents of an Entry Document before publishing it, signatures within an entry are only likely to be useful to the server to which the entry is being sent. Clients cannot assume that the signature will be valid when viewed by a third party, or even that the server will publish the client's signature.
由于允许服务器（在某些情况下，预期服务器）在发布条目文档之前修改其内容，因此条目中的签名只可能对将条目发送到的服务器有用。客户端无法假定签名在第三方查看时有效，甚至服务器也无法发布客户端的签名。
A server is allowed to strip client-applied signatures, to strip client-applied signatures and then re-sign with its own public key, and to oversign an entry with its own public key. The meaning to a third party of a signature applied by a server is the same as a signature from anyone, as described in [RFC4287]. It is RECOMMENDED that a server that is aware that it has changed any part of an Entry Document that was signed by the client should strip that signature before publishing the entry in order to prevent third parties from trying to interpret a signature that cannot be validated.
允许服务器剥离客户端应用的签名，剥离客户端应用的签名，然后使用自己的公钥重新签名，并使用自己的公钥对条目进行过度签名。服务器应用的签名对第三方的意义与任何人的签名相同，如[RFC4287]所述。建议意识到已更改客户端签名的条目文档的任何部分的服务器在发布条目之前删除该签名，以防止第三方尝试解释无法验证的签名。
Atom Publishing Protocol implementations handle URIs and IRIs. See Section 7 of [RFC3986] and Section 8 of [RFC3987] for security considerations related to their handling and use.
Atom发布协议实现处理URI和IRI。有关其处理和使用的安全注意事项，请参见[RFC3986]第7节和[RFC3987]第8节。
The Atom Publishing Protocol leaves the server in control of minting URIs. The use of any client-supplied data for creating new URIs is subject to the same concerns as described in the next section.
Atom发布协议让服务器控制生成URI。使用任何客户端提供的数据来创建新的URI都会受到与下一节所述相同的关注。
Atom Feed and Entry Documents can contain a broad range of content types including code that might be executable in some contexts. Malicious clients could attempt to attack servers or other clients by injecting code into a Collection Document's Entry or Media Resources.
Atom提要和条目文档可以包含广泛的内容类型，包括在某些上下文中可以执行的代码。恶意客户端可以通过向集合文档的条目或媒体资源中注入代码来尝试攻击服务器或其他客户端。
Server implementations are strongly encouraged to verify that client-supplied content is safe prior to accepting, processing, or publishing it. In the case of HTML, experience indicates that verification based on a white list of acceptable content is more effective than a black list of forbidden content.
强烈建议服务器实现在接受、处理或发布客户端提供的内容之前验证其安全性。就HTML而言，经验表明，基于可接受内容白名单的验证比基于禁止内容黑名单的验证更有效。
Additional information about XHTML and HTML content safety can be found in Section 8.1 of [RFC4287].
有关XHTML和HTML内容安全的更多信息，请参见[RFC4287]的第8.1节。
This specification uses two new media types that conform to the registry mechanism described in [RFC4288], a new message header that conforms to the registry mechanism described in [RFC3864], and two new link relations that conform to the registry mechanism described in [RFC4287].
本规范使用符合[RFC4288]中所述注册表机制的两种新媒体类型、符合[RFC3864]中所述注册表机制的新消息头以及符合[RFC4287]中所述注册表机制的两种新链接关系。
An Atom Publishing Protocol Category Document, when serialized as XML 1.0, can be identified with the following media type:
Atom发布协议类别文档序列化为XML 1.0时，可以使用以下媒体类型标识：
MIME media type name: application
MIME媒体类型名称：应用程序
MIME subtype name: atomcat+xml
MIME子类型名称：atomcat+xml
Required parameters: None.
所需参数：无。
Optional parameters:
可选参数：
"charset": This parameter has identical semantics to the charset parameter of the "application/xml" media type as specified in [RFC3023].
“charset”：此参数与[RFC3023]中指定的“application/xml”媒体类型的charset参数具有相同的语义。
Encoding considerations: Identical to those of "application/xml" as described in [RFC3023], Section 3.2.
编码注意事项：与[RFC3023]第3.2节中描述的“应用程序/xml”相同。
Security considerations: As defined in RFC 5023.
安全注意事项：如RFC 5023中所定义。
In addition, as this media type uses the "+xml" convention, it shares the same security considerations as described in [RFC3023], Section 10.
此外，由于该媒体类型使用“+xml”约定，因此它具有与[RFC3023]第10节所述相同的安全注意事项。
Interoperability considerations: There are no known interoperability issues.
互操作性注意事项：不存在已知的互操作性问题。
Published specification: RFC 5023.
已发布规范：RFC 5023。
Applications that use this media type: No known applications currently use this media type.
使用此媒体类型的应用程序：目前没有已知的应用程序使用此媒体类型。
Additional information:
其他信息：
Magic number(s): As specified for "application/xml" in [RFC3023], Section 3.2.
幻数：如[RFC3023]第3.2节中“应用程序/xml”所述。
File extension: .atomcat
文件扩展名：.atomcat
Fragment identifiers: As specified for "application/xml" in [RFC3023], Section 5.
片段标识符：如[RFC3023]第5节中“应用程序/xml”所述。
Base URI: As specified in [RFC3023], Section 6.
基本URI：如[RFC3023]第6节所述。
Macintosh file type code: TEXT
Macintosh文件类型代码：文本
Person & email address to contact for further information:
Joe Gregorio <joe@bitworking.org>
Person & email address to contact for further information:
Joe Gregorio <joe@bitworking.org>
Intended usage: COMMON
预期用途：普通
Author/Change controller: IETF (iesg@ietf.org) Internet Engineering Task Force
作者/变更控制员：IETF(iesg@ietf.org)互联网工程专责小组
An Atom Publishing Protocol Service Document, when serialized as XML 1.0, can be identified with the following media type:
Atom发布协议服务文档序列化为XML 1.0时，可以使用以下媒体类型标识：
MIME media type name: application
MIME媒体类型名称：应用程序
MIME subtype name: atomsvc+xml
MIME子类型名称：atomsvc+xml
Required parameters: None.
所需参数：无。
Optional parameters:
可选参数：
"charset": This parameter has identical semantics to the charset parameter of the "application/xml" media type as specified in [RFC3023].
“charset”：此参数与[RFC3023]中指定的“application/xml”媒体类型的charset参数具有相同的语义。
Encoding considerations: Identical to those of "application/xml" as described in [RFC3023], Section 3.2.
编码注意事项：与[RFC3023]第3.2节中描述的“应用程序/xml”相同。
Security considerations: As defined in RFC 5023.
安全注意事项：如RFC 5023中所定义。
In addition, as this media type uses the "+xml" convention, it shares the same security considerations as described in [RFC3023], Section 10.
此外，由于该媒体类型使用“+xml”约定，因此它具有与[RFC3023]第10节所述相同的安全注意事项。
Interoperability considerations: There are no known interoperability issues.
互操作性注意事项：不存在已知的互操作性问题。
Published specification: RFC 5023.
已发布规范：RFC 5023。
Applications that use this media type: No known applications currently use this media type.
使用此媒体类型的应用程序：目前没有已知的应用程序使用此媒体类型。
Additional information:
其他信息：
Magic number(s): As specified for "application/xml" in [RFC3023], Section 3.2.
幻数：如[RFC3023]第3.2节中“应用程序/xml”所述。
File extension: .atomsvc
文件扩展名：.atomsvc
Fragment identifiers: As specified for "application/xml" in [RFC3023], Section 5.
片段标识符：如[RFC3023]第5节中“应用程序/xml”所述。
Base URI: As specified in [RFC3023], Section 6.
基本URI：如[RFC3023]第6节所述。
Macintosh file type code: TEXT
Macintosh文件类型代码：文本
Person and email address to contact for further information: Joe
Gregorio <joe@bitworking.org>
Person and email address to contact for further information: Joe
Gregorio <joe@bitworking.org>
Intended usage: COMMON
预期用途：普通
Author/Change controller: IETF (iesg@ietf.org) Internet Engineering Task Force
作者/变更控制员：IETF(iesg@ietf.org)互联网工程专责小组
Header field name: SLUG
标题字段名称：SLUG
Applicable protocol: http [RFC2616]
适用协议：http[RFC2616]
Status: standard.
状态：标准。
Author/Change controller: IETF (iesg@ietf.org) Internet Engineering Task Force
作者/变更控制员：IETF(iesg@ietf.org)互联网工程专责小组
Specification document(s): RFC 5023.
规范文件：RFC 5023。
Related information: None.
相关信息：无。
Attribute Value: edit
属性值：编辑
Description: An IRI of an editable Member Entry. When appearing within an atom:entry, the href IRI can be used to retrieve, update, and delete the Resource represented by that Entry.
描述：可编辑成员条目的IRI。当出现在atom:条目中时，href IRI可用于检索、更新和删除该条目表示的资源。
Expected display characteristics: Undefined; this relation can be used for background processing or to provide extended functionality without displaying its value.
预期显示特性：未定义；此关系可用于后台处理或提供扩展功能，而不显示其值。
Security considerations: Automated agents should take care when this relation crosses administrative domains (e.g., the URI has a different authority than the current document).
安全注意事项：当此关系跨越管理域时（例如，URI具有与当前文档不同的权限），自动化代理应小心。
Attribute Value: edit-media
属性值：编辑媒体
Description: An IRI of an editable Media Resource. When appearing within an atom:entry, the href IRI can be used to retrieve, update, and delete the Media Resource associated with that Entry.
描述：可编辑媒体资源的IRI。当出现在atom:条目中时，href IRI可用于检索、更新和删除与该条目关联的媒体资源。
Expected display characteristics: Undefined; this relation can be used for background processing or to provide extended functionality without displaying its value.
预期显示特性：未定义；此关系可用于后台处理或提供扩展功能，而不显示其值。
Security considerations: Automated agents should take care when this relation crosses administrative domains (e.g., the URI has a different authority than the current document).
安全注意事项：当此关系跨越管理域时（例如，URI具有与当前文档不同的权限），自动化代理应小心。
IANA has added a reference to this specification in the 'application/atom+xml' media type registration.
IANA在“应用程序/atom+xml”媒体类型注册中添加了对该规范的引用。
[REC-xml] Yergeau, F., Paoli, J., Bray, T., Sperberg-McQueen, C., and E. Maler, "Extensible Markup Language (XML) 1.0 (Fourth Edition)", World Wide Web Consortium Recommendation REC-xml-20060816, August 2006, <http://www.w3.org/TR/2006/REC-xml-20060816>.
[REC xml]Yergeau，F.，Paoli，J.，Bray，T.，Sperberg McQueen，C.，和E.Maler，“可扩展标记语言（xml）1.0（第四版）”，万维网联盟建议REC-xml-20060816，2006年8月<http://www.w3.org/TR/2006/REC-xml-20060816>.
[REC-xml-infoset] Cowan, J. and R. Tobin, "XML Information Set (Second Edition)", World Wide Web Consortium Recommendation REC-xml-infoset-20040204, February 2004, <http://www.w3.org/TR/2004/REC-xml-infoset-20040204>.
[REC xml infoset]Cowan，J.和R.Tobin，“xml信息集（第二版）”，万维网联盟建议REC-xml-infoset-200402042004年2月<http://www.w3.org/TR/2004/REC-xml-infoset-20040204>.
[REC-xml-names] Hollander, D., Bray, T., Tobin, R., and A. Layman, "Namespaces in XML 1.0 (Second Edition)", World Wide Web Consortium Recommendation REC-xml-names-20060816, August 2006, <http://www.w3.org/TR/2006/REC-xml-names-20060816>.
[REC xml名称]Hollander，D.，Bray，T.，Tobin，R.，和A.Layman，“xml 1.0中的名称空间（第二版）”，万维网联盟建议REC-xml-names-20060816，2006年8月<http://www.w3.org/TR/2006/REC-xml-names-20060816>.
[REC-xmlbase] Marsh, J., "XML Base", W3C REC W3C.REC-xmlbase-20010627, June 2001, <http://www.w3.org/TR/2001/REC-xmlbase-20010627>.
[REC xmlbase]Marsh，J.，“XML库”，W3C REC W3C.REC-xmlbase-20010627，2001年6月<http://www.w3.org/TR/2001/REC-xmlbase-20010627>.
[REC-xmldsig-core] Solo, D., Reagle, J., and D. Eastlake, "XML-Signature Syntax and Processing", World Wide Web Consortium Recommendation REC-xmldsig-core-20020212, February 2002, <http://www.w3.org/TR/2002/REC-xmldsig-core-20020212>.
[REC xmldsig-core]Solo，D.，Reagle，J.，和D.Eastlake，“XML签名语法和处理”，万维网联盟建议REC-xmldsig-core-20020212，2002年2月<http://www.w3.org/TR/2002/REC-xmldsig-core-20020212>.
[REC-xmlenc-core] Eastlake, D. and J. Reagle, "XML Encryption Syntax and Processing", World Wide Web Consortium Recommendation REC-xmlenc-core-20021210, December 2002, <http://www.w3.org/TR/2002/REC-xmlenc-core-20021210>.
[REC xmlenc core]Eastlake，D.和J.Reagle，“XML加密语法和处理”，万维网联盟建议REC-xmlenc-core-20021210，2002年12月<http://www.w3.org/TR/2002/REC-xmlenc-core-20021210>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC2246，1999年1月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[RFC2617]Franks，J.，Hallam Baker，P.，Hostetler，J.，Lawrence，S.，Leach，P.，Lootonen，A.，和L.Stewart，“HTTP认证：基本和摘要访问认证”，RFC 26171999年6月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC2818，2000年5月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023]Murata，M.，St.Laurent，S.，和D.Kohn，“XML媒体类型”，RFC 3023，2001年1月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[RFC3864]Klyne，G.，Nottingham，M.和J.Mogul，“消息头字段的注册程序”，BCP 90，RFC 3864，2004年9月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[RFC3987]Duerst，M.和M.Suignard，“国际化资源标识符（IRIs）”，RFC 3987，2005年1月。
[RFC4287] Nottingham, M. and R. Sayre, "The Atom Syndication Format", RFC 4287, December 2005.
[RFC4287]诺丁汉，M.和R.Sayre，“原子联合格式”，RFC 4287，2005年12月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288]Freed，N.和J.Klensin，“介质类型规范和注册程序”，BCP 13，RFC 4288，2005年12月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
[NOTE-detect-lost-update] Nielsen, H. and D. LaLiberte, "Editing the Web: Detecting the Lost Update Problem Using Unreserved Checkout", World Wide Web Consortium NOTE NOTE-detect-lost-update, May 1999, <http://www.w3.org/1999/04/Editing/>.
[注：检测丢失的更新]Nielsen，H.和D.LaLiberte，“编辑网络：使用无保留签出检测丢失的更新问题”，万维网联盟注：检测丢失的更新，1999年5月<http://www.w3.org/1999/04/Editing/>.
[REC-webarch] Walsh, N. and I. Jacobs, "Architecture of the World Wide Web, Volume One", W3C REC REC-webarch-20041215, December 2004, <http://www.w3.org/TR/2004/REC-webarch-20041215>.
[REC webarch]Walsh，N.和I.Jacobs，“万维网的体系结构，第一卷”，W3C REC-webarch-20041215，2004年12月<http://www.w3.org/TR/2004/REC-webarch-20041215>.
[RNC] Clark, J., "RELAX NG Compact Syntax", December 2001, <http://www.oasis-open.org/committees/relax-ng/ compact-20021121.html>.
[RNC]Clark，J.，“RELAXNG紧凑语法”，2001年12月<http://www.oasis-open.org/committees/relax-ng/ compact-20021121.html>。
The content and concepts within are a product of the Atom community and the Atompub Working Group.
其中的内容和概念是Atom社区和Atompub工作组的产物。
This appendix is informative.
本附录为资料性附录。
The Relax NG schema explicitly excludes elements in the Atom Protocol namespace that are not defined in this revision of the specification. Requirements for Atom Protocol processors encountering such markup are given in Sections 6.2 and 6.3 of [RFC4287].
RELAXNG模式明确排除了本规范修订版中未定义的Atom协议命名空间中的元素。[RFC4287]第6.2节和第6.3节给出了遇到此类标记的Atom协议处理器的要求。
The Schema for Service Documents:
服务文档的架构：
# -*- rnc -*- # RELAX NG Compact Syntax Grammar for the Atom Protocol
# -*- rnc -*- # RELAX NG Compact Syntax Grammar for the Atom Protocol
namespace app = "http://www.w3.org/2007/app"
namespace atom = "http://www.w3.org/2005/Atom"
namespace xsd = "http://www.w3.org/2001/XMLSchema"
namespace xhtml = "http://www.w3.org/1999/xhtml"
namespace local = ""
namespace app = "http://www.w3.org/2007/app"
namespace atom = "http://www.w3.org/2005/Atom"
namespace xsd = "http://www.w3.org/2001/XMLSchema"
namespace xhtml = "http://www.w3.org/1999/xhtml"
namespace local = ""
start = appService
start = appService
# common:attrs
#通用：ATTR
atomURI = text
atomURI = text
appCommonAttributes =
attribute xml:base { atomURI }?,
attribute xml:lang { atomLanguageTag }?,
attribute xml:space {"default"|"preserved"}?,
undefinedAttribute*
appCommonAttributes =
attribute xml:base { atomURI }?,
attribute xml:lang { atomLanguageTag }?,
attribute xml:space {"default"|"preserved"}?,
undefinedAttribute*
atomCommonAttributes = appCommonAttributes
atomCommonAttributes = appCommonAttributes
undefinedAttribute = attribute * - (xml:base | xml:space | xml:lang
| local:*) { text }
undefinedAttribute = attribute * - (xml:base | xml:space | xml:lang
| local:*) { text }
atomLanguageTag = xsd:string {
pattern = "([A-Za-z]{1,8}(-[A-Za-z0-9]{1,8})*)?"
}
atomLanguageTag = xsd:string {
pattern = "([A-Za-z]{1,8}(-[A-Za-z0-9]{1,8})*)?"
}
atomDateConstruct = appCommonAttributes, xsd:dateTime
atomDateConstruct=appCommonAttributes，xsd:dateTime
# app:service
appService =
element app:service {
appCommonAttributes,
( appWorkspace+
& extensionElement* )
}
# app:service
appService =
element app:service {
appCommonAttributes,
( appWorkspace+
& extensionElement* )
}
# app:workspace
#应用程序：工作区
appWorkspace =
element app:workspace {
appCommonAttributes,
( atomTitle
& appCollection*
& extensionSansTitleElement* )
}
appWorkspace =
element app:workspace {
appCommonAttributes,
( atomTitle
& appCollection*
& extensionSansTitleElement* )
}
atomTitle = element atom:title { atomTextConstruct }
atomTitle = element atom:title { atomTextConstruct }
# app:collection
#应用程序：收集
appCollection =
element app:collection {
appCommonAttributes,
attribute href { atomURI },
( atomTitle
& appAccept*
& appCategories*
& extensionSansTitleElement* )
}
appCollection =
element app:collection {
appCommonAttributes,
attribute href { atomURI },
( atomTitle
& appAccept*
& appCategories*
& extensionSansTitleElement* )
}
# app:categories
#应用程序：类别
atomCategory =
element atom:category {
atomCommonAttributes,
attribute term { text },
attribute scheme { atomURI }?,
attribute label { text }?,
undefinedContent
}
atomCategory =
element atom:category {
atomCommonAttributes,
attribute term { text },
attribute scheme { atomURI }?,
attribute label { text }?,
undefinedContent
}
appInlineCategories =
element app:categories {
attribute fixed { "yes" | "no" }?,
attribute scheme { atomURI }?,
(atomCategory*,
undefinedContent)
}
appInlineCategories =
element app:categories {
attribute fixed { "yes" | "no" }?,
attribute scheme { atomURI }?,
(atomCategory*,
undefinedContent)
}
appOutOfLineCategories =
element app:categories {
attribute href { atomURI },
undefinedContent
}
appOutOfLineCategories =
element app:categories {
attribute href { atomURI },
undefinedContent
}
appCategories = appInlineCategories | appOutOfLineCategories
appCategories=appInlineCategories | AppOutofInCategories
# app:accept
#应用程序：接受
appAccept =
element app:accept {
appCommonAttributes,
( text? )
}
appAccept =
element app:accept {
appCommonAttributes,
( text? )
}
# Simple Extension
#简单扩展
simpleSansTitleExtensionElement =
element * - (app:*|atom:title) {
text
}
simpleSansTitleExtensionElement =
element * - (app:*|atom:title) {
text
}
simpleExtensionElement =
element * - (app:*) {
text
}
simpleExtensionElement =
element * - (app:*) {
text
}
# Structured Extension
#结构化扩展
structuredSansTitleExtensionElement =
element * - (app:*|atom:title) {
(attribute * { text }+,
(text|anyElement)*)
| (attribute * { text }*,
(text?, anyElement+, (text|anyElement)*))
}
structuredSansTitleExtensionElement =
element * - (app:*|atom:title) {
(attribute * { text }+,
(text|anyElement)*)
| (attribute * { text }*,
(text?, anyElement+, (text|anyElement)*))
}
structuredExtensionElement =
element * - (app:*) {
(attribute * { text }+,
(text|anyElement)*)
| (attribute * { text }*,
(text?, anyElement+, (text|anyElement)*))
}
structuredExtensionElement =
element * - (app:*) {
(attribute * { text }+,
(text|anyElement)*)
| (attribute * { text }*,
(text?, anyElement+, (text|anyElement)*))
}
# Other Extensibility
#其他扩展性
extensionSansTitleElement =
simpleSansTitleExtensionElement|structuredSansTitleExtensionElement
extensionSansTitleElement =
simpleSansTitleExtensionElement|structuredSansTitleExtensionElement
extensionElement = simpleExtensionElement | structuredExtensionElement
extensionElement=simpleExtensionElement | StructureXtensionElement
undefinedContent = (text|anyForeignElement)*
undefinedContent = (text|anyForeignElement)*
# Extensions
#扩展
anyElement =
element * {
(attribute * { text }
| text
| anyElement)*
}
anyElement =
element * {
(attribute * { text }
| text
| anyElement)*
}
anyForeignElement =
element * - app:* {
(attribute * { text }
| text
| anyElement)*
}
anyForeignElement =
element * - app:* {
(attribute * { text }
| text
| anyElement)*
}
atomPlainTextConstruct =
atomCommonAttributes,
attribute type { "text" | "html" }?,
text
atomPlainTextConstruct =
atomCommonAttributes,
attribute type { "text" | "html" }?,
text
atomXHTMLTextConstruct = atomCommonAttributes, attribute type { "xhtml" }, xhtmlDiv
atomXHTMLTextConstruct=atomCommonAttributes，属性类型{“xhtml”}，xhtmlDiv
atomTextConstruct = atomPlainTextConstruct | atomXHTMLTextConstruct
atomTextConstruct=atomPlainTextConstruct | atomXHTMLTextConstruct
anyXHTML = element xhtml:* {
(attribute * { text }
| text
| anyXHTML)*
}
anyXHTML = element xhtml:* {
(attribute * { text }
| text
| anyXHTML)*
}
xhtmlDiv = element xhtml:div {
(attribute * { text }
| text
| anyXHTML)*
}
xhtmlDiv = element xhtml:div {
(attribute * { text }
| text
| anyXHTML)*
}
# EOF
#EOF
The Schema for Category Documents:
类别文档的架构：
# -*- rnc -*- # RELAX NG Compact Syntax Grammar for the Atom Protocol
# -*- rnc -*- # RELAX NG Compact Syntax Grammar for the Atom Protocol
namespace app = "http://www.w3.org/2007/app"
namespace atom = "http://www.w3.org/2005/Atom"
namespace xsd = "http://www.w3.org/2001/XMLSchema"
namespace local = ""
namespace app = "http://www.w3.org/2007/app"
namespace atom = "http://www.w3.org/2005/Atom"
namespace xsd = "http://www.w3.org/2001/XMLSchema"
namespace local = ""
start = appCategories
start = appCategories
atomCommonAttributes =
attribute xml:base { atomURI }?,
attribute xml:lang { atomLanguageTag }?,
undefinedAttribute*
atomCommonAttributes =
attribute xml:base { atomURI }?,
attribute xml:lang { atomLanguageTag }?,
undefinedAttribute*
undefinedAttribute = attribute * - (xml:base | xml:lang | local:*) {
text }
undefinedAttribute = attribute * - (xml:base | xml:lang | local:*) {
text }
atomURI = text
atomURI = text
atomLanguageTag = xsd:string {
pattern = "([A-Za-z]{1,8}(-[A-Za-z0-9]{1,8})*)?"
}
atomLanguageTag = xsd:string {
pattern = "([A-Za-z]{1,8}(-[A-Za-z0-9]{1,8})*)?"
}
atomCategory =
element atom:category {
atomCommonAttributes,
attribute term { text },
attribute scheme { atomURI }?,
attribute label { text }?,
undefinedContent
}
atomCategory =
element atom:category {
atomCommonAttributes,
attribute term { text },
attribute scheme { atomURI }?,
attribute label { text }?,
undefinedContent
}
appInlineCategories =
element app:categories {
attribute fixed { "yes" | "no" }?,
attribute scheme { atomURI }?,
(atomCategory*,
undefinedContent)
}
appInlineCategories =
element app:categories {
attribute fixed { "yes" | "no" }?,
attribute scheme { atomURI }?,
(atomCategory*,
undefinedContent)
}
appOutOfLineCategories =
element app:categories {
attribute href { atomURI },
(empty)
}
appOutOfLineCategories =
element app:categories {
attribute href { atomURI },
(empty)
}
appCategories = appInlineCategories | appOutOfLineCategories
appCategories=appInlineCategories | AppOutofInCategories
# Extensibility
#扩展性
undefinedContent = (text|anyForeignElement)*
undefinedContent = (text|anyForeignElement)*
anyElement =
element * {
(attribute * { text }
| text
| anyElement)*
}
anyElement =
element * {
(attribute * { text }
| text
| anyElement)*
}
anyForeignElement =
element * - atom:* {
(attribute * { text }
| text
| anyElement)*
}
anyForeignElement =
element * - atom:* {
(attribute * { text }
| text
| anyElement)*
}
# EOF
#EOF
Authors' Addresses
作者地址
Joe Gregorio (editor) Google
乔·格雷戈里奥（编辑）谷歌
EMail: joe@bitworking.org
URI: http://bitworking.org/
EMail: joe@bitworking.org
URI: http://bitworking.org/
Bill de hOra (editor) NewBay Software
比尔·德霍拉（编辑）纽贝软件
EMail: bill@dehora.net
URI: http://dehora.net/
EMail: bill@dehora.net
URI: http://dehora.net/
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
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的IETF-ipr@ietf.org.