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
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
very
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
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 you.
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 state of a
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 that not
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 is
* 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 of
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 with
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
Window may
On Sun, 06 Feb 2005 16:21:25 +1100, Eric Scheid
[EMAIL PROTECTED] wrote:
consider
link href=tag:example.com,2005:/2005/02/musings /
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
12 matches
Mail list logo
