2010/5/20 Niklas Lindström <[email protected]>:
> On Thu, May 20, 2010 at 8:54 AM, Ed Summers <[email protected]> wrote:
>>
>> On Wed, May 19, 2010 at 10:58 PM, Bob Wyman <[email protected]> wrote:.
>>> I would strongly encourage you to ensure that deleted-entry is symmetrical
>>> with atom:entry and that it is available in all contexts (i.e. both within
>>> and without a Feed Document) that an Atom entry is. Just as we can have
>>> Entry Documents, we should be able to have Deleted-entry Documents.
>>
>> +1
>>
>> I could well imagine wanting to return a Tombstone as the message body
>> for a 403 Gone response for a resource that I know has been deleted.
>
> +1 from me as well.
>
Ok, looks like we've got quite a bit good support for standalone
docs.. I'll add that in.
> Apart from the use cases already mentioned (XMPP, 403
> representations), I see potential for using deleted-entry documents in
> our system (the swedish legal information system). I'm currently using
> entry documents internally in our "depot", both as manifests and to
> represent the collected source entries ("via" entries). Having
> deleted-entry documents there as well would be very beneficial.
>
> (In fact, this was a primary motive for my wish for allowing
> atom:source in at:deleted-entry elements. Which I'm very happy to see
> in the latest draft -- thanks James!)
>
No prob. Thanks for the great feedback and input.
> Two points come to mind if this is done:
>
> * What would the mime-type for deleted-entry documents be? A new
> "application/atom+xml;type=deleted-entry"?
Putting these under the application/atom+xml media type would likely
cause badness. I'm thinking something like
application/atomdeleted+xml.
> * For good measure, making sure that this doesn't lead to a pattern of
> PUT:ing deleted-entry docs instead of using DELETE... ;)
>
Yeah, this is a concern of mine also. Need to make sure people don't go there.
> Best regards,
> Niklas
>
--
- James Snell
http://www.snellspace.com
[email protected]
