Re: Core Component Analysis - SWIFT's Comments

[Alain Chapdaniel <alain.chapdaniel@actimum.com>]

I support, it's why I think BSR is useful.
Best regards

Alain Chapdaniel
alain.chapdaniel@actimum.com
ACTIMUM
http://www.actimum.com
----- Original Message -----
From: Blantz, Mary Kay <mblantz@netfish.com>
To: 'Philip Goatly' <philip.goatly@bolero.net>; Blantz, Mary Kay
<mblantz@netfish.com>; <Steve.GIS.Tompkins@chase.com>
Cc: ebXML Core <ebxml-core@lists.ebxml.org>
Sent: Thursday, January 25, 2001 1:33 AM
Subject: RE: Core Component Analysis - SWIFT's Comments


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