On 20 Feb 2005, at 4:38 am, Eric Scheid wrote:
You opposed it because you couldn't foresee any use case for it, and now you
have a use case for it but you say that that use case should be banned
because you opposed atom:modified.
That's not what I meant. I opposed atom:modified because this use case wasn't on the table then. I oppose multiple ids partly because we don't have atom:modified. You can't have one without the other.
My real problem with atom:modified is that it's unnecessarily tied to the Last Modification Date semantic, when it would work just as well for this purpose if it weren't. We just need a date with the constraint "date(a)<date(b) whenever entry instance a is older than entry instance b". This would make it easier to generate in various scenarios, and sidestep the problem of defining what a "modification" is.
Naïve or smart? I subscribe to one feed which is the top headlines for that
site, and I also subscribe to all headlines for one category at that site.
The "naïve" thing to do there would be to not conflate entries with
identical id's.
No, I'm talking about storing the entries retrieved from different uris in the same local record and letting them overwrite each other. A really smart aggregator would inform the user that they got different versions from each place, and let them see both.
None. That's why it should be explicitly barred, since no software is expecting it.
Nonsense. That's like arguing that http agents should only support those
mime-types which were already defined oh so many years ago. No software
currently exists that can possibly be expecting "application/foo", but that
doesn't mean "application/foo" is an illegal mime-type.
No, since the HTTP spec says that any mime type is possible, whereas the Atom spec says ids are "universally unique". If it's wrong to then think you won't find the same id twice in the same document, the spec needs to say so.
Graham
