Re: Core Component Analysis - SWIFT's Comments

["William J. Kammerer" <wkammerer@foresightcorp.com>]

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"