On 6 Feb 2005, at 08:00, Bob Wyman wrote:
-1.
The use cases for archiving have not been well defined or well
discussed on this list. It is, I believe, inappropriate and unwise to
try to
rush through something this major at the last moment before a pending
Last
Call.
I agree. Very serious -1 for
> What do you propose one should do when the current system to which Atom
> output is to be added do not record such updates but only records the
> date when the bytes changed?
Henri: As a practical matter? If that's what you have, that's what you use.
But a lot of it comes down to knowing your
> The problem with commenting as it is practiced today is that it
> relies on granting others the right to write into one's blog.
> ...
> Thus, more and more commenting will move to a
> track-back model (either explicit via mechanisms like
> trackback or implicit
> via link tracking tool
On Feb 6, 2005, at 11:56, Roger B. wrote:
What do you propose one should do when the current system to which
Atom
output is to be added do not record such updates but only records the
date when the bytes changed?
Henri: As a practical matter?
Yes. Also as a spec expectation--that is, how often is
Thinking about it, I would be in favor of clarifying it to be
"any change should result in a date update". Clients can
do simple diffs and work out themselves if the changes warrant
a new date. Presumably clients that see that the only change has been
to the white space layout may decide that this
From what has been said recently previous versions of RSS had
no versioning mechanism. It was therefore not possible for software
to automate the difference tracking behavior. Hence your problem is
partly related to the limitations in the previous formats.
Since Atom does in fact have a versioning
On 6 Feb 2005, at 7:15 am, Henri Sivonen wrote:
What do you propose one should do when the current system to which
Atom output is to be added do not record such updates but only records
the date when the bytes changed?
The modification dates in my current RSS feed are based on the HTTP
Last-Mod
James M Snell wrote:
My challenge with the idea of mustUnderstand in Atom is in trying to
figure out how the heck it would realistically be used for anything
worthwhile. Take blog content for instance, if my blog reader accesses
a feed that contains an entry with a mustUnderstand metadata element
On Feb 6, 2005, at 3:16 AM, Henry Story wrote:
Thinking about it, I would be in favor of clarifying it to be
"any change should result in a date update".
If you will go back and review the correspondence, you will discover a
lot of argument, the upshot of which was, different publishers have
ver
Henry Story wrote:
On 6 Feb 2005, at 08:00, Bob Wyman wrote:
-1.
The use cases for archiving have not been well defined or well
discussed on this list. It is, I believe, inappropriate and unwise to
try to
rush through something this major at the last moment before a pending
Last
Call.
I agree
On 6 Feb 2005, at 3:39 pm, Sam Ruby wrote:
If you produce feeds that contain multiple entries with the same id,
there will be people who misunderstand such documents.
I do believe that there needs to be some way to say "this is not a
feed, but an archive".
Solution:
A new atom:archive top level
Graham wrote:
On 6 Feb 2005, at 3:39 pm, Sam Ruby wrote:
If you produce feeds that contain multiple entries with the same id,
there will be people who misunderstand such documents.
I do believe that there needs to be some way to say "this is not a
feed, but an archive".
Solution:
A new atom:arc
Tim Bray wrote:
On Feb 6, 2005, at 3:16 AM, Henry Story wrote:
Thinking about it, I would be in favor of clarifying it to be
"any change should result in a date update".
No, atom:update is subjective. How UIs support that subjectivity is best
left to innovation. I like Graham's wording as it make
Graham wrote:
On 6 Feb 2005, at 3:39 pm, Sam Ruby wrote:
If you produce feeds that contain multiple entries with the same id,
there will be people who misunderstand such documents.
I do believe that there needs to be some way to say "this is not a
feed, but an archive".
Solution:
A new atom:arch
Antone Roundy wrote:
I'd rather have held off while we discussed further, but as the
deadline is approaching, here it is.
Abstract
Creates a new option for the document element, , which can
contain multiple feeds or instances of the same feed, in order to
archive the states of a feed or feeds a
Bill de hÓra wrote:
Tim Bray wrote:
The reason that
we have "updated" with the current language is it reflects the reality
that the *only* kind of change that can be cleanly defined is "The
publisher thinks it changed."
Strong agreement and as I'm not constrained by being a chair, I'll go
furt
Sam Ruby wrote:
> If you produce feeds that contain multiple entries with the same
> id, there will be people who misunderstand such documents.
So what? If they initially misunderstand, they will eventually learn
how to do it properly.
In any case, I think you miswrote the quoted s
Roger Benningfield wrote:
> Bob: Bah, bug, and hum. Comments are just micro-message boards,
Wrong... Comments are just entries that are normally presented to
users in what appear to be micro-message boards.
As is usually the case in software design, it is very important to
ensure t
I have read your message in full, and I am totally convinced by your
argument. I think the sliding window view is clear, simple and powerful.
(I also think it can easily be modeled in RDF.)
Many +1's from me.
Henry Story
On 6 Feb 2005, at 20:20, Bob Wyman wrote:
The current proposals to define an "
Bob Wyman wrote:
I have long contended that a Feed Document is a "sliding window"
on a feed. Sayre and others have said that a Feed Document is "a
representation of the current state of a set of entries."
Agreed that these are different and that defining which is
acceptable/required is needed.
Bob Wyman wrote:
Sam Ruby wrote:
If you produce feeds that contain multiple entries with the same
id, there will be people who misunderstand such documents.
So what? If they initially misunderstand, they will eventually learn
how to do it properly.
It is quite possible that "they" outnumber "yo
On 7/2/05 6:20 AM, "Bob Wyman" <[EMAIL PROTECTED]> wrote:
> In this particular debate, the core issue is "What is a Feed
> Document?" I have long contended that a Feed Document is a "sliding window"
> on a feed. Sayre and others have said that a Feed Document is "a
> representation of the current
Bob Wyman wrote:
Anyway, I am convinced that the "current state" view is less useful
then the "sliding window" view. The current proposals to define an "archive"
type to patch "sliding window" into Atom are excellent indications that I'm
right... I know others disagree... I also realize tha
feeds frequently have multiple entries with the same atom:id
Can you name one example that wasn't written by an arsehole trying to
trick aggregators into behaving in a way they weren't designed to?
I have long contended that a Feed Document is a "sliding window"
on a feed. Sayre and others have
Eric Scheid wrote:
On 7/2/05 6:20 AM, "Bob Wyman" <[EMAIL PROTECTED]> wrote:
In this particular debate, the core issue is "What is a Feed
Document?" I have long contended that a Feed Document is a "sliding window"
on a feed. Sayre and others have said that a Feed Document is "a
re
Bob Wyman wrote:
In this particular debate, the core issue is "What is a Feed
Document?" I have long contended that a Feed Document is a "sliding window"
on a feed. Sayre and others have said that a Feed Document is "a
representation of the current state of a set of entries." The difference
John Panzer wrote:
Since an entry is identified uniquely by its atom:id (though it can have
different states at different times);
And, since it's not possible to add more than one of any unique thing to
a (mathematical) set;
And, since Sliding Window may require adding two elements with
the sam
* John Panzer <[EMAIL PROTECTED]> [2005-02-06 13:58-0800]
> Since an entry is identified uniquely by its atom:id (though it can have
> different states at different times);
As I understand the Web, the "REST" concepts that underpin HTTP
are quite happy with their being multiple representations
On Feb 6, 2005, at 2:24 PM, Dan Brickley wrote:
* John Panzer <[EMAIL PROTECTED]> [2005-02-06 13:58-0800]
Since an entry is identified uniquely by its atom:id (though it can
have
different states at different times);
As I understand the Web, the "REST" concepts that underpin HTTP
are quite happy w
On 7/2/05 8:58 AM, "John Panzer" <[EMAIL PROTECTED]> wrote:
> Since an entry is identified uniquely by its atom:id (though it can have
> different states at different times); And, since it's not possible to add more
> than one of any unique thing to a (mathematical) set; And, since Sliding
> Wind
Eric Scheid wrote:
On 7/2/05 8:58 AM, "John Panzer" <[EMAIL PROTECTED]> wrote:
...
I didn't specifically define "set" to be the more limited mathematical
definition. Think dining room set -- a collection of otherwise identical
items (chairs).
Okay. I suggest we use
On Sun, 06 Feb 2005 16:21:25 +1100, Eric Scheid
<[EMAIL PROTECTED]> wrote:
>
> consider
>
>
>
> assume for the moment that is a valid scheme
>
> is that kind of URI something we want to allow in link/@href?
I see no problem with the above example. The usage of
a URI in no way mandate
Roy T. Fielding wrote:
> Aggregators do not consume feed resources -- they consume an
> iterative set of overlapping feed representations.
This is only true of pull based aggregators that poll for feeds.
None of the aggregators that I use are polling based. I use the PubSub
Sidebars and th
On Feb 5, 2005, at 6:01 PM, Roy T.Fielding wrote:
On Feb 5, 2005, at 9:48 AM, Mark Nottingham wrote:
What does that mean? SOAP is a "Must Ignore format," but it also has
a way of saying that you have to understand a particular extension;
as I said before, this is one of the big problems with HTT
This is why I prefer "snapshot" to "feed"; the latter doesn't convey
what an Atom Feed Document really is, and leads to just this kind of
confusion.
Another direction to go in would be to add metadata (probably in the
head) that says what kind of feed it is; e.g., "an archive," "a
snapshot of
35 matches
Mail list logo
