I sent a message yesterday (Beyond PaceCompoundEntries) but haven't seen it yet on the list. Whatever, I tidy my desk yesterday evening and found my notes about using Multipart/Related with APP, and particularly the MAYs and MUSTs, interop and conformance levels.
To summarize: - any conformant server is still compatible with the core protocol, thus with clients which doesn't implement Compound Entries - any conformant client is still compatible with the core protocol, thus with servers which doesn't implement Compound Entries - any conformant server is compatible with any conformant client and vice versa, whichever their conformance level Server conformance ================== Each level adds features/constraints to lower levels. Level 1: atomic creation of Compound Entries using multipart/related ------- - accepts multipart/related;type="application/atom+xml" on POST - keeps the relationships between parts - when a client PUTs an application/atom+xml entity, the server MAY figure out which subsidiary parts are no longer referenced and delete them (otherwise, a client will have to later edit the multipart/related representation of the Compound Entry to explicitely remove those parts) - sends the Atom Entry part (with cid: URIs resolved) in response to a GET to the entry Edit-URL - advertizes its conformance to the spec - MAY expose some or all subsidiary parts in a Media collection to allow for individual update, but then MUST disallow DELETE Level 2: creation and editing Compound Entries using multipart/related ------- - sends multipart/related;type="application/atom+xml" in response to a GET (using content negotiation or by providing an additional URL, exposed in the Atom Feed representation of the collection as an atom:[EMAIL PROTECTED]"edit" and @type='multipart/related;type="application/atom+xml"']). Subsidiary parts can be provided as message/external-body;access-type=URL - accept multipart/related;type="application/atom+xml" on PUT: updates the Atom Entry root part, deletes every subsidiary part of the previous entry state and creates new resources for the subsidiary parts of the new entry state [@@NOTE@@ subsidiary parts are not updated], except for message/external-body;access-type=URL subsidiary parts which are preserved, using the provided URL as the identifier for the subsidiary part Level 3: ------- - MUST expose subsidiary parts in a Media collection - includes Atom-ID header fields within each multipart/related subsidiary part (might include one on the root part as well) to communicate their atom:id. This will be used on PUT to update subsidiary parts instead of deleting the "old" parts and creating new ones. Client conformance ================== Each level adds features/constraints to lower levels. Level 1: atomic creation of Compound Entries using multipart/related ------- - sends valid multipart/related;type="application/atom+xml" - only sends multipart/related to servers advertizing Compound Entries support - MUST NOT send multipart/related on PUT Level 2: creation and editing Compound Entries using multipart/related ------- - accepts multipart/related;type="application/atom+xml" (advertized on the Accept HTTP header) for editing (and then sends the updated multipart/related on PUT) - MUST NOT send multipart/related on PUT if the Compound Entry wasn't previously retrieved as a multipart/related Level 3: ------- - MUST preserve Atom-ID header fields in multipart/related subsidiary parts (obvioulsy, only when the server previously sent them) -- Thomas Broyer
