Bob Wyman wrote:
Given that history shows that publishing repeated ids has never
bothered anyone enough to cause them to complain, we should permit this
benign practice to continue.
I have exactly the opposite experience. I have people who have thanked
me for noticing that they have repeated
On 20 Feb 2005, at 4:07 am, Bob Wyman wrote:
PubSub regularly produces feeds with multiple instances of the same
atom:id.
Which part of universally unique didn't you understand?
It is particularly important to avoid prohibiting this benign
practice since it is so important to generators of
On 20/2/05 4:34 PM, Graham [EMAIL PROTECTED] wrote:
That's not what I meant. I opposed atom:modified because this use case
wasn't on the table then. I oppose multiple ids partly because we don't
have atom:modified. You can't have one without the other.
if this use case was on the table back
On 20 Feb 2005, at 17:10, Graham wrote:
On 20 Feb 2005, at 4:07 am, Bob Wyman wrote:
PubSub regularly produces feeds with multiple instances of the same
atom:id.
Which part of universally unique didn't you understand?
Ok, I see so you interpret the universally unique in
[[
An Identity construct
About logical clocks in atom:modified:
--On February 21, 2005 3:30:13 AM +1100 Eric Scheid [EMAIL PROTECTED] wrote:
Semantically, it would work ... for comparing two instances of one entry. It
wouldn't work for establishing if an entry was modified before or after
[some event moment] (eg.
On 20 Feb 2005, at 4:30 pm, Eric Scheid wrote:
if this use case was on the table back then, and you were to consider
the
question in that light, where would you stand?
I like the model where the feed content is approximately The current
version of the latest entries. I don't think anything else
Graham wrote:
My idea would be that the originating server would simply stamp
entries with the current time during feed generation, so if they
get mixed up in transit by third parties or caches the later version
would still be known. Note the originating server doesn't have to
store or keep
I think I can prove that the two versions are perfectly compatible and
orthogonal. I can prove that logically there is no inconsistency, and
some empirical backing that this is feasible. But I am not alone. Bob
Wyman I believe has a lot more empirical support.
You on the other hand, as usual I
On 18 Feb 2005, at 23:55, Graham wrote:
Allowing more than one version of the same entry in a syndication
feed is unacceptable in itself, which is fundamentally incompatible
with archive feeds, no matter what the conceptual definition of id
is.
Graham
Let me make my point even clearer. If
On 19 Feb 2005, at 11:23 am, Henry Story wrote:
Let me make my point even clearer. If something is fundamentally
incompatible,
then it should be *dead-easy* to prove or reveal this incompatibility.
i) Syndication documents shouldn't ever contain multiple versions of
the same entry*.
ii) Archive
i) Syndication documents shouldn't ever contain multiple versions of
the same entry*.
Graham: +1.
ii) Archive documents apparently need to be able to contain multiple
versions of the same entry.
I don't even buy that much, personally.
--
Roger Benningfield
On 20/2/05 2:46 AM, Graham [EMAIL PROTECTED] wrote:
i) Syndication documents shouldn't ever contain multiple versions of
the same entry*.
* for the simple reason that it makes them an order of magnitude harder
to process and display correctly (and often impossible to display
correctly,
On 19 Feb 2005, at 11:06 pm, Eric Scheid wrote:
If two instances with the same atom:id have the same atom:updated,
then there is no significant difference between the two, so go with a
random choice
*that the author considered significant*. If you've told the use
they're getting the latest
On 19 Feb 2005, at 16:46, Graham wrote:
On 19 Feb 2005, at 11:23 am, Henry Story wrote:
Let me make my point even clearer. If something is fundamentally
incompatible,
then it should be *dead-easy* to prove or reveal this incompatibility.
i) Syndication documents shouldn't ever contain multiple
On 20 Feb 2005, at 1:27 am, Eric Scheid wrote:
hmmm ... looking back in the archives I see you were opposed to
atom:modified, you couldn't see any use case where you would want the
entry
instances to clearly indicate which is more recent. Hashes won't help
you
here.
Yes, if you want multiple
Graham wrote:
[1] do you know of any publishing software which currently emits
feeds with multiple instances of entries? I can't think of any.
None. That's why it should be explicitly barred, since no software
is expecting it.
PubSub regularly produces feeds with multiple instances of
On 20/2/05 1:47 PM, Graham [EMAIL PROTECTED] wrote:
On 20 Feb 2005, at 1:27 am, Eric Scheid wrote:
hmmm ... looking back in the archives I see you were opposed to
atom:modified, you couldn't see any use case where you would want the entry
instances to clearly indicate which is more recent.
I was not able to go and do the exercise I wanted to do, so here is a
more carefully worded version
The id construct in atom is ambiguous between two meanings. Since the
two meanings are orthogonal and not incompatible when
18 matches
Mail list logo
