Re: Core Component Analysis - SWIFT's Comments

[Steve.GIS.Tompkins@chase.com]

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"
> >
> >
> >
>
>
>
>
>