Re[2]: VS: langauges and tags

["Mark CRAWFORD"<mcrawfor@lmi.org>]

As part of your ongoing discussion regarding language in tags, I would encourage
you all to consider section 2.3 of the draft ebXML Requirements specification
which states -

"To simplify development efforts, all work shall use English. To support
globalization, all ebXML technical specifications will be translatable into the
other official UN languages- French and Russian. Translation into other
languages will be the responsibility of the intended user, although such
translations should be supported in the ebXML repository.  Regardless of
language, and in keeping with the requirements of XML 1.0, all work will be
compliant with Unicode and ISO/IEC 10646 for characters, Internet RFC 1766 for
language identification tags, ISO 639 for language name codes, and ISO 3166 for
country name codes."

    This language is consistent with, and taken from, the approach taken for
developing EDIFACT messages. 

    Mark
Mark Crawford
Research Fellow
______
LMI Logistics Management Institute
2000 Corporate Ridge, McLean, VA 22102-7805
(703) 917-7177   Fax (703) 917-7518
mcrawfor@lmi.org
http://www.lmi.org
"Opportunity is what you make of it"



____________________Reply Separator____________________
Subject:    Re: VS: langauges and tags 
Author: Matthew MacKenzie <matt@xmlglobal.com>
Date:       3/9/00 8:42 AM

Another argument for keeping it simple!

--
Matthew MacKenzie
CTO/VP R&D
XML Global Technologies, Inc.

At 10:38 AM 3/9/00 +0200, Matti.Vasara@fingrid.fi wrote:
>Dear All
>As a non english speaking native but a rather long experience of
>transforming things to one culture to another,  I strongly support, that the
>tags should be made by mnemonic english and translations to other languages
>(cultures) should be made separately by people who know the business and
>their culture. If ebXML should have the terms in many languages, you can add
>half year to the time of the work for every other language and more if the
>cultures are not so near another as those in Portugal and Russia.
>best wishes
>Matti Vasara
>
> > -----Alkuperäinen viesti-----
> > Lähettäjä:    David Burdett [SMTP:david.burdett@commerceone.com]
> > Lähetetty:    9. maaliskuuta 2000 4:14
> > Vastaanottaja:        'Duane Nickull'; Troy R Lowe
> > Kopio:        ebXML-Architecture List; ebXML-TransportÉlists. oasis-open.
> > org
> > Aihe: RE: COMPLEXITY BIG ISSUE
> >
> > Duane
> >
> > I agree. Let's assume English, right now, for all names while we develop
> > them, but actively encourage and support literal translations to other
> > languages such as French and Russian, if groups want to do it.
> >
> > You could then have a very simple utility that did the conversion from
> > language to another.
> >
> > By the way I think that an Invoice in France and Portugal apparantly has
> > to
> > written in the native language for it to be legally valid. So a
> > translation
> > utility might be very useful ... ;-) Can anyone in France or Portugal
> > confirm this.
> >
> > David
> >
> > -----Original Message-----
> > From: Duane Nickull [mailto:duane@xmlglobal.com]
> > Sent: Wednesday, March 08, 2000 10:28 AM
> > To: Troy R Lowe
> > Cc: ebXML-Architecture List; ebXML-Transport@lists. oasis-open. org
> > Subject: RE: COMPLEXITY BIG ISSUE
> >
> >
> > <Troy>
> > What group of humans? English speaking only? This is to enable what? XML
> > should
> >  not be seen by a human if it works.
> > </Troy>
> >
> > The UN, who is sponsoring the initiative, has three official languages.
> > They are English, Russian and French.
> >
> > It has been discussed that we may possibly adopt  a system where
> >
> > ELEMENT=(EnglishTerm || FrenchTerm || RussianTerm )
> >
> > The message structure should be reasonably intuitive.  This means that a
> > human being should be able to somewhat decifer a message.  This is very
> > important for manually constructed messages, error checking, archiving and
> > searching.  It also reduces the system architectural complexity.
> >
> > In short - I am totally against using numerical values for Elements.  We
> > do
> > not want to create another cryptic taxonomy.
> >
> > EXAMPLE:
> >
> > If you encounter:
> >
> > <ebXML>
> >   <Header>
> >      <From>Foo Inc.</From>
> >      <To>Bar Corp.</To>
> >   </Header>
> >   <Message Type="Index">
> >    Blah
> >   </Message>
> > </ebXML>
> >
> > OR:
> >
> > <ebXML>
> >   <En-tête>
> >      <Du>Foo Inc.</Du>
> >      <A>Bar Corp></A>
> >   </En-tête>
> >   <Communique Tapent="facture">
> >    Blah
> >   </Communique>
> > </ebXML>
> >
> > This is certainly more intuitive than
> >
> > <123>
> >   <3422-3>
> >      <993-44321-2>Foo Inc.<993-44321-2>
> >      <128-2>Bar Corp.</128-2>
> > ...
> >
> > You get the idea.
> >
> > Also - in the event that one of the elements was mal formed,  you would
> > need
> > a translation tool to verify the numerical equivalent of your elements.
> > Not
> > a good Idea.
> >
> > Duane Nickull
> >
> >
> >
> >

--
Matthew MacKenzie
CTO/VP R&D
XML Global Technologies, Inc.