RE: Core Component Analysis - SWIFT's Comments

["Blantz, Mary Kay" <mblantz@netfish.com>]

Unique identifiers, probably entirely numeric.

-----Original Message-----
From: Philip Goatly [mailto:philip.goatly@bolero.net]
Sent: Wednesday, January 24, 2001 7:55 AM
To: Blantz, Mary Kay; Steve.GIS.Tompkins@chase.com
Cc: ebXML Core
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"
> >
> >
> >
>
>
>
>
>