RE: Core Component Analysis - SWIFT's Comments

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

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