draft-ietf-atompub-protocol-04.txt		draft-ietf-atompub-protocol-05.txt
	Network Working Group J. Gregorio, Ed.		Network Working Group J. Gregorio, Ed.
	Internet-Draft BitWorking, Inc		Internet-Draft BitWorking, Inc
	Expires: November 10, 2005 R. Sayre, Ed.		Expires: April 14, 2006 B. de hOra, Ed.
	May 9, 2005		Propylon Ltd.
			October 11, 2005
	The Atom Publishing Protocol		The Atom Publishing Protocol
	draft-ietf-atompub-protocol-04.txt		draft-ietf-atompub-protocol-05.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 34		skipping to change at page 1, line 35
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on November 10, 2005.		This Internet-Draft will expire on April 14, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2005).
	Abstract		Abstract
	This memo presents a protocol for using XML (Extensible Markup		This memo presents a protocol for using XML (Extensible Markup
	Language) and HTTP (HyperText Transport Protocol) to edit content.		Language) and HTTP (HyperText Transport Protocol) to edit content.
	The Atom Publishing Protocol is an application-level protocol for		The Atom Publishing Protocol (APP) is an application-level protocol
	publishing and editing Web resources belonging to periodically		for publishing and editing Web resources. The protocol at its core
	updated websites. The protocol at its core is the HTTP transport of		is the HTTP transport of Atom-formatted representations. The Atom
	Atom-formatted representations. The Atom format is documented in the		format is documented in the Atom Syndication Format
	Atom Syndication Format (draft-ietf-atompub-format-06.txt).		(draft-ietf-atompub-format-11.txt).
	Editorial Note		Editorial Note
	To provide feedback on this Internet-Draft, join the atom-protocol		To provide feedback on this Internet-Draft, join the atom-protocol
	mailing list (http://www.imc.org/atom-protocol/index.html) [1].		mailing list (http://www.imc.org/atom-protocol/index.html) [1].
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 4		2. XML Namespace and Language . . . . . . . . . . . . . . . . . 5
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Notational Conventions . . . . . . . . . . . . . . . . . . . 6
	4. The Atom Publishing Protocol Model . . . . . . . . . . . . . . 6		4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 7
	4.1 Collections . . . . . . . . . . . . . . . . . . . . . . . 6		5. The Atom Publishing Protocol Model . . . . . . . . . . . . . 8
	4.2 Discovery . . . . . . . . . . . . . . . . . . . . . . . . 6		5.1 Collections . . . . . . . . . . . . . . . . . . . . . . . 8
	4.3 Listing . . . . . . . . . . . . . . . . . . . . . . . . . 7		5.2 Editable Resources . . . . . . . . . . . . . . . . . . . . 9
	4.4 Authoring . . . . . . . . . . . . . . . . . . . . . . . . 7		5.2.1 Read . . . . . . . . . . . . . . . . . . . . . . . . . 10
	4.4.1 Create . . . . . . . . . . . . . . . . . . . . . . . . 7		5.2.2 Update . . . . . . . . . . . . . . . . . . . . . . . . 10
	4.4.2 Read . . . . . . . . . . . . . . . . . . . . . . . . . 8		5.2.3 Delete . . . . . . . . . . . . . . . . . . . . . . . . 10
	4.4.3 Update . . . . . . . . . . . . . . . . . . . . . . . . 8		5.3 Capabilities Discovery . . . . . . . . . . . . . . . . . . 11
	4.4.4 Delete . . . . . . . . . . . . . . . . . . . . . . . . 8		5.4 Listing . . . . . . . . . . . . . . . . . . . . . . . . . 11
	4.5 Success and Failure . . . . . . . . . . . . . . . . . . . 9		5.5 Success and Failure . . . . . . . . . . . . . . . . . . . 12
	5. Collections . . . . . . . . . . . . . . . . . . . . . . . . . 10		6. Atom Publishing Protocol Documents . . . . . . . . . . . . . 13
	5.1 Collection Documents . . . . . . . . . . . . . . . . . . . 10		6.1 Use of xml:base xml:lang . . . . . . . . . . . . . . . . . 13
	5.1.1 Element Definitions . . . . . . . . . . . . . . . . . 10		6.2 Collection Documents . . . . . . . . . . . . . . . . . . . 14
	5.2 Collection Resource . . . . . . . . . . . . . . . . . . . 12		6.2.1 Element Definitions . . . . . . . . . . . . . . . . . 14
	5.2.2 POST . . . . . . . . . . . . . . . . . . . . . . . . . 14		6.3 Introspection Documents . . . . . . . . . . . . . . . . . 16
	5.2.3 Usage Scenarios . . . . . . . . . . . . . . . . . . . 15		6.3.1 Element Definitions . . . . . . . . . . . . . . . . . 17
	5.2.4 Range: Header . . . . . . . . . . . . . . . . . . . . 16		7. Introspection Resource . . . . . . . . . . . . . . . . . . . 20
	5.2.5 Accept-Ranges: Header . . . . . . . . . . . . . . . . 16		7.1 Discovery . . . . . . . . . . . . . . . . . . . . . . . . 20
	5.2.6 Name: Header . . . . . . . . . . . . . . . . . . . . . 17		8. Collection Resources . . . . . . . . . . . . . . . . . . . . 21
	6. Entry Collection . . . . . . . . . . . . . . . . . . . . . . . 18		8.1 GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	6.1 Editing Entry Resources . . . . . . . . . . . . . . . . . 18		8.2 POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	6.2 Role of Atom Entry Elements During Editing . . . . . . . . 18		8.3 Title: Header . . . . . . . . . . . . . . . . . . . . . . 22
	7. Generic Collection . . . . . . . . . . . . . . . . . . . . . . 20		9. Entry Collections . . . . . . . . . . . . . . . . . . . . . 23
	7.1 Editing Generic Resources . . . . . . . . . . . . . . . . 20		9.1 Editing Entry Resources . . . . . . . . . . . . . . . . . 23
	8. Introspection . . . . . . . . . . . . . . . . . . . . . . . . 21		9.2 Role of Atom Entry Elements During Editing . . . . . . . . 23
	8.1 Introspection Document . . . . . . . . . . . . . . . . . . 21		10. Generic Collections . . . . . . . . . . . . . . . . . . . . 25
	8.1.1 Element Definitions . . . . . . . . . . . . . . . . . 21		10.1 Editing Generic Resources . . . . . . . . . . . . . . . 25
	8.2 Introspection Resource . . . . . . . . . . . . . . . . . . 23		10.2 Title: Header . . . . . . . . . . . . . . . . . . . . . 25
	8.2.1 Discovery . . . . . . . . . . . . . . . . . . . . . . 24		11. List Resources . . . . . . . . . . . . . . . . . . . . . . . 26
	9. Securing the Atom Protocol . . . . . . . . . . . . . . . . . . 25		11.1 URI Templates . . . . . . . . . . . . . . . . . . . . . 26
	10. Security Considerations . . . . . . . . . . . . . . . . . . 26		11.2 URI Template Parameters . . . . . . . . . . . . . . . . 27
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 27		11.2.1 \{index\} URI template variable . . . . . . . . . . 27
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30		11.2.2 \{daterange\} URI template variable . . . . . . . . 27
	12.1 Normative References . . . . . . . . . . . . . . . . . . . 30		11.2.3 Other URI Template parameters . . . . . . . . . . . 28
	12.2 Informative References . . . . . . . . . . . . . . . . . . 31		12. Atom Entry Extensions . . . . . . . . . . . . . . . . . . . 29
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 32		13. Securing the Atom Protocol . . . . . . . . . . . . . . . . . 30
	A. Revision History . . . . . . . . . . . . . . . . . . . . . . . 33		14. Security Considerations . . . . . . . . . . . . . . . . . . 31
	Intellectual Property and Copyright Statements . . . . . . . . 35		15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 32
			16. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
			16.1 Normative References . . . . . . . . . . . . . . . . . . 35
			16.2 Informative References . . . . . . . . . . . . . . . . . 36
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 37
			A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 38
			B. Revision History . . . . . . . . . . . . . . . . . . . . . . 39
			Intellectual Property and Copyright Statements . . . . . . . 41
	1. Introduction		1. Introduction
	The Atom Publishing Protocol is an application-level protocol for		The Atom Publishing Protocol is an application-level protocol for
	publishing and editing Web resources using HTTP [RFC2616] and XML 1.0		publishing and editing Web resources using HTTP [RFC2616] and XML 1.0
	[W3C.REC-xml-20040204].		[W3C.REC-xml-20040204].
	2. Notational Conventions		2. XML Namespace and Language
			The XML Namespaces URI [W3C.REC-xml-names-19990114] for the XML data
			format described in this specification is: http://purl.org/atom/app#
			XML elements defined by this specification MAY have an xml:lang
			attribute, whose content indicates the natural language for the
			element (and its descendents). The language context is only
			significant for elements and attributes declared to be "Language-
			Sensitive" by this specification. Requirements regarding the content
			and interpretation of xml:lang are specified in [W3C.REC-xml-
			20040204], Section 2.12.
			3. Notational Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	3. Terminology		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.
			This specification uses the namespace prefix "app:" for the Namespace
			URI identified in Section 2 above. It uses the namespace prefix
			"atom:" for the Namespace URI identified in [AtomFormat]. Note that
			choices of namespace prefix are arbitrary and not semantically
			significant.
			4. Terminology
			For convenience, this protocol may be referred to as "Atom Protocol"
			or "APP". This specification uses both internally.
	URI/IRI - A Uniform Resource Identifier and Internationalized		URI/IRI - A Uniform Resource Identifier and Internationalized
	Resource Identifier, respectively. These terms (and the distinction		Resource Identifier, respectively. These terms (and the distinction
	between them) are defined in [RFC3986] and [RFC3987].		between them) are defined in [RFC3986] and [RFC3987].
	Resource - an item identified by a URI [W3C.REC-webarch-20041215].		Resource - A network data object or service that can be identified
			by a URI, as defined in [RFC2616].
	Collection Resource - A resource that contains a listing of Member
	Resources and meets the requirements in Section 5 of this
	specification.
	Member Resource - A resource whose URI is listed by a Collection		Representation - An entity included with a request or response as
	Resource.		defined in [RFC2616].
	4. The Atom Publishing Protocol Model		5. The Atom Publishing Protocol Model
	The Atom Publishing Protocol operates on collections of Web		The Atom Publishing Protocol is a subset of HTTP that is used to edit
	resources. All collections support the same basic interactions, as		resources on the web. The APP operates on collections of Web
	do the resources within the collections. The patterns of interaction		resources. Collections are HTTP resources, as are the members of the
	are based on the common HTTP verbs.		collection. Both Collections and collection member resources support
			the same basic interactions. The patterns of interaction are based
			on the common HTTP verbs.
	o GET is used to retrieve a representation of a resource or perform		o GET is used to retrieve a representation of a resource or perform
	a read-only query.		a read-only query.
	o POST is used to create a new, dynamically-named resource.		o POST is used to create a new, dynamically-named resource, or to
			provide a block of data to a data-handling process.
	o PUT is used to update a known resource.		o PUT is used to update a known resource.
	o DELETE is used to remove a resource.		o DELETE is used to remove a resource.
	4.1 Collections		5.1 Collections
	The APP groups resources into "Collections", which are analogous to		The APP groups resources into "Collections", which are analogous to
	the "folders" or "directories" found in many file systems.		folders or directories found in a file system. In the figure we have
			member resources in a collection.
	4.2 Discovery
	To discover the location of the collections exposed by an APP		+-------------------------+
	service, the client must locate and request an Introspection Document		| Collection |
	(Section 8).		| |
			| +----------------+ |
			| | Member_A | |
			| +----------------+ |
			| |
			| +----------------+ |
			| | Member_B | |
			| +----------------+ |
			| |
			| +----------------+ |
			| | Member_C | |
			| +----------------+ |
			| |
			| ... |
			| |
			| +----------------+ |
			| | Member_Oldest | |
			| +----------------+ |
			| |
			+-------------------------+
			To add a new member to a collection an appropriate representation is
			POSTed to the URI of the collection resource. Here we show it being
			added to the beginnng of the list. The ordering of the members of
			collections is in terms of the time at which each resource was last
			updated, which includes the act of creating the resource. The
			ordering of collection members is covered in more detail in Section 8
			and Section 11.
	Client Server		+-------------------------+
			| Collection |
	| |		| |
	| 1.) GET Introspection |		POST | +----------------+ |
	|------------------------------->|		--------->| Member_New | |
			| +----------------+ |
	| |		| |
	| 2.) Introspection Doc |		| +----------------+ |
	|<-------------------------------|		| | Member_A | |
			| +----------------+ |
			| |
			| +----------------+ |
			| | Member_B | |
			| +----------------+ |
	| |		| |
			| +----------------+ |
			| | Member_C | |
			| +----------------+ |
			| |
			| ... |
			| |
			| +----------------+ |
			| | Member_Oldest | |
			| +----------------+ |
			| |
			+-------------------------+
	1. The client sends a GET request to the Service Description		You'll note that up until now we haven't said what kinds of
	Resource.		representations we are expecting at each of the resources. There are
			two kinds of collections, Entry and Generic. In Entry Collections
			all the members MUST have representations as Atom Entries. For
			further restrictions on Entry Collection see Section 9 The other type
			of collection is a Generic Collection. Generic Collections make no
			restriction on the representations of their member resources.
	2. The server responds with an Introspection Document containing the		5.2 Editable Resources
	locations of collections provided by the service. The content of
	this document can vary based on aspects of the client request,
	including, but not limited to, authentication credentials.
	4.3 Listing		All the members of a collection are Editable Resources. An Editable
			resource is a resource whose available HTTP methods can be used to
			retrieve, update and delete it.
	Once the client has discovered the location of a collection, it can		5.2.1 Read
	request a listing of the collection's membership. However,
	collections might be extremely large, so servers are likely to list a		To retrieve a representation of the resource, you send a GET to the
	small subset of the collection by default.		URI of the Editable Resource. Remember that for members of Entry
			Collections, the served representation will be an Atom Entry.
	Client Server		Client Server
	| |		| |
	| 1.) GET to Collection URI |		| 1.) GET to Editable Resource URI |
	|------------------------------->|		|------------------------------------------>|
	| |		| |
	| 2.) 200 OK, Atom Feed Doc |		| 2.) 200 OK |
	|<-------------------------------|		|<------------------------------------------|
	| |		| |
	1. The client sends a GET request to the Collection's URI.		1. The client sends a GET request to the member's URI.
	2. The server responds with an Atom Feed Document containing a full
	or partial listing of the collection's membership.
	4.4 Authoring		2. The server responds with the representation of the resource.
	After locating a collection, a client can add entries by sending a		5.2.2 Update
	request to the collection; other changes are accomplished by sending
	HTTP requests to its member resources.
	4.4.1 Create		To update an Editable Resource the client will PUT an updated
			representation to the URI of the resource.
	Client Server		Client Server
	| |		| |
	| 1.) POST to Collection URI |		| 1.) PUT to Editable Resource URI |
	|------------------------------->|		|------------------------------------------>|
	| |
	| 2.) 201 Created @ Location |
	|<-------------------------------|
	| |		| |
			| 2.) 200 OK |
			|<------------------------------------------|
	1. The client sends a representation of a member to the server via		1. The client PUTs an updated representation to the member's URI.
	HTTP POST. The Request URI is that of the Collection.
	2. The server responds with a response of "201 Created" and a		2. The server MAY respond with an updated representation of the
	"Location" header containing the URI of the newly-created		member's new state.
	resource.
	4.4.2 Read		5.2.3 Delete
			An Editable Resource is deleted by sending it DELETE. Note that this
			also removes it from all the collections that it belonged to.
	Client Server		Client Server
	| |		| |
	| 1.) GET or HEAD to Member URI |		| 1.) DELETE to Editable Resource URI |
	|------------------------------->|		|------------------------------------------>|
	| |		| |
	| 2.) 200 OK |		| 2.) 200 Ok |
	|<-------------------------------|		|<------------------------------------------|
	| |		| |
	1. The client sends a GET (or HEAD) request to the member's URI.		1. The client sends a DELETE request to the member's URI.
	2. The server responds with an appropriate representation.		2. The server responds with successful status code.
	4.4.3 Update		5.3 Capabilities Discovery
			Each collection resource responds to GET and can return a Collection
			Document as it's representation. The Collection Document enumerates
			the capabilities of each collection and the format is described in
			Section 6.2.
	Client Server		Client Server
	| |		| |
	| 1.) PUT to Member URI |		| 1.) GET to Collection |
	|------------------------------->|		|------------------------------->|
	| |		| |
	| 2.) 200 OK |		| 2.) Collection Document |
	|<-------------------------------|		|<-------------------------------|
			| |
	1. The client PUTs an updated representation to the member's URI.		1. The client sends a GET request to the Collection Resource.
	2. The server responds with a representation of the member's new		2. The server responds with a Collection Document containing a
	state.		description of the capabilities of the collection. The content
			of this document can vary based on aspects of the client request,
			including, but not limited to, authentication credentials.
	4.4.4 Delete		5.4 Listing
			Clients can request a listing of the Collection's membership.
			Listing the Editable Resources that are members of a collection is
			done using one of the List Resources in the Introspection Document,
			utilizing the 'app:uri-template' element. The List Resource returns
			Atom Feed Documents with one Atom Entry for each member resource that
			match the selection criteria. This is true whether the collection is
			an Entry Collection or a Generic Collection. If an Entry Collection
			is being interrogated, the entries returned by a list resource SHOULD
			NOT to be considered complete representations of the member
			resources. See Section 11 and Section 12 for more details on the
			extensions and constraints found on the entries returned from List
			Resources.
	Client Server		Client Server
	| |		| |
	| 1.) DELETE to Member URI |		| 1.) GET to List Resource |
	|------------------------------->|		|------------------------------->|
	| |		| |
	| 2.) 204 No Content |		| 2.) 200 OK, Atom Feed Doc |
	|<-------------------------------|		|<-------------------------------|
	| |		| |
	1. The client sends a DELETE request to the member's URI.		1. The client sends a GET request to the Collection's URI.
	2. The server responds with successful status code.		2. The server responds with an Atom Feed Document containing a full
			or partial listing of the Collection's membership.
	4.5 Success and Failure		5.5 Success and Failure
	HTTP defines classes of response. HTTP status codes of the form 2xx		HTTP defines different classes of response, which are used by the
	signal that a request was successful. HTTP status codes of the form		Atom Protocol. HTTP status codes of the form 2xx signal that a
	4xx or 5xx signal that an error has occurred, and the request has		request was successful. HTTP status codes of the form 4xx or 5xx
	failed. Consult the HTTP specification for more detailed definitions		signal that an error has occurred, and the request has failed.
	of each status code.		Consult the HTTP specification [RFC2616] for more detailed
			definitions of each status code.
	5. Collections		6. Atom Publishing Protocol Documents
	An Atom Collection is a set of related resources. All members of a		This specification describes two kinds of Atom Publishing Protocol
	collection have an "updated" property, and the collection is		Documents: Atom Collections Documents and Atom Introspection
	considered to be ordered by this property.		Documents.
	5.1 Collection Documents		An Atom Collection Document is a representation of an Atom
			collection, including metadata about the collection, and some or all
			of the members associated with it. Its root is the app:collection
			element.
	An example Collection Document.		An Atom Introspection Document represents one or more workspaces,
			which describe server-defined groupings of collections. Its root is
			the app:service element.
			namespace app = "..." start = appCollection | appIntrospection
			Both kinds of Atom Publishing Protocol Documents are specified in
			terms of the XML Information Set, serialised as XML 1.0 ([W3C.REC-
			xml-20040204]). Atom Publishing Protocol Documents MUST be well-
			formed XML. This specification does not define a DTD for Atom
			Protocol, and hence does not require them to be valid (in the sense
			used by XML).
			Atom Collection Documents are identified with the "application/
			atomcoll+xml" media type.
			Atom Introspection Documents are identified with the "application/
			atomserv+xml" media type.
			Atom allows the use of IRIs [RFC3987], as well as URIs [RFC3986].
			Every URI is an IRI, so any URI can be used where an IRI is needed.
			While IRIs must, for many protocols, be mapped to URIs prior to
			dereferencing, they MUST NOT be so mapped for comparison when used in
			atom:id. Section 3.1 of [RFC3987] describes how to map an IRI to a
			URI when necessary.
			6.1 Use of xml:base xml:lang
			Any element defined by this specification MAY have an xml:base
			attribute [W3C.REC-xmlbase-20010627]. When xml:base is used in an
			Atom Publishing Protocol Document, it serves the function described
			in section 5.1.1 of [RFC3986], establishing the base URI (or IRI) for
			resolving any relative references found within the effective scope of
			the xml:base attribute.
			Any element defined by this specification MAY have an xml:lang
			attribute, whose content indicates the natural language for the
			element and its descendents. The language context is only
			significant for elements and attributes declared to be "Language-
			Sensitive" by this specification. Requirements regarding the content
			and interpretation of xml:lang are specified in XML 1.0 ([W3C.REC-
			xml-20040204]), Section 2.12.
			appCommonAttributes =
			attribute xml:base { atomUri }?,
			attribute xml:lang { atomLanguageTag }?,
			undefinedAttribute*
			6.2 Collection Documents
			The Collection Document describes the capabilities of a Collection,
			the types of Entries that it will support, the URI Templates it
			supports.
			The Collection Document has the media-type 'application/atomcoll+xml'
			(see Section 15).
			Here's an example document:
	<?xml version="1.0" encoding='utf-8'?>		<?xml version="1.0" encoding='utf-8'?>
	<collection xmlns="http://purl.org/atom/app#">		<app:collection xmlns:app="http://purl.org/atom/app#">
	<member href="http://example.org/1"		<app:member-type>entry</pub:member-type>
	hrefreadonly="http://example.com/1/bar"		<app:uri-template>http://example.org/{index}</pub:uri-template>
	title="Sample 1"		<app:uri-template>http://example.org/{daterange}</pub:uri-template>
	updated="2003-12-13T18:30:02Z" />		</app:collection>
	<member href="http://example.org/2"
	hrefreadonly="http://example.com/2/bar"
	title="Sample 2"
	updated="2003-12-13T18:30:02Z" />
	<member href="http://example.org/3"
	hrefreadonly="http://example.com/3/bar"
	title="Sample 3"
	updated="2003-12-13T18:30:02Z" />
	<member href="http://example.org/4"
	title="Sample 4"
	updated="2003-12-13T18:30:02Z" />
	</collection>
	Atom Collection Documents have the media-type 'application/		This example says the Collection contains Atom Entry documents, and
	atomcoll+xml', see Section 11.		that there are two means of selecting entries using what are called
			'URI Templates'; one based on the collection's order, and another
			based on dates. See Section 11.1 for more about URI Templates.
	5.1.1 Element Definitions		6.2.1 Element Definitions
	5.1.1.1 The 'app:collection' Element		6.2.1.1 The 'app:collection' Element
	The 'app:collection' element represents an Atom Collection. A		The app:collection is the document element of a Collection Document.
	collection document does not necessarily list every member of the
	collection.
	appCollection =		appCollection =
	element app:collection {		element app:collection {
	attribute next { text } ?,		appCommonAttributes,
	appMember*		( appMemberType+
			appSearchTemplate
			& anyElement* )
	}		}
	o 'app:collection' elements MAY contain any number of 'app:member'
	elements.
	o 'app:collection' elements MAY contain a 'next' attribute which		This specification defines two child elements for app:collection:
	identifies a collection document containing member elements
	updated earlier in time.
	The members listed in a collection document MUST constitute a		o app:member-type: any number of elements listing the types of
	consecutive sequence of the collection's members, ordered by their		Entries that the Collection may contain.
	"updated" properties. That is, a collection document MUST contain a
	contiguous subset of the members of the collection ordered by their
	'updated' property.
	5.1.1.2 The 'app:member' Element		o app:uri-template: any number of URI Templates for a List Resource
			(See Section 11).
	The 'app:member' represent