Chairs/Editors,
- I think that this discussion (repeat ids) is architecturally significant in terms of how Atom layers onto the Web and is best taken forward under feed state,
- Feed state discussion ought to deal explicitly with entry state, as that's the more difficult case.
Graham wrote:
> On 20 Feb 2005, at 4:38 am, Eric Scheid wrote:
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.
Graham, Eric,
My thinking goes like this,
- Is there a difference between an entry and the chunk of XML you see in a feed?
- If there is, it will be in the same way there is a difference between a resource and a representation in web architecture.
- If you *don't* think a difference exists between an entry and the chunk of XML you see in a feed, there may be things you can't sensibly say [1]. For example if we disallow multiple appearance of an id in one feed we might as well disallow multiple appearance of an id across all feeds, for consistency. That, or document our spec's private definition of the word "unique".
- If you *do* think a difference exists between an entry and the chunk of XML you see in a feed, there may be some practical limitations. For example we will want to ask what's the difference operationally between two Entries that have been assigned the same id and the appearance of two entries with the same in an Atom document that represent the Entry at different states? What's the test that distinguishes between those two cases?
- That we can start sending multiple representations of a resource each marked as so inside another single representation I suspect extends web architecture. I looked and didn't see any support for this idea in AWWW. Whether it's tunneling, abuse, or a new application layer I don't know.
- Maybe the WebDAV folks have been through this. HTTP has no obvious use cases or support for serving up resource state in one entity body rather than as a stream of entities.
My opinion is that keeping XML representations of entries distinct from entries affords the most flexibility and maximises internal consistency for the kind of use cases feeds support [2]. It will be an arbitrary limitation of language if Atom can't deliver entries with the same id in the same feed - I don't believe that limitation will be respected in practice. It also means we're (possibly) formalizing something for the Web that hasn't been done before.
cheers Bill
[1] I emphasise 'sensibly say' here rather than 'sensibly do'. Just because or spec can't say something doesn't mean people won't try to do it if they think they need to.
[2] I spend a lot of time dealing with identity issues in my job. I've come to believe that neither unique ids or content based identity or a combination of both can eliminate all ambiguities. Sometimes you have to guess whether two things are the same no matter what model you're working with.
