Thomas Broyer wrote:
David Powell wrote:
I'm in favour of allowing duplicate ids. This only seems to be a
partial solution though:
Their atom:updated timestamps SHOULD be different
But what if they are not? What if I want to represent an archive of a
feed - maybe mine, maybe someone
Don't you have the same problem with atom:modified? What if the
publisher does not update the atom:modified entry?
I suppose that if you are making an archive of an atom entries and
believe
that the author has made a mistake with the atom:updated field, you can
of course try to correct the
David Powell wrote:
I'm in favour of allowing duplicate ids. This only seems to be a
partial solution though:
Their atom:updated timestamps SHOULD be different
But what if they are not? What if I want to represent an archive of a
feed - maybe mine, maybe someone else's - but the atom:updated
On 12/5/05 5:26 PM, Henry Story [EMAIL PROTECTED] wrote:
Don't you have the same problem with atom:modified? What if the
publisher does not update the atom:modified entry?
Theoretically, the publisher doesn't get that choice. To not update
atom:modified would be an error.
There remains the
Friday, May 6, 2005, 3:52:19 PM, Eric Scheid wrote:
On 7/5/05 12:09 AM, Graham [EMAIL PROTECTED] wrote:
If an Atom Feed Document contains multiple entries with the same
atom:id, software MUST treat them as multiple versions of the same
entry
I don't think this changes the technical
with the
same ID for me means that they are simply not doing their job.
Aggregators should aggregate, not just function as GIGO (garbage
in, garbage out) processors.
So it should be clear that I'm -1 on PaceAllowDuplicateIDs.
Regards,Martin.
it is not. Let the applications and the market decide. We just need
to make certain types of communication possible.
So it should be clear that I'm -1 on PaceAllowDuplicateIDs.
Should I be -1 on UTF-8 and internationalization because most people
I know are english, french or german and so that ISO-latin
I have no good answer to that until I know what what an id stands for.
The answer an entry isn't sufficient.
Bill: Semi-random thoughts...
* An atom:id is a globally unique name for a specific database query.
* There is no stream of instances over time. There's just old data
that's out of
On 7/5/05 3:53 AM, Tim Bray [EMAIL PROTECTED] wrote:
On May 6, 2005, at 8:49 AM, Eric Scheid wrote:
Are they still the same entry if they have different source elements that
identify their source as being different feeds?
I don't see why. I subscribe to a Local News feed, a National News
Robert Sayre wrote:
I'm much more sympathetic to the aggregate feed problem of multiple
IDs. People advocating this type of thing seem to think the default
action should be grouping, so they want to use the same ID. I think
that's a bad idea, and there are plenty of other ways to indicate the
On 6 May 2005, at 2:10 pm, Dave Johnson wrote:
Yes, I think both of my arguments fail to hold and I no longer have
a real objection to duplicates. Allowing duplicates gives feed
produces to model events or other objects (versioned documents in a
wiki) as they wish. Like you, I wonder Does
Unique IDs allow clients to determine the state of the feed. If entry
ids are
not unique, then we still need some other way to determine the unique
state of the feed. If we allow duplicate IDs but *require* something else
to be different (e.g. update time), then we can still determine the
As the WG may have noticed, I have some serious problems with the
Pace. One small change would eliminate about 75% of them:
Replace the line:
If an Atom Feed Document contains multiple entries with the same
atom:id, software MAY choose to display all of them or some subset of
them
with:
If
Graham wrote:
Does anyone remember why having the same id in a feed is a bad idea?
Beacuse instead of a fixed model where a feed is a stream of
entries each with their own id, it is now a stream of entries each
of which does not have its own id, but shares it with similar
entries. This is
What determines a version? If we have multiple entries with identical
information,
these are copies, not versions.
The real issue is feed state. Given there are identical IDs, can we
determine if
the entries are identical or different? The end client can then deal
with it any way
it wants
On May 6, 2005, at 7:09 AM, Graham wrote:
Replace the line:
If an Atom Feed Document contains multiple entries with the same
atom:id, software MAY choose to display all of them or some subset of
them
with:
If an Atom Feed Document contains multiple entries with the same
atom:id, software MUST
On 6/5/05 11:37 PM, Graham [EMAIL PROTECTED] wrote:
Beacuse instead of a fixed model where a feed is a stream of entries
each with their own id, it is now a stream of entries each of which
does not have its own id, but shares it with similar entries. This is
bullshit.
See the spec:
On 7/5/05 12:09 AM, Graham [EMAIL PROTECTED] wrote:
If an Atom Feed Document contains multiple entries with the same
atom:id, software MUST treat them as multiple versions of the same
entry
I don't think this changes the technical meaning of the proposal, but
does make it very explicit.
Graham wrote:
On 6 May 2005, at 2:10 pm, Dave Johnson wrote:
Yes, I think both of my arguments fail to hold and I no longer have a
real objection to duplicates. Allowing duplicates gives feed produces
to model events or other objects (versioned documents in a wiki) as
they wish. Like you, I
On 7/5/05 1:16 AM, Bob Wyman [EMAIL PROTECTED] wrote:
Graham wrote:
If an Atom Feed Document contains multiple entries with the
same atom:id, software MUST treat them as multiple versions of
the same entry
Are they still the same entry if they have different source elements
that identify
On 5/6/05, Bob Wyman [EMAIL PROTECTED] wrote:
Graham wrote:
If an Atom Feed Document contains multiple entries with the
same atom:id, software MUST treat them as multiple versions of
the same entry
Are they still the same entry if they have different source elements
that
On May 6, 2005, at 8:49 AM, Eric Scheid wrote:
Are they still the same entry if they have different source elements
that identify their source as being different feeds?
I don't see why. I subscribe to a Local News feed, a National News
feed, and
a Science News feed. All from the same publisher.
On 6 May 2005, at 4:16 pm, Bob Wyman wrote:
Graham wrote:
If an Atom Feed Document contains multiple entries with the
same atom:id, software MUST treat them as multiple versions of
the same entry
Are they still the same entry if they have different source
elements
that identify their source
On Friday, May 6, 2005, at 09:16 AM, Bob Wyman wrote:
Graham wrote:
If an Atom Feed Document contains multiple entries with the
same atom:id, software MUST treat them as multiple versions of
the same entry
Are they still the same entry if they have different source elements
that identify
that I means am +1000 on this now.
:-) That's consensus, I am sure.
Henry
http://bblfish.net/blog/
On 5 May 2005, at 06:02, Tim Bray wrote:
co-chair-hat status=OFF
http://www.intertwingly.net/wiki/pie/PaceAllowDuplicateIDs
This Pace was motivated by a talk I had with Bob Wyman today about
On 5 May 2005, at 5:02 am, Tim Bray wrote:
feedtitleMy Portfolio/title
entrytitleMSFT/title
updated2005-05-03T10:00:00-05:00/updated
contentBid: 25.20 Ask: 25.50 Last: 25.20/content/item
/entry
entrytitleMSFT/title
updated2005-05-03T11:00:00-05:00/updated
contentBid: 25.15 Ask:
On 5 May 2005, at 2:20 am, Bob Wyman wrote:
Basically, you dont have to update atom:updated unless you think
it makes sense OR you are publishing to a feed that already has an
entry with the same atom:id as the atom:id of the entry you are
currently publishing.
Or someone downstream is
On 5 May 2005, at 11:36 am, Henry Story wrote:
Tim, model this as a blog first. Is it:
a) One entry that's being updated?
b) Hourly new postings with the latest price?
Given that the ids are the same it is now clear that we have
situation a)
I said first, before we decide what ids we should
On 5/5/05, Eric Scheid [EMAIL PROTECTED] wrote:
Because feeds are feeds and archives are archives? They have
different audiences and different uses and different requirements.
And what about the use case of a wiki's RecentChanges log? Each entry refers
to a specific page, and there may
On 5 May 2005, at 2:26 pm, Eric Scheid wrote:
perhaps we needed atom:modified after all :-(
Yes we do, if we want to go down this route. I suggest appending the
current time (or for old versions, the last time that version was
current) at the source.
And what about the use case of a wiki's
On 5 May 2005, at 15:55, Graham wrote:
On 5 May 2005, at 2:26 pm, Eric Scheid wrote:
perhaps we needed atom:modified after all :-(
Yes we do, if we want to go down this route. I suggest appending
the current time (or for old versions, the last time that version
was current) at the source.
On 5/5/05, Eric Scheid [EMAIL PROTECTED] wrote:
On 5/5/05 11:55 PM, Graham [EMAIL PROTECTED] wrote:
Each log entry is an entry in itself, with its own id.
Sorry, that makes as much sense as changing the id for a blog entry if that
blog entry is updated.
Graham's got it exactly right.
On 5 May 2005, at 3:32 pm, Henry Story wrote:
As I explained in my lengthy reply to your lengthy post, I think
one should be able to do either.
Each way has its advantages and disadvantages. Let the publisher
decide which mechanism to use.
Well please flag it so that I can provide a
On 5 May 2005, at 3:23 pm, Eric Scheid wrote:
And what about the use case of a wiki's RecentChanges log? Each
entry refers
to a specific page, and there may be multiple such entries for
each page as
it gets rapidly edited ... and wiki folks have found it important
to be able
to monitor all
On 6/5/05 12:32 AM, Henry Story [EMAIL PROTECTED] wrote:
Sorry I don't understand why we need atom:modified.
Graham suggested it : a reliable way for an aggregator to discern the latest
version of an entry.
atom:updated is used by the publisher to show what they consider a
significant
On 6/5/05 12:45 AM, Graham [EMAIL PROTECTED] wrote:
Have a look here:
http://en.wikipedia.org/w/index.php?title=Main_Pageaction=history
There you have a reverse chrono list, each with an author, date, and
summary. Looks an awful lot like each one is an entry to me.
and looks to me like a
On 5 May 2005, at 16:38, Graham wrote:
On 5 May 2005, at 3:32 pm, Henry Story wrote:
As I explained in my lengthy reply to your lengthy post, I think
one should be able to do either.
Each way has its advantages and disadvantages. Let the publisher
decide which mechanism to use.
Well please
I'm -1 on PaceAllowDuplicateIDs
Reasons:
1) We're supposed to be standardizing current practice not inventing
new things. Current best practice is to have unique IDs and current
software (e.g. Javablogs.com) is predicated on this practice. I know,
this practice is not followed widely enough
On Thursday, May 5, 2005, at 09:15 AM, Eric Scheid wrote:
Have a look here:
http://en.wikipedia.org/w/index.php?title=Main_Pageaction=history
There you have a reverse chrono list, each with an author, date, and
summary. Looks an awful lot like each one is an entry to me.
and looks to me like a
the article not an event in the blog entry's life. So, you can
discount my second reason against the pace.
- Dave
On May 5, 2005, at 11:27 AM, David M Johnson wrote:
I'm -1 on PaceAllowDuplicateIDs
Reasons:
1) We're supposed to be standardizing current practice not inventing
new things. Current best
On 5 May 2005, at 4:22 pm, Henry Story wrote:
If you don't want to keep a history of the entries all you need to
do is drop all but the
latest entry with the same id. There is nothing more to it. Just
show the user the last
one you came across.
But, if we follow Eric's model of how a wiki
on PaceAllowDuplicateIDs
Please consider the following points before you vote.
Reasons:
1) We're supposed to be standardizing current practice not
inventing new things. Current best practice is to have unique IDs
and current software (e.g. Javablogs.com) is predicated on this
practice. I know
On 5 May 2005, at 17:53, Graham wrote:
On 5 May 2005, at 4:22 pm, Henry Story wrote:
If you don't want to keep a history of the entries all you need to
do is drop all but the
latest entry with the same id. There is nothing more to it. Just
show the user the last
one you came across.
But, if
On 6/5/05 1:53 AM, Graham [EMAIL PROTECTED] wrote:
This proposal permits this, and it does not harm anyone else.
It harms everyone, by allowing a second, unrelated data model in Atom
feeds. They may not be posting today, but I assure you, when other
aggregator authors get the first user
On Thursday, May 5, 2005, at 08:44 AM, Antone Roundy wrote:
If we accept this Pace, are we going to do anything to address the DOS
issue for aggregated feeds?
Bob, if I may direct a few question to you, since you have the most
experience with this issue: if PaceAllowDuplicateIDs is adopted, how
On 5 May 2005, at 5:38 pm, Eric Scheid wrote:
Many wiki's offer options in displaying their change log with
either most
recent changes only, or all changes. Both models are commonly
supported
because some people want to see notifications of all changes, while
others
just want to see the most
Graham wrote:
On 5 May 2005, at 5:38 pm, Eric Scheid wrote:
Many wiki's offer options in displaying their change log with either
most
recent changes only, or all changes. Both models are commonly supported
because some people want to see notifications of all changes, while
others
just want to
. It is not required that
atom:updated be modified when a newer version is written.
If the
PaceAllowDuplicateIDs is accepted, it will be permitted to have multiple
entries with the same atom:id in a single feed. However, the Pace language says
processors SHOULD regard as feed generation errors any
On May 4, 2005, at 6:20 PM, Bob Wyman wrote:
+1 with a comment:
If this Pace is accepted (and I hope it will be) the issue of
Duplicate IDs should probably be dealt with in Marks Implementation
Guide.[1]
Er, I had planned to refine this a bit and then announce it to the
group with some
co-chair-hat status=OFF
http://www.intertwingly.net/wiki/pie/PaceAllowDuplicateIDs
This Pace was motivated by a talk I had with Bob Wyman today about the
problems the synthofeed-generator community has.
Summary:
1. There are multiple plausible use-cases for feeds with duplicate IDs
2. Pro
50 matches
Mail list logo
