On 20/2/05 4:34 PM, "Graham" <[EMAIL PROTECTED]> wrote:
> That's not what I meant. I opposed atom:modified because this use case
> wasn't on the table then. I oppose multiple ids partly because we don't
> have atom:modified. You can't have one without the other.
if this use case was on the table back then, and you were to consider the
question in that light, where would you stand?
(actually, we could have atom:modified while still outlawing multiple id's,
but you are right that atom:modified is required to disambiguate if multiple
id's are allowed.)
> My real problem with atom:modified is that it's unnecessarily tied to
> the Last Modification Date semantic, when it would work just as well
> for this purpose if it weren't. We just need a date with the constraint
> "date(a)<date(b) whenever entry instance a is older than entry instance
> b". This would make it easier to generate in various scenarios, and
> sidestep the problem of defining what a "modification" is.
heh -- one way to then generate to fit your requirements would be
atom:modified := atom:published + sequential-number
that is, increment the atom:modified by one second for every version.
Semantically, it would work ... for comparing two instances of one entry. It
wouldn't work for establishing if an entry was modified before or after
[some event moment] (eg. close of the stock exchange).
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.
>> 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.
>>
> No, since the HTTP spec says that any mime type is possible, whereas the Atom
> spec says ids are "universally unique". If it's wrong to then think you won't
> find the same id twice in the same document, the spec needs to say so.
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.
e.
