draft-ietf-atompub-protocol-06.txt		draft-ietf-atompub-protocol-07.txt
	Network Working Group J. Gregorio, Ed.		Network Working Group J. Gregorio, Ed.
	Internet-Draft BitWorking, Inc		Internet-Draft BitWorking, Inc
	Expires: April 30, 2006 B. de hOra, Ed.		Expires: July 5, 2006 B. de hOra, Ed.
	Propylon Ltd.		Propylon Ltd.
	October 27, 2005		January 01, 2006
	The Atom Publishing Protocol		The Atom Publishing Protocol
	draft-ietf-atompub-protocol-06.txt		draft-ietf-atompub-protocol-07.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 30, 2006.		This Internet-Draft will expire on July 5, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	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 is based on		for publishing and editing Web resources. The protocol is based on
	HTTP transport of Atom-formatted representations. The Atom format is		HTTP transport of Atom-formatted representations. The Atom format is
	documented in the Atom Syndication Format		documented in the Atom Syndication Format (RFC4287).
	(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. Notational Conventions . . . . . . . . . . . . . . . . . . . 5		2. Notational Conventions . . . . . . . . . . . . . . . . . . . 5
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6
	4. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 7		4. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 7
	5. Protocol Operations . . . . . . . . . . . . . . . . . . . . 8		5. Protocol Operations . . . . . . . . . . . . . . . . . . . . 8
	5.1 Retrieving an Introspection Document . . . . . . . . . . . 8		5.1 Retrieving an Introspection Document . . . . . . . . . . . 8
	5.2 Creating a Resource . . . . . . . . . . . . . . . . . . . 8		5.2 Creating a Resource . . . . . . . . . . . . . . . . . . . 8
	5.3 Editing a Resource . . . . . . . . . . . . . . . . . . . . 8		5.3 Editing a Resource . . . . . . . . . . . . . . . . . . . . 8
	5.3.1 Retrieving a Resource . . . . . . . . . . . . . . . . 9		5.3.1 Retrieving a Resource . . . . . . . . . . . . . . . . 9
	5.3.2 Updating a Resource . . . . . . . . . . . . . . . . . 9		5.3.2 Updating a Resource . . . . . . . . . . . . . . . . . 9
	5.3.3 Deleting a Resource . . . . . . . . . . . . . . . . . 9		5.3.3 Deleting a Resource . . . . . . . . . . . . . . . . . 9
	5.4 Listing Collections . . . . . . . . . . . . . . . . . . . 10		5.4 Listing Collection Members . . . . . . . . . . . . . . . . 10
	5.5 Success and Failure . . . . . . . . . . . . . . . . . . . 10		5.5 Use of HTTP Response codes . . . . . . . . . . . . . . . . 10
	6. XML-related Conventions . . . . . . . . . . . . . . . . . . 11		6. XML-related Conventions . . . . . . . . . . . . . . . . . . 11
	6.1 Referring to Information Items . . . . . . . . . . . . . . 11		6.1 Referring to Information Items . . . . . . . . . . . . . . 11
	6.2 XML Namespace Usage . . . . . . . . . . . . . . . . . . . 11		6.2 XML Namespace Usage . . . . . . . . . . . . . . . . . . . 11
	6.3 RELAX NG Schema . . . . . . . . . . . . . . . . . . . . . 11		6.3 Use of xml:base and xml:lang . . . . . . . . . . . . . . . 11
	6.4 Use of xml:base and xml:lang . . . . . . . . . . . . . . . 11		6.4 RELAX NG Schema . . . . . . . . . . . . . . . . . . . . . 12
	7. Introspection Documents . . . . . . . . . . . . . . . . . . 13		7. Introspection Documents . . . . . . . . . . . . . . . . . . 13
	7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 13		7.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . 13
	7.2 Example . . . . . . . . . . . . . . . . . . . . . . . . . 13		7.2 Element Definitions . . . . . . . . . . . . . . . . . . . 14
	7.3 Element Definitions . . . . . . . . . . . . . . . . . . . 14		7.2.1 The "app:service" Element . . . . . . . . . . . . . . 14
	7.3.1 The 'app:service' Element . . . . . . . . . . . . . . 14		7.2.2 The "app:workspace" Element . . . . . . . . . . . . . 14
	7.3.2 The 'app:workspace' Element . . . . . . . . . . . . . 14		7.2.3 The "app:collection" Element . . . . . . . . . . . . . 15
	7.3.3 The 'app:collection' Element . . . . . . . . . . . . . 15		7.2.4 The "app:member-type" Element . . . . . . . . . . . . 15
	7.3.4 The 'app:member-type' Element . . . . . . . . . . . . 15		8. Collections . . . . . . . . . . . . . . . . . . . . . . . . 17
	7.3.5 The 'app:list-template' Element . . . . . . . . . . . 16		8.1 Creating resources with POST . . . . . . . . . . . . . . . 17
	8. Collections . . . . . . . . . . . . . . . . . . . . . . . . 18		8.1.1 Example . . . . . . . . . . . . . . . . . . . . . . . 17
	8.1 Creating resources with POST . . . . . . . . . . . . . . . 18		8.1.2 Title: Header . . . . . . . . . . . . . . . . . . . . 17
	8.1.1 Title: Header . . . . . . . . . . . . . . . . . . . . 18		8.2 Entry Collections . . . . . . . . . . . . . . . . . . . . 18
	8.2 Entry Collections . . . . . . . . . . . . . . . . . . . . 19		8.3 Media Collections . . . . . . . . . . . . . . . . . . . . 18
	8.2.1 Role of Atom Entry Elements During Editing . . . . . . 19		8.3.1 Editing Media Resources . . . . . . . . . . . . . . . 18
	8.3 Media Collections . . . . . . . . . . . . . . . . . . . . 20		9. Listing Collections . . . . . . . . . . . . . . . . . . . . 19
	8.3.1 Editing Media Resources . . . . . . . . . . . . . . . 20		9.1 Collection Paging . . . . . . . . . . . . . . . . . . . . 19
	9. Listing Collections . . . . . . . . . . . . . . . . . . . . 21		10. Atom Format Link Relation Extensions . . . . . . . . . . . . 21
	10. Atom Entry Extensions . . . . . . . . . . . . . . . . . . . 23		10.1 The "edit" Link Relation . . . . . . . . . . . . . . . . 21
	10.1 The 'edit' Link Relation . . . . . . . . . . . . . . . . 23		11. Atom Publishing Control Extensions . . . . . . . . . . . . . 22
	10.2 Publishing Control . . . . . . . . . . . . . . . . . . . 23		11.1 The Atom Publishing Control Namespace . . . . . . . . . 22
	10.2.1 The app:draft Element . . . . . . . . . . . . . . . 24		11.2 The "pub:control" Element . . . . . . . . . . . . . . . 22
	11. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 25		11.2.1 The "pub:draft" Element . . . . . . . . . . . . . . 22
	12. Securing the Atom Protocol . . . . . . . . . . . . . . . . . 27		12. Atom Publishing Protocol Example . . . . . . . . . . . . . . 23
	13. Security Considerations . . . . . . . . . . . . . . . . . . 28		13. Securing the Atom Protocol . . . . . . . . . . . . . . . . . 25
	14. IANA Considerations . . . . . . . . . . . . . . . . . . . . 29		14. Security Considerations . . . . . . . . . . . . . . . . . . 26
	15. References . . . . . . . . . . . . . . . . . . . . . . . . . 31		15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 27
	15.1 Normative References . . . . . . . . . . . . . . . . . . 31		16. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
	15.2 Informative References . . . . . . . . . . . . . . . . . 32		16.1 Normative References . . . . . . . . . . . . . . . . . . 29
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 33		16.2 Informative References . . . . . . . . . . . . . . . . . 30
	A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 34		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 31
	B. RELAX NG Compact Schema . . . . . . . . . . . . . . . . . . 35		A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32
	C. Revision History . . . . . . . . . . . . . . . . . . . . . . 38		B. RELAX NG Compact Schema . . . . . . . . . . . . . . . . . . 33
	Intellectual Property and Copyright Statements . . . . . . . 40		C. Revision History . . . . . . . . . . . . . . . . . . . . . . 36
			Intellectual Property and Copyright Statements . . . . . . . 39
	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]. The protocol supports the creation of		[W3C.REC-xml-20040204]. The protocol supports the creation of
	arbitrary web resources and provides facilities for:		arbitrary web resources and provides facilities for:
	o Collections: Sets of resources, which may be retrieved in whole or		o Collections: Sets of resources, which may be retrieved in whole or
	in part.		in part.
	skipping to change at page 6, line 7		skipping to change at page 6, line 7
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	Note: The Introspection Document allows the use of IRIs [RFC3987], as		Note: The Introspection Document allows the use of IRIs [RFC3987], as
	well as URIs [RFC3986]. Every URI is an IRI, so any URI can be used		well as URIs [RFC3986]. Every URI is an IRI, so any URI can be used
	where an IRI is needed. How to map an IRI to a URI is specified in		where an IRI is needed. How to map an IRI to a URI is specified in
	Section 3.1 of Internationalized Resource Identifiers (IRIs)		Section 3.1 of Internationalized Resource Identifiers (IRIs)
	[RFC3987].		[RFC3987].
	3. Terminology		3. Terminology
	For convenience, this protocol may be referred to as "Atom Protocol"		For convenience, this protocol may be referred to as the "Atom
	or "APP".		Protocol" or "APP".
			URI/IRI - A Uniform Resource Identifier and Internationalized
			Resource Identifier. These terms and the distinction between them
			are defined in [RFC3986] and [RFC3987].
			Resource - A network-accessible data object or service identified by
			an IRI, as defined in [RFC2616]. See [W3C.REC-webarch-20041215] for
			further discussion on resources.
	The phrase "the IRI of a document" in this specification is shorthand		The phrase "the IRI of a document" in this specification is shorthand
	for "an IRI which, when dereferenced, is expected to produce that		for "an IRI which, when dereferenced, is expected to produce that
	document as a representation".		document as a representation".
	URI/IRI - A Uniform Resource Identifier and Internationalized		Representation - An entity included with a request or response as
	Resource Identifier, respectively. These terms (and the distinction
	between them) are defined in [RFC3986] and [RFC3987].
	resource - A network data object or service that can be identified
	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
	defined in [RFC2616].		defined in [RFC2616].
	collection - A resource that contains a set of member IRIs, as		Collection - A resource that contains a set of member IRIs. See
	described in Section 8 of this specification.		Section 8.
	member - A resource whose IRI is listed in a collection.
	IRI template - A parameterized string that becomes a IRI when the
	parameters are filled in. See Section 9.
	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		Member - A resource whose IRI is listed in a Collection.
	editable by the client and not enforced by the server.
	server-controlled element - An element of an Atom Entry whose value		Introspection Document - A document that describes the location and
	is enforced by the server and not editable by the client.		capabilities of one or more Collections. See Section 7.
	4. Protocol Model		4. Protocol Model
	The Atom Publishing Protocol uses HTTP to edit resources on the web.		The Atom Publishing Protocol uses HTTP to edit and author web
	It provides a list based mechanism for managing collections of		resources. The Atom Protocol uses the following HTTP methods:
	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 query.		a query.
	o POST is used to create a new, dynamically-named resource.		o POST is used to create a new, dynamically-named resource.
	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.
	This diagram shows the APP model:		Along with operations on resources, the Atom Protocol provides list-
			based structures, called Collections, for managing and organising
	+---------------+		resources, called Members. Collections contain the IRIs of, and
	| Introspection | +------------+		metadata about, their Member resources. For authoring and editing of
	| |-->| Collection |		resources to commence, an Atom Protocol client can examine server-
	+---------------+ | |		defined groups of Collections, called Introspection Documents.
	| | +--------+
	| |-->| Member |
	| | +--------+
	| |
	| | .
	| | .
	| | .
	| |
	| | +--------+
	| |-->| Member |
	| | +--------+
	| |
	+------------+
	The introspection document contains the IRIs of one or more
	collections. A collection contains IRIs and metadata describing
	member resources. The protocol allows editing of resources with
	representations of any media-type. Some types of collections are
	specialized and restrict the resource representations of their
	members.
	5. Protocol Operations		5. Protocol Operations
	5.1 Retrieving an Introspection Document		5.1 Retrieving an Introspection Document
	Client Server		Client Server
	| |		| |
	| 1.) GET to IRI of Introspection Document |		| 1.) GET to IRI of Introspection Document |
	|------------------------------------------>|		|------------------------------------------>|
	| |		| |
	| 2.) Introspection Document |		| 2.) Introspection Document |
	|<------------------------------------------|		|<------------------------------------------|
	| |		| |
	1. The client sends a GET request to the IRI of the introspection		1. The client sends a GET request to the IRI of the Introspection
	document.		Document.
	2. The server responds with the introspection document which		2. The server responds with the document which enumerates the IRIs
	enumerates the IRIs of all the collections, and the capabilities		of all the Collections and the capabilities of those Collections
	of those collections, that the service supports.		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.
	5.2 Creating a Resource		5.2 Creating a Resource
	Client Server		Client Server
	| |		| |
	| 1.) POST to IRI of Collection |		| 1.) POST to IRI of Collection |
	|------------------------------------------>|		|------------------------------------------>|
	| |		| |
	| 2.) 201 Created |		| 2.) 201 Created |
	|<------------------------------------------|		|<------------------------------------------|
	| |		| |
	1. The client POSTs a representation to the IRI of the collection.		1. The client POSTs a representation of the Member to the IRI of the
			collection.
	2. If the member resource was created successfully the server		2. If the Member resource was created successfully, the server
	responds with a status code of 201 and a Location: header that		responds with a status code of 201 and a Location: header that
	contains the IRI of the newly created member resource.		contains the IRI of the newly created resource.
	5.3 Editing a Resource		5.3 Editing a Resource
	Once a resource has been created and its IRI is known, that IRI may		Once a resource has been created and its IRI is known, that IRI may
	be used to retrieve, update, and delete it.		be used to retrieve, update, and delete the resource.
	5.3.1 Retrieving a Resource		5.3.1 Retrieving a Resource
	Client Server		Client Server
	| |		| |
	| 1.) GET to Member IRI |		| 1.) GET to Member IRI |
	|------------------------------------------>|		|------------------------------------------>|
	| |		| |
	| 2.) Member Representation |		| 2.) Member Representation |
	|<------------------------------------------|		|<------------------------------------------|
	| |		| |
	1. The client sends a GET request to the member's IRI to retrieve		1. The client sends a GET request to the Member's IRI to retrieve
	its representation .		its representation .
	2. The server responds with the representation of the resource.		2. The server responds with the representation of the resource.
	5.3.2 Updating a Resource		5.3.2 Updating a Resource
	Client Server		Client Server
	| |		| |
	| 1.) PUT to Member IRI |		| 1.) PUT to Member IRI |
	|------------------------------------------>|		|------------------------------------------>|
	| |		| |
	| 2.) 200 OK |		| 2.) 200 OK |
	|<------------------------------------------|		|<------------------------------------------|
	1. The client PUTs an updated representation to the member's IRI.		1. The client PUTs an updated representation to the Member's IRI.
	2. Upon a successful update of the resource the server responds with		2. Upon a successful update of the resource the server responds with
	a status code of 200.		a status code of 200.
	5.3.3 Deleting a Resource		5.3.3 Deleting a Resource
	Client Server		Client Server
	| |		| |
	| 1.) DELETE to Member Resource IRI |		| 1.) DELETE to Member Resource IRI |
	|------------------------------------------>|		|------------------------------------------>|
	| |		| |
	| 2.) 200 Ok |		| 2.) 200 Ok |
	|<------------------------------------------|		|<------------------------------------------|
	| |		| |
	1. The client sends a DELETE request to the member's IRI.		1. The client sends a DELETE request to the Member's IRI.
	2. Upon the successful deletion of the resource the server responds		2. Upon the successful deletion of the resource the server responds
	with a status code of 200.		with a status code of 200.
	Note: deleting a member also removes it from all the collections to		5.4 Listing Collection Members
	which it belongs.
	5.4 Listing Collections
	To enumerate the members of a collection the client sends a GET to		To list the members of a Collection the client sends a GET request to
	its IRI. This IRI is constructed from information in the		the Collection's IRI. An Atom Feed Document is returned containing
	introspection document. An Atom Feed Document is returned with one		one Atom Entry for each member resource. See Section 9 and
	Atom Entry for each member resource that matches the selection		Section 10 for a description of the feed contents.
	criteria in the IRI. See Section 9 and Section 10 for a description
	of the feed contents.
	Client Server		Client Server
	| |		| |
	| 1.) GET to List IRI |		| 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 membership list IRI.		1. The client sends a GET request to the Collection's IRI.
	2. The server responds with an Atom Feed Document containing the		2. The server responds with an Atom Feed Document containing the
	IRIs of all the collection members that match the selection		IRIs of all the collection members that match the selection
	criteria.		criteria.
	5.5 Success and Failure		5.5 Use of HTTP Response codes
	The Atom Protocol uses HTTP status codes to signal the results of		The Atom Protocol uses the response status codes defined in HTTP to
	protocol operations. Status codes of the form 2xx signal that a		indicate the success or failure of an operation. Consult the HTTP
	request was successful. HTTP status codes of the form 4xx or 5xx		specification [RFC2616] for detailed definitions of each status code.
	signal that an error has occurred. Consult the HTTP specification		It is strongly recommended that entities contained within HTTP 4xx
	[RFC2616] for the definitions of HTTP status codes.		and 5xx responses include a human readable, natural language
			explanation of the error.
	6. XML-related Conventions		6. XML-related Conventions
	The data format in this specification is specified in terms of the		The data format in this specification is specified in terms of the
	XML Information Set, serialised as XML 1.0 [W3C.REC-xml-20040204].		XML Information Set, serialised as XML 1.0 [W3C.REC-xml-20040204].
	Atom Publishing Protocol Documents MUST be well-formed XML. This		Atom Publishing Protocol Documents MUST be well-formed XML. This
	specification does not define any DTDs for Atom Protocol, and hence		specification does not define any DTDs for Atom Protocol, and hence
	does not require them to be valid (in the sense used by XML).		does not require them to be "valid" in the sense used by XML.
	6.1 Referring to Information Items		6.1 Referring to Information Items
	This specification uses a shorthand for two common terms: the phrase		This specification uses a shorthand for two common terms: the phrase
	"Information Item" is omitted when naming Element Information Items		"Information Item" is omitted when discussing Element Information
	and Attribute Information Items. Therefore, when this specification		Items and Attribute Information Items. Therefore, when this
	uses the term "element," it is referring to an Element Information		specification uses the term "element," it is referring to an Element
	Item in Infoset terms. Likewise, when it uses the term "attribute,"		Information Item in Infoset terms. Likewise, when it uses the term
	it is referring to an Attribute Information Item.		"attribute," it is referring to an Attribute Information Item.
	6.2 XML Namespace Usage		6.2 XML Namespace Usage
	The Namespace URI [W3C.REC-xml-names-19990114] for the data format		The namespace name [W3C.REC-xml-names-19990114] for the XML format
	described in this specification is:		described in this specification is:
	http://purl.org/atom/app#		http://purl.org/atom/app#
	This specification uses the prefix "app:" for the Namespace URI. The		This specification uses the prefix "app:" for the namespace name.
	choice of namespace prefix is not semantically significant.		The choice of namespace prefix is not semantically significant.
	This specification also uses the prefix "atom:" for the Namespace URI
	identified in [AtomFormat].
	6.3 RELAX NG Schema
	Some sections of this specification are illustrated with fragments of		This specification also uses the prefix "atom:" for
	a non-normative RELAX NG Compact schema [RNC]. However, the text of		"http://www.w3.org/2005/Atom", the namespace name of the Atom
	this specification provides the definition of conformance. A		Publishing Format [RFC4287].
	complete schema appears in Appendix B.
	6.4 Use of xml:base and xml:lang		6.3 Use of xml:base and xml:lang
	XML elements defined by this specification MAY have an xml:base		XML elements defined by this specification MAY have an xml:base
	attribute [W3C.REC-xmlbase-20010627]. When xml:base is used, it		attribute [W3C.REC-xmlbase-20010627]. When xml:base is used, it
	serves the function described in section 5.1.1 of [RFC3986],		serves the function described in section 5.1.1 of [RFC3986],
	establishing the base URI (or IRI) for resolving any relative		establishing the base URI (or IRI) for resolving any relative
	references found within the effective scope of the xml:base		references found within the effective scope of the xml:base
	attribute.		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 Section 2.12 of XML		and interpretation of xml:lang are specified in Section 2.12 of XML
	1.0 [W3C.REC-xml-20040204], .		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*
	7. Introspection Documents		6.4 RELAX NG Schema
	7.1 Introduction		Some sections of this specification are illustrated with fragments of
			a non-normative RELAX NG Compact schema [RNC]. A complete schema
			appears in Appendix B. However, the text of this specification
			provides the definition of conformance.
			7. Introspection Documents
	For authoring to commence, a client needs to first discover the		For authoring to commence, a client needs to first discover the
	capabilities and locations of collections offered. This is done		capabilities and locations of collections offered. This is done
	using Introspection Documents. An Introspection Document describes		using Introspection Documents. An Introspection Document describes
	workspaces, which are server-defined groupings of collections.		workspaces, which are server-defined groupings of collections.
	7.2 Example		Introspection documents are identified with the "application/
			atomserv+xml" media type (see Section 15).
			While an introspection document allows multiple workspaces, there is
			no requirement that a service support multiple workspaces. In
			addition, a collection MAY appear in more than one workspace.
			7.1 Example
	<?xml version="1.0" encoding='utf-8'?>		<?xml version="1.0" encoding='utf-8'?>
	<service xmlns="http://purl.org/atom/app#">		<service xmlns="http://purl.org/atom/app#">
	<workspace title="Main Site" >		<workspace title="Main Site" >
	<collection		<collection
	title="My Blog Entries"		title="My Blog Entries"
	href="http://example.org/reilly/main" >		href="http://example.org/reilly/main" >
	<member-type>entry</member-type>		<member-type>entry</member-type>
	<list-template>http://example.org/{index}</list-template>		<list-template>http://example.org/{index}</list-template>
	</collection>		</collection>
	skipping to change at page 13, line 42		skipping to change at page 13, line 47
	<workspace title="Side Bar Blog">		<workspace title="Side Bar Blog">
	<collection title="Remaindered Links"		<collection title="Remaindered Links"
	href="http://example.org/reilly/list" >		href="http://example.org/reilly/list" >
	<member-type>entry</member-type>		<member-type>entry</member-type>
	<list-template>http://example.org/l/{index}</list-template>		<list-template>http://example.org/l/{index}</list-template>
	</collection>		</collection>
	</workspace>		</workspace>
	</service>		</service>
	This Introspection Document describes two workspaces. The first,		This Introspection Document describes two workspaces. The first,
	called 'Main Site', has two collections called 'My Blog Entries' and		called "Main Site", has two collections called "My Blog Entries" and
	'Pictures' whose IRIs are 'http://example.org/reilly/main' and		"Pictures" whose IRIs are "http://example.org/reilly/main" and
	'http://example.org/reilly/pic' respectively. 'My Blog Entries' is		"http://example.org/reilly/pic" respectively. "My Blog Entries" is
	an Entry collection and 'Pictures' is a Media collection. Entry and		an Entry collection and "Pictures" is a Media collection. Entry and
	Media collections are discussed in Section 7.3.4.		Media collections are discussed in Section 7.2.4.
	The second workspace is called 'Side Bar Blog' and has a single		The second workspace is called "Side Bar Blog" and has a single
	collection called 'Remaindered Links' whose collection IRI is		collection called "Remaindered Links" whose collection IRI is
	'http://example.org/reilly/list'. 'Remaindered Links' is an Entry		"http://example.org/reilly/list". "Remaindered Links" is an Entry
	collection.		collection.
	Introspection documents are identified with the "application/		7.2 Element Definitions
	atomserv+xml" media type (see Section 14).
	While an introspection document allows multiple workspaces, there is
	no requirement that a service support multiple workspaces. In
	addition, a collection MAY appear in more than one workspace.
	7.3 Element Definitions
	7.3.1 The 'app:service' Element		7.2.1 The "app:service" Element
	The root of an introspection document is the app:service element.		The root of an introspection document is the "app:service" element.
	namespace app = "http://purl.org/atom/app#"		namespace app = "http://purl.org/atom/app#"
	start = appService		start = appService
	The "app:service" element is the container for introspection		The "app:service" element is the container for introspection
	information associated with one or more workspaces. An app:service		information associated with one or more workspaces. An app:service
	element MUST contain one or more app:workspace elements.		element MUST contain one or more app:workspace elements.
	appService =		appService =
	element app:service {		element app:service {
	appCommonAttributes,		appCommonAttributes,
	( appWorkspace+		( appWorkspace+
	& extensionElement* )		& extensionElement* )
	}		}
	7.3.2 The 'app:workspace' Element		7.2.2 The "app:workspace" Element
	The 'app:workspace' element contains information elements about the		The "app:workspace" element contains information elements about the
	collections of resources available for editing. The app:workspace		collections of resources available for editing. The app:workspace
	element MUST contain one or more app:collection elements.		element MUST contain one or more app:collection elements.
	appWorkspace =		appWorkspace =
	element app:workspace {		element app:workspace {
	appCommonAttributes,		appCommonAttributes,
	attribute title { text },		attribute title { text },
	( appCollection+		( appCollection+
	& extensionElement* )		& extensionElement* )
	}		}
	7.3.2.1 The 'title' Attribute		In an app:workspace element, the first app:collection element SHOULD
			refer to the preferred or primary collection. In the following
			example, the "Entries" collection would be considered the "preferred"
			or "primary" collection of the workspace:
	The app:workspace element MUST contain a 'title' attribute, which		<service>
	conveys a human-readable name for the workspace. This attribute is		<workspace title="My Blog">
			<collection title="Entries" ... >
			<collection title="Photos" ... >
			</workspace>
			</service>
			7.2.2.1 The "title" Attribute
			The app:workspace element MUST contain a "title" attribute, which
			gives a human-readable name for the workspace. This attribute is
	Language-Sensitive.		Language-Sensitive.
	7.3.3 The 'app:collection' Element		7.2.3 The "app:collection" Element
	The app:collection contains information elements that describe the		The "app:collection" describes a collection. This specification
	location and capabilities of a collection.		defines one child element: app:member-type.
	appCollection =		appCollection =
	element app:collection {		element app:collection {
	appCommonAttributes,		appCommonAttributes,
	attribute title { text },		attribute title { text },
	attribute href { text },		attribute href { text },
	( appMemberType		( appMemberType
	& appListTemplate		& appListTemplate