Am Dienstag, den 04.10.2005, 14:28 +0200 schrieb Henry Story: > > On 28 Sep 2005, at 14:48, Reto Bachmann-Gmür wrote: > > > > [snip lots of interesting stuff, to get to later] > > > Note that the first two entries share the same value of atom:updated, > > this is a SHOULD-Level violation of section 4.1.1. I think the spec > > should allow multiple entries with the same timestamp iff they > > differ by > > language and/or content-type. In multilingual countries like > > Switzerland > > it is required (as for laws) or at least a matter of political > > correctness (as for press releases) for some publications to be > > published at the same time in all language versions. > > Why not publish content negotiated atom feeds, so that the French > version > of the feed only contains french entries, the German version only German > entries, the Italian one only Italian ones, and the Romansh one only > Romansh > entries? Then the user would subscribe to the feed serving the > entries in > the language preferred by the author. > > Of course since in Switzerland the German, French and Italian > representations > of the feed have to appear simultaneously they will each contain > entries with > identical ids and identical atom:updated time stamps. This would not > contradict > the atom spec which mentions only that in a particular feed document two > entries with the same id should not have the same updated time stamp. > It is > something on the other hand that an ontology of atom would have to be > careful > about (or a database consuming atom feeds), as it would have to take > into > account the possibility of multiple language versions of the same > update of > an entry. This would be a solution not to violate the spec in this point. Still I don't get the intention of the requirement of having different timestamp for entries with different language or content-type. Thanks to http-content negotiation abilities delivering only the version of an entry that best matches the client request is possible and makes generally sense - but as long as I don't understand the rationale in the spec it still feels a bit like a hack.
Also, the HTTP-Accept Header sent by the client when requesting the feed describes the preferred format of the feed itself and not necessarily of its entries. So it may be wrong to conclude a preference on the version of the entries from a header like: "Accept: text/xml, */*; q=0.1". reto
