Remove the Service Document from the Protocol Spec.


under development


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.


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

   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.


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>

   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 {
            ( 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.


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.