RE: Specifying a language preference in the message header.

["Burdett, David" <david.burdett@commerceone.com>]

David

The particular situation I'm thinking of is the text explanation to go along
with an error code. There can be many errors associated with an ebXML header
document and the design principle was that it would be simpler to have a
restricted set of codes to indicate the general category of an error and a
free text field that was used to explain it. This way, it is flexible and
extensible as well as readable by the software engineer that has to fix the
problem.

David

-----Original Message-----
From: David Boreham [mailto:david_list@boreham.org]
Sent: Friday, September 29, 2000 8:48 AM
To: ebXML Transport (E-mail)
Subject: Re: Specifying a language preference in the message header.



> I think it would be a good idea to have an optional attribute/element in
the
> ebXML header document that indicates the preferred language of the sender
of
> a message. This would be used, for example, when creating descriptions of
> errors.
>
> Even if there is a Party Agreement, I think that you might want to vary
this
> on a message by message basis.
>
> Thoughts?

Bad idea.
Error messages imply UI, which is not the province of a message _transport_.
Such things should be conveyed in a machine-readable form, and UI at
the viewer's end can render them in whatever form and language they want.
Furthermore, if you want to convey information about a _person_ or
_role_ (not the same as a message sender), then leverage some existing
scheme such as X.500 or LDAP. Isn't the preferred language a property of the
person rather than the message ? 
(e.g. what if someone changes their
preferred language ? messages out in cyberspace now contain incorrect
information). So I also disagree that it's useful to specify this on a
per-message basis.

My experience is that one only uses natural language encoding in
messages when there is no alternative (e.g. in Internet e-mail,
bounce messages and out of office messages are encoded in
one particular natural language, but that's only because the
designer of the transport originally omitted to specify a machine-readable
form for such information). Is that the case here ? (I'm guessing
no, since this is a newly designed protocol).