Last modified: 2005-11-17 00:24:57 UTC
Feed.php generates a unique ID every time a user loads the Recent Changes feed.
According to lines 256-257 of that file, this is because "Atom 1.0 requires a
unique, opaque IRI as a unique indentifier [sic] for every feed we create." But
"feeds" in Atom aren't the documents generated in response to a user request,
they are "lists of related information," and an "Atom Feed Document" is merely
"a representation of an Atom feed," it isn't the feed itself.
Moreover, the "atom:id" element description states that "When an Atom Document
is relocated, migrated, syndicated, republished, exported or imported, the
content of its atom:id element MUST NOT change," and IDs on blogger.com, whose
programmers had a major role in the development of the Atom spec, don't change
when a user reloads them or even when a new entry gets published to them.
Feed IDs should remain the same between feed loads in MediaWiki too.
You should talk to the standards committee to have the document corrected,
>You should talk to the standards committee to have the document corrected,
Perhaps I was unclear before, but when I said that feeds are "lists of related
information" I was quoting from the spec:
And when I said that an "Atom Feed Document" is merely "a representation of an
Atom feed" rather than the feed itself, I was also quoting from the spec:
Finally, when I quoted the numerous conditions (in particular republication)
under which the atom:id element must not change, I was quoting from the spec:
It's pretty clear that the Atom 1.0 spec that was published by the IETF
standards committee standardizing the Atom syndication format does not support
the idea that feed IDs should change every time a user loads a feed document
over the web. Rather, it defines feeds as lists of related information, says
that feed IDs must uniquely identify feeds, and requires them to stay the same
every time documents representing those feeds are loaded.
Ok, experimenting with alternate ids and stuff...
Changed to just the permalink, without the extra crap to make a unique URL like
the spec's unclear language appears to ask for.
Thanks Brion, I appreciate the quick fix!