Re: Core Component Analysis - SWIFT's Comments

[Philip Goatly <philip.goatly@bolero.net>]

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