2006/7/6, Bill de hÓra <[EMAIL PROTECTED]>:

Joe Gregorio wrote:
>
> On 7/4/06, Elias Torres <[EMAIL PROTECTED]> wrote:
>> 7.1 Should we have language-aware titles in app:collection? 7.2.2.1
>> says that @title is language sensitive. I guess you may use xml:lang,
>> but what about multiple language versions of the title.
>
> Bah, you're right, @title should be an element not an attribute
> and we should allow mulitple child elements as long as none
> of them have the same xml:lang value. Good catch.

+1.

http://www.intertwingly.net/wiki/pie/UseElementsForAppCollectionTitles

Your Pace is incomplete (no mention of the cardinalities of the
app:title element wrt xml:lang).

Plus, Atom (RFC4287) does not allow multiple atom:title, atom:summary,
atom:content or any other language sensitive construct. A language
sensitive value is always given in exactly one language. If you want
to serve a feed or entry in different languages, you have to either
send duplicates (be careful about the atom:id+atom:updated unicity
constraint!) or use content negotiation.
The idea behind the Pace (although not expressed in the Pace, but
given above by Joe Gregorio) suggests client-side content negotiation
(the client will display one version of the title depending on user
preferences; or maybe it will display all versions at once? ouch!).
If we go the content negotiation way, why not using server-side /
transparent content negotiation and send only one language (using the
current, draft 09, attribute-based, document format)?
Otherwise, do as with Atom feeds and entries: provide distinct IRIs
depending on the language (service.en.atomsrv, service.fr.atomsrv,
etc.) or duplicate workspaces (once in English, then in French, etc.)

Conclusion: I'm -1 to the idea expressed by Joe Gregorio above (which
is not what the Pace says)

--
Thomas Broyer

Reply via email to