On 20 Feb 2005, at 4:30 pm, Eric Scheid wrote:
if this use case was on the table back then, and you were to consider the
question in that light, where would you stand?
I like the model where the feed content is approximately "The current version of the latest entries". I don't think anything else makes much sense, least of all "Various states past and present of various entries (some assembly required)".
heh -- one way to then generate to fit your requirements would be
My idea would be that the originating server would simply stamp entries with the current time during feed generation, so if they get mixed up in transit by third parties or caches the later version would still be known. Note the originating server doesn't have to store or keep track of anything.
As to defining "modification" ... I was writing spec text which attempted
just that ... I was working towards the idea that any changes in values of
atom:entry elements, other than serialisation (including character encoding
and element order), and ignoring any changes in referenced resources.
But that gets complicated to generate cleanly. When you edit your feed template you need to do something like:
if (entry modification date > date template was edited)
print date template was edited
else
print entry modification dateGenerating a last modification date according to someone else's idea of modification is not pretty.
My apologies: I was making an analogy, not providing an example. As such,
ignore the specifics of the analogy. I should have just written "Spec FOO is
silent on X, therefore X is verboten". Which is a nonsense position.
I wouldn't define the phrase "universally unique" as Atom being silent. It is massively open to interpretation since the literal meaning is nonsense, and I suppose conveying no useful information could be interpreted as silence.
Graham
