Friday, December 23, 2005, 10:47:23 AM, Henry Story wrote:
> On 23 Dec 2005, at 10:56, James Holderness wrote: >> >> The similarity to the Thread Extension also occured to me, but I >> didn't have time to write more about it earlier. My thought was >> that we could perhaps get by with an extension attribute to the >> link element that would work for both cases. The link element >> already has an href for pointing to the feed itself, so all we need >> is an id to point to a particular entry in the feed. I guess for >> the Thead Extension you'd also need a new rel value though. >> >> An example thead reply-to link would look something like this: >> >> <link rel="in-reply-to" >> type="application/atom+xml" >> href=http://www.example.org/feed1.atom >> x:id="entry1_id" /> >> >> An example translation link would look something like this: >> >> <link rel="alternate" >> type="application/atom+xml" >> hreflang="fr" >> x:id="french_entry_id" /> >> >> What do you think? I assume that there is an href missing from that? Isn't it likely that the entry will have been dropped from the end of the feed by the time anyone dereferences it? Would it be better to point the link at a static Atom Entry document instead. I've said it before, but I strongly dislike extending standard elements by adding namespaced attributes. I think that it is a failing that the specification defines several extension points, then pretty much says that you can extend anything pretty much anywhere, and fails to explain why some options might be better than others. It is difficult to support attribute extensions in an APP server or Atom API without explicitly coding support for each one. It is quite likely that some implementations will fail to preserve the namespaced attribute and forward on a corrupted link element without it. The spec's statement that "the role of other foreign markup is undefined by this specification", would just be an unhelpful comp.lang.c-ism, except C does at least clearly define the meaning and implications of the term "undefined". But anyway... > The problem as I explained a little quickly in my mail yesterday, is > that you are relating a entry and an id. Because there can be any > number of entries with the same id it won't be clear which entry is > the translation. The description of atom:id in the spec flounders slightly, but I assumed that the intention was that representations of entries only vary over time. The use of the word "revision" implies that to me. So, the relation is to any revision of the entry with that id, though the latest is probably most relevant. Unlike HTTP, Atom Syntax can't support conneg, so I don't think that it would be useful for entries to vary over anything other than time. If you want to support multi-languages, I think it is better to build that on top of Atom's infrastructure via linking, rather than underneath it via stretching the scope of the entry id. -- Dave
