Subject: [Fwd: Re: todo: add language encoding information]

From: James M Snell <[email-masked]>
Date: Thu, 22 Dec 2005 10:17:01 -0800

FYI...

-------- Original Message --------
Subject: Re: todo: add language encoding information
Date: Thu, 22 Dec 2005 19:03:25 +0100
From: Henry Story <[email-masked]>
To: James M Snell <[email-masked]>
References: <[email-masked]>

Hi James, you forgot to send this to the Atom syntax list, where it
will be most useful.

Henry
On 22 Dec 2005, at 18:53, James M Snell wrote:

> (this may not make it to the atom-owl list as I'm not subscribed to  
> that one)
>
> One possibility for this in Atom is to provide multiple Atom  
> documents, each covering their own language.  Given that the date  
> restriction only covers Atom entries within the *same* feed  
> document, the following would be perfectly acceptable:
>
> <feed xml:lang="de">
>   ...
>   <entry>
>     <id>tag:example.org,2005:some_entry</id>
>     ...
>   </entry>
> </feed>
>
> <feed xml:lang="fr">
>   ...
>   <entry>
>     <id>tag:example.org,2005:some_entry</id>
>     ...
>   </entry>
> </feed>
>
> To indicate that the feeds were translations of one another, a new  
> "translation" link rel could be established on the feed level
>
> <feed xml:lang="de">
>   ...
>   <link rel="translation"
>         hreflang="fr"
>         href="http://.../thefeed?lang=fr"
>   <entry>
>     <id>tag:example.org,2005:some_entry</id>
>     ...
>   </entry>
> </feed>
>
> <feed xml:lang="fr">
>   ...
>   <link rel="translation"
>         hreflang="de"
>         href="http://.../thefeed?lang=de"
>   <entry>
>     <id>tag:example.org,2005:some_entry</id>
>     ...
>   </entry>
> </feed>
>
> - James
>
> Henry Story wrote:
>> Sorry again to take so long to respond. I have been a little too  
>> busy to respond recently.
>> On 4 Dec 2005, at 16:42, Simon Phipps wrote:
>>> On Dec 4, 2005, at 14:33, Henry Story wrote:
>>>
>>>> I have written my first blog entry in French [1] which has made  
>>>> me aware that
>>>> it would be very useful to add language information to the atom  
>>>> file generated by
>>>> BlogEd. A menu beneath the Entry icon would probably do the trick.
>>>>
>>>> Henry
>>>>
>>>> [1] http://bblfish.net/blog/page9.html#t2005_12_04.14_17_02_642
>>>
>>> Does Atom allow there to be multiple parallel renditions of a  
>>> blog entry in different languages? I've been discussing with Dave  
>>> Johnson how we might provide a facility in Roller where a blog  
>>> entry might be provided in multiple languages and then select the  
>>> appropriate entry based on the contents of the HTTP GET. If this  
>>> were to be implemented, we'd need a way to express the same  
>>> reality in the Atom feed.
>> This is a complicated and delicate issue. An atom entry has been  
>> syntactically limited by the atom spec by the following clause
>> [[
>>    If multiple atom:entry elements with the same atom:id value  
>> appear in
>>    an Atom Feed Document, they represent the same entry.  Their
>>    atom:updated timestamps SHOULD be different.  If an Atom Feed
>>    Document contains multiple entries with the same atom:id, Atom
>>    Processors MAY choose to display all of them or some subset of  
>> them.
>>    One typical behavior would be to display only the entry with the
>>    latest atom:updated timestamp.
>> ]] last para of section 4.1.1 of http://www.ietf.org/rfc/rfc4287
>> So it is not really possible to put atom entries with the same id  
>> and updated time stamp in a  feed (without a SHOULD level  
>> violation) even if they are translation of each other. That means  
>> that the Swiss would not be able to publish a law with the same  
>> atom id in french and in german, as they are obliged to publish  
>> these at the exact same time by law. (No linguistic preference)
>> If we want to respect this we have to give different translations  
>> of a document different ids. We should be able to specify that  
>> they are translations of each other some other way. Using the Atom  
>> OWL ontology [1] we could do this by adding some translation  
>> relation between the entries. Once this the best way to do this is  
>> settled and that it satisfies our needs it should be possible to  
>> put a proposal to the atom syntax group for an extension to their  
>> xml format.
>> So perhaps something like this is needed
>> [ a :Feed, :Version;
>>     :title [ :value "Example Feed";
>>              :type "text/plain" ];
>>     :link  [ :href <http://example.org/>;
>>              :rel iana:alternate ];
>>     :updated "2003-12-13T18:30:02Z"^^xsd:dateTime;
>>     :author [ :name "John Doe" ];
>>     :id <urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6>;
>>     :entry [ a :Entry;
>>              :title [ :value "Atom-Powered Robots Run Amok";
>>                       :type "text/plain" ];
>>              :link [  :href <http://example.org/2003/12/13/en/ 
>> atom03>;
>>                       :rel iana:alternate ];
>>              :id <tag:example.com,2005/en/atom03>;
>>              :updated "2003-12-13T18:30:02Z"^^xsd:dateTime;
>>              :summary [  :value "After a course of integration in  
>> French philosophy,...";
>>                          :type "text/plain" ];
>>              ext:translation <tag:example.com,2005/fr/atom03>
>>            ];
>>     :entry [ a :Entry;
>>              :title [ :value "Des Robot Atomiques se rebellent";
>>                       :type "text/plain" ];
>>              :link [  :href <http://example.org/2003/12/13/fr/ 
>> atom03>;
>>                       :rel iana:alternate ];
>>              :id <tag:example.com,2005/fr/atom03>;
>>              :updated "2003-12-13T18:30:02Z"^^xsd:dateTime;
>>              :summary [  :value "Apres un cours d'integration en  
>> philosophie francaise...";
>>                          :type "text/plain" ]
>>              ext:translation <tag:example.com,2005/en/atom03>
>>            ];
>> ] .
>> The ext:translation relation above relates a :Entry to an :EntryId  
>> which is to say that it cannot distinguish between one version of  
>> an entry and another. So we would either be saying that each  
>> version of one entry is always going to be a translation of the  
>> other, or that there is some version of the other entry that is a  
>> translation of this one (which is a little too vague for comfort).
>> We could be more precise by giving each entry version its unique  
>> id, in which case we could say that this particular entry is a  
>> translation of that particular entry, which would be more precise  
>> and satisfactory. In N3:
>> [ a :Feed, :Version;
>>     :title [ :value "Example Feed";
>>              :type "text/plain" ];
>>     :link  [ :href <http://example.org/>;
>>              :rel iana:alternate ];
>>     :updated "2003-12-13T18:30:02Z"^^xsd:dateTime;
>>     :author [ :name "John Doe" ];
>>     :id <urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6>;
>>     :entry [ a :Entry;
>>              = _:someid1;
>>              :title [ :value "Atom-Powered Robots Run Amok";
>>                       :type "text/plain" ];
>>              :link [  :href <http://example.org/2003/12/13/en/ 
>> atom03>;
>>                       :rel iana:alternate ];
>>              :id <tag:example.com,2005/en/atom03>;
>>              :updated "2003-12-13T18:30:02Z"^^xsd:dateTime;
>>              :summary [  :value "After a course of integration in  
>> French philosophy,...";
>>                          :type "text/plain" ];
>>              ext:translation _:someid2;
>>            ];
>>     :entry [ a :Entry;
>>               = _:someid2;
>>              :title [ :value "Des Robot Atomiques se rebellent";
>>                       :type "text/plain" ];
>>              :link [  :href <http://example.org/2003/12/13/fr/ 
>> atom03>;
>>                       :rel iana:alternate ];
>>              :id <tag:example.com,2005/fr/atom03>;
>>              :updated "2003-12-13T18:30:02Z"^^xsd:dateTime;
>>              :summary [  :value "Apres un cours d'integration en  
>> philosophie francaise...";
>>                          :type "text/plain" ]
>>              ext:translation _:someid1;
>>            ];
>> ] .
>> So in RDF we have no trouble doing the right thing and we have  
>> choice.
>> It should therefore be possible to express something like the  
>> above in atom syntax. How to do it is of course less clear given  
>> the lack of clear semantics for the atom xml.
>> Henry Story
>> [1] http://groups.google.com/group/atom-owl/browse_frm/thread/ 
>> a5ff6dcca7b512b8
>>>
>>> S.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Thu, 22 Dec 2005 19:35:57 +0100

* James M Snell <[email-masked]> [2005-12-22 19:30]:
> To indicate that the feeds were translations of one another, a
> new  "translation" link rel could be established on the feed
> level
> 
> <feed xml:lang="de">
>   ...
>   <link rel="translation"
>         hreflang="fr"

Is that even necessary? Wouldn’t @rel='self' already work here?

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: "James Holderness" <[email-masked]>
Date: Thu, 22 Dec 2005 19:55:52 -0000

> Is that even necessary? Wouldn’t @rel='self' already work here?

I would have thought @rel='alternate' (an alternate version of the resource 
described by the containing element) slightly more appropriate than 
@rel='self' (a resource equivalent to the containing element). There's also 
the restriction in section 4.1.1 that suggest that the 'self' link is the 
"preferred URI for retrieving Atom Feed Documents representing this Atom 
feed". I think that could be a bit confusing when mixed with hreflang.

Either way though, I agree that a new rel value isn't necessary.

Regards
James

---

From: Henry Story <[email-masked]>
Date: Thu, 22 Dec 2005 21:08:01 +0100

Yes. That is one solution. But what we are looking for is how one can  
state that two entries in the same feed are translations of one another.

Henry

On 22 Dec 2005, at 20:52, James M Snell wrote:

>
> Hmmm.. interesting thought, hadn't considered that.
>
> rel="self" should always point to *this* document, and never to  
> some other document, but if the document referenced is the same  
> document just in a different language, then it is possible?  Good  
> thinking but I'm not sure if it's legal according to the spec.
>
>  <feed xml:lang="de">
>    ...
>    <link rel="self"
>          hreflang="fr"
>    <link rel="self"

---

From: "A. Pagaltzis" <[email-masked]>
Date: Thu, 22 Dec 2005 21:17:21 +0100

* James Holderness <[email-masked]> [2005-12-22 21:00]:
> I would have thought @rel='alternate' (an alternate version of
> the resource described by the containing element) slightly more
> appropriate than @rel='self' (a resource equivalent to the
> containing element). There's also the restriction in section
> 4.1.1 that suggest that the 'self' link is the "preferred URI
> for retrieving Atom Feed Documents representing this Atom

Yeah, agreed. In retrospect I can’t think of why I picked `self`;
`alternate` is clearly the correct choice. D’oh.

Regards,

---

From: James M Snell <[email-masked]>
Date: Thu, 22 Dec 2005 12:34:34 -0800

In that case, the only viable solution is an extension element.  This is 
similar to the Thread Extension use case in which replies may appear 
within the same feed as the original.

Here's how I would do it:

1. Introduce a new <translation> element.

       <translation id="id_of_resource" />

2. Use rel="alternate", hreflang="{otherlanguage}" to point to other 
documents that may contain translations.  I would prefer a "translation" 
link rel but agree that reuse of alternate is better.

- James

Henry Story wrote:
>> rel="self" should always point to *this* document, and never to some 
>> other document, but if the document referenced is the same document 
>> just in a different language, then it is possible?  Good thinking but 
>> I'm not sure if it's legal according to the spec.
>>
>>  <feed xml:lang="de">
>>    ...
>>    <link rel="self"
>>          hreflang="fr"

---

From: James M Snell <[email-masked]>
Date: Thu, 22 Dec 2005 11:52:13 -0800

rel="self" should always point to *this* document, and never to some 
other document, but if the document referenced is the same document just 
in a different language, then it is possible?  Good thinking but I'm not 
sure if it's legal according to the spec.

  <feed xml:lang="de">
    ...
    <link rel="self"
          hreflang="fr"

- James

---

From: Henry Story <[email-masked]>
Date: Thu, 22 Dec 2005 22:33:49 +0100

On 22 Dec 2005, at 21:34, James M Snell wrote:

> In that case, the only viable solution is an extension element.

Yep. I have added James Holderness's solution and clarified the  
points in N3.

> This is similar to the Thread Extension use case in which replies  
> may appear within the same feed as the original.
>

That was like my first example rdf. And my question there was: would  
this mean that the entry containing the translation element was a  
translation of a entry with the given id, or of all entries with the  
given id, or that all entries with the id of the containing element  
were translations of entries with the given id? The problem is that  
when one makes a translation of something one really wants to specify  
which version of the entry pointed to is the translation.  Things may  
otherwise get to be quite misleading.

> 2. Use rel="alternate", hreflang="{otherlanguage}" to point to  
> other documents that may contain translations.  I would prefer a  
> "translation" link rel but agree that reuse of alternate is better.

This solution is best for pointing to the place where the content of  
the entry is translated I suppose. Here we are saying that the  
content is translated at a certain place. In theory the titles and  
the summaries could in both entries remain in english.

[ a :Feed, :Version;
   :entry [ a :Entry;
              :title [ :value "Atom-Powered Robots Run Amok";
                       :type "text/plain" ];
              :link [  :href <http://example.org/2003/12/13/en/atom03>;
                       :rel iana:alternate ];
              :id <tag:example.com,2005/en/atom03>;
              :updated "2003-12-13T18:30:02Z"^^xsd:dateTime;
              :summary [  :value "After a course of integration in  
French philosophy,...";
                          :type "text/plain" ];
              :content <http://example.org/2003/12/13/en/atom0.html>;
              :translation [ = <http://example.org/2003/12/13/fr/ 
atom0.html>;
                             :representation [ :type "text/html";
                                               :lang "fr" ]
                           ]
            ];

     :entry [ a :Entry;
              :title [ :value "Des Robot Atomiques se rebellent";
                       :type "text/plain" ];
              :link [  :href <http://example.org/2003/12/13/fr/atom03>;
                       :rel iana:alternate ];
              :id <tag:example.com,2005/fr/atom03>;
              :updated "2003-12-13T18:30:02Z"^^xsd:dateTime;
              :content <http://example.org/2003/12/13/fr/atom0.html>;
              :translation [ = <http://example.org/2003/12/13/en/ 
atom0.html>;
                            :representation [ :type "text/html";
                                              :lang "en" ]
                           ];

            ];
] .

3. The suggestion by James Holderness

> Alternatively you could create a separate Atom document for each  
> entry and then each entry in the feed would include a @rel='self'  
> link pointing to their corresponding document with  
> @type='application/atom+xml' as well as a @rel='alternate' links  
> pointing to the Atom documents of any translations (also with  
> @type='application/atom+xtml').

I suppose this would be a way to identify particular entries with  
urls so that they could be identified directly, and so the entries  
would be specified as translations of each other. In N3 this would be  
something like my second example, but we use urls to identify the  
entries and place the content at the url location.

That seems more appropriate when one wants the point to a translation  
that translates both the content and the title and the summary (and  
the metadata?).

[ a :Feed, :Version;
     :entry <http://example.org/2003/12/13/en/atom03.atom>;
     :entry <http://example.org/2003/12/13/fr/atom03.atom>
] .

http://example.org/2003/12/13/en/atom03.atom would return the  
following representation
-----8<---
           <> a :Entry;
              :title [ :value "Atom-Powered Robots Run Amok";
                       :type "text/plain" ];
              :link [  :href <http://example.org/2003/12/13/en/atom03>;
                       :rel iana:alternate ];
              :id <tag:example.com,2005/en/atom03>;
              :updated "2003-12-13T18:30:02Z"^^xsd:dateTime;
              :summary [  :value "After a course of integration in  
French philosophy,...";
                          :type "text/plain" ];
              ext:translation <http://example.org/2003/12/13/fr/ 
atom03.atom>.
-----8<---

http://example.org/2003/12/13/fr/atom03.atom would return the  
following representation
-----8<---
           <> a :Entry;
              :title [ :value "Des Robot Atomiques se rebellent";
                       :type "text/plain" ];
              :link [  :href <http://example.org/2003/12/13/fr/atom03>;
                       :rel iana:alternate ];
              :id <tag:example.com,2005/fr/atom03>;
              :updated "2003-12-13T18:30:02Z"^^xsd:dateTime;
              :summary [  :value "Apres un cours d'integration en  
philosophie francaise...";
                          :type "text/plain" ]
              ext:translation <http://example.org/2003/12/13/en/ 
atom03.atom> .
-----8<---

Does that cover all cases?

(I may be a little less quick to respond in the next few days, though  
I'll try my best to keep up on this :-)

Henry

>
> - James
>
> Henry Story wrote:
>> Yes. That is one solution. But what we are looking for is how one  
>> can state that two entries in the same feed are translations of  
>> one another.
>> Henry

---

From: "James Holderness" <[email-masked]>
Date: Fri, 23 Dec 2005 09:56:31 -0000

> within the same feed as the original.

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?

Regards
James

---

From: Henry Story <[email-masked]>
Date: Fri, 23 Dec 2005 11:47:23 +0100

response below...

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.
>

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. So if we take an xml feed with one entry (A below)  
and  two entries with the same id (B, and C below) one of which is a  
translation of the first (I don't have time right now to write out  
the xml in full), and you then extract the facts using the atom-owl  
ontology for example [1], then you will be able to draw a graph like  
the following (not all the facts are drawn)

As you see I drew your translation relation in blue. It relates an  
entry and an id <tag:eg.com,2005/en/atom03>. This id is the id of two  
entries (represented as circles). There is no way you can tell from  
the above relation which of the entries B or C is the translation of  
A. And that is an indeterminacy that as far as translations goes is  
probably unacceptable.

Henry

[1] I explain in more detail how xml and semantics relate here:
http://blogs.sun.com/roller/page/bblfish? 
entry=the_relation_between_xml_and

---

From: Elliotte Harold <[email-masked]>
Date: Fri, 23 Dec 2005 06:37:23 -0500

Henry Story wrote:

> 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. 

I'm not sure if this is technically relevant or not, but in the case at 
hand neither entry is the translation, or alternately both are. Legally 
both are equally valid. This is customary in bi/multilingual 
jurisdictions and international treaties. For example, article 133 of 
the Geneva convention states:

The present Convention is established in English and in French. Both 
texts are equally authentic. The Swiss Federal Council shall arrange for 
official translations of the Convention to be made in the Russian and 
Spanish languages.

In that case, I suppose, neither English nor French is a translation but 
  Russian and Spanish are.

-- 
Elliotte Rusty Harold  [email-masked]
XML in a Nutshell 3rd Edition Just Published!
http://www.cafeconleche.org/books/xian3/
http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim

---

From: David Powell <[email-masked]>
Date: Fri, 23 Dec 2005 11:40:49 +0000

>>  x:id="french_entry_id" />

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 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

---

From: Henry Story <[email-masked]>
Date: Fri, 23 Dec 2005 23:31:22 +0100

On 23 Dec 2005, at 12:37, Elliotte Harold wrote:

> Henry Story wrote:
>
>> 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.
>
>
> I'm not sure if this is technically relevant or not, but in the  
> case at hand neither entry is the translation, or alternately both  
> are. Legally both are equally valid. This is customary in bi/ 
> multilingual jurisdictions and international treaties. For example,  
> article 133 of the Geneva convention states:

I think you have not quite grasped the point my graph was trying to  
make. Perhaps I did not explain myself clearly enough. The graph  
represents a feed with three entries A, B and C.
B and C share the same id. C has an updated time stamp that is after  
B so C is an update of B.
If the translation link from A is pointing to the id that B and C  
share (the red line), then it is not possible to tell which entry A  
is a translation of. Is it B or is it C? But clearly (to a human who  
speaks both english and french) A is a translation of C, not of B. So  
you can't have a link pointing from an entry to an id, without  
loosing some very important information. We need something more  
specific. We need a link pointing from A to C as shown by the blue line.

>
> The present Convention is established in English and in French.  
> Both texts are equally authentic. The Swiss Federal Council shall  
> arrange for official translations of the Convention to be made in  
> the Russian and Spanish languages.

Yes. It is true that if we have a link pointing from A to C then we  
could define the inverse to also be true. That is we could (in OWL)  
specify that the blue translation relation is symmetric. I think that  
is another issue. One can argue for and against this. The swiss would  
probably either want a symmetric translation relation, or make it a  
policy to always have two relations going both ways. This would allow  
us to cover both the Swiss case and other cases such as a relation  
between an entry for Shakespears "Romeo and Juliet" pointing to its  
french translation, where clearly it would be false to state that the  
english version was also a translation of the french version.

I hope this makes my intial intent clearer.

Henry

> In that case, I suppose, neither English nor French is a  
> translation but  Russian and Spanish are.
>
> --

---

From: Walter Underwood <[email-masked]>
Date: Fri, 23 Dec 2005 15:32:43 -0800

--On December 23, 2005 11:31:22 PM +0100 Henry Story <[email-masked]> wrote:
>
> So  you can't have a link pointing from an entry to an id, without losing some
> very important information. We need something more  specific. We need a link
> pointing from A to C as shown by the blue line.

Some people will need that in the guts of their publishing system. Why do
we need it in Atom? Is there something essential that subscribers cannot do
because this isn't represented? This sounds like something needed for the
publishing/translation workflow, not for the general readership.

Extended provenance information is sometimes needed, but there is almost
no limit to that. It certainly does not stop at translation, source, and
translator. I'm reading a new translation of Andersen's tales where 
"Thumbelina" is "Inchelina" because the translator knew the right dialect
of Danish. That is significant, but does it need to be in Atom?

The semantics here should be exactly the same as for dates -- the date
means what the publisher thinks it means. Same for language info. Trying
to get more exact means that the model will be wrong for some publishers
that generate completely legal Atom.

wunder
--
Walter Underwood
Principal Software Architect, Verity

---

From: "James Holderness" <[email-masked]>
Date: Sat, 24 Dec 2005 06:23:28 -0000

> I assume that there is an href missing from that?

Actually no. At least not necessarily. That was to indicate the special case 
where the link was pointing to an entry in the same feed.

> point the link at a static Atom Entry document instead.

I would say that's up to the publisher to decide since it depends on how 
they expect the information to be used. There's nothing wrong with them 
linking to an Atom entry document (and that was one of my suggested 
solutions earlier), but creating a separate document for every entry may not 
be something they're willing to do.

If a client is already subscribed to the feed containing the translation and 
they save all data in the feed then the problem goes away. Alternatively the 
publisher could use the Feed History extension (when it eventually becomes 
available) which would enable a client to search through the archives to 
find the translation if necessary.

> difficult to support attribute extensions in an APP sFrom [email-masked] Sat Dec 24 01:31:34 2005
From: "James Holderness" <[email-masked]>
To: <[email-masked]>, "atom-syntax Syntax" <[email-masked]>,
        "bloged" <[email-masked]>
Subject: Re: [Fwd: Re: todo: add language encoding information]
Date: Sat, 24 Dec 2005 06:23:28 -0000
Sender: [email-masked]

> I assume that there is an href missing from that?

Actually no. At least not necessarily. That was to indicate the special case 
where the link was pointing to an entry in the same feed.

> point the link at a static Atom Entry document instead.

I would say that's up to the publisher to decide since it depends on how 
they expect the information to be used. There's nothing wrong with them 
linking to an Atom entry document (and that was one of my suggested 
solutions earlier), but creating a separate document for every entry may not 
be something they're willing to do.

If a client is already subscribed to the feed containing the translation and 
they save all data in the feed then the problem goes away. Alternatively the 
publisher could use the Feed History extension (when it eventually becomes 
available) which would enable a client to search through the archives to 
find the translation if necessary.

> attribute and forward on a corrupted link element without it.

That had occurred to me and I had another somewhat obscure idea in that 
regard. How wrong would it be to use the anchor part of the URI to refer to 
an entry in a feed the same way you can point to a particular element on an 
html page? That way you wouldn't need an extension attribute for the id 
anymore. Obviously some characters in the id would need to be escaped since 
it's a URI itself, but other than that I don't see any technical problems 
with the concept.

Regards
James

---

From: "James Holderness" <[email-masked]>
Date: Sat, 24 Dec 2005 06:25:35 -0000

> B so C is an update of B.

If you went with my link+hreflang method, this could be handled with an 
additional date attribute in the link, where the date signified the time at 
which the translation was valid. For example:

<entry>
  <id>tag:eg.com,2005:/en/atom03</id>
  <link hreflang="fr" x:id="tag:eg.com,200erver or Atom API

Regards
James

---

From: "James Holderness" <[email-masked]>
Date: Sat, 24 Dec 2005 06:25:35 -0000

<entry>
  <id>tag:eg.com,2005:/en/atom03</id>
  <link hreflang="fr" x:id="tag:eg.com,2005:/fr/atom03" 
x:updated="2005-11-15T18:30:02Z"/>
</entry>
<entry>
  <id>tag:eg.com,2005:/fr/atom03</id>
  <updated>2005-11-13T18:30:02Z</updated>
  <link />
</entry>
<entry>
  <id>tag:eg.com,2005:/fr/atom03</id>
  <updated>2005-11-15T18:30:02Z</updated>
  <link />
</entry>

I've left off the obvious elements and attributes for brevity, but you get 
the idea.

Regards
James

5:/fr/atom03" 
x:updated="2005-11-15T18:30:02Z"/>
</entry>
<entry>
  <id>tag:eg.com,2005:/fr/atom03</id>
  <updated>2005-11-13T18:30:02Z</updated>
  <link />
</entry>
<entry>
  <id>tag:eg.com,2005:/fr/atom03</id>
  <updated>2005-11-15T18:30:02Z</updated>
  <link />
</entry>

I've left off the obvious elements and attributes for brevity, but you get 
the idea.

Regards
James