Re: Tombstones and Link Extensions
Alistair Miles <alimanfoo@googlemail.com> Thu, 11 November 2010 12:30 UTC
Return-Path: <owner-atom-syntax@mail.imc.org>
X-Original-To: ietfarch-atompub-archive@core3.amsl.com
Delivered-To: ietfarch-atompub-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C9C23A68F2 for <ietfarch-atompub-archive@core3.amsl.com>; Thu, 11 Nov 2010 04:30:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.176
X-Spam-Level: **
X-Spam-Status: No, score=2.176 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_22=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_48=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsqDuF5IdIGW for <ietfarch-atompub-archive@core3.amsl.com>; Thu, 11 Nov 2010 04:30:04 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 6D7593A6899 for <atompub-archive@ietf.org>; Thu, 11 Nov 2010 04:30:01 -0800 (PST)
Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oABCOQPx009509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Nov 2010 05:24:27 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id oABCOQ7f009508; Thu, 11 Nov 2010 05:24:26 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail-qy0-f171.google.com (mail-qy0-f171.google.com [209.85.216.171]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oABCOPOB009500 for <atom-syntax@imc.org>; Thu, 11 Nov 2010 05:24:26 -0700 (MST) (envelope-from alimanfoo@googlemail.com)
Received: by qyk38 with SMTP id 38so4096213qyk.16 for <atom-syntax@imc.org>; Thu, 11 Nov 2010 04:24:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Ig8CagVeR4I3avSvg4RNasQ69IQPKqhb8eSlIyVpCqM=; b=BOnac0lrpxOQfTWcL15Pxm9sxgFDghplbG8XXCfw0RtZsCWRv8h8iVY9qGkE5pKNem N/ZlJbEGsU2llg5Ekz3JgGoZBtlM5uQyaBgMrKFOPsdqTu+wBATMiVpCyNPGLVW5yE8d fX+K/ZTM52M2zZGiKZvDWfg/F0J4bQzQ8QtDY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=UKH8U7qfdWQVHx7bvVtBAuiPE3n/iwFv6NkZ2vDsbUDqHXfN88Sps+21a8+ldk6hX4 BMmJiT4Agbz2UMu1bMDYw5/nTHDuC2SxgD8zJGDYSxrovjnQgFx371jZpDnSoi888DmA lO9o47/nCPNiz8l55NBvU8rbeDUWdqkvvnxsY=
MIME-Version: 1.0
Received: by 10.224.185.211 with SMTP id cp19mr813169qab.323.1289478263542; Thu, 11 Nov 2010 04:24:23 -0800 (PST)
Received: by 10.220.169.8 with HTTP; Thu, 11 Nov 2010 04:24:23 -0800 (PST)
In-Reply-To: <AANLkTinkccbxBNc4b+-4xD67jZOJfkxKCgFEi_Q5OM+v@mail.gmail.com>
References: <AANLkTikwt6o9U0oye0H9jku4O62Ue7sJSV1HrOgz5FGB@mail.gmail.com> <20101110113537.GB4316@aliman-desktop> <AANLkTin4d+wthGrzdmqDvwx-9ub+LPsnR1yMNsQJYEYY@mail.gmail.com> <AANLkTinkccbxBNc4b+-4xD67jZOJfkxKCgFEi_Q5OM+v@mail.gmail.com>
Date: Thu, 11 Nov 2010 12:24:23 +0000
Message-ID: <AANLkTi=-WONFNaqkZi+9gtsw0pZT-5h4La+E4X2e3VbS@mail.gmail.com>
Subject: Re: Tombstones and Link Extensions
From: Alistair Miles <alimanfoo@googlemail.com>
To: James Snell <jasnell@gmail.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id oABCOQOB009504
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Hi James, On Wed, Nov 10, 2010 at 3:56 PM, James Snell <jasnell@gmail.com> wrote: > Ok I was getting ready to say that the definition of deleted-entry already > allows for it but I went back to double check and it's a good thing I did. I > notice that it says "extensionElement*" instead of "anyElement*". In > rfc4287, extensionElement explicitly omits atom:* elements. I will change > that to anyElement so that additional atom:* metadata elements can be > included. I don't know relaxng very well, but I'm wondering if rather than using anyElement you want to do something like atExtensionElement analogous to the definition of extensionElement in RFC4287, e.g.,: atSimpleExtensionElement = element * - at:* { text } # Structured Extension atStructuredExtensionElement = element * - at:* { (attribute * { text }+, (text|anyElement)*) | (attribute * { text }*, (text?, anyElement+, (text|anyElement)*)) } # Other Extensibility atExtensionElement = atSimpleExtensionElement | atStructuredExtensionElement ...i.e., be explicit about not allowing extensions within the at: namespace. Cheers Alistair > > On Wed, Nov 10, 2010 at 7:53 AM, Bob Wyman <bob@wyman.us> wrote: >> >> Alistair Miles <alimanfoo@googlemail.com> wrote: >> > we have a need to include some metadata elements >> > from the original atom entry within the deleted entry >> +1 >> In a variety of content-based message routing applications it is actually >> very important that the record of a deletion carry with it as much as >> possible of the data which is being deleted. The reason is that >> content-based streaming systems do message routing based on the content of >> an entry rather than simply on its source elements. (They implement "Track" >> not just "Follow.") For such a system to be able to route a deletion to a >> destination that might have previously received the item being deleted, one >> of two approaches must be used: >> >> The simplest approach is to include in the deleted entry the same content >> that would have been used to route the entry prior to its deletion. This >> makes it possible to simply route deleted-entries by using the same code as >> is used for routing normal entries. >> A more complex and robust method requires that the router maintains a >> persistent record of all routing decisions, keyed by atom:id. Deleted >> entries are then routed based on this record of previous routing decisions. >> This can be, however, excessively expensive in some contexts. If using this >> approach, one must also deal with issues such as the maximum age of useful >> routing data. (When, if ever, can you delete routing logs?) >> >> The second method (i.e. recording all routing decisions) is probably the >> most robust since it can also be used to handle cases of updates to entries >> which produce a new entry instance that would have not been routed in the >> same way as the original. However, it should be noted that few systems >> implement such complexity. >> Given the considerations above, I would support (as I have in the past) >> the suggestion that deleted entries be permitted to optionally carry much if >> not all of the same content as the entries which are being deleted. It >> should probably be made clear somewhere, that developers SHOULD NOT expect >> that all publishers of deleted entries will, in fact, include this content. >> Developers should only build code that relies on content-full >> deleted-entries in cases where application profiles extending the base >> specification assure that such content is provided. But, note that while >> carrying this content should be optional, it isn't possible unless >> permitted. >> I support the optional provision of additional content in the deleted >> entries. >> bob wyman >> On Wed, Nov 10, 2010 at 6:35 AM, Alistair Miles <alimanfoo@googlemail.com> >> wrote: >>> >>> Hi James, >>> >>> On Tue, Nov 09, 2010 at 12:48:04PM -0800, James Snell wrote: >>> > Ok, so the Atom Tombstones [1] draft, at this point, is definitely >>> > complete. >>> > I decided to wait a while before advancing it to see if any further >>> > comments >>> > would come in. I know there are some implementations already and no >>> > major >>> > issues have come up so I'm ready to push that forward to get an RFC # >>> > for >>> > it. >>> >>> In [1] I mentioned that we have a need to include some metadata elements >>> from >>> the original atom entry within the deleted entry, in particular >>> atom:title, >>> atom:author and atom:publised, but that this is prohibited by the content >>> model for the at:deleted-entry element, so we invented an extension >>> element >>> in our own namespace for this (see [2]). >>> >>> If no-one else has this requirement then fine, but I would have thought >>> there >>> would be quite a few situations where an application would want to >>> present >>> a list of deleted entries to a user and show more than just @ref @when >>> and >>> at:by - pretty much every situation in which a person wants to look at a >>> list of deleted entries. >>> >>> I would much rather avoid a custom extension element and instead make the >>> content-model for at:deleted-entry more permissive, e.g.: >>> >>> deletedEntry = element at:deleted-entry { >>> atomCommonAttributes, >>> attribute ref { atomUri }, >>> attribute when { atomDateConstruct }, >>> ( element at:by { atomPersonConstruct }? >>> & element at:comment { atomTextConstruct }? >>> & atomAuthor* >>> & atomCategory* >>> & atomContent? >>> & atomContributor* >>> & atomId? >>> & atomLink* >>> & atomPublished? >>> & atomRights? >>> & atomSource? >>> & atomSummary? >>> & atomTitle? >>> & extensionElement*) >>> } >>> >>> An implementation would then be free to include as little or as many of >>> these >>> additional elements within a deleted entry as required. A client >>> consuming >>> a feed with deleted entries could choose to render this information if >>> present. >>> >>> Again, if no-one else sees this as an issue then fine, but I do think >>> there >>> is a potential interoperability issue here that should be at least >>> commented >>> on prior to RFC. >>> >>> Apologies if I've missed anything relevant in previous discussions. >>> >>> Cheers >>> >>> Alistair >>> >>> [1] http://www.imc.org/atom-syntax/mail-archive/msg21574.html >>> [2] >>> http://code.google.com/p/atombeat/wiki/TombstonesDesign#Configuring_Ghosts >>> >>> -- >>> Alistair Miles >>> Head of Epidemiological Informatics >>> Centre for Genomics and Global Health <http://cggh.org> >>> The Wellcome Trust Centre for Human Genetics >>> Roosevelt Drive >>> Oxford >>> OX3 7BN >>> United Kingdom >>> Web: http://purl.org/net/aliman >>> Email: alimanfoo@gmail.com >>> Tel: +44 (0)1865 287669 >>> >> > > -- -- Alistair Miles Head of Epidemiological Informatics Centre for Genomics and Global Health <http://cggh.org> The Wellcome Trust Centre for Human Genetics Roosevelt Drive Oxford OX3 7BN United Kingdom Web: http://purl.org/net/aliman Email: alimanfoo@gmail.com Tel: +44 (0)1865 287669
- Tombstones and Link Extensions James Snell
- Re: Tombstones and Link Extensions Alistair Miles
- Re: Tombstones and Link Extensions Bob Wyman
- Re: Tombstones and Link Extensions James Snell
- Re: Tombstones and Link Extensions Alistair Miles