Bob Wyman wrote:
In this particular debate, the core issue is "What is a Feed Document?" I have long contended that a Feed Document is a "sliding window" on a feed. Sayre and others have said that a Feed Document is "a representation of the current state of a set of entries." The difference is significant. For instance, if you accept the "sliding window" view, then since a feed (the abstract thing) can have multiple instances of entries with the same atom:id, then it is obvious that a Feed Document should have the same property. On the other hand, if you accept the "current state" definition of a Feed Document, you end up saying that while a Feed can have multiple same-id instances, it is clear that a Feed Document cannot since there is only one "current state" of a resource at any one time.
If I don't take a technical interpretation of the word 'set', there's no useful distinction (which is to say I don't see a need to specify
one over the other).
In either case, the definition of "Feed Document" implies the
answer, without debate, to the question: "Can a Feed Document contain
multiple entries with the same atom:id?" Had we dealt with architectural
issues, this debate would not and could not be happening.
With no malice: you're assuming we'd be finished dealing with the architectural issues by now.
Of course, adopting "current state" instead of "sliding window" also means that we have to invent the atom:archive type so that we can produce the sliding window view which is implied by the archive requirement. Thus, we're making things more complex by offering both "current state" and "sliding window" views.
The archive element is being invented so people can treat the entire lump of XML as an archive. It's a control code, not an artefact of a model.
cheers Bill
