On 24/03/2006, at 2:45 AM, Tim Bray wrote:
On Mar 23, 2006, at 1:46 AM, Toru Marumoto wrote:
Thank you for clarifying this for me.
Then I've got no choice but to always ignore the response body(of
PUT and POST)
since you aren't sure what format of the body would be returned.
The samples in the spec kind of confuse me.
Sounds to me like the spec needs tightening up here. At the *very
least* we should write in Toru's finding: "You can't count on what,
if anything, comes back". Should we consider asserting that
nothing comes back from an entry-creation POST? -Tim
+1 to spec tightening. This has been the single biggest issue with
the interop testing I've done so far.
I'm +0 to either of whether the body is empty or contains an atom
entry per James Snell's email.
The main point of confusion in the spec is the example in section 12.
Section 12 also raises ambiguity with regard to the Location header.
I'll repeat my email from 28th February below...
1. Body of 201 Response
The example in 12 is the first and only time that it is suggested an
entry document can be returned as the body of a 201 Created.
Neither 5.2 nor 8.1 mentions this.
We should explicitly say in 5.2 and 8.1 whether the inclusion of the
entry as the body is a MUST, SHOULD or MAY (could be different for
entry versus media collections)
2. Location in 201 Response
5.2 states that the Location header "contains the URI of the newly
created resource".
8.3.1 states that a media entry MUST have a content whose src
attribute contains "the IRI of the media resource itself"
8.3.2 states that the 'edit' link of the media entry "contains the
IRI of an Atom Entry document representing the metadata of the member
resource."
However, in the example in 12, the Location header has the same URI
as the 'edit' link rather than the content/@src
Is this just a mistake in the example?
James
--
James Tauber http://jtauber.com/
journeyman of some http://jtauber.com/blog/
