Graham wrote:
What if someone (either the publisher or someone downstream)
wants to store a history of every revision in an archive
feed?
To this, Tim Bray answered:
I don't see why, if you wanted that kind of archive, you couldn't
use atom:updated for every little change in the archived
On 21/5/05 9:40 AM, Tim Bray [EMAIL PROTECTED] wrote:
1. The datestamp is inserted by the provider. Thus it could be a lie;
this is the Internet, remember. You, the consumer, either trust the
publisher or you don't. If you don't, you will ignore the datestamp
and check the content. If
Tim Bray directs the editors to insert the following words:
If multiple atom:entry elements with the same atom:id value appear in
an Atom Feed document, they describe the same entry and Atom Processors
MUST treat them as such.
It is a long standing and valued tradition in the IETF
On 18 May 2005, at 17:30, Antone Roundy wrote:
On Wednesday, May 18, 2005, at 09:12 AM, Henry Story wrote:
I supposed the surest way to make it impossible to fake the id, is
to specify that
by dereferencing the id and doing a GET (whatever the correct
method of doing that for the
Tim Bray wrote:
I think the WG basically decided to punt on the DOS scenario. -Tim
I believe you are correct in describing the WG's unfortunate
disposition towards this issue. (Naturally, I object...) In any case, given
that a significant DOS attack has been identified -- yet not
On 21/5/05 1:26 PM, Roger B. [EMAIL PROTECTED] wrote:
change from a unicode combined char to single + combining
diacritic,
No.
change in paragraph 27 of an article that doesn't show up in a
summaries-only feed,
No.
Dave: In my case, and seemingly in the case of most of the tools
On 21/5/05 10:48 AM, Tim Bray [EMAIL PROTECTED] wrote:
I don't see why, if you wanted that kind of archive, you couldn't use
atom:updated for every little change in the archived version but
atom:updated only for the ones you cared about in the published
version. In which case the archived
On 21/5/05 4:24 PM, Henry Story [EMAIL PROTECTED] wrote:
So those are just a few thoughts on the topic. It just seems that if one
works with the web these phishing problems seem to disappear.
all good stuff, with the exception of making atom:id dereferenceable... once
you do that you have
Saturday, May 21, 2005, 4:26:13 AM, Roger B. wrote:
change from a unicode combined char to single + combining
diacritic,
No.
change in paragraph 27 of an article that doesn't show up in a
summaries-only feed,
No.
Dave: In my case, and seemingly in the case of most of the tools
I detect that a lot of opposition to atom:modified comes from the fact
that it is a REQUIRED element and that many of the publishers actually
putting it in the feed and paying for the bandwidth don't intend using
it frequently?
Would it help if we said that if the atom:modified element is
David Powell wrote:
I detect that a lot of opposition to atom:modified comes from the fact
that it is a REQUIRED element and that many of the publishers actually
putting it in the feed and paying for the bandwidth don't intend using
it frequently?
Would it help if we said that if the
On 21/5/05 5:32 PM, David Powell [EMAIL PROTECTED] wrote:
Would it help if we said that if the atom:modified element is absent,
its value MAY be taken from the atom:updated element? (or to put it
another way: atom:modified MAY be omitted if its value is equivalent
to the value of
On 21 May 2005, at 08:44, Eric Scheid wrote:
On 21/5/05 4:24 PM, Henry Story [EMAIL PROTECTED] wrote:
So those are just a few thoughts on the topic. It just seems that
if one
works with the web these phishing problems seem to disappear.
all good stuff, with the exception of making atom:id
Tim Bray wrote:
A scan of the archives reveals no discussion; i.e. this rule is
something that predates the move to the IETF. I believe that (with a
bit of offline help) I can explain the reasoning though. We were trying
to borrow the Dublin Core semantics, wherein there is the notion of
On 21 May 2005, at 1:59 am, Tim Bray wrote:
Let me speak as a victim of a few years in the publishing-software
trenches: The semantics of author and contributor are a tangled
mess, a real swamp, and I don't think that Atom is going to do a
very good job of solving them. In particular, I
The appropiate answer to this is to say comparing an id from a
document retrieved from one URI to an id retrieved from a second URI
is not reliable. This makes feed:ids largely useless. The primary
use, of comparing with a previous version of a document retrieved
from the same URI, is
Tim Bray wrote:
On May 20, 2005, at 12:00 AM, Thomas Broyer wrote:
In 4.1.3.2:
[
If the value of type begins with text/ or ends with +xml, the
content SHOULD be local; that is to say, no src attribute should be
provided.
]
Replace with:
[
If the value of type is a text or XML
On 21 May 2005, at 2:41 am, Robert Sayre wrote:
OK. The chairs' latest text reads:
If multiple atom:entry elements with the same atom:id value appear
in an Atom Feed document, they describe the same entry and Atom
Processors MUST treat them as such.
Where does the bad behavior come in, and
On 21 May 2005, at 1:51 pm, Henry Story wrote:
That makes sense. But then it only gives one a very limited ability
to move an entry from one place
to another. If the entry has to be located in the same feed, then
presumably that means that it
would be difficult to move the entry from one
On 5/21/05, Graham [EMAIL PROTECTED] wrote:
You can say that about anything. A flat list of people associated
with an entry is infinitely better than the weird one author/multiple
contributors model that doesn't offer a clear way to cope with the
common model of multiple co-authors.
Ben Lund
This whole argument is silly. Atom:modified is needed. It should be
provided. Nobody has given a decent argument against it.
I was deeply -1 and continue to be. Every single problem you're
talking about with atom:updated will simply be transferred to
atom:modified.
Timestamps are not
On 5/21/05, Bill de hÓra [EMAIL PROTECTED] wrote:
Tim Bray wrote:
A scan of the archives reveals no discussion; i.e. this rule is
something that predates the move to the IETF. I believe that (with a
bit of offline help) I can explain the reasoning though. We were trying
to borrow
On 21 May 2005, at 3:30 pm, Robert Sayre wrote:
On 5/21/05, Graham [EMAIL PROTECTED] wrote:
The appropriate way to decode this is Written by Graham with
contributions from Friend 1 and Friend 2
Lets decode your sample in the same way: Written by Yuri Fialko,
David Sandwell, Mark Simons
On Saturday, May 21, 2005, at 12:30 AM, Bob Wyman wrote:
Tim Bray wrote:
I think the WG basically decided to punt on the DOS scenario. -Tim
I believe you are correct in describing the WG's unfortunate
disposition towards this issue. (Naturally, I object...)
I've tried to get
On 5/21/05, Graham [EMAIL PROTECTED] wrote:
On 21 May 2005, at 2:41 am, Robert Sayre wrote:
OK. The chairs' latest text reads:
If multiple atom:entry elements with the same atom:id value appear
in an Atom Feed document, they describe the same entry and Atom
Processors MUST treat
I detect that a lot of opposition to atom:modified comes from the fact
A lot of the opposition comes from the fact the WG found it useless,
months ago. Allowing multiple atom:ids in a feed doesn't change that.
You want to sit here and talk about atom:modified for another month?
For an optional
It's the impression I've had for nearly 2 years. If I'm wrong, then
fine, but there's nothing in the spec that says anything either way.
Well, there's nothing in the spec that explicitly separates
atom:author from lots of elements. Your impression is not in the spec.
I do think you're right
Robert Sayre wrote:
On 5/21/05, Bill de hÓra [EMAIL PROTECTED] wrote:
I also scanned the archives and found no consensus.
I can point you to many discussions surrounding atom:author.
Thanks for the offer, but I've already done that for myself. I don't
much care for the number of
If we make any technical changes
after the IETF last call is over (that is, weeks ago), we will
probably have to go through an IETF Last Call again. Good engineering
design allows for this. Many of us work for, or have worked for,
companies whose product ship dates slipped for months or even
On 22/5/05 12:14 AM, Robert Sayre [EMAIL PROTECTED] wrote:
This whole argument is silly. Atom:modified is needed. It should be
provided. Nobody has given a decent argument against it.
I was deeply -1 and continue to be. Every single problem you're
talking about with atom:updated
On 22/5/05 12:25 AM, Graham [EMAIL PROTECTED] wrote:
Ben Lund is okay with the current draft:
http://www.imc.org/atom-syntax/mail-archive/msg15380.html
Why aren't you?
Because what you presented to him makes no sense against the current
draft.
[...]
Which makes no sense. The two
On 5/21/05, Bill de hÓra [EMAIL PROTECTED] wrote:
If there is consensus and I missed it, I'll withdraw and apologise for
distracting the WG. If an IETF process wizard says it's too late now,
technically or in the spirit of things, I'll withdraw. If the WG makes
it known that at this point in
On 5/21/05, Eric Scheid [EMAIL PROTECTED] wrote:
atom:modified more than hits the 80:20 mark, especially if we ignore the
edge cases of bad actors (which no proposal stands much chance against).
Oh, really? What are you applying that cliche to? What problem does it
solve? Maybe a concrete
* Eric Scheid [EMAIL PROTECTED] [2005-05-21 17:30]:
what if author in that example was renamed to byline (and
specced to be something other than a Person Construct),
+1, calling it author when that sort of usage is expected and
encouraged is a lie.
and some mechanism introduced to indicate
On 5/21/05, A. Pagaltzis [EMAIL PROTECTED] wrote:
* Eric Scheid [EMAIL PROTECTED] [2005-05-21 17:30]:
what if author in that example was renamed to byline (and
specced to be something other than a Person Construct),
What are you talking about? Please refrain from complaining your pet
On 22/5/05 2:51 AM, Robert Sayre [EMAIL PROTECTED] wrote:
what if author in that example was renamed to byline (and specced to be
something other than a Person Construct), and some mechanism introduced to
indicate the nature of the contribution by each of the contributors?
What are you
Robert Sayre wrote:
I fully agree that other ways of arranging authors and contributors
are possible and reasonable, but no one has demonstrated a document
that format-08 can't cover.
The Atom Syndication Fformat spec has two authors and many contributors.
Limiting to one author, you can't
* Robert Sayre [EMAIL PROTECTED] [2005-05-21 19:05]:
At this stage, changing the spec to suit religious preferences
would be extremely arrogant.
Please stop talking to people about process bullshit at one
occasion and turning around to chide others for at this stage
at the next.
Regards,
--
Thomas Broyer wrote:
+1 on allowing multiple atom:author
-1 to dropping atom:contributor
-1 to renaming atom:author
+1 to that.
--
Anne van Kesteren
http://annevankesteren.nl/
On 5/21/05, A. Pagaltzis [EMAIL PROTECTED] wrote:
* Robert Sayre [EMAIL PROTECTED] [2005-05-21 19:05]:
At this stage, changing the spec to suit religious preferences
would be extremely arrogant.
Please stop talking to people about process bullshit at one
occasion and turning around to
Here's an abbreviated feed:
feed
entry
authornameRaggett, D, Hors, A, and I Jacobs/name/author
contributornameDave Raggett/name/contributor
contributornameArnaud Le Hors/name/contributor
contributornameIan Jacobs/name/contributor
/entry
entry
Saturday, May 21, 2005, 3:28:26 PM, Robert Sayre wrote:
This line:
Their atom:updated timestamps SHOULD be different
Ah. I misread their orders, thinking I was only to include the first
sentence. You're 100% right. Note that this does not mean I'm in favor
of atom:modified. Versioning
Eric Scheid wrote:
I'm +0.5 to all that ... the sticky problem is just how do we insert an
authorship string like Raggett, D, Hors, A, and I Jacobs into an entry,
and I'm -1 on using an extension for that since there is a $17 billion
industry already using feeds that really wants to be able to
On 5/21/05, Phil Ringnalda [EMAIL PROTECTED] wrote:
Thomas Broyer wrote:
The Atom Syndication Fformat spec has two authors and many contributors.
Limiting to one author, you can't distinguish between the authors and
contributors.
Actually, no. It has one author, a corporation, or
On 5/21/05, Eric Scheid [EMAIL PROTECTED] wrote:
On 22/5/05 5:13 AM, Robert Sayre [EMAIL PROTECTED] wrote:
Making up requirements after last call is out of order.
Not so...
Paul Hoffman wrote:
New issues for the format spec are now being brought up, issues that
existed *before*
http://atompub.org/2005/04/18/draft-ietf-atompub-format-08.html#rfc.section.4.2.7.1
I was wondering about:
# Likewise,
#
# http://www.example.com/~bob
# http://www.example.com/%7ebob
# http://www.example.com/%7Ebob
#
# are three distinct identifiers, because IRI %-escaping is
Robert Sayre wrote:
On 5/21/05, Phil Ringnalda [EMAIL PROTECTED] wrote:
Actually, no. It has one author, a corporation, or similar entity, the
ATOMPUB Working Group, and two editors and many contributors. (Editorial
nit: -08 says it's a product of the Network Working Group, apparently
the
Anne van Kesteren wrote:
http://atompub.org/2005/04/18/draft-ietf-atompub-format-08.html#rfc.section.4.2.7.1
I was wondering about:
# Likewise,
#
# http://www.example.com/~bob
# http://www.example.com/%7ebob
# http://www.example.com/%7Ebob
#
# are three distinct identifiers,
On 5/21/05, Anne van Kesteren [EMAIL PROTECTED] wrote:
Anne van Kesteren wrote:
http://atompub.org/2005/04/18/draft-ietf-atompub-format-08.html#rfc.section.4.2.7.1
I was wondering about:
# Likewise,
#
# http://www.example.com/~bob
# http://www.example.com/%7ebob
#
Robert Sayre wrote:
Versioning problems aren't solved by timestamps.
I don't understand why this version issue keeps coming up. It
should be apparent to everyone that there is NO relationship between
timestamp and version. Timestamps have only two functions:
1. Different
On 5/21/05, Bob Wyman [EMAIL PROTECTED] wrote:
Robert Sayre wrote:
Atom should support atom:modified to permit the temporal-ordering of
members of sets that share the same atom:id and atom:updated values. This
has nothing to do with versioning.
What does atom:id have to do with
On 22/5/05 7:49 AM, Robert Sayre [EMAIL PROTECTED] wrote:
Atom should support atom:modified to permit the temporal-ordering of
members of sets that share the same atom:id and atom:updated values. This
has nothing to do with versioning.
What does atom:id have to do with temporal
On 22/5/05 3:38 AM, Robert Sayre [EMAIL PROTECTED] wrote:
The problem with the example you gave is that it suggests that even entries
with just the one author/contributor would need two person constructs in the
entry, or maybe just the one ... either way it's confusing.
No, it doesn't. Why
Robert Sayre wrote:
What does atom:id have to do with temporal ordering?
Absolutely nothing.
Atom:id is used to identify sets of entry instances which, according
to the Atom specification, should be considered the same entry. Sets
composed of instances of the same entry can then
On 5/21/05, Bob Wyman [EMAIL PROTECTED] wrote:
Robert Sayre wrote:
What does atom:id have to do with temporal ordering?
Absolutely nothing.
Atom:id is used to identify sets of entry instances which, according
to the Atom specification, should be considered the same entry.
I'm sorry to raise this issue back again but...
The Atom Publishing Protocol defines SOAP bindings. This (in my mind)
means there will be WSDL files over there. WSDL rely on XML Schema which
in turn are limited to deterministic content models.
Will the APP limit Atom entries in SOAP
On 5/20/05, Paul Hoffman [EMAIL PROTECTED] wrote:
Does the WG want to be able to open up new topics, or re-open old
topics with a twist? If so, do we all agree to the delay in
publication that comes with that? Also, how long should this opening
and re-opening last? Are there any limits on
On Saturday, May 21, 2005, at 04:08 PM, Robert Sayre wrote:
You think you'll be able to disambiguate entries by
adding a more-specific date field, making for two date fields. I think
you can disambiguate entries by adding any number of extension fields.
That's great. Add extensions.
+1 --
I wrote:
I believe this was communicated when I wrote:
Atom should support atom:modified to permit the temporal-ordering of
members of sets that share the same atom:id and atom:updated values.
Robert Sayre wrote:
No, that's not what you communicated. How can I temporally order atom
On 5/21/05, Bob Wyman [EMAIL PROTECTED] wrote:
I wrote:
I believe this was communicated when I wrote:
Atom should support atom:modified to permit the temporal-ordering of
members of sets that share the same atom:id and atom:updated values.
Robert Sayre wrote:
No, that's not
Robert Sayre wrote:
atom:modified cannot be operationally distinguished from atom:updated.
Obviously, if people start shipping feeds with the same id and
atom:updated figure, it will be needed. There's no reason to
standardize it, though. We don't know how that would work.
The
The definition of atom:updated was explicitly and intentionally
crafted to permit the creation of multiple non-identical entries that shared
common atom:id and atom:updated values. Clearly, it was the intention of the
Working Group to permit this, otherwise the definition of
On 5/21/05, Bob Wyman [EMAIL PROTECTED] wrote:
Robert Sayre wrote:
So, it's about disambiguating versions of an entry, right?
No. It has nothing to do with versions or even variants. I have
explained that on numerous occasions. The denial of relevance to the issue
of version is even
Robert Sayre wrote:
Here's the last time this discussion happened:
http://www.imc.org/atom-syntax/mail-archive/msg13276.html
Tim's point in the referenced mail supported the current definition
of atom:updated which provides a means for publishers to express their own
subjective opinions
On 5/21/05, Bob Wyman [EMAIL PROTECTED] wrote:
Objective metrics which can be clearly understood by both publishers and
readers must be used. In this case, the best objective measure to use is to
say that the change of one of more bits in the encoding or representation of
an entry should
On 22 May 2005, at 01:27, Robert Sayre wrote:
On 5/21/05, Bob Wyman [EMAIL PROTECTED] wrote:
Robert Sayre wrote:
So, it's about disambiguating versions of an entry, right?
No. It has nothing to do with versions or even
variants. I have
explained that on numerous occasions. The
Robert Sayre wrote:
Temporal order of what? They are all the same entry, so what is it
you are temporally ordering?
We are discussing the temporal ordering of multiple non-identical
*instances* of a single Atom entry. It is common in the realm of software
engineering to deal with this
On 5/21/05, Bob Wyman [EMAIL PROTECTED] wrote:
Robert Sayre wrote:
Temporal order of what? They are all the same entry, so what is it
you are temporally ordering?
We are discussing the temporal ordering of multiple non-identical
*instances* of a single Atom entry. It is common in
On 22 May 2005, at 02:27, Robert Sayre wrote:
On 5/21/05, Bob Wyman [EMAIL PROTECTED] wrote:
Robert Sayre wrote:
Temporal order of what? They are all the same entry, so what is it
you are temporally ordering?
We are discussing the temporal ordering of multiple non-
identical
On May 20, 2005, at 6:06 PM, Graham wrote:
I don't see why, if you wanted that kind of archive, you couldn't
use atom:updated for every little change in the archived version
but atom:updated only for the ones you cared about in the
published version. In which case the archived version
On May 20, 2005, at 8:26 PM, Roger B. wrote:
change from a unicode combined char to single + combining
diacritic,
No.
change in paragraph 27 of an article that doesn't show up in a
summaries-only feed,
No.
Dave: In my case, and seemingly in the case of most of the tools
surveyed, both
Summary: David Powell fails to materially address any of the three
fatal flaws I pointed out in the notion of atom:modified. I remain
firmly at -1.
On May 20, 2005, at 6:04 PM, David Powell wrote:
1. The datestamp is inserted by the provider. Thus it could be a
lie;
this is the
Bob Wyman in particular and others in general have argued eloquently
for the utility of atom:modified in managing feeds and distinguishing
between temporally-varying instances of the same thing.
I agree with the usefulness of doing what Bob and others want to do,
and that they need to
Tim Bray wrote:
for archiving purposes I consider all changes no matter how small
significant, and thus preserve them all with different values of
atom:updated. For publication to the web, I have a different
criterion as to what is significant. I fail to see any problem
in the archive
Tim Bray wrote:
I regularly make minor changes to the trailing part of long
entries and decline to refresh the feed or the atom:updated date,
specifically because I do not went each of the ten thousand or
so newsreaders who fetch my feed to go and re-get the entry
because I fixed a typo in
I'd like to see a fair number of changes from the current draft, but
there are very few changes that I want badly enough, and have enough
hope of seeing approved to overshadow my desire to finish Atom 1.0
expeditiously. Here's what I'd like to see--small changes that
minimally deal with
Antone Roundy wrote:
Unless the need for this can be shown, and it can be shown that
an extension can't take care of it, I'm -1 on atom:modified.
The need is simple and I've stated it dozens of times... Given two
non-identical entries that share the same atom:id and the same
* Antone Roundy [EMAIL PROTECTED] [2005-05-22 05:25]:
Multiple authors:
* Allow multiple atom:author elements per feed/entry
* Keep atom:contributor
* Leave byline or ordering of authors to an extension for
those who need it
+1
Multiple instances of an entry in a feed document
* Allow it
On May 21, 2005, at 8:10 PM, Bob Wyman wrote:
It seems like you are concerned that people who see a change in
your
feed will re-fetch the HTML? If this is your concern, then do as
you do now
and don't refresh the feed unless you have a change that warrants
an update
to atom:updated.
On Saturday, May 21, 2005, at 09:20 PM, Bob Wyman wrote:
Antone Roundy wrote:
Unless the need for this can be shown, and it can be shown that
an extension can't take care of it, I'm -1 on atom:modified.
The need is simple and I've stated it dozens of times...
...but is it a need or a
* Robert Sayre [EMAIL PROTECTED] [2005-05-21 21:25]:
On 5/21/05, A. Pagaltzis [EMAIL PROTECTED] wrote:
* Robert Sayre [EMAIL PROTECTED] [2005-05-21 19:05]:
At this stage, changing the spec to suit religious
preferences would be extremely arrogant.
Please stop talking to people about
On 5/21/05, Henry Story [EMAIL PROTECTED] wrote:
On 22 May 2005, at 02:27, Robert Sayre wrote:
On 5/21/05, Bob Wyman [EMAIL PROTECTED] wrote:
Robert Sayre wrote:
Temporal order of what? They are all the same entry, so what is it
you are temporally ordering?
We are
Tim Bray wrote:
Yes, atom:modified would require that I update the date, and have the
entry fetched another ten thousand times, even if I made a change that
struck me as trivial. Since I'm a good citizen about specs, I would do
this wasteful thing. Others would just ignore it. -Tim
No,
* Tim Bray [EMAIL PROTECTED] [2005-05-22 04:50]:
I do not agree in the slightest that atom:modified is any more
useful than atom:updated for these purposes. The only
distinction between modified and updated is that there might be
changes, not considered significant by the publisher, which
Tim Bray wrote:
As a matter of policy, my feed contains the most recent 20
posts. However, if one of those posts is a long post and only the
summary is provided, when I make a change, I make a conscious
decision whether it's sufficient that I want newsreaders to re-fetch
it, and if
On 22/5/05 1:10 PM, Bob Wyman [EMAIL PROTECTED] wrote:
There is no requirement that your feed change whenever
you modify your posts.
+1
86 matches
Mail list logo
