On 4 Apr 2005, at 4:32 am, Paul Hoffman wrote:
This isn't a negotiating game. We have to have technical reasons for our assigning requirements levels.
Right:
1. Feed level ids.
By all reasonable web conventions, requesting a feed from a particular URI can be expected to only ever return one particular feed resource. Whereas, the request will also return an essentially random combination of entry resources. Entry ids are a MUST because of the latter, which doesn't apply to feeds.
A separate feature of entry or feed ids is comparison and duplicate-removal across URIs. Since many users/implementers may choose not to do this due to concerns over security and potentially unexpected-behaviour, it can be described as "truly optional" functionality, which makes it MAY.
2. Link rel=self
Subscribing to feeds is a fundamental feature, and since the whole purpose of "self" is to make it simple and reliable, this element is not optional, and it's reasonable to say it must be present. But I can think of a few edge cases where the service generating the XML may not know its eventual URI, and of course there may be circumstances where there isn't one. This is the only reason I can think of to omit it. Since "SHOULD" allows implementers to wimp out for any reason they choose, I think the appropriate wording is "MUST where one exists and is known".
3. Link rel=alternate
Sorry Sam, but this is "truly optional" as per MAY. Being able to click back to the home page is nice, but how is it an "absolute requirement"?
Graham
