Abstract
Remove the Service Document from the Protocol Spec.
Status
under development
Rationale
The Service document is not well enough defined, and does not contain any information that is really needed for the protocol. It can be removed safely from the protocol document.
Proposal
Replace 5.1
5.1 Retrieving an Introspection Document Client Server | | | 1.) GET to URI of Introspection Document | |------------------------------------------>| | | | 2.) Introspection Document | |<------------------------------------------| | | 1. The client sends a GET request to the URI of the Introspection Document. 2. The server responds with the document enumerating the IRIs of a set of Collections and the capabilities of those Collections supported by the server. The content of this document can vary based on aspects of the client request, including, but not limited to, authentication credentials.
to
5.1 Retrieving a Collection Client Server | | | 1.) GET to URI of Collection | |------------------------------------------>| | | | 2.) Feed Document | |<------------------------------------------| | | 1. The client sends a GET request to the Collection URI 2. The server responds with an atom Feed document . If this document contains an app:accept element, this specifies what type of mime types can be POSTED to this uri.
Remove section 7. Introspection Documents
and replace with
7. Introspection extensions The "app:accept" Element The atom:feed element MAY contain one "app:accept" element. The app:accept element value specifies a comma-separated list of media- ranges [RFC2616] identifying the types of representations that can be POSTed to the Collection's URI. Whitespace separating the media- range values is considered insignificant and MUST be ignored. The app:accept element is similar to the HTTP Accept request-header [RFC2616] with the exception that app:accept has no notion of preference. Accordingly, the value syntax of app:accept does not use accept-params or "q" parameters as specified in [RFC2616], section 14.1. The order of media-ranges is not significant. The following lists are all equivalent: <app:accept>image/png, image/*</app:accept> <app:accept>image/*, image/png</app:accept> <app:accept>image/*</app:accept> A value of "entry" indicates that Atom Entry Documents can be posted to the Collection. If the accept element is omitted, or empty, clients SHOULD assume that only Atom Entry documents will be accepted by the collection. appAccept = element app:accept { appCommonAttributes, ( appTypeValue? ) } appTypeValue = ( "entry" | media-type |entry-or-media-type ) media-type = xsd:string { pattern = "entry,(.+/.+,?)*" } entry-or-media-type = xsd:string { pattern = "(.+/.+,?)*" }
Remove most of appendix B. relating to service documents.
Impacts
Positive. It mostly just removes information from the spec, so it cannot go wrong. Since the spec will be shorter, it will be easier to show it to be correct, and so it will pass through the standardisation process faster.