I would just like to revisit this question, because it will help clarify
the alternate relation.
On 1 Mar 2005, at 11:39, Henry Story wrote:
On 20 Feb 2005, at 13:25, Bill de hÓra wrote:
Graham, Eric,
My thinking goes like this,
- Is there a difference between an entry and the chunk of XML you
On 20 Feb 2005, at 13:25, Bill de hÓra wrote:
Graham, Eric,
Ok since the above chickened out of answering your questions above,
I'll do so
myself.
My thinking goes like this,
- Is there a difference between an entry and the chunk of XML you see
in a feed?
The question is vague and open to
On 1/3/05 9:39 PM, Henry Story [EMAIL PROTECTED] wrote:
On 20 Feb 2005, at 13:25, Bill de hÓra wrote:
Graham, Eric,
Ok since the above chickened out of answering your questions above,
I'll do so myself.
My apologies: I didn't see the second part of that email. I thought the
extent of
Henry Story wrote:
On 23 Feb 2005, at 00:18, Bill de hÓra wrote:
My read of the mailing list is that people are simply looking at the
model described in the document differently. Some folks actively want
the model the way the document currently reads, other actively want
the model to be
Henry Story wrote:
I would be in favor of not resolving the ambiguity but of highlighting it
with text such as
[ whether more than one entry with the same id can appear in a feed
document
has not yet been resolved ]
-1. That is of no little value to a user of the spec. Also, do read what
I
On 23 Feb 2005, at 08:53, Henry Story wrote:
On 23 Feb 2005, at 00:18, Bill de hÓra wrote:
Sorry that should have been Paul Hoffman wrote:
My read of the mailing list is that people are simply looking at the
model described in the document differently. Some folks actively
want the model the way
I like the way you put the question below. It is indeed very clear.
But it does not seem incompatible with us adding some text now in the
spec that acknowledges that we have not yet answered the questions you
pose. I would surround this text with square brackets [] just as we
have done with other
At 12:25 PM + 2/20/05, Bill de hÓra wrote:
Chairs/Editors,
- I think that this discussion (repeat ids) is architecturally
significant in terms of how Atom layers onto the Web and is best
taken forward under feed state,
- Feed state discussion ought to deal explicitly with entry state,
as
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.
The PaceRepeatIdInDocument tries to set the constraints in the
Identity construct whereas the constraint should have gone on the
individual elements.
Instead I would replace the following in the spec:
4.5 The atom:id Element
The atom:id element is an Identity construct that conveys a
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
27 matches
Mail list logo
