draft-ietf-atompub-protocol-05.txt		draft-ietf-atompub-protocol-06.txt
	Network Working Group J. Gregorio, Ed.		Network Working Group J. Gregorio, Ed.
	Internet-Draft BitWorking, Inc		Internet-Draft BitWorking, Inc
	Expires: April 14, 2006 B. de hOra, Ed.		Expires: April 30, 2006 B. de hOra, Ed.
	Propylon Ltd.		Propylon Ltd.
	October 11, 2005		October 27, 2005
	The Atom Publishing Protocol		The Atom Publishing Protocol
	draft-ietf-atompub-protocol-05.txt		draft-ietf-atompub-protocol-06.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 35		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 April 14, 2006.		This Internet-Draft will expire on April 30, 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
	Language) and HTTP (HyperText Transport Protocol) to edit content.
	The Atom Publishing Protocol (APP) is an application-level protocol		The Atom Publishing Protocol (APP) is an application-level protocol
	for publishing and editing Web resources. The protocol at its core		for publishing and editing Web resources. The protocol is based on
	is the HTTP transport of Atom-formatted representations. The Atom		HTTP transport of Atom-formatted representations. The Atom format is
	format is documented in the Atom Syndication Format		documented in the Atom Syndication Format
	(draft-ietf-atompub-format-11.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 . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. XML Namespace and Language . . . . . . . . . . . . . . . . . 5		2. Notational Conventions . . . . . . . . . . . . . . . . . . . 5
	3. Notational Conventions . . . . . . . . . . . . . . . . . . . 6		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6
	4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 7		4. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 7
	5. The Atom Publishing Protocol Model . . . . . . . . . . . . . 8		5. Protocol Operations . . . . . . . . . . . . . . . . . . . . 8
	5.1 Collections . . . . . . . . . . . . . . . . . . . . . . . 8		5.1 Retrieving an Introspection Document . . . . . . . . . . . 8
	5.2 Editable Resources . . . . . . . . . . . . . . . . . . . . 9		5.2 Creating a Resource . . . . . . . . . . . . . . . . . . . 8
	5.2.1 Read . . . . . . . . . . . . . . . . . . . . . . . . . 10		5.3 Editing a Resource . . . . . . . . . . . . . . . . . . . . 8
	5.2.2 Update . . . . . . . . . . . . . . . . . . . . . . . . 10		5.3.1 Retrieving a Resource . . . . . . . . . . . . . . . . 9
	5.2.3 Delete . . . . . . . . . . . . . . . . . . . . . . . . 10		5.3.2 Updating a Resource . . . . . . . . . . . . . . . . . 9
	5.3 Capabilities Discovery . . . . . . . . . . . . . . . . . . 11		5.3.3 Deleting a Resource . . . . . . . . . . . . . . . . . 9
	5.4 Listing . . . . . . . . . . . . . . . . . . . . . . . . . 11		5.4 Listing Collections . . . . . . . . . . . . . . . . . . . 10
	5.5 Success and Failure . . . . . . . . . . . . . . . . . . . 12		5.5 Success and Failure . . . . . . . . . . . . . . . . . . . 10
	6. Atom Publishing Protocol Documents . . . . . . . . . . . . . 13		6. XML-related Conventions . . . . . . . . . . . . . . . . . . 11
	6.1 Use of xml:base xml:lang . . . . . . . . . . . . . . . . . 13		6.1 Referring to Information Items . . . . . . . . . . . . . . 11
	6.2 Collection Documents . . . . . . . . . . . . . . . . . . . 14		6.2 XML Namespace Usage . . . . . . . . . . . . . . . . . . . 11
	6.2.1 Element Definitions . . . . . . . . . . . . . . . . . 14		6.3 RELAX NG Schema . . . . . . . . . . . . . . . . . . . . . 11
	6.3 Introspection Documents . . . . . . . . . . . . . . . . . 16		6.4 Use of xml:base and xml:lang . . . . . . . . . . . . . . . 11
	6.3.1 Element Definitions . . . . . . . . . . . . . . . . . 17		7. Introspection Documents . . . . . . . . . . . . . . . . . . 13
	7. Introspection Resource . . . . . . . . . . . . . . . . . . . 20		7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 13
	7.1 Discovery . . . . . . . . . . . . . . . . . . . . . . . . 20		7.2 Example . . . . . . . . . . . . . . . . . . . . . . . . . 13
	8. Collection Resources . . . . . . . . . . . . . . . . . . . . 21		7.3 Element Definitions . . . . . . . . . . . . . . . . . . . 14
	8.1 GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 21		7.3.1 The 'app:service' Element . . . . . . . . . . . . . . 14
	8.2 POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 21		7.3.2 The 'app:workspace' Element . . . . . . . . . . . . . 14
	8.3 Title: Header . . . . . . . . . . . . . . . . . . . . . . 22		7.3.3 The 'app:collection' Element . . . . . . . . . . . . . 15
	9. Entry Collections . . . . . . . . . . . . . . . . . . . . . 23		7.3.4 The 'app:member-type' Element . . . . . . . . . . . . 15
	9.1 Editing Entry Resources . . . . . . . . . . . . . . . . . 23		7.3.5 The 'app:list-template' Element . . . . . . . . . . . 16
	9.2 Role of Atom Entry Elements During Editing . . . . . . . . 23		8. Collections . . . . . . . . . . . . . . . . . . . . . . . . 18
	10. Generic Collections . . . . . . . . . . . . . . . . . . . . 25		8.1 Creating resources with POST . . . . . . . . . . . . . . . 18
	10.1 Editing Generic Resources . . . . . . . . . . . . . . . 25		8.1.1 Title: Header . . . . . . . . . . . . . . . . . . . . 18
	10.2 Title: Header . . . . . . . . . . . . . . . . . . . . . 25		8.2 Entry Collections . . . . . . . . . . . . . . . . . . . . 19
	11. List Resources . . . . . . . . . . . . . . . . . . . . . . . 26		8.2.1 Role of Atom Entry Elements During Editing . . . . . . 19
	11.1 URI Templates . . . . . . . . . . . . . . . . . . . . . 26		8.3 Media Collections . . . . . . . . . . . . . . . . . . . . 20
	11.2 URI Template Parameters . . . . . . . . . . . . . . . . 27		8.3.1 Editing Media Resources . . . . . . . . . . . . . . . 20
	11.2.1 \{index\} URI template variable . . . . . . . . . . 27		9. Listing Collections . . . . . . . . . . . . . . . . . . . . 21
	11.2.2 \{daterange\} URI template variable . . . . . . . . 27		10. Atom Entry Extensions . . . . . . . . . . . . . . . . . . . 23
	11.2.3 Other URI Template parameters . . . . . . . . . . . 28		10.1 The 'edit' Link Relation . . . . . . . . . . . . . . . . 23
	12. Atom Entry Extensions . . . . . . . . . . . . . . . . . . . 29		10.2 Publishing Control . . . . . . . . . . . . . . . . . . . 23
	13. Securing the Atom Protocol . . . . . . . . . . . . . . . . . 30		10.2.1 The app:draft Element . . . . . . . . . . . . . . . 24
	14. Security Considerations . . . . . . . . . . . . . . . . . . 31		11. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 25
	15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 32		12. Securing the Atom Protocol . . . . . . . . . . . . . . . . . 27
	16. References . . . . . . . . . . . . . . . . . . . . . . . . . 35		13. Security Considerations . . . . . . . . . . . . . . . . . . 28
	16.1 Normative References . . . . . . . . . . . . . . . . . . 35		14. IANA Considerations . . . . . . . . . . . . . . . . . . . . 29
	16.2 Informative References . . . . . . . . . . . . . . . . . 36		15. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 37		15.1 Normative References . . . . . . . . . . . . . . . . . . 31
	A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 38		15.2 Informative References . . . . . . . . . . . . . . . . . 32
	B. Revision History . . . . . . . . . . . . . . . . . . . . . . 39		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 33
	Intellectual Property and Copyright Statements . . . . . . . 41		A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 34
			B. RELAX NG Compact Schema . . . . . . . . . . . . . . . . . . 35
			C. Revision History . . . . . . . . . . . . . . . . . . . . . . 38
			Intellectual Property and Copyright Statements . . . . . . . 40
	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]. The protocol supports the creation of
			arbitrary web resources and provides facilities for:
	2. XML Namespace and Language		o Collections: Sets of resources, which may be retrieved in whole or
			in part.
	The XML Namespaces URI [W3C.REC-xml-names-19990114] for the XML data		o Introspection: Discovering and describing collections.
	format described in this specification is: http://purl.org/atom/app#
	XML elements defined by this specification MAY have an xml:lang		o Editing: Creating, updating and deleting resources.
	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		2. 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].
	Some sections of this specification are illustrated with fragments of		Note: The Introspection Document allows the use of IRIs [RFC3987], as
	a non-normative RELAX NG Compact schema [RNC]. However, the text of		well as URIs [RFC3986]. Every URI is an IRI, so any URI can be used
	this specification provides the definition of conformance.		where an IRI is needed. How to map an IRI to a URI is specified in
			Section 3.1 of Internationalized Resource Identifiers (IRIs)
	This specification uses the namespace prefix "app:" for the Namespace		[RFC3987].
	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		3. Terminology
	For convenience, this protocol may be referred to as "Atom Protocol"		For convenience, this protocol may be referred to as "Atom Protocol"
	or "APP". This specification uses both internally.		or "APP".
			The phrase "the IRI of a document" in this specification is shorthand
			for "an IRI which, when dereferenced, is expected to produce that
			document as a representation".
	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 - A network data object or service that can be identified		resource - A network data object or service that can be identified
	by a URI, as defined in [RFC2616].		by a IRI, as defined in [RFC2616]. See [W3C.REC-webarch-20041215]
			for further discussion on resources.
	Representation - An entity included with a request or response as		representation - An entity included with a request or response as
	defined in [RFC2616].		defined in [RFC2616].
	5. The Atom Publishing Protocol Model		collection - A resource that contains a set of member IRIs, as
			described in Section 8 of this specification.
	The Atom Publishing Protocol is a subset of HTTP that is used to edit		member - A resource whose IRI is listed in a collection.
	resources on the web. The APP operates on collections of Web
	resources. Collections are HTTP resources, as are the members of the		IRI template - A parameterized string that becomes a IRI when the
	collection. Both Collections and collection member resources support		parameters are filled in. See Section 9.
	the same basic interactions. The patterns of interaction are based
	on the common HTTP verbs.		introspection document - A document that describes the location and
			capabilities of one or more collections. See Section 7
			client writable element - An element of an Atom Entry whose value is
			editable by the client and not enforced by the server.
			server-controlled element - An element of an Atom Entry whose value
			is enforced by the server and not editable by the client.
			4. Protocol Model
			The Atom Publishing Protocol uses HTTP to edit resources on the web.
			It provides a list based mechanism for managing collections of
			editable resources called member resources. Collections contain the
			IRIs and metadata describing member resources. The APP uses these
			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 query.
	o POST is used to create a new, dynamically-named resource, or to		o POST is used to create a new, dynamically-named resource.
	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.
	5.1 Collections		This diagram shows the APP model:
	The APP groups resources into "Collections", which are analogous to
	folders or directories found in a file system. In the figure we have
	member resources in a collection.
	+-------------------------+		+---------------+
	| Collection |		| Introspection | +------------+
	| |		| |-->| Collection |
	| +----------------+ |		+---------------+ | |
	| | Member_A | |		| | +--------+
	| +----------------+ |		| |-->| Member |
	| |		| | +--------+
	| +----------------+ |
	| | Member_B | |
	| +----------------+ |
	| |
	| +----------------+ |
	| | Member_C | |
	| +----------------+ |
	| |		| |
	| ... |		| | .
			| | .
			| | .
	| |		| |
	| +----------------+ |		| | +--------+
	| | Member_Oldest | |		| |-->| Member |
	| +----------------+ |		| | +--------+
	| |		| |
	+-------------------------+		+------------+
	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.
	+-------------------------+		The introspection document contains the IRIs of one or more
	| Collection |		collections. A collection contains IRIs and metadata describing
	| |		member resources. The protocol allows editing of resources with
	POST | +----------------+ |		representations of any media-type. Some types of collections are
	--------->| Member_New | |		specialized and restrict the resource representations of their
	| +----------------+ |		members.
			5. Protocol Operations
			5.1 Retrieving an Introspection Document
			Client Server
	| |		| |
	| +----------------+ |		| 1.) GET to IRI of Introspection Document |
	| | Member_A | |		|------------------------------------------>|
	| +----------------+ |
	| |		| |
	| +----------------+ |		| 2.) Introspection Document |
	| | Member_B | |		|<------------------------------------------|
	| +----------------+ |
	| |		| |
	| +----------------+ |
	| | Member_C | |		1. The client sends a GET request to the IRI of the introspection
	| +----------------+ |		document.
			2. The server responds with the introspection document which
			enumerates the IRIs of all the collections, and the capabilities
			of those collections, that the service supports.
			5.2 Creating a Resource
			Client Server
	| |		| |
	| ... |		| 1.) POST to IRI of Collection |
			|------------------------------------------>|
	| |		| |
	| +----------------+ |		| 2.) 201 Created |
	| | Member_Oldest | |		|<------------------------------------------|
	| +----------------+ |
	| |		| |
	+-------------------------+
	You'll note that up until now we haven't said what kinds of		1. The client POSTs a representation to the IRI of the collection.
	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.
	5.2 Editable Resources		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 member resource.
	All the members of a collection are Editable Resources. An Editable		5.3 Editing a Resource
	resource is a resource whose available HTTP methods can be used to
	retrieve, update and delete it.
	5.2.1 Read		Once a resource has been created and its IRI is known, that IRI may
			be used to retrieve, update, and delete it.
	To retrieve a representation of the resource, you send a GET to the		5.3.1 Retrieving a Resource
	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 Editable Resource URI |		| 1.) GET to Member IRI |
	|------------------------------------------>|		|------------------------------------------>|
	| |		| |
	| 2.) 200 OK |		| 2.) Member Representation |
	|<------------------------------------------|		|<------------------------------------------|
	| |		| |
	1. The client sends a GET request to the member's URI.		1. The client sends a GET request to the member's IRI to retrieve
			its representation .
	2. The server responds with the representation of the resource.		2. The server responds with the representation of the resource.
	5.2.2 Update		5.3.2 Updating a Resource
	To update an Editable Resource the client will PUT an updated
	representation to the URI of the resource.
	Client Server		Client Server
	| |		| |
	| 1.) PUT to Editable Resource URI |		| 1.) PUT to Member IRI |
	|------------------------------------------>|		|------------------------------------------>|
	| |		| |
	| 2.) 200 OK |		| 2.) 200 OK |
	|<------------------------------------------|		|<------------------------------------------|
	1. The client PUTs an updated representation to the member's URI.		1. The client PUTs an updated representation to the member's IRI.
	2. The server MAY respond with an updated representation of the
	member's new state.
	5.2.3 Delete		2. Upon a successful update of the resource the server responds with
			a status code of 200.
	An Editable Resource is deleted by sending it DELETE. Note that this		5.3.3 Deleting a Resource
	also removes it from all the collections that it belonged to.
	Client Server		Client Server
	| |		| |
	| 1.) DELETE to Editable Resource URI |		| 1.) DELETE to Member Resource IRI |
	|------------------------------------------>|		|------------------------------------------>|
	| |		| |
	| 2.) 200 Ok |		| 2.) 200 Ok |
	|<------------------------------------------|		|<------------------------------------------|
	| |		| |
	1. The client sends a DELETE request to the member's URI.		1. The client sends a DELETE request to the member's IRI.
	2. The server responds with successful status code.
	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
	| |
	| 1.) GET to Collection |
	|------------------------------->|
	| |
	| 2.) Collection Document |
	|<-------------------------------|
	| |
	1. The client sends a GET request to the Collection Resource.		2. Upon the successful deletion of the resource the server responds
			with a status code of 200.
	2. The server responds with a Collection Document containing a		Note: deleting a member also removes it from all the collections to
	description of the capabilities of the collection. The content		which it belongs.
	of this document can vary based on aspects of the client request,
	including, but not limited to, authentication credentials.
	5.4 Listing		5.4 Listing Collections
	Clients can request a listing of the Collection's membership.		To enumerate the members of a collection the client sends a GET to
	Listing the Editable Resources that are members of a collection is		its IRI. This IRI is constructed from information in the
	done using one of the List Resources in the Introspection Document,		introspection document. An Atom Feed Document is returned with one
	utilizing the 'app:uri-template' element. The List Resource returns		Atom Entry for each member resource that matches the selection
	Atom Feed Documents with one Atom Entry for each member resource that		criteria in the IRI. See Section 9 and Section 10 for a description
	match the selection criteria. This is true whether the collection is		of the feed contents.
	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.) GET to List Resource |		| 1.) GET to List IRI |
	|------------------------------->|		|------------------------------->|
	| |		| |
	| 2.) 200 OK, Atom Feed Doc |		| 2.) 200 OK, Atom Feed Doc |
	|<-------------------------------|		|<-------------------------------|
	| |		| |
	1. The client sends a GET request to the Collection's URI.		1. The client sends a GET request to the membership list IRI.
	2. The server responds with an Atom Feed Document containing a full		2. The server responds with an Atom Feed Document containing the
	or partial listing of the Collection's membership.		IRIs of all the collection members that match the selection
			criteria.
	5.5 Success and Failure		5.5 Success and Failure
	HTTP defines different classes of response, which are used by the		The Atom Protocol uses HTTP status codes to signal the results of
	Atom Protocol. HTTP status codes of the form 2xx signal that a		protocol operations. Status codes of the form 2xx signal that a
	request was successful. HTTP status codes of the form 4xx or 5xx		request was successful. HTTP status codes of the form 4xx or 5xx
	signal that an error has occurred, and the request has failed.		signal that an error has occurred. Consult the HTTP specification
	Consult the HTTP specification [RFC2616] for more detailed		[RFC2616] for the definitions of HTTP status codes.
	definitions of each status code.
	6. Atom Publishing Protocol Documents		6. XML-related Conventions
	This specification describes two kinds of Atom Publishing Protocol		The data format in this specification is specified in terms of the
	Documents: Atom Collections Documents and Atom Introspection		XML Information Set, serialised as XML 1.0 [W3C.REC-xml-20040204].
	Documents.		Atom Publishing Protocol Documents MUST be well-formed XML. This
			specification does not define any DTDs for Atom Protocol, and hence
			does not require them to be valid (in the sense used by XML).
	An Atom Collection Document is a representation of an Atom		6.1 Referring to Information Items
	collection, including metadata about the collection, and some or all
	of the members associated with it. Its root is the app:collection
	element.
	An Atom Introspection Document represents one or more workspaces,		This specification uses a shorthand for two common terms: the phrase
	which describe server-defined groupings of collections. Its root is		"Information Item" is omitted when naming Element Information Items
	the app:service element.		and Attribute Information Items. Therefore, when this specification
			uses the term "element," it is referring to an Element Information
			Item in Infoset terms. Likewise, when it uses the term "attribute,"
			it is referring to an Attribute Information Item.
	namespace app = "..." start = appCollection | appIntrospection		6.2 XML Namespace Usage
	Both kinds of Atom Publishing Protocol Documents are specified in		The Namespace URI [W3C.REC-xml-names-19990114] for the data format
	terms of the XML Information Set, serialised as XML 1.0 ([W3C.REC-		described in this specification is:
	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/		http://purl.org/atom/app#
	atomcoll+xml" media type.
	Atom Introspection Documents are identified with the "application/		This specification uses the prefix "app:" for the Namespace URI. The
	atomserv+xml" media type.		choice of namespace prefix is not semantically significant.
	Atom allows the use of IRIs [RFC3987], as well as URIs [RFC3986].		This specification also uses the prefix "atom:" for the Namespace URI
	Every URI is an IRI, so any URI can be used where an IRI is needed.		identified in [AtomFormat].
	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		6.3 RELAX NG Schema
	Any element defined by this specification MAY have an xml:base		Some sections of this specification are illustrated with fragments of
	attribute [W3C.REC-xmlbase-20010627]. When xml:base is used in an		a non-normative RELAX NG Compact schema [RNC]. However, the text of
	Atom Publishing Protocol Document, it serves the function described		this specification provides the definition of conformance. A
	in section 5.1.1 of [RFC3986], establishing the base URI (or IRI) for		complete schema appears in Appendix B.
	resolving any relative references found within the effective scope of
	the xml:base attribute.		6.4 Use of xml:base and xml:lang
			XML elements defined by this specification MAY have an xml:base
			attribute [W3C.REC-xmlbase-20010627]. When xml:base is used, 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		Any element defined by this specification MAY have an xml:lang
	attribute, whose content indicates the natural language for the		attribute, whose content indicates the natural language for the
	element and its descendents. The language context is only		element and its descendents. The language context is only
	significant for elements and attributes declared to be "Language-		significant for elements and attributes declared to be "Language-
	Sensitive" by this specification. Requirements regarding the content		Sensitive" by this specification. Requirements regarding the content
	and interpretation of xml:lang are specified in XML 1.0 ([W3C.REC-		and interpretation of xml:lang are specified in Section 2.12 of XML
	xml-20040204]), Section 2.12.		1.0 [W3C.REC-xml-20040204], .
	appCommonAttributes =		appCommonAttributes =
	attribute xml:base { atomUri }?,		attribute xml:base { atomUri }?,
	attribute xml:lang { atomLanguageTag }?,		attribute xml:lang { atomLanguageTag }?,
	undefinedAttribute*		undefinedAttribute*
	6.2 Collection Documents		7. Introspection Documents
	The Collection Document describes the capabilities of a Collection,		7.1 Introduction
	the types of Entries that it will support, the URI Templates it
	supports.
	The Collection Document has the media-type 'application/atomcoll+xml'		For authoring to commence, a client needs to first discover the
	(see Section 15).		capabilities and locations of collections offered. This is done
			using Introspection Documents. An Introspection Document describes
			workspaces, which are server-defined groupings of collections.
	Here's an example document:		7.2 Example
	<?xml version="1.0" encoding='utf-8'?>		<?xml version="1.0" encoding='utf-8'?>
	<app:collection xmlns:app="http://purl.org/atom/app#">		<service xmlns="http://purl.org/atom/app#">
	<app:member-type>entry</pub:member-type>		<workspace title="Main Site" >
	<app:uri-template>http://example.org/{index}</pub:uri-template>