Subject: Re: More on atom:id handling

From: Thomas Broyer <[email-masked]>
Date: Wed, 1 Feb 2006 16:20:23 +0100

[CC'ing atom-syntax]

2006/2/1, David Powell <[email-masked]>:
>
> Wednesday, February 1, 2006, 6:21:12 AM, James M Snell wrote:
>
> > Entries in an Atom feed can share the same atom:id but their
> > atom:updated values should be different.
>
> To be precise, it is "Entries in an Atom Feed Document" not "Entries
> in an Atom feed".
>
> I really really dislike that rule, and don't understand how it was
> ever accepted, and personally I would be tempted to ignore it.

IIRC, it was to allow a feed listing "revisions" of the same entry:
same id, different "updated" values.

--
Thomas Broyer

---

From: David Powell <[email-masked]>
Date: Wed, 1 Feb 2006 16:01:38 +0000

> same id, different "updated" values.

I don't have a problem with allowing multiple revisions with the same
atom:id in a single document at all; I think that is a good thing.

On the contrary, I have a problem with preventing multiple revisions
from having the same atom:updated value. It subverts the intent of
atom:updated being a subjective element, and it puts the feed compiler
in an impossible situation. Nothing prohibits the entry author from
producing two different instances with the same atom:updated value,
but given this valid situation, the feed compiler is forced to
silently lose data.

And for what purpose? The restriction is useless anyway. If it is
trying to provide a strict ordering of instances within a feed, it
fails, because the restriction only applies within a feed document.
Two seperate polls of a feed document can still produce two different
instances with the same updated value.

It also prevents synchronization applications, such as Microsoft's SSE
from introducing a more discerning date/revision extension, because
nothing is allowed to be more discerning than atom:updated, even
though the specification admits that:

  "not all modifications necessarily result in a changed atom:updated
  value"

-- 
Dave

---

From: Thomas Broyer <[email-masked]>
Date: Wed, 1 Feb 2006 17:12:50 +0100

[on atom-syntax only, no need to CC atom-protocol]

> but given this valid situation, the feed compiler is forced to
[…]
>   "not all modifications necessarily result in a changed atom:updated

Totally agree.

You should add it to http://intertwingly.net/wiki/pie/RFC4287Errata

--
Thomas Broyer

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 1 Feb 2006 22:44:41 +0100

* David Powell <[email-masked]> [2006-02-01 17:10]:
>On the contrary, I have a problem with preventing multiple
>revisions from having the same atom:updated value.

But then you have no idea which revision will be picked by
clients that try to show the latest one, which to me sounds like
it fulfills the criteria for a potential interop problem, which
is exactly what “SHOULD” is about, so I think this was the right
choice.

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

---

From: Danny Ayers <[email-masked]>
Date: Thu, 2 Feb 2006 02:09:19 +0100

On 2/1/06, A. Pagaltzis <[email-masked]> wrote:
> is exactly what "SHOULD" is about, so I think this was the right
> choice.

It's not straightforward, this came up pretty quickly in the Atom/OWL
efforts. As Bill said, it's a composite key. In RDF/OWL that has so
far demanded a rule* - somewhat less convenient than having a single
URI as id. The question is, from what is the composite key formed? id
certainly, updated too - but is same id+updated enough? What if other
parts of the entry differ? Different xml:lang even...same entry or
different?

*see also : http://esw.w3.org/topic/CIFP

Cheers,
Danny.

--

http://dannyayers.com

---

From: Henry Story <[email-masked]>
Date: Thu, 2 Feb 2006 12:43:35 +0100

>> is exactly what "SHOULD" is about, so I think this was the right

yes. One could of course have also allowed different language  
versions of an entry at the same time for example. But then things  
would probably have gotten a lot more complicated in the protocol.

> efforts. As Bill said, it's a composite key.

yes. Though this is very much true for the web on the whole. A url  
names a thing
but there may be many representations for that thing, even at the  
same time. So for a given URL there can be any number of different  
language dependent representations, or even different mime type  
representations. If you want to refer to the representations instead  
of the resource you do usually need a composite key. You are not  
usually aware of this composite key nature of the web, as you usually  
use defaults: the default representation is returned as the  
representation given to you at the time you ask for it, in the  
default language, for the default mime type.

An atom Entry is a representation of the resource named by the id.  
This id can only have representations that vary along the axis of  
time it seems.

> In RDF/OWL that has so far demanded a rule* - somewhat less  
> convenient than having a single
> URI as id.

The id relation is functional. That is an entry can only have one id.

[ a :Entry;
   :id <tag:eg.com,2/t1>;
   :updated "2003-12-13T18:30:02Z"^^xsd:dateTime;
   :title "an example"
] .

but the same feed can have another anonymous :Entry with the same id.

[ a :Entry;
   :id <tag:eg.com,2/t1>;
   :updated "2005-08-24T09:32:04Z"^^xsd:dateTime;
   :title "an fixed example"
]

The inverse of :id is :version so that we could rewrite the above  
triples as

<tag:eg.com,2/t1> :version [ a :Entry
                              :updated  
"2003-12-13T18:30:02Z"^^xsd:dateTime;
                              :title "an example" ];
                   :version [ a :Entry
                              :updated  
"2005-08-24T09:32:04Z"^^xsd:dateTime;
                              :title "a fixed example" ] .

which shows more clearly the relation between the resource and its 2  
representations.

Now the question is when we find two entries with the same id and the  
same updated time stamp are they the same entry? This is where the  
CIFP's Danny metnioned enter into play.

And this is where I am unsure in atom-owl currently. My feeling is  
that deep down that is what all of us believe.

> The question is, from what is the composite key formed? id

or is it only the case in one feed document?

---

From: Manoj <[email-masked]>
Date: Wed, 08 Feb 2006 15:47:51 +0530

On Thu, 02 Feb 2006 17:13:35 +0530, Henry Story <[email-masked]>  
wrote:

> yes. One could of course have also allowed different language versions  
> of an entry at the same time for example. But then things would probably  
> have gotten a lot more complicated in the protocol.
>
> yes. Though this is very much true for the web on the whole. A url names  
> a thing
> but there may be many representations for that thing, even at the same  
> time. So for a given URL there can be any number of different language  
> dependent representations, or even different mime type representations.  
> If you want to refer to the representations instead of the resource you  
> do usually need a composite key. You are not usually aware of this  
> composite key nature of the web, as you usually use defaults: the  
> default representation is returned as the representation given to you at  
> the time you ask for it, in the default language, for the default mime  
> type.
>
> An atom Entry is a representation of the resource named by the id. This  
> id can only have representations that vary along the axis of time it  
> seems.
>
>> In RDF/OWL that has so far demanded a rule* - somewhat less convenient  
>> than having a single
>> URI as id.
>
> And this is where I am unsure in atom-owl currently. My feeling is that  
> deep down that is what all of us believe.
>

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Mon, 13 Feb 2006 09:50:41 +0100

> but given this valid situation, the feed compiler is forced to

This goes way back to the days we discussed this, and different ways of  
signaling "change" to the user. I was always for the more automatic,  
strict and professional publishing-centric way of doing it, with  
atom:modified which got changed with every revision of the entry, no  
matter how significant.

This didn't fit the blogging community too well, though, so the conclusion  
came to something less strict and thus we have atom:updated. I don't think  
there's anything constructive to get out from surfacing that discussion  
again, but I might of course be wrong.

-- 
Asbjørn Ulsberg     -=|=-    http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»