Ok, I updated PaceMediaEntries4 to reflect some of these suggestions. Notes below.
Thomas Broyer wrote: >[snip] > In the previously suggested paragraph, change the sentence about > Content-Location to "and the response contains a Content-Location > header with the same value *character-by-character* as the Location > header". > Changed to: === Any response to the POST request that contains an Atom Entry Document representing the created resource SHOULD contain a Content-Location header with the same character-by-character value as the Location header. === >[snip] > """ > 8.2 The 'edit' link relation > > In an Atom Entry, an atom:link element with a link relation of "edit" > indicates the IRI used to retrieve, update or delete the entry. > [EMAIL PROTECTED]: the next part can be ignored if the WG thinks it can be > left [EMAIL PROTECTED] When no such link exists in an Atom Entry, this > specification defines no other mean to discover the IRI used to edit > the entry. > """ > I don't see how this is better than what is currently in the Pace. The second sentence is unnecessary, and the first doesn't seem to be much different than what we already have. >[snip] > I was just asking which "valid reasons in particular circumstances" > are envisioned for not making this a MUST, as they're not in the > proposed spec text. > > Actually, I can see some reasons: > - "soft deletes" (instead of deleting the resource, move it to a > "trashcan" from where it can be recovered), > - the server knows the "media resource" is referenced from elsewhere > and choose to keep the resource accessible (but no longer editable) > Both of these reasons apply to our implementation/interop endpoint. When an item is soft-deleted, it's linked resources are still around until the item is purged. > How about: > """ > 10.2 The "edit-resource" Link Relation > > In an Atom Entry whose atom:content "type" attribute value is a > media-type, an atom:link element with a link relation of > "edit-resource" indicates the IRI used to update the entry content. > """ > I changed the text in the Pace to: === 10.2 The "edit-resource" Link Relation The Atom Protocol adds the value "edit-resource" to the Atom Registry of Link Relations (see section 7.1 of [RFC4287]). When appearing within an atom:entry, the value of the href attribute is an IRI that may be used to modify a media resource associated with that entry. === I also updated the text for section 10.1, === 10.1 The "edit" Link Relation The Atom Protocol adds the value "edit" to the Atom Registry of Link Relations (see section 7.1 of [RFC4287]). The value of "edit" specifies that the value of the href attribute is the IRI of an editable Atom Entry Document. When appearing within an atom:entry, the href IRI may be used to update and delete the resource represented by that entry. === >[snip] > """ > The app:accept element value specifies a list of media-ranges > [RFC2616] identifying the types of representations that may be POSTed > to the Collection's URI. Media-ranges are separated by one or more > commas, and OPTIONAL whitespace [REC-XML]. In that sense, the > app:accept element is similar to the HTTP Accept request-header field > with the exception that app:accept has no notion of preference, thus > its value syntax has no accept-params or "q" parameters. As there is > no notion of preference, the order of media-ranges is not important; > therefore, 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> > """ > I changed the Pace text to: === The app:collection 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 may be POSTd 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]. 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> === >> The accept represents what you can POST to the collection, not >> necessarily what the collection can contain. For instance, I would >> consider it appropriate behavior for a server accepting image/png POSTs >> to create entries containing inlined, base64-encoded image/pngs as >> opposed to using the src attribute. But that's just me. > > That wasn't my point. > Sorry, I did get your point, I just didn't communicate it very well ;-) I personally don't see a problem with a server accepting an inlined base64 encoded content element, however, I can definitely see how doing so could cause problems. I'd leave it unspecified and let server implementors sort it out. >[snip] > How about discussing app:accept separately from "media entries"? > app:accept could very be taken outside PaceMediaEntries and put into > another Pace of its own, without making PaceMediaEntries less > consistent. Well, the problem with that is that the "cat blog" scenario doesn't work too well without it. And at this point, we seem to have lots of heads nodding in agreement with what we've got. - James
