Re: Core Component Analysis - SWIFT's Comments

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

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"