Thomas Broyer wrote:
Your Pace is incomplete (no mention of the cardinalities of the
app:title element wrt xml:lang).
I'm not fussed about how often a specific xml:lang value appears in a
group of titles. I'll wager most code will just pick the first one it
finds in document order if we don't say anything.
If someone wants to write the constraint in, go ahead, but I'll wager if
that actually did happen, it'll "just" be a bug somewhere and we'll have
designed in a validation error that people have to check for (if we say
SHOULD or MUST). Whereas in the desert of the real, people could just
mush on via bug reports.
Plus, Atom (RFC4287) does not allow multiple atom:title, atom:summary,
atom:content or any other language sensitive construct.
I see your point, but it's not an RFC4287 document. The app:title elem
is in the http://purl.org/atom/app# namespace.
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)?
I don't mind. But some i18n aware web systems end up with policies that
do conneg along with other approaches (like stored user preferences). I
wouldn't want to disallow that.
cheers
Bill
