Bill de hÓra wrote:
>
> 0
>
> Some comments:
>
> [[[
> If an entry was created in the collection which received the POST, its
> URI MUST be returned in a Location HTTP header.
> ]]]
>
> [[[
> The request body of the POST need not be an Atom entry; for example, it
> might be a picture or a movie.
> ]]]
>
> These are not consistent. Replace the first with:
>
> """
> If a resource was created in the collection which received the POST, its
> URI MUST be returned in a HTTP Location header.
> """
>
-1. The wording may need some work, but the Location URI SHOULD point to
the created Atom Entry, regardless of what type of representation was
posted.
>
> [[[
> When the server generates a response with a status code of 201
> ("Created"), it SHOULD also return a response body, which MUST be an
> Atom Entry Document representing the newly-created resource. Clients
> MUST NOT assume that an Atom Entry returned is a complete representation
> of the member resource and SHOULD GET the member resource before editing.
> ]]]
>
> The last directive doesn't take caches or accelerators into
> consideration. I think this is a flaw, what say you?
>
How so? How should the flaw be resolved?
>
> [[[
> Note that the Entry created by the server may or may not exactly match
> the Entry POSTed by the client. In particular, a server MAY change the
> values of various elements in the Entry such as the atom:id,
> atom:updated and atom:author values and MAY choose to remove or add
> metadata elements.
> ]]]
>
> I'd like to point out that the only way to correlate a POSTed member
> with whatever the server creates is via the immediate response. What's
> the APP way of dealing with no response received and/or double posting?
>
No standard way of dealing with these issues. If a client does not
receive a response, the client should likely assume failure, putting the
burden on the server to detect and protect against duplicates. It is
conceivable that some form of nonce could be introduced as a pub:control
or request header.
>
> [[[
> 8.2 Example,
> 8.4.2 Example
> ]]]
>
> Any pace that claims to be clarifying this part of the spec needs to
> explain where "John Doe" materialized from. I've mentioned this at least
> once before, and indicated it's probably acquired in a stateful/out of
> protocol manner in the implementations that haven't been bitten by it.
> we have patched atom:title but not atom:author (or atom:summary for
> meeja resources). I'd like to see this point addressed.
>
The pace includes the start of such a description;
Implementors should note that, per the requirements of [RFC4287],
media link entries MUST contain an atom:summary element. Upon
successful creation of a media link entry, a server MAY choose to
populate the atom:summary element (as well as other required elements
such as atom:id, atom:author and atom:title) with content derived from
the POSTed media resource or from any other source. A server may or
may not allow a client to modify the server selected values for these
elements.
If this is not adequate, can you suggest alternative spec text that
would be?
>
> [[[
> 8.4.2 Example
> ]]]
>
> If a server has an app:accept with multipart/form-data and I send
> multipart/form-data (say a batch of fotes*) what can I expect the atom
> entry to look like?
>
> An Atom feed?
>
A POST to a collection, regardless of the media type of the payload,
would be expected to lead to the creation of exactly one Atom entry
representing one member of the collection. What that entry would look
like is dependent on the server implementation. The expectation is
likely that it would take the form of a media link entry.
Batches are likely best handled via POST to a separate URI specifically
purposed for processing batched operations over a collection.
> If yes, please note above point about correlation.
>
>
> (*yeah, I think we'll end up creating fotes in batch)
>
>
> [[[
> 7.2.4 The "app:accept" Element
> ]]]
>
> Why aren't accept-params or "q" parameters MUST NOT?
>
Is "the value syntax of app:accept ***does not use*** accept-params or
"q" parameters as specified" not adequate to make the point?
>
> [[[
> A value of "entry" indicates that Atom Entry Documents can be posted to
> the Collection.
> ]]]
>
> Is the atom+xml media type being excluded because it doesn't distinguish
> between entries and feeds?
>
Correct.
>
> [[[
> appAccept =
> element app:accept {
> appCommonAttributes,
> ( ( ("entry" | media-range) ',' )* )
> }
> ]]]
>
> xml:base/lang mean nothing here. Please replace with:
>
Good point.
> """
> appAccept =
> element app:accept {
> undefinedAttribute,
> ( ( ("entry" | media-range) ',' )* )
> }
> """
>
>
>
> Otherwise,the English needs deformalising, there are non-spec uses of
> keywords, minor inconsistencies here and there, but ok.
>
>
- James
