On Jun 1, 2006, at 3:42 PM, Bill de hÓra wrote:
[[[
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.
"""
I agree that "HTTP Location" is better than "Location HTTP", but I
don't see the inconsistency.
[[[
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?
I would be totally friendly to an amendment to remove "and the SHOULD
GET" clause. I think that while harmless, it will be widely ignored
by client authors in special circumstances that know what they're doing.
[[[
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?
Out of scope, but I think it would be valuable to point out that
implementors need to know that these things can occur.
[[[
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.
Agreed.
[[[
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?
If yes, please note above point about correlation.
(*yeah, I think we'll end up creating fotes in batch)
What are fotes? I think the issue is out of scope; I can think of a
dozen other pathological media-types that you could send, and if you
do it, you deserve whatever happens to you.
[[[
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?
Exactly, and I had been meaning to elucidate that in the draft.
Should be done.
[[[
appAccept =
element app:accept {
appCommonAttributes,
( ( ("entry" | media-range) ',' )* )
}
]]]
xml:base/lang mean nothing here. Please replace with:
"""
appAccept =
element app:accept {
undefinedAttribute,
( ( ("entry" | media-range) ',' )* )
}
"""
Agreed. -Tim
