How is Atom superior to RSS?

I’ll be making a presentation on Tuesday which will include a slide on how Atom improves on RSS. If you have any thoughts on this subject, I would appreciate hearing them…   bob wyman  

Re: I wanna go home - process questions

Paul/Tim, please advise: (1) if the format spec succeeds last call, will it not sit in limbo until the other specs which it relies upon also go into last call? (2) if, in wrangling the protocol spec, we realise that something is broken in the format spec, does IETF process allow us to recall t

Re: Refresher on Updated/Modified

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

Re: Refresher on Updated/Modified

On 22 May 2005, at 2:05 am, Tim Bray wrote: I'm not hacking at all. In this scenario, 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

RE: Refresher on Updated/Modified

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

Re: updated and modified yet again

New flash! Bob and I agree! On May 21, 2005, at 8:53 PM, Bob Wyman wrote: If I have two non-identical entries, each with the same atom:id and the same atom:updated, I need an algorithm that can be used to determine which of the two entry instances should be presented to a consumer wh

Re: updated and modified yet again

* 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, whic

Re: I wanna go home

Sounds like a good way to scope the discussion. All of this sounds reasonable. On 5/21/05, A. Pagaltzis <[EMAIL PROTECTED]> wrote: > > * Antone Roundy <[EMAIL PROTECTED]> [2005-05-22 05:25]: > > Multiple authors: > > * Allow multiple atom:author elements per feed/entry > > * Keep atom:contribut

RE: atom:modified (was Re: Fetch me an author. Now, fetch me another author.)

Antone Roundy wrote: > Only in the unusual cases will there be any difficulty in determining > which instance came last. "Unusual" is a relative term... I read over 10 million feeds every day, many of them multiple times each day. I intend to read every public feed that gets created. Thus,

Re: Refresher on Updated/Modified

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,

Re: atom:modified indicates temporal ORDER not version....

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? > >>>

RE: updated and modified yet again

Tim Bray wrote: > So the only reason why atom:modified can ever be more useful is if > you disagree with the publisher's opinion as to what is significant. If this "framing" of the issue was valid, then there would be no reason to support atom:modified. However, the framing is NOT valid.

Re: Fetch me an author. Now, fetch me another author.

* 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 talki

Re: atom:modified (was Re: Fetch me an author. Now, fetch me another author.)

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

Re: Refresher on Updated/Modified

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.

Re: I wanna go home

* 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 >

RE: atom:modified (was Re: Fetch me an author. Now, fetch me another author.)

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 atom:upd

I wanna go home

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 prob

RE: Refresher on Updated/Modified

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

RE: Refresher on Updated/Modified

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

atom:modified (was Re: Fetch me an author. Now, fetch me another author.)

On Saturday, May 21, 2005, at 05:57 PM, Bob Wyman wrote: The second problem is that readers (not publishers) need to be able to distinguish and temporally order entries that have been written by publishers. We may not have been discussing exactly the same details before, but when atom:modifi

updated and modified yet again

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 dis

Re: Refresher on Updated/Modified

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 Intern

Re: Refresher on Updated/Modified

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 o

Re: Refresher on Updated/Modified

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 wo

Re: atom:modified indicates temporal ORDER not version....

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 *ins

Re: Fetch me an author. Now, fetch me another author.

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 similar entity," the ATOMPUB Working Group, and two editors an

Re: atom:modified indicates temporal ORDER not version....

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 com

RE: atom:modified indicates temporal ORDER not version....

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

Re: atom:modified indicates temporal ORDER not version....

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.

Re: Fetch me an author. Now, fetch me another author.

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

RE: Fetch me an author. Now, fetch me another author.

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 opinion

Re: atom:modified indicates temporal ORDER not version....

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 "ver

RE: atom:modified indicates temporal ORDER not version....

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 in the title of this thread. Read: "atom:modi

Re: Fetch me an author. Now, fetch me another author.

> 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 atom:u

RE: Fetch me an author. Now, fetch me another author.

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 defi

Re: atom:modified indicates temporal ORDER not version....

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: > >

RE: atom:modified indicates temporal ORDER not version....

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 orde

Re: Fetch me an author. Now, fetch me another author.

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 -- thos

Close the Atompub WG? (was: PROCESS QUESTION: are we done yet?)

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 o

Deterministic content models (conflict with Atom Publishing Protocol?)

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 envel

Re: atom:modified indicates temporal ORDER not version....

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 e

RE: atom:modified indicates temporal ORDER not version....

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 t

Re: Fetch me an author. Now, fetch me another author.

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 do

Re: atom:modified indicates temporal ORDER not version....

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 t

Re: Fetch me an author. Now, fetch me another author.

On 5/21/05, David Powell <[EMAIL PROTECTED]> wrote: > > Saturday, May 21, 2005, 8:13:13 PM, Robert Sayre wrote: > > > So, really, we have folks who want to delay this spec > > because they think they've solved Distributed Versioning On The > > Internet. > > This is a straw man argument. No, it

Re: Fetch me an author. Now, fetch me another author.

Saturday, May 21, 2005, 8:13:13 PM, Robert Sayre wrote: > So, really, we have folks who want to delay this spec > because they think they've solved Distributed Versioning On The > Internet. This is a straw man argument. PaceDateModified2 was created to allow subscribers to determine the latest

Re: atom:modified indicates temporal ORDER not version....

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

atom:modified indicates temporal ORDER not version....

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 timesta

Re: 4.2.7.1 Comparing atom:id

On 5/21/05, Anne van Kesteren <[EMAIL PROTECTED]> wrote: > > Anne van Kesteren wrote: > > > > > > I was wondering about: > > > > # Likewise, > > # > > # http://www.example.com/~bob > > # http://www.examp

Re: 4.2.7.1 Comparing atom:id

Anne van Kesteren wrote: I was wondering about: # Likewise, # # http://www.example.com/~bob # http://www.example.com/%7ebob # http://www.example.com/%7Ebob # # are three distinct identifiers, bec

Re: Fetch me an author. Now, fetch me another author.

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

4.2.7.1 Comparing atom:id

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 sign

Re: PROCESS QUESTION: are we done yet? (was: Fetch me an author)

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 > >

Re: Fetch me an author. Now, fetch me another author.

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

Re: PROCESS QUESTION: are we done yet? (was: Fetch me an author)

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* the WG Last Call, much less the IETF-wide Last Call. >

Re: Fetch me an author. Now, fetch me another author.

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 t

Re: Refresher on Updated/Modified

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. Versio

Re: Fetch me an author. Now, fetch me another author.

On 22/5/05 4:46 AM, "Anne van Kesteren" <[EMAIL PROTECTED]> wrote: > Thomas Broyer wrote: >> +1 on allowing multiple atom:author >> -1 to dropping atom:contributor >> -1 to renaming atom:author > > +1 to that. I'm +0.5 to all that ... the sticky problem is just how do we insert an authorship st

extracting authors and contributors from the format

Here's an abbreviated feed: Raggett, D, Hors, A, and I Jacobs Dave Raggett Arnaud Le Hors Ian Jacobs Homer Simpson Marge Simpson Barney Rubble, Esq Simpson, H J, and D Raggett Dave Raggett

Re: Fetch me an author. Now, fetch me another author.

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 turn

Re: Fetch me an author. Now, fetch me another author.

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

Re: Fetch me an author. Now, fetch me another author.

* 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. Regard

Re: Fetch me an author. Now, fetch me another author.

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 di

Re: Fetch me an author. Now, fetch me another author.

On 5/21/05, Eric Scheid <[EMAIL PROTECTED]> wrote: > > Here are some simple questions, which > > you can answer by reading the example I gave, and reading the draft. > > > > http://www.imc.org/atom-syntax/mail-archive/msg15380.html > > > > Who is the author of that entry? > > Who are the contribut

Re: Fetch me an author. Now, fetch me another author.

On 22/5/05 2:51 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote: >> what if in that example was renamed to (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 s? > What are you talking about? Ple

Re: Fetch me an author. Now, fetch me another author.

On 5/21/05, A. Pagaltzis <[EMAIL PROTECTED]> wrote: > > * Eric Scheid <[EMAIL PROTECTED]> [2005-05-21 17:30]: > > what if in that example was renamed to (and > > specced to be something other than a Person Construct), What are you talking about? Please refrain from complaining your pet semanti

Re: Fetch me an author. Now, fetch me another author.

* Eric Scheid <[EMAIL PROTECTED]> [2005-05-21 17:30]: > what if in that example was renamed to (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 the nat

Re: Refresher on Updated/Modified

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 e

Re: Fetch me an author. Now, fetch me another author.

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 poin

Re: Fetch me an author. Now, fetch me another author.

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

Re: Refresher on Updated/Modified

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 at

Re: Fetch me an author. Now, fetch me another author.

On 21 May 2005, at 4:02 pm, Robert Sayre wrote: 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 impress

Re: PROCESS QUESTION: are we done yet?

> 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

Re: Fetch me an author. Now, fetch me another author.

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 discu

Re: Fetch me an author. Now, fetch me another author.

> 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 a

Re: atom:modified : Reducing the cruft

> 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

Re: Refresher on Updated/Modified

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

Re: Compulsory feed ID?

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 discuss

Re: Fetch me an author. Now, fetch me another author.

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

Re: Fetch me an author. Now, fetch me another author.

On 21 May 2005, at 3:11 pm, Robert Sayre wrote: 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

Re: Fetch me an author. Now, fetch me another author.

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 > >

Re: Refresher on Updated/Modified

> 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

Re: Fetch me an author. Now, fetch me another author.

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

Re: Accidental and intentional atom:id collisions

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 do

Re: Accidental and intentional atom:id collisions

On 21 May 2005, at 13:19, Graham wrote: The appropriate 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 docum

Re: Accidental and intentional atom:id collisions

On 21 May 2005, at 12:50, Eric Scheid wrote: On 21/5/05 7:47 PM, "Henry Story" <[EMAIL PROTECTED]> wrote: But perhaps it is not such a problem after all, because perhaps we can have dereferenceable ids that allow us to move entries around. I can think of a few: 1. if an entry moves the

Re: Accidental and intentional atom:id collisions

On 21/5/05 7:47 PM, "Henry Story" <[EMAIL PROTECTED]> wrote: > But perhaps it is not such a problem after all, because perhaps we can have > dereferenceable ids that allow us to move entries around. I can think of a > few: > >1. if an entry moves the old entry position redirects to the new one.

Re: Refresher on Updated/Modified

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

Re: Editorial: rules based on MIME media types in @type attributes

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

Re: Accidental and intentional atom:id collisions

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 fin

Re: Fetch me an author. Now, fetch me another author.

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 d

Re: Fetch me an author. Now, fetch me another author.

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 an

Re: Accidental and intentional atom:id collisions

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

Re: atom:modified : Reducing the cruft

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 atom

Re: atom:modified : Reducing the cruft

Saturday, May 21, 2005, 8:44:39 AM, Anne van Kesteren wrote: > 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 inte

Re: atom:modified : Reducing the cruft

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 atom:modif

atom:modified : Reducing the cruft

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 absent

Re: Refresher on Updated/Modified (oh the irony!)

Saturday, May 21, 2005, 2:04:57 AM, I wrote: > [reposted without so many typos and grammatical errors - reply to either] I just noticed some irony in my attempt to repost that mail about atom:modified, with the intention to disclaim that any "significant changes" had been made, thereby saving a

Re: Refresher on Updated/Modified

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

  1   2   >