Re: Entries in multiple language
Am Mittwoch, den 05.10.2005, 07:08 +0800 schrieb Zhang Yining: > Reto Bachmann-Gmür wrote: > > >I'm trying to implement Atom support for KnoBot [1], the KnoBot CMS > >supports entries and feeds in multiple language with http-language > >negotiation. > > > >Reading the spec I'm not sure how an entry should be described in > >multiple language, more specifically how updates of a multilingual entry > >should be communicated. > > > >The examples below are based on a real press release published by my > >employer the Swiss Refugee Council [2], the URLs are real and refer to > >the multilingual press release. For the purpose of the example however, > >I made fictional changes to the content. > > > >My questions are: > >- Is this the atom-way of dealing with different language versions? > > > > > Is it possible that different languages have different ID's? Why not? But the aggregating agent should know how to find out that the items are equivalent and present only one version to the user. I guess the spec should tell implementors how to handle this. reto
Re: Entries in multiple language
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
Re: Next and Previous
James Holderness wrote: > Thomas Broyer wrote: >> Compare their atom:[EMAIL PROTECTED]"self" and >> @type="application/atom+xml"]/@href, they'll point you to the "start" of >> the "list", the one whose author and copyright apply. > > On the whole I tend to agree, but since there isn't a "self" link in > either of the RSS formats and Mark would like this extension to be format > neutral, he would either have to introduce an equivalent element into the > spec or strongly suggest that RSS feeds include a "self" atom:link. Maybe one more reason to use an atom:link instead of fh:prev... > Technically it isn't even required that all Atom feeds have such a link, > so either way it's something worth clarifying. Agreed. >> (Actually, author >> and copyright should really appear in "history feed documents" as well, >> aggregators shouldn't "apply copyright" from one document to other >> documents linked from it). > > Technically yes, but try and imagine how an aggregator might handle that > sort of thing. The feed may be made up of a collection of documents, but > from the user's point of view it's all just one big feed. A copyright > message is the sort of thing that would show up once in a properties > dialog for the feed, or somewhere in the header or footer in a "newspaper" > view. Hmm, right. > It's highly unlikely an aggregator would try and track multiple copyright > messages and display them on a per item basis. atom:rights at feed-level don't apply to its entries, just to the feed as it stands. If you want to grant/restrict rights at an entry-level, use the entry-level atom:rights. I can understand how an entry-level atom:rights could be presented to the end-user, but I can't imagine how it could be done for the feed-level atom:rights, given that it can change during the feed's "life". The only solution I can see is to store feed metadata on an atom:source inside each entry, so you can ask for the entry-level and feed-level atom:rights for each entry in your aggregator. > As for author, if you've got item-level author elements you should be ok, > but if there aren't, the aggregator is quite likely to take the last > feed-level author it received and apply it to all subsequent items. It can > be argued that that's a bug, but it's not unreasonable to imagine than > many aggregators might do such a thing unless explicitly told not to. Aggregators are more likely to copy/paste de feed-level authors into each entry and totally forget about feed-level ones. -- Thomas Broyer
Re: Next and Previous
Thomas Broyer wrote: Compare their atom:[EMAIL PROTECTED]"self" and @type="application/atom+xml"]/@href, they'll point you to the "start" of the "list", the one whose author and copyright apply. On the whole I tend to agree, but since there isn't a "self" link in either of the RSS formats and Mark would like this extension to be format neutral, he would either have to introduce an equivalent element into the spec or strongly suggest that RSS feeds include a "self" atom:link. Technically it isn't even required that all Atom feeds have such a link, so either way it's something worth clarifying. (Actually, author and copyright should really appear in "history feed documents" as well, aggregators shouldn't "apply copyright" from one document to other documents linked from it). Technically yes, but try and imagine how an aggregator might handle that sort of thing. The feed may be made up of a collection of documents, but from the user's point of view it's all just one big feed. A copyright message is the sort of thing that would show up once in a properties dialog for the feed, or somewhere in the header or footer in a "newspaper" view. It's highly unlikely an aggregator would try and track multiple copyright messages and display them on a per item basis. As for author, if you've got item-level author elements you should be ok, but if there aren't, the aggregator is quite likely to take the last feed-level author it received and apply it to all subsequent items. It can be argued that that's a bug, but it's not unreasonable to imagine than many aggregators might do such a thing unless explicitly told not to. Regards James
Re: Next and Previous
James Holderness wrote: > > Mark Nottingham wrote: >> Probably the closest thing to what you want is this proposal: >> http://www.ietf.org/internet-drafts/draft-nottingham-atompub-feed- >> history-04.txt >> >> It has "previous", but not "next". > > It just occurred to me when reading this message that there may be some > advantages to having a "next" link to go along with the "prev". I realise > you don't need it in order to reconstruct a feed's history, but it does > provide you with a certain amount of validation. For example, it's > possible that someone could create an empty feed with nothing but their > own title, author and copyright messages and a "fh:prev" link to someone > else's feed in order to claim credit for a publication that wasn't their > own. If an aggregator could rely on the existence of a "next" link it > would be able to check for issues like that. Compare their atom:[EMAIL PROTECTED]"self" and @type="application/atom+xml"]/@href, they'll point you to the "start" of the "list", the one whose author and copyright apply. (Actually, author and copyright should really appear in "history feed documents" as well, aggregators shouldn't "apply copyright" from one document to other documents linked from it). If the "borrower" uses an atom:[EMAIL PROTECTED]"self"]/@href different from the one found in history documents, aggregators should issue a warning. They could also dereference the @href and see if they are redirected to the final same URI. If the "borrower" uses the same atom:[EMAIL PROTECTED]"self"]/@href as the one found in history documents, aggregators should subscribe to that URI and not the "borrower"'s one, so the "borrower" can't claim anything. I think atom:[EMAIL PROTECTED]"self"] is sufficient, there's no need for a "next". -- Thomas Broyer
