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
:
[ whether more than one entry with the same id can appear in a feed
document
has not yet been resolved ]
rather than go the way Tim Bray was thinking of going, namely:
PaceRepeatIdInDocument
Lots of discussion, more -1's than +1's.
DISPOSITION: No consensus, close it. But now we have a problem
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
types of ids that were hidden
in the ambiguous text that PaceRepeatIdInDocument tried to disambiguate
one
way and other Paces tried to disambiguate the other way.
As such it correctly resolves an ambiguity by allowing both options.
Henry Story
Ps. text above written quickly cause I have to go do some
by next and
previous links inconsistent.
This will create a really deep flaw in Atom.
Therefore I think the conclusion that the group has decided not
only against PaceRepeatIdInDocument but furthermore for a
restriction is a understandable but very dangerous conclusion
to come to.
sincerely,
Henry
PaceRepeatIdInDocument
+1 over any attempt to clearly specify that it is not allowed
to be repeated.
It is better to be clear than to be ambiguous. But it is better to
be ambiguous than to close the doors on rich possibilities just for the
sake of clarity.
This proposal is clearly better than
PaceRepeatIdInDocument
+1
I'm happy with allowing multiple entries with the same ID in the one feed
instance. Aggregators already must handle the case of seeing the same ID in
some way, since that ID could quite reasonably have been in a previous
edition of the feed resource.
On 5 Feb 2005, at 4:18 pm, Antone Roundy wrote:
1. In order to show the revision history of a particular entry,
multiple revisions of the entry must be able to appear in the same
document.
But must we have this facility?
2. Changing the atom:id of the entry with each revision would
Graham wrote:
2. Changing the atom:id of the entry with each revision would
severly reduce the duplicate detection value of atom:id.
I don't think anyone's proposed this.
-1
-1 also. I think we'd do better to focus on the specification text for
id - that will be much more effective than
Antone Roundy wrote:
Neither of these is equivalent to atom:id--according to this text, the
{item_uri} and rdf:about for a particular item could change each time
you transmit the feed. Whether we accept this Pace or not, that is not
what is intend for atom:id. Could you explain how these are
Bob Wyman wrote:
Robert Sayre wrote:
Bob Wyman wrote:
As long as multiple instances/versions of an entry are permitted to
exist in a single atom document while sharing the same atom:id, the
current Atom document format provides a useable archive format.
This is clearly a non-starter for a
Bob Wyman wrote:
It is all this informality and hand-waving around atom:id and
atom:updated that is the source of any trouble with using atom:feed as an
archive format. Given globally unique ids (atom:id) and version tags
(atom:updated) for entries, archiving would be trivial even for
On Saturday, February 5, 2005, at 03:55 PM, Sam Ruby wrote:
-1 to the Pace.
Just to be sure we don't forget, if we don't want to allow multiple
versions of an entry in the same feed document, we need to add language
to the spec to clarify that point.
Like Robert, I believe that this Pace
On Saturday, February 5, 2005, at 02:07 PM, Robert Sayre wrote:
Antone Roundy wrote:
On Saturday, February 5, 2005, at 11:48 AM, Robert Sayre wrote:
Part of our charter is to define a format suitable for archiving
feeds.
Right, and breaking the feed format isn't the way to do it. Since
you're
On Saturday, February 5, 2005, at 06:25 PM, Antone Roundy wrote:
I'd be perfectly happy with not allowing atom:id to be repeated in a
feed or the hypothetical aggregation if we had an archive
element which acts exactly like aggregation except that atom:id may
be repeated.
Oops, correction:
Antone Roundy wrote:
This would not address your question of tracking changes to the feed's
metadata. I'd be perfectly happy with not allowing atom:id to be
repeated in a feed or the hypothetical aggregation if we had an
archive element which acts exactly like aggregation except that
atom:id
On 6/2/05 8:41 AM, Bob Wyman [EMAIL PROTECTED] wrote:
If
anything we should address the lack of a standard method for creating
atom:id's and we should create a requirement that atom:updated must be
changed on *every* update -- not just on the whim of the entry author...
arrgh!
atom:updated
On 6 Feb 2005, at 4:17 am, Eric Scheid wrote:
On 6/2/05 3:28 AM, Graham [EMAIL PROTECTED] wrote:
1. In order to show the revision history of a particular entry,
multiple revisions of the entry must be able to appear in the same
document.
But must we have this facility?
your other options are:
*
41 matches
Mail list logo
