OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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

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

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:


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:


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:


Or more usefully, in business applications, as:


William J. Kammerer
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"

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC