Hi James,
On Wed, Nov 10, 2010 at 3:56 PM, James Snell <[email protected]> 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 <[email protected]> wrote:
>>
>> Alistair Miles <[email protected]> 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 <[email protected]>
>> 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: [email protected]
>>> 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: [email protected]
Tel: +44 (0)1865 287669
