Re: Core Component Analysis - SWIFT's Comments

[Steve.GIS.Tompkins@chase.com]

I would like to put my two cents worth in here at this point.

For the past year and a bit we have been devising an XML based solution for
our SWIFT messaging, based purely on their ISO 15022 standards. As far as
dates are concerned we have adopted the following, using settlement date as
an example:

<Settlement>
  <Date>...</Date>
</Settlement>

This has been used purely from the point of view that other components may
be added for date fields, especially time and, in some circumstances,
amounts, currencies and so on. In this scenario with time the mark up would
become:

<Settlement>
  <Date>...</Date>
  <Time>...</Time>
</Settlement>

Another XML feature that we have used is the use of attributes to define
currencies. Settlement amount, with a USD currency would be marked up as:

<SettlementAmount Curr="USD">999.99</SettlementAmount>

I am not saying that this is the defined correct method of doing this. This
is done based on the XML rules as defined in the reading that I have done
in this regard. All comments appreciated.

Steve Tompkins
Business Systems Officer
J P Morgan Chase and co.

---------------------- Forwarded by Steve GIS Tompkins/CHASE on 22/01/2001
15:19 ---------------------------


"William J. Kammerer" <wkammerer@foresightcorp.com> on 22/01/2001 14:51:38



To:   ebXML Core <ebxml-core@lists.ebxml.org>
cc:
Subject:  Re: Core Component Analysis - SWIFT's Comments


Jacques Littré, in the "SWIFT Comments on the 'Core Component Aggregate
Entities' ebXML CC Document," advocates getting rid of EDIFACT-like
qualifiers.  Instead of hiding the semantics of a <Date/Time> aggregate
in a "PurposeCode," Jacques reasonably suggests using the
InformationEntityUseName as the tag name itself, eliminating the
PurposeCode describing the particular kind of date:

   <Party> ...
      <BirthDate>
         <Date>20010101</Date>
         <Time>102300</Time>
         ..........
      </BirthDate>
      <DeathDate>
         <Date>20800202</Date>
         <Time>102300</Time>
         ..........
      </DeathDate>
      ...........
   </Party

As an aside,  I'm a little confused by the ellipses in <BirthDate> and
<DeathDate>, since there's very little more that one could add to these
elements: date and time are pretty much all you need to describe a
BirthDate.

But this does inspire some observations, motivated by Martin Bryan's
"The need for process-based semantic sets," at
http://www.sgml.u-net.com/semantics.htm. Since the example goes to the
trouble of enveloping subordinate <Date> and <Time> elements, there's no
need for the "Date" suffix in <BirthDate>, which unnecessarily restricts
its extension to further describe attending facts to a "Birth" event:
Location, Hospital, Attending Physician, Weight, etc., etc. The
"context," if you will (pardon the overloaded use of the word), is set
by the Name of the enclosing tag;  all subordinate tags can be assumed
to pertain to a Birth:

   <Birth>
      <Date>1922-10-16</Date>
      <Location>
         <CityName>Cincinnati</CityName>
         <CountryCode>US</CountryCode>
         <CountrySubEntityName>Ohio</CountrySubEntityName>
      </Location>
      ..........
   </Birth>

A <Date> element, based on the XML Schema "date" type, is understood to
be expressed in the ISO 8601 extended date format   Likewise, it's
understood that the <CountryCode> basic core component is expressed as
an ISO 3166 2 alpha country code.  The <CountrySubEntityName> semantics
could be subsumed into <CountryCode> if we were to agree that the latter
could be represented by an ISO 3166-2:1998 country (and optional
subdivision) code;  thus <CountryCode>US-OH</CountryCode> would
unambiguously identify Ohio, the home of Warren G. Harding.

Since everything enveloped within <Birth> describes the birth event,
there's no need for a redundant "Birth" prefix on any of the enclosed
element tag names.  And now the ellipses make sense, because there's
clearly more information that we could see pertaining to a Birth event.
The same stuff found within <Birth> would also find a place in
describing Death events.

The above is a nice collection of data useful for most business
applications which require birth date and location information.  Rarely
would the birth time be recorded, especially for an adult, but the
<Date> could easily be replaced by:

   <DateAndTime>1922-10-16T10:40-0500</DateAndTime>

But if Birth Date (and Time, for whatever reason) were the only desired
facts pertaining to the Birth, the component instance should be able to
be abbreviated as:

   <BirthDateAndTime>1922-10-16T10:40-0500</BirthDateAndTime>

Or more usefully, in business applications, as:

   <BirthDate>1922-10-16</BirthDate>

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"