RE: COMPLEXITY BIG ISSUE

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

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