Subject: Re: Tombstones

From: Bill de hOra <[email-masked]>
Date: Tue, 01 Jan 2008 14:09:44 +0000

James M Snell wrote:

> Soft-delete is a special case.  

Soft delete is a move operation, it's not that special. What's special 
is the need to be able to move it back, like an OS trashcan. So when I 
see things like rel="trash", I suspect there's a use-case specific 
modelling problem stopping a general purpose solution getting out.

> With this, entries are moved to a trash
> collection.  We need a way of indicating that the entry has been removed
> from it's original feed, while at the same time indicating it's new
> location in the trash feed, e.g., something along the lines of:
> 
>   <x:deleted>
>     <id>tag:example.org,2007:foo</id>
>     <link rel="trash"
>           type="application/atom+xml"
>           href="/trash/foo" />
>   </x:deleted>
> 
> Entries in the trash collection can be undeleted or purged.  If they are
> undeleted, they go back to the original feed and are removed from the
> trash.  If they are purged, all of the metadata, save the id and perhaps
> a timestamp, will be removed from the database.

I can see why you need a way to indicate where the trashed entry should 
go back to, but not where it went to /from/ the original feed. If you 
really need that, I suggest you need to generalise it to a moved-from 
marker. In that case,  don't bake the notion of "trash" or "delete" into 
a design for soft delete - it's a move op. I have other concerns,

  - about this kind of metadata becoming accumulated cruft, that 
requires extra tooling to clean up.

  - mixing up the state and housing of an entry with its type (a 
tombstone is a thing, but the person underneath it is surely dead).

>> 7) one way (master-replica) full and incremental sync.
> 
> This is a significant use case for us.  We must have a reliable and
> performant one-way sync model that can support full and incremental
> operation.  By incremental I mean we need to have the ability to request
> a feed listing only changes that have occurred since the previous sync
> operation.

We've been here before. You can't do this without a timestamp (or some 
temporal ordering) that everyone agrees on (where 'everyone' is all the 
clients using the server).

cheers
Bill

---

From: Bill de hOra <[email-masked]>
Date: Tue, 01 Jan 2008 14:33:45 +0000

James M Snell wrote:

> That said, what is the value of reusing atom:entry in this case?
> 
> Why is this...
> 
> <entry>
>   <id>tag:example.org,2007:/the/only/useful/thing/here</id>
>   <updated>2007-12-12T12:12:12Z</updated>
>   <title>useless</title>
>   <author><name>useless</name></author>
>   <summary>useless</summary>
> </entry>
> 
> Better than this:
> 
> <x:deleted>
>   <id>tag:example.org,2007:/the/only/useful/thing/here</id>
>   <updated>2007-12-12T12:12:12Z</updated>
> </x:deleted>
> 
> Or even just this:
> 
> <x:deleted>
>   <id>tag:example.org,2007:/the/only/useful/thing/here</id>
> </x:deleted>

Two things:

1: what you deleted was an entry.

2: you might want to know the properties of the entry that was deleted, 
not just its name.

cheers
Bill

---

From: Bill de hOra <[email-masked]>
Date: Tue, 01 Jan 2008 14:38:44 +0000

Brian Smith wrote:

> How do you suggest dealing with inappropriate data in the atom:id
> element? Examples:
> 
>  <x:deleted
> id='http://example.org/blog/i-am-so-high-at-work-right-now'/>
>  <x:deleted
> id='http://example.org/blog/im-getting-divorced-and-marrying-my-secretar
> y'/>
>  <x:deleted id='http://engizmet.org/{embargoed-iphone-news-item}'/>
> 
> (I've seen very similar entries posted and then deleted from actual
> feeds.)
> 
> This still discloses a significant amount of information that the feed
> author doesn't want disclosed after deleting the entry, and this kind of
> disclosure is something that a non-technical blogger would not expect.

Unfortunately, this makes it seem that decentralization and caching are 
bugs, not features.

cheers
Bill

---

From: James M Snell <[email-masked]>
Date: Tue, 01 Jan 2008 09:46:47 -0800

Bill de hOra wrote:
>> [snip]

Ok, but why does that mean we have to use atom:entry to represent the
thing that no longer exists?

> 2: you might want to know the properties of the entry that was deleted,

There's no reason this data could not be added as children of the
x:deleted element.  Keep in mind that atom:entry has minimum content
requirements so you'd either have to keep around a minimum amount of
metadata or start passing around useless cruft.

- James

---

From: Bill de hOra <[email-masked]>
Date: Tue, 01 Jan 2008 20:00:01 +0000

> thing that no longer exists?

Because as I said, the thing was an Entry. But we're moving the 
discussion about a bit. If we're talking about hard delete, all you need 
is 410 gone, no markup needed. For soft deletes (or audit, or history, 
or compliance, or who knows), why not represent the deleted Entry with 
an Entry? It seems the most natural thing.

> metadata or start passing around useless cruft.

It's still cruft.

Apologies tho'; I know I came to this thread late, but I'm not seeing 
the reason to introduce a new type (aka 'tombstone'), insofar as adding 
a new type is a big deal.

cheers
Bill

---

From: James M Snell <[email-masked]>
Date: Tue, 01 Jan 2008 12:15:10 -0800

I think I've covered the reasons why I think atom:entry is inappropriate
well enough that there's no reason to go back into it.  If you haven't
yet had the time to go back through the thread (which would be
understandable since it's a pretty long thread), I would encourage you
to go back and read the points I've made thus far.

- James

---

From: Aristotle Pagaltzis <[email-masked]>
Date: Tue, 1 Jan 2008 21:24:48 +0100

* Bill de hOra <[email-masked]> [2008-01-01 21:10]:
> If we're talking about hard delete, all you need is 410 gone,
> no markup needed.

Eh? How is a feed reader supposed to know that an Entry (which
might not even have had a permalink) was deleted from a feed vs
just fell off the bottom?

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: Bill de hOra <[email-masked]>
Date: Tue, 01 Jan 2008 22:40:31 +0000

> just fell off the bottom?

1: If it doesn't have a permalink (or a link at all), it's not on the 
web; in all seriousness, why do we care about it?

2: why does it matter, the difference between falling off the bottom and 
being deleted?

cheers
Bill

---

From: Bill de hOra <[email-masked]>
Date: Tue, 01 Jan 2008 23:31:42 +0000

> to go back and read the points I've made thus far.

I already went through the thread.

cheers
Bill

---

From: Aristotle Pagaltzis <[email-masked]>
Date: Wed, 2 Jan 2008 00:54:16 +0100

* Bill de hOra <[email-masked]> [2008-01-01 23:55]:
> 1: If it doesn't have a permalink (or a link at all), it's not
> on the web; in all seriousness, why do we care about it?

Doesn’t matter. I preemptively pointed that out just to say that
even if you wanted to propose that feed readers poll every
permalink on every feed poll (), that wouldn’t even work.

> 2: why does it matter, the difference between falling off the
> bottom and being deleted?

’Cause the original use case here is comments feed and comment
spam that slipped through.

And that reminds that 401 is further useless, because the
permalink of such Entries is distinguished from the blog post
permalink only through a fragment identifier, so they have no
public identity in HTTP separate from the blog post itself.

Sorry, 401 doesn’t cut it. Communicating deletion requires the
Atom ID, not the permalink, and a timestamp, and that’s all that
should be required, which disqualifies the use of atom:entry as
the vehicle.

Regards,

---

From: James M Snell <[email-masked]>
Date: Tue, 01 Jan 2008 16:45:28 -0800

> web; in all seriousness, why do we care about it?

Whether the thing has a permalink or not is irrelevant.  We're talking
about having a mechanism of indicating when an entry is no longer part
of a collection or a feed.  It could be that the entry still exists in
some form or other somewhere else, but how do I know that the thing is
no longer part of a specific feed?

> 2: why does it matter, the difference between falling off the bottom and

Define "falling off".  If the feed is paged, does "falling off" mean
we'll find the entry on the next or previous page?  What if the feed
only shows the 100 most recent items?  What should I do with my local
copy of the entry if suddenly the entry no longer appears in the feed?

There is a significant difference between falling off and being deleted.

- James

---

From: Aristotle Pagaltzis <[email-masked]>
Date: Wed, 2 Jan 2008 01:48:07 +0100

Err, I missed two bits while writing:

* Aristotle Pagaltzis <[email-masked]> [2008-01-02 01:05]:
> Doesn’t matter. I preemptively pointed that out just to say
> that even if you wanted to propose that feed readers poll every
                               ^ (obviously absurd)

> permalink of such Entries is distinguished from the blog post
                              ^ commonly
> Atom ID, not the permalink, and a timestamp, and that’s all
> that should be required, which disqualifies the use of
> atom:entry as the vehicle.

Regards,

---

From: Bill de hOra <[email-masked]>
Date: Wed, 02 Jan 2008 01:33:36 +0000

> spam that slipped through.

That honestly doesn't explain it. The comment was in the feed, then it 
was not. Why do you need to say why it's not there anymore?

> public identity in HTTP separate from the blog post itself.

Right, there is a lot of stupid blog code about.

> should be required, which disqualifies the use of atom:entry as

"disqualifies"  - sorry, I'm not convinced.

cheers
Bill

---

From: Bill de hOra <[email-masked]>
Date: Wed, 02 Jan 2008 01:36:17 +0000

> no longer part of a specific feed?

It's not in the feed anymore - but first perhaps define "feed".

> There is a significant difference between falling off and being deleted.

I didn't say there wasn't, I asked it be explained why the difference 
matters in this case, to the extent we need a new type and new markup.

cheers
Bill

---

From: Peter Keane <[email-masked]>
Date: Tue, 1 Jan 2008 20:52:37 -0600 (CST)

Re: tombstones, I'll just throw in a mention if the OAI-ORE work (Open 
Archives Initiative Object Reuse and Exchange - 
http://www.openarchives.org/ore/0.1/atom-implementation) which figures to 
be very important in archiving/preservation, etc. and serializes a 
"Resource Map" (named graphs that represent aggregations of Web Resources) 
and serializes them using Atom.

The issue of tombstones will be big and the previous discussion around 
"soft-deletes" (deletions that can be resurrected or perhaps used in 
various client-determined ways) will be a significant use case.  I feel 
like Joe Gregorio's suggestion of two feeds
  (http://www.mail-archive.com/[email-masked]/msg01092.html) feels 
like the best solution for this case. (since those deletes really ARE of 
type atom:entry -- a new type does not smell quite right).

And why can't atom:category be used to indicate that an entry has been 
deleted?  (In fact, perhaps a few different categories for the different 
kinds of "deleted").

-peter keane

> I didn't say there wasn't, I asked it be explained why the difference matters 
> in this case, to the extent we need a new type and new markup.
>
> cheers
> Bill
>

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 2 Jan 2008 15:57:50 +1100

I still don't understand the pushback that people have against a new  
feed-level element not "smelling right." Atom explicitly allows  
extensions there.

Cheers,

On 02/01/2008, at 1:52 PM, Peter Keane wrote:

>
> Re: tombstones, I'll just throw in a mention if the OAI-ORE work  
> (Open Archives Initiative Object Reuse and Exchange - http://www.openarchives.org/ore/0.1/atom-implementation) 
>  which figures to be very important in archiving/preservation, etc.  
> and serializes a "Resource Map" (named graphs that represent  
> aggregations of Web Resources) and serializes them using Atom.
>
> The issue of tombstones will be big and the previous discussion  
> around "soft-deletes" (deletions that can be resurrected or perhaps  
> used in various client-determined ways) will be a significant use  
> case.  I feel like Joe Gregorio's suggestion of two feeds
> (http://www.mail-archive.com/[email-masked]/msg01092.html)  
> feels like the best solution for this case. (since those deletes  
> really ARE of type atom:entry -- a new type does not smell quite  
> right).
>
> And why can't atom:category be used to indicate that an entry has  
> been deleted?  (In fact, perhaps a few different categories for the  
> different kinds of "deleted").
>
> -peter keane
>
>>
>> James M Snell wrote:
>>> Bill de hOra wrote:
>>>> [snip]
>>>> bottom and
>> I didn't say there wasn't, I asked it be explained why the  
>> difference matters in this case, to the extent we need a new type  
>> and new markup.
>>
>> cheers
>> Bill
>>
>

--
Mark Nottingham     http://www.mnot.net/

---

From: James M Snell <[email-masked]>
Date: Tue, 01 Jan 2008 21:41:07 -0800

+1.  I've asked several times why using atom:entry would be better than
x:deleted and I have yet to see a clear, coherent argument.

- James

Mark Nottingham wrote:
>> http://www.openarchives.org/ore/0.1/atom-implementation) which figures
>> to be very important in archiving/preservation, etc. and serializes a
>> "Resource Map" (named graphs that represent aggregations of Web
>> Resources) and serializes them using Atom.
>>
>> various client-determined ways) will be a significant use case.  I
>> feel like Joe Gregorio's suggestion of two feeds
>> like the best solution for this case. (since those deletes really ARE
>> of type atom:entry -- a new type does not smell quite right).
>>
>> deleted?  (In fact, perhaps a few different categories for the

---

From: Peter Keane <[email-masked]>
Date: Wed, 2 Jan 2008 00:37:27 -0600 (CST)

I'll certainly defer to the judgement to folks who have a better 
understanding of the nuances of Atom, but my perspective is that of a 
librarian/programmer interesting in Atom in the broadest and most 
non-blogging-oriented domains (as an aside I think the strength of the 
spec comes from a set of well-understood uses cases in a particular domain 
-- I just want to see how effective it might be outside of that domain).

Feed-level elements are of two types: metadata about the feed, and items 
in a "set" of things.  Throwing a new type in the mix is really a huge 
change -- if it's about the feed, OK (but clearly a tombstone is an entity 
of it's own and not metadata about the feed), otherwise you are creating a 
second "set" and there goes the beauty of Atom (and up goes the cognitive 
load -- at least at the conceptual level).  Perhaps it comes down to: are 
tombstones a significant resource (I say yes)? And if so, they need to 
have a URI.  Also, a new type seems to create a tighter coupling with the 
client than is ideal -- why must I (the client or client implementor) need 
to think about a new type? I'd much prefer an atom:category element that 
flagged an entry as "deleted" with an expectation that it'd hang around 
for some period of time (soft-delete) and at some indeterminate point fall 
off the feed (hard-deleted) if/when the feed publisher so chooses.  It 
just seems more natural to deal with a deleted entry like that -- a new 
type seems to me to presuppose an understanding of the possible use cases 
which is simply impossible at this point.

--peter keane

---

From: Peter Keane <[email-masked]>
Date: Wed, 2 Jan 2008 00:57:28 -0600 (CST)

Also, FWIW, here's an excerpt from the OAI-PMH (protocal for metadata 
harvesting):

http://www.openarchives.org/OAI/openarchivesprotocol.html#DeletedRecords

(This is a different protocol than the one I mentioned earlier -- OAI-ORE 
-- and is widely implemented).  Perhaps there is some useful wisdom here:

2.5.1 Deleted records

If a record is no longer available then it is said to be deleted. 
Repositories must declare one of three levels of support for deleted 
records in the deletedRecord element of the Identify response:

     * no - the repository does not maintain information about deletions. A 
repository that indicates this level of support must not reveal a deleted 
status in any response.
     * persistent - the repository maintains information about deletions 
with no time limit. A repository that indicates this level of support must 
persistently keep track of the full history of deletions and consistently 
reveal the status of a deleted record over time.
     * transient - the repository does not guarantee that a list of 
deletions is maintained persistently or consistently. A repository that 
indicates this level of support may reveal a deleted status for records.

If a repository does not keep track of deletions then such records will 
simply vanish from responses and there will be no way for a harvester to 
discover deletions through continued incremental harvesting. If a 
repository does keep track of deletions then the datestamp of the deleted 
record must be the date and time that it was deleted. Responses to 
GetRecord request for a deleted record must then include a header with the 
attribute status="deleted", and must not include metadata or about parts. 
Similarly, responses to selective harvesting requests with set membership 
and date range criteria that include deleted records must include the 
headers of these records. Incremental harvesting will thus discover 
deletions from repositories that keep track of them.

Deleted status is a property of individual records. Like a normal record, 
a deleted record is identified by a unique identifier, a metadataPrefix 
and a datestamp. Other records, with different metadataPrefix but the same 
unique identifier, may remain available for the item.

--peter keane

---

From: James M Snell <[email-masked]>
Date: Wed, 02 Jan 2008 17:28:23 -0800

Peter Keane wrote:
> change -- if it's about the feed, OK (but clearly a tombstone is an

I disagree. Feeds already contain several sets of things... entries,
authors, contributors, links, and categories.  Adding a new set of
things is not a "huge" change by any stretch of the imagination.

> entity of it's own and not metadata about the feed), otherwise you are
> creating a second "set" and there goes the beauty of Atom (and up goes
> the cognitive load -- at least at the conceptual level).  Perhaps it
> comes down to: are tombstones a significant resource (I say yes)? And if

Tombstones are not resources.  An entry in a trash folder may be a
resource, but a tombstone is just a flag that indicates that a
particular entry is no longer part of a logical collection.

> so, they need to have a URI.  Also, a new type seems to create a tighter
> coupling with the client than is ideal -- why must I (the client or
> client implementor) need to think about a new type? I'd much prefer an
> atom:category element that flagged an entry as "deleted" with an
> expectation that it'd hang around for some period of time (soft-delete)
> and at some indeterminate point fall off the feed (hard-deleted) if/when
> the feed publisher so chooses.  It just seems more natural to deal with
> a deleted entry like that -- a new type seems to me to presuppose an
> understanding of the possible use cases which is simply impossible at
> this point.
> 

The key challenge with these kinds of views is that there are existing
applications and use cases out there that simply do not share this point
of view.

- James

---

From: Peter Keane <[email-masked]>
Date: Wed, 2 Jan 2008 20:34:24 -0600 (CST)

> things is not a "huge" change by any stretch of the imagination.

But those are all clearly "metadata about the feed" i.e. they have a 
well-defined relationship with the feed.  Same with entries -- the 
conceptual model (although not spelled out in the spec) is easy to grok. 
Being able to abstract out a conceptual model is *really* important and 
it's what makes Atom so useful.  What sort of things are these tombstones? 
Well, their most obvious relationship is to an entry not the feed itself. 
How would I extend one of these tombstones in a similar but 
not-exactly-the-original-purpose way?  Atom is an elegant set of 
*interfaces* and here are these *implementation details* (tombstones) 
smack dab in the middle.

Also, what sort of slippery slope is this?  Will this be the start of more 
bags of stuff being added to a feed?  Right now a feed has a 1:1 
relationship with it's set of contained items.  Suddenly that's 1:2 
(entries and tombstones) which effectively means 1:n.  Note I still 
contend that metadata about the feed itself is a different sort of beast.

> applications and use cases out there that simply do not share this point

I would highly recommend that you take a look at the Open Archives 
Initiative Protocol for Metadata Harvesting because Atom shows great 
promise as newer/simpler protocol for the exact same purpose (to the 
extent that OAI-ORE could replace or at least extend OAI-PMH, it's a done 
deal since OAI-ORE is expressed in Atom).  This is THE widely implemented 
standard in the archives area and work on issues like tombstones and feed 
archives with Atom really requires (it seems to me) that folks understand 
how this is being done right now -- OAI-PMH is a truly impressive piece of 
work and has proven incredibly useful.

--peter

---

From: "Brian Smith" <[email-masked]>
Date: Sun, 6 Jan 2008 13:23:54 -0800

Peter Keane wrote:
> James Snell wrote:
> > I disagree. Feeds already contain several sets of things... 
> > entries, authors, contributors, links, and categories. Adding a
> > new set of things is not a "huge" change by any stretch of
> > the imagination.
> 
> But those are all clearly "metadata about the feed" i.e. they 
> have a well-defined relationship with the feed.  Same with 
> entries -- the conceptual model (although not spelled out in 
> the spec) is easy to grok. 
> Being able to abstract out a conceptual model is *really* 
> important and it's what makes Atom so useful.  What sort of 
> things are these tombstones? 

What practical implications does this have? This is just a distinction
without a difference.

The specification says:
   
   Child elements of atom:entry, atom:feed,
   atom:source, and Person constructs are considered Metadata elements
   and are described below.  Child elements of Person constructs are
   considered to apply to the construct.  The role of other foreign
   markup is undefined by this specification.

There is no "about the feed" there.

> *interfaces* and here are these *implementation details* 
> (tombstones) smack dab in the middle.
> 
> Also, what sort of slippery slope is this?  Will this be the 
> start of more bags of stuff being added to a feed?

Sure, why not?

- Brian

---

From: "David Powell" <[email-masked]>
Date: Sun, 6 Jan 2008 22:46:56 -0000

> What practical implications does this have? This is just a distinction

No.  What a metadata element is "about" has no direct implications on
implementations, but the implied life-cycle of the metadata and entities
involved (entry and feed) do.

Say you poll a feed URI twice, you might get back entry 1,2,3 in the first
poll, and entry 2,3,4 in the second poll.  Stateful Atom implementations
will need to store entries that aren't in the most recent polling of the
feed URI.  This requires entry and feed state to be decoupled.  A good
example is Microsoft's Feed Platform, which downloads feeds, and presents
them to client applications via an API that allows the entries of a feed
(including metadata elements) to be accessed as XML structures.

If you start putting entry metadata elements at <feed> level this simply
won't work.  Perhaps Windows Feed Platform is faulty for not anticipating
James's latest proposal, but I don't think so.  

> There is no "about the feed" there.

No there isn't, and practically anything is syntactically valid according to
the spec.  But, I'm not replying to these posts to save people from reading
the spec, but to highlight the harmful effects of these extensions.  I
believe that violating the separation between entry and feed metadata breaks
a large and useful category of applications and that approving such
behaviour would be extremely damaging to the Atom community.

The feed abstraction for Atom and RSS is one of a feed+metadata and a stream
of entries+metadata - this has been the case for the last 10 years, and it
isn't going to change now.  The model is not, as would be required if were
to mix entry and feed metadata, a feed+metadata and a stream of
entries+metadata + associations with every feed document that that entry has
ever been part of just in case there is some sort of misplaced entry
metadata hidden at feed level, so that clients looking at an entry can
manually reimplement the sliding window mechanism for tombstones or
whatever.  Urgh.

-- 
Dave

---

From: "Brian Smith" <[email-masked]>
Date: Sun, 6 Jan 2008 17:20:12 -0800

David Powell wrote:
> > What practical implications does this have? This is just a 
> distinction without a difference.
> 
> If you start putting entry metadata elements at <feed> level 
> this simply won't work.  Perhaps Windows Feed Platform is 
> faulty for not anticipating James's latest proposal, but I 
> don't think so.  

If Windows Feed Platform ignores the tombstones it will be working just
as James intended. If Windows Feed Platform chokes on the tombstones
then it isn't compliant with the atom specification.

> No there isn't, and practically anything is syntactically 
> valid according to the spec.  But, I'm not replying to these 
> posts to save people from reading the spec, but to highlight 
> the harmful effects of these extensions.  I believe that 
> violating the separation between entry and feed metadata 
> breaks a large and useful category of applications and that 
> approving such behaviour would be extremely damaging to the 
> Atom community.

Could you please give an example of such harm. The rationale for James's
design is that it is the least harmful of all the alternatives,
especially the FeedSync design.

> The feed abstraction for Atom and RSS is one of a 
> feed+metadata and a stream of entries+metadata - this has 
> been the case for the last 10 years, and it isn't going to 
> change now.  The model is not, as would be required if were 
> entries+metadata + associations with every feed document that 
> that entry 
> entries+has
> ever been part of just in case there is some sort of 
> misplaced entry metadata hidden at feed level, so that 
> clients looking at an entry can manually reimplement the 
> sliding window mechanism for tombstones or whatever.  Urgh.

Implementations are free to ignore the tombstones and have the exact
same behavior that they have now. That is the primary benefit of this
design over the FeedSync one.

- Brian

---

From: Peter Keane <[email-masked]>
Date: Sun, 6 Jan 2008 17:31:23 -0600 (CST)

> behaviour would be extremely damaging to the Atom community.

Agreed 100%.

> isn't going to change now.  The model is not, as would be required if were

Yes -- it's that easy to grok abstraction that makes Atom (and RSS) 
"work".

--peter keane

---

From: Peter Keane <[email-masked]>
Date: Sun, 6 Jan 2008 17:44:55 -0600 (CST)

On Sun, 6 Jan 2008, Brian Smith wrote:
[snip]
> especially the FeedSync design.

Because the "feed abstraction" is that much more complicated.  Why is a 
bit of metadata as a child of an "entry" element a non-starter? 
"deleted","moved", etc. are just attributes of an entry (and 
there IS a category element available...).  Obviously I don't believe that 
a tomstone is anything but another kind (or state) of (an) entry.

> design over the FeedSync one.

Yes, and then what sort of extension will be proposed for the folks who 
want a "deleted" feature, but need/want to keep the deleted entry AS an 
entry.

--peter

---

From: "Brian Smith" <[email-masked]>
Date: Sun, 6 Jan 2008 18:01:59 -0800

Peter Keane wrote:
> > Could you please give an example of such harm. The rationale for 
> > James's design is that it is the least harmful of all the 
> > alternatives, especially the FeedSync design.
> >
> 
> Because the "feed abstraction" is that much more complicated. 

I disagree that it is a significant complication, and even if it was, I
fail to see the actual harm caused.

> Why is a bit of metadata as a child of an "entry" element a 
> non-starter? 

James and I have explained this in this thread multiple times. If you
disagree with our reasoning, that is fine, but let's not keep running in
circles. 

> > Implementations are free to ignore the tombstones and have 
> > the exact same behavior that they have now. That is the primary 
> > benefit of this design over the FeedSync one.
> 
> Yes, and then what sort of extension will be proposed for the 
> folks who want a "deleted" feature, but need/want to keep the 
> deleted entry AS an entry.

I suggest using FeedSync, if that is what you want. It has a lot of nice
features besides tombstones.

- Brian

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 7 Jan 2008 11:11:48 +1100

I'm having trouble seeing how this is relevant at all. If an  
implementation doesn't implement tombstones, they'll ignore them. If  
it chokes on them because they don't recognise them, or treat them as  
if they're entries, that implementation is broken as per section six,  
where all of this is very explicitly laid out. What's the problem?