Re: Core Component Analysis - SWIFT's Comments

[CANON Stephane <stephane.canon@swift.com>]

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