Re: Core Component Analysis - SWIFT's Comments

[Philip Goatly <philip.goatly@bolero.net>]

Hello Folks,

    I think what I really want to say is that translations are not a good
idea.

    A little story:

    Once upon a time there was an Englishman, a Chinese man and a French
man.

    They wanted to hold a meeting but unfortunately none of them spoke the
others language.

    They decided that they would employ interpreters, but found that
professional
    interpreters were only willing to translate into their mother tongue.

    Thus they found that they needed 6 interpreters:

    English to Chinese
    Chinese to English
    French to Chinese
    Chinese to French
    French to English
    English to French

    3 participants and 6 interpreters.

    They realised that if they held a conference of 50 participants all
speaking different
    languages they would need more interpreters so they employed a
mathematician to
    calculate their requirements.

    The mathematician worked out a formula for them so they could work out
the number of
    interpreters per number of language groups.

    If n is the number of language groups then the number of interpreters is
n*(n-1)

    Which in the case of 50 language groups is 50*49 = 2450

    If however all the interpreters spoke say English then they would only
need 100
    interpreters

    The point is that translation can lead to an exponential amount of
'work' and
    interoperability can have a large overhead.

    This was one of the main planks of EDI when it was first initiated, that
there should be
    an EDI 'lingua' franca and thus only the need to translate from each
participants
    in-house format to EDI and vice-versa.

    I think that it is at our peril that we have translation of tags from
English to say
   Russian or French etc.

    If we are designing for International trade, and one transaction can
involve a
    Buyer, Seller, Advising Bank, Reimbursing Bank, Notifying Party,
Shipper, Freight
    Forwarder, Carriers etc. there would be some merit in codeing the tags
and having the
    Name of the field as an attribute (#IMPLIED) so that local names could
be used for
    readibility and the code able to be looked up in a look up table
depending on a language
    setting.

    Cheers, Phil

    P.S. we even employed such a look up scheme on the Fortran 77 compiler
on the GEIS
          network in the late 70's, giving compiler error messages in local
languages.
         the






----- Original Message -----
From: <Steve.GIS.Tompkins@chase.com>
To: "Philip Goatly" <philip.goatly@bolero.net>
Cc: "Blantz, Mary Kay" <mblantz@netfish.com>; "ebXML Core"
<ebxml-core@lists.ebxml.org>
Sent: Wednesday, January 24, 2001 1:20 PM
Subject: Re: Core Component Analysis - SWIFT's Comments



Seeing as I seem to have not only opened the can of worms, but spille them
all over the boat, let me try and smoothe things over a bit.

This is one of those great international issues. A great example of an
international issue is air traffic control. Would an American or British
airline servicing a destination in the Far East expect their pilots to be
fluent in the language of their destination. Certainly not which is why
most air traffic control stations, all of the ones I have ever spoken to as
a private pilot, have been very fluent in English, regardless of the
torture involved in speaking it. This leads me to the point that if we were
to receive XML components written in, let's say, Japanese we would need to
have someone or something translate this into English so that we can
understand it. This is true for every other country in the world where
Japanese is not the spoken language. This is further heightened by the way
in which we write. This leads to scenarios where people stand, hands on
hips, and say "well what are we going to do about it?"

At the risk of being relabelled as arrogant I would like to reiterate that
the reason we use the English language is because if we used French,
German, Italian or Klingon we would have to translate it before anyone
could use it from a human view point. Similarly if we were sending a
message to a country that does not speak English we would have to go
through the process of translating to the appropriate language. From what I
understand from being slated for this - this is where the whole EDIFACT
thing comes into play. The fact remains that it is going to have to be
written in one or more Earth languages (really??!!) with core components in
the language most recognised internationally. It may not surprise many of
you that a large proportion of the students entering the UK do so to learn
English.

The view point that we are using is that if we receive a message from an
institution in a foreign language we will parse it into one that we can
work with, good old arrogant English. Obviously we are not encouraging
this. Training people in the knowledge of foreign languages for a parsing
exercise is not a great plan.

ST




"Philip Goatly" <philip.goatly@bolero.net> on 24/01/2001 12:55:14

Please respond to "Philip Goatly" <philip.goatly@bolero.net>



To:   "Blantz, Mary Kay" <mblantz@netfish.com>, Steve GIS
      Tompkins/CHASE@CHASE
cc:   "ebXML Core" <ebxml-core@lists.ebxml.org>
Subject:  Re: Core Component Analysis - SWIFT's Comments


Given different tags in different languages etc. how will interoperability
work ???

We had this trouble some time ago (several thousand years) in the Plain of
Shinar - will we ever learn !!!

Cheers, Phil
----- Original Message -----
From: "Blantz, Mary Kay" <mblantz@netfish.com>
To: <Steve.GIS.Tompkins@chase.com>; "Philip Goatly"
<philip.goatly@bolero.net>
Cc: "ebXML Core" <ebxml-core@lists.ebxml.org>
Sent: Wednesday, January 24, 2001 12:28 PM
Subject: RE: Core Component Analysis - SWIFT's Comments


> I haven't wanted to enter this discussion, Steve, but do want to let you
> know that the plan is to start with Oxford English.  People who
> require tags in other languages intend to develop Core Components (and
> tags) in those languages.  We expect French, German, Russian, and
Japanese
> at the very least.  We may even have some people who want to use
American!
>
> Mary Kay
>
>
> -----Original Message-----
> From: Steve.GIS.Tompkins@chase.com [mailto:Steve.GIS.Tompkins@chase.com]
> Sent: Wednesday, January 24, 2001 5:52 AM
> To: Philip Goatly
> Cc: ebXML Core
> Subject: Re: Core Component Analysis - SWIFT's Comments
>
>
>
> I must confess that I have not seen the EDIFACT tags yet. This is
certainly
> something that I will need to do once I manage to find enough time to
> ensure that I am still alive. One thing that I would like to point out,
> even though this is from a point of view within my own morking
enviroment,
> is this.
>
> We are in the process of making our user area more literate in the basic
> use of XML. This saves us time in the long term in that we do not have to
> parse the marked up data into database fields only to have to extract the
> data again and rebuild the mark ups. One of the benefits of the XML model
> is that it should be humanly readable. As we are in England, as William
so
> - shall we say tactlessly - proclaimed it is logical to have the mark ups
> in English. There seems to be much ado here about nothing. Essentially we
> are dealing with an agent and client network that is totally fluent in
> English. Why should we bother with anything other than English as the
> language of choice if:
> 1) It totally fills our needs and requirements unambiguously.
> 2) Nobody other than English capable people are going to use it.
> 3) It provides us with more flexibility than a solution that only
> technically minded people are capable of reading. What are we trying to
> protect here?
>
> I look forward to Mr. Kammerer's inevitable response.
>
> ST
>
>
>
>
> Philip Goatly <philip.goatly@bolero.net> on 24/01/2001 09:49:09
>
> Please respond to Philip Goatly <philip.goatly@bolero.net>
>
>
>
> To:   "William J. Kammerer" <wkammerer@foresightcorp.com>, ebXML Core
>       <ebxml-core@lists.ebxml.org>
> cc:
> Subject:  Re: Core Component Analysis - SWIFT's Comments
>
>
> William - thanks for your comments.
>
> FYI -I have seen in places - not so far from here :-) tag names of 50-60
> characters i.e with end tag 100-120 chars
> and a data 'payload' of  10 chars. - I know bandwidth is larger now but
> ...........
>  f only 'techies' need to look at the tags why not used coded tags - a
lot
> of us can still read EDIFACT messages
>
> Phil Goatly
>
> ----- Original Message -----
> From: "William J. Kammerer" <wkammerer@foresightcorp.com>
> To: "ebXML Core" <ebxml-core@lists.ebxml.org>
> Sent: Wednesday, January 24, 2001 2:23 AM
> Subject: Re: Core Component Analysis - SWIFT's Comments
>
>
> > Upon being presented with Steve Tompkins' examples of labeled tags used
> > in XML based SWIFT messaging, Philip Goatly has gently reminded us that
> > "not every user of ebXML will have English as their mother tongue - in
> > fact - this may surprise you - a great number of people in the world do
> > not even understand English."
> >
> > Yes, this is one more example of the overarching arrogance and
> > tendency towards imperialism that we Americans notice in our cultural
> > cousins, the English. We are, quite frankly, embarrassed for them.
> > Thanks for the reminder, Phil.
> >
> > But, as discussed much before, the tags are most likely to be read only
> > by programmer types, all of whom read English, at least if they're any
> > good.  So that's not as big a problem as it seems at first.  And if the
> > tags are built up in semantic units from a dictionary, like the ISO BSR
> > (Basic Semantic Register), then there are just a relatively few words
> > being used. That's not so bad, is it?  The BSR even includes
> > translations for the Semantic Components' definitions in French and
> > German.
> >
> > Speaking of the BSR: is any use of it going to be made in the names for
> > core components and/or InformationEntityUseNames?  There seems to be
> > some sort of bias against the BSR evident in certain circles, but I
> > notice that Hartmut Hermes has a reference to the BSR in his signature
-
> > so it can't be all dead, yet.
> >
> > I think Phil is also uncomfortable with the notion of big, long tag
> > names built up from semantic units - like those suggested by SWIFT's
> > Jacques Littré: BirthDate, DeathDate, and IncorporationDate.  He'd
> > probably have the same objection to using BSR semantic units as tags:
> > AccountsPayables.Contact.Person.Name, Approval.DateAndTime or
> > Consignee.Location.City.Name. But the intent of these techniques based
> > on ISO 11179 is to give us decomposable names - the same purpose served
> > by  EDIFACT qualifiers.  In actuality, any one set of instances of a
> > particular business message employed in some vertical may only use a
> > small subset of qualifiers (or components of the Information Entity
> > name) - there's only so many different types of parties relevant to
> > Phil's specialty of international trade. Hence, the number of derived
> > tag names would be fairly finite once you press the button to convert a
> > UML data model into an XML schema.
> >
> > Phil wonders "[who] would consider making each country a separate
class?
> > or even worse, who would make each UN-Location Code (UN-LOCODE) of
which
> > there are 30,000 a separate class?"  Actually, no one.  These codes
> > serve, in Bob Miller's term, a "reference" service - as opposed to the
> > "element alias" service provided by the semantic components discussed
> > above.  See in RE: Units of Measure and follow-up commentary, at
> > http://lists.ebxml.org/archives/ebxml-core/200007/msg00073.html.
> >
> > Finally, Phil asks "how are we going to deal with many to many
> > relationships within an XML hierarchy. I am sufficiently old/mature to
> > remember the problem  we had with such things in Hierarchical databases
> > and the factors which led to Relational Databases where relationships
> > are made at run time. With XML we seem to be back to hierarchies which
> > may lead to similar difficulties."  I am far too young to answer this.
> > I will have to yield to Bob Miller.
> >
> > William J. Kammerer
> > FORESIGHT Corp.
> > 4950 Blazer Memorial Pkwy.
> > Dublin, OH USA 43017-3305
> > +1 614 791-1600
> >
> > Visit FORESIGHT Corp. at http://www.foresightcorp.com/
> > "Commerce for a New World"
> >
> >
> >
>
>
>
>
>