Bill de hOra wrote:
>
> James M Snell wrote:
>> Bill de hOra wrote:
>>> James M Snell wrote:
>>>
>>>> 1. deleted-entry is now part of the Atom namespace
>>> "The Atom namespace is reserved for future forward-compatible revisions
>>> of Atom." RFC4287, 6.2.
>>>
>>> The rfc-editor should have picked this up.
>>>
>>
>> Picked what up? The rfc-editor is not involved in the publishing of
>> I-D's. If this I-D is published as a Standards Track RFC, it would
>> specifically indicate that it is an update to RFC 4287 and would qualify
>> as a "forward-compatible revision of Atom". I believe that it's up to
>> the Area Director to determine whether or not to allow individual
>> submissions such as this to proceed along that route or whether a WG is
>> required.
>
> You seem to be assuming this won't get implemented before it gets to
> standards track. Until that time, I suggest you revert the namespace. Or
> make it clear that you intend to use this to create a forward compatible
> revision of Atom.
>
Until (and if) it gets to the standards track, the deleted-entry element
is no different than any other unknown extension element an application
may add to a feed; conformant implementations are required to ignore it
and validators will be right to point it out as a validation error.
I will update the draft to make it clearer that the intent is to update
RFC 4287.
>
>>>> 2. a "trash" link relation is registered to point
>>>> to trash feeds.
>>> Aside from what we talked about recently, the document only talks about
>>> deletion in the past tense; there's no deletion mechanism specified.
>>>
>>
>> There's no need to specify a deletion mechanism. A deleted-entry
>> element indicates that an entry has been removed from the feed and the
>> trash link relation points to a resource listing the entries that have
>> been removed. The mechanism used to remove those items is orthogonal to
>> both.
>
> Without a mechanism (for delete, sync, undelete, etc), how are we
> supposed to know whether this metadata is useful or well-designed
> outside whatever private application originally needed it? Or how it
> interacts with Atompub operations, or some other protocol? Or what
> happens when there are multiple trash feeds? Or further extended
> metadata? Or where 95% of comments are spam? Or how it interacts with
> DELETE/POST? Or whether it can be used for dead letter queuing?
>
> In other posts you've suggested you need something just like this, so
> let me suggest if you have a mechanism or a technical reason, at least
> document it as an example.
>
I may just be being a bit too obtuse here but I'm really not following
this at all. The tombstone is nothing more than a flag that indicates
that an entry has been removed from a feed. Why or how it has been
removed is inconsequential. The element identifies which entry was
removed and optionally specifies who removed it, when it was removed,
and provides the ability to specify a comment explaining the deletion.
If we're talking about an Atompub collection, whenever an item is
deleted, a tombstone may be added to the feed and/or the item may be
moved to a trash feed. I'm not sure what else there is to say about it.
I cannot imagine a case where a feed will have multiple trash feeds but
I cannot rule it out either. For now, it would likely be best to simply
leave that bit undefined until it actually becomes an issue.
The deleted-entry element is designed to be extensible so if additional
metadata is required, it can be easily added. The elements that are
there currently represent what my research has indicated to be a lowest
common denominator across applications.
There could be many ways tombstones are used. For instance, if a paged
feed as a high rate of deletions, rather than letting tombstones
accumulate ad infinitum, the implementation may decide to only list the
most recent deletions in the first ("current") page. Clients that only
periodically check the feed may miss a few tombstones now and then but
they're also just as likely to have missed the entry that had been deleted.
- James
> cheers
> Bill
>
>
