>> I also still don't understand why the response body, if provided,
>> "must" be an Atom Entry Document:
for the record,
I'm fine with "SHOULD" or even "RECOMMENDED" if some forks
think "MUST" is not good.
As long as "On successful creation, the response to the
POST request MUST return a Location: header with the URI of an Atom Entry
Document representing the newly created resource. " thing is there.
<hopeless wish>
However, could we change
"When the server generates a response with a status code of 201 ("Created"),
it MAY also return a response body"
to
"When the server generates a response with a status code of 201 ("Created"),
it is RECOMMENDED to return a response body"
</hopeless wish>
best
On 5/4/06, Bill de hÓra <[EMAIL PROTECTED]> wrote:
Tim Bray wrote:
>
> On May 3, 2006, at 3:55 PM, Thomas Broyer wrote:
>
>> I also still don't understand why the response body, if provided,
>> "must" be an Atom Entry Document:
>
> Bah, we discussed this a *lot* and I thought it was pretty clear the WG
> had consensus for an Atom entry or nothing. -Tim
I read what Mark Baker had to say about this and I'm inclined to agree
with him. It's short-sighted to assume Atom is all anyone will ever need.
On the other hand one reason to insist on Atom is that currently the
data format is fundamental to the workings of the protocol machine, cf
any required Atom field has to be supported. The media paces indicate we
are not doing that properly yet, as did past discussion around atom:id.
(I'm not beyond persuading that this dependency a design flaw)
Thus - I'm fine with SHOULD, *iff* someone can explain to me how a
SHOULD directive works sensibly with headers like Title or elements like
atom:id.
cheers
Bill
