Thomas, great feedback. Comments below.
Thomas Broyer wrote:
>[snip]
> Let me try rephrasing:
> """When the server generates a response with a status code of 201
> ("Created") and provide a response body, clients MUST NOT assume the
> response body represents the newly-created resource unless it is an
> Atom Entry Document and the response contains a Content-Location
> header with the same value as the Location header. When generating
> response with a Content-Type of application/atom+xml, the response
> body MUST be an Atom Entry Document (i.e. clients can assume it will
> not be an Atom Feed Document)."""
>
This works for me (minus the parenthesized comment in the final sentence).
>[snip]
> It might also be useful either a) paraphrasing RFC2616 saying that
> Content-Location might be a relative URL (relative to the request URI)
> or b) spec'ing that Content-Location values must be absolute URLs in
> the context of the Atom Publishing Protocol.
> I'd prefer b), a bit easier to implement for clients, and a noop for
> servers (well, except eventually for some cases where they provide a
> Content-Location with a value different from the Location value)
>
Can you offer some suggested spec text that I can work into the pace?
>
> """
> 8.2 The 'edit' Link
>
> Each member Entry within a collection SHOULD contain an atom:link
> element with
> a link relation of "edit" that contains the IRI used to retrieve,
> update or
> delete the member Entry.
> """
>
> I thought this was changed to a MAY. How about just describing the
Not sure, I was basing this on what is actually in the current draft text.
> "edit" link relation meaning and either leave implicit or explicitly
> say that an entry in a collection listing without an [EMAIL PROTECTED]"edit"]
> is not editable.
> (Note that it's not really clear per the actual wording whether an
> entry retrieved through its [EMAIL PROTECTED]"edit"] should in turn also
> contain such a link or not)
>
Again, suggested spec text would be helpful.
>
> """
> Deletion of a media link entry SHOULD result in the deletion of the
> linked media resource.
> """
>
> Any reason to make it a SHOULD rather than a MUST?
>
Any reason to make a MUST rather than a SHOULD? ;-)
>
> """
> […] A server may or may not allow a
> client to modify the server selected values for these elements.
> """
> This is related to the problem above with [EMAIL PROTECTED]"edit"]: if the
> server does not allow a client to modify the server selected values,
> how does it do?
> Could be explained a bit more with something like:
> """A server may or may not allow a client to modify the server
> selected values for these elements, for example by not providing an
> atom:link with a link relation of "edit" (the entry is not editable
> neither deletable), by refusing PUT requests with a status code of 405
> ("Method Not Supported"), by refusing PUT requests modifying those
> field values with a status code of 409 ("Conflict") or by overwriting
> any value set by the client."""
>
I'm not sure this is necessary, but the proposed text works for me.
>[snip]
> How about adding something like
> """This specification assigns no significance to atom:link elements
> with a link relation of "edit-resource" as direct children of
> atom:feed elements, or within entries whose atom:content "type"
> attribute value is not a media-type (e.g. the attribute is absent or
> its value is one of "text", "html" or "xhtml"): because those contents
> have no media-types, they cannot reliably be sent over HTTP outside an
> Atom Entry."""
>
-1, don't think this is necessary. e.g. we don't say similar things
with regards to any other link relation.
> """
> The app:accept
> element value specifies a comma-separated listing of media-ranges [RFC2616]
> identifying the types of representations that may be POSTed to the
> Collection's URI.
> """
> Still lacks something about "qvalues" and "accept-parameters" ;-)
> maybe also something about prevalence of "wildcard media-ranges" over
> "media-type media-ranges", e.g. what does this mean: <accept>image/*,
> image/png</accept>
>
Again, suggested spec text would be helpful. I'll incorporate it into
the pace.
> """
> A value of "entry" indicates that Atom Entry Documents can be posted
> to the Collection.
> """
> I assume it implies that when this value is not present in the list,
> the collection doesn't accept Atom Entry Documents?
Right.
> Given that any collection member has an Atom Entry "representation"
> (or call it "description" if you want for "media link entries"), be it
> editable or not, then if a server accepts image/png, why couldn't it
> also accept an Atom Entry Document with an inlined, based64-encoded
> image/png?
> I understand that it's meant to represent text/html/xhtml
> atom:content/@type values but it's really not clear per this Pace.
>
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. At this point,
I'd prefer that APP define as few constraints in this area as possible
and just let implementors figure out the best approaches.
> """
> If present, the value of the accept element MUST NOT
> be empty and MUST NOT contain leading or trailing whitespace.
> """
> What's the rational behind this constraint? Also, why couldn't
Convention mostly. I don't care either way, actually, I'll be
trim()'ing the values before I process them no matter what the constraint.
>[snip]
> Good work James, thank you. Actually, it's becoming so similar to what
> I think that I do not have to bother writing an alternative Pace ;-)
>
Very good to hear. Your suggestions are good, but I don't have the time
today to work up the spec text. If you can get me some suggested text,
I'll work it in to PaceMediaEntries4.
- James
