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 intend using >> it frequently? >> >> 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:updated). > I think this will result in people misusing the field. It is hard to predict, but: > Either giving atom:updated the last modified time I think that these publishers will implement atom:updated incorrectly regardless of whether atom:modified is defined, and whether it is optional or not. If atom:modified isn't defined at all, then this would be quite a significant risk. > or giving it the last significant modification time and simply > omitting atom:modified because that is extra work. Yes, this sounds like a risk. We could add a warning about what the consequences might be: "The modified date MAY be used by processors to select the latest revision of an entry. If multiple revisions of an entry exist with the same atom:modified value, then processors MAY select any available revision as the latest." This would act as a good replacement for the contentious paragraph about atom:updated that was dropped from PaceAllowDuplicateIDs. > If it is introduced in some optional fashion it should not relate to > another date construct I think. I support atom:modified whether it is syntactically mandatory, or whether its value is implied if absent. As an alternative, I'm also open to suggestions of a sequential revision id element, but I prefer atom:modified. -- Dave
