Re: computing atom:updated, was: change proposal for issue-86, was: ISSUE-86 - atom-id-stability - Chairs Solicit Proposals

On 16.04.2010 14:56, Julian Reschke wrote:
> When I went to the atom-syntax mailing list, people pointed out that
> there may be more problems with the algorithm (but did not provide any
> details).
>
> In the meantime, I realized that the computation of the atom:updated
> timestamp for *updated* entries (see
> <http://greenbytes.de/tech/webdav/rfc4287.html#rfc.section.4.2.15>)
> surprisingly depends on the presence of <ins>/<del> markup (see
> <http://dev.w3.org/html5/spec/interactive-elements.html#atom>, Step 15/13).
>
> There's nothing really *wrong* about that, but I think the specification
> needs to clarify that if you don't use <ins>/<del> (with timestamps) on
> an updated entry, the generated atom:updated will be incorrect.
> ...

...and furthermore, you can't assume that you have control over the 
styling of <ins> and <del> when displayed in a feed reader.

So, summarizing:

1) The spec is focused on describing the algorithm, not the patterns in 
the source document that are required. (I realize that this the way the 
spec is written, but I'll continue to point out it's sub-optimal for 
most readers).

2) The specific algorithm is based on finding certain HTML authoring 
patterns that can be mapped to feed formats, without having to invent 
any additional metadata (well, except the @pubdate attribute?). I agree 
it's an interesting thought experiment, but the example above shows that 
it's simply not sufficient; the semantics of atom:updated arent't 
adequately mapped: either authors will not realize what they have to do 
(including ins/del), or they'll be forced to include needless markup 
that will display weirdly in many feed consumers.

Proposal: get this issue resolved by removing this part, and *if* it 
stays in another spec then please encourage that the right people will 
review it, and their concerns get addressed.

Best regards, Julian

Received on Sunday, 18 April 2010 11:44:29 UTC