Re: Core Component Analysis - SWIFT's Comments

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

Just a précision about BSR.
In the BSR there is a unique identifier but several names (a preferred name
for each language present in the BSR, and if needed others names used as
synonyms of the preferrred names).
Best regards

Alain Chapdaniel
alain.chapdaniel@actimum.com
ACTIMUM
http://www.actimum.com
----- Original Message -----
From: CANON Stephane <stephane.canon@swift.com>
To: Philip Goatly <philip.goatly@bolero.net>
Cc: William J. Kammerer <wkammerer@foresightcorp.com>; ebXML Core
<ebxml-core@lists.ebxml.org>
Sent: Wednesday, January 24, 2001 3:59 PM
Subject: Re: Core Component Analysis - SWIFT's Comments


> I don't think the issue is english/american tags or something else. The
problem of using different languages should be fixed through
> the UID of an element.
> The problem is first (I think) how to identify an XML element. Edifact was
said to be "semantically dispersed". The semantic of a
> data element depends on the meaning of the Segment name, the segment
qualifier, the element name, the element qualifier, ... BSR is
> an initiative leading to give a unique name to an element.
> Jacques's was commenting about the reintroduction of qualifiers in ebXML
CoreComponents.
>
> We have different implementation proposals:
>
> ebXML Core Component:
>
> <Party> ...
>  <Date/Time>
>    <Date>20010101</Date>
> <Time>102300</Time>
> <PurposeCode>birthdate<PurposeCode>
> ..........
>  </Date/Time>
>  <Date/Time>
>    <Date>20800202</Date>
> <Time>102300</Time>
> <PurposeCode>DeathDate<PurposeCode>
> ..........
>  </Date/Time>
> ...........
> </Party>
>
> SWIFT:
>
>    <Party> ...
>       <BirthDate>
>          <Date>20010101</Date>
>          <Time>102300</Time>
>          ..........
>       </BirthDate>
>       <DeathDate>
>          <Date>20800202</Date>
>          ..........
>       </DeathDate>
>       ...........
>    </Party
>
> another one:
>
>    <Birth>
>       <Date>1922-10-16</Date>
>       ..........
>    </Birth>
>
> The BSR proposal would be something like that:
>
> <PartyBirthDate>1922-10-12</PartyBirthDate>
>
> Let's try to determine what is the best representation (we shouldn't spend
too much time discussing the arrogance of the englisk
> speaking world: this is a fact, not an item for discussion).
> We need comments from the people involved with the BSR intiative, from the
XML experts and from people working on translation tools.
>
> Stephane
>
> Philip Goatly wrote:
>
> > 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"
> > >
> > >
> > >
>
>