Comments on Initial Core Components Catalogue Ver 1.01 (Appendix A)

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

Re: Lines 182 and 184 of the Initial Core Components Catalogue Ver 1.01
(Appendix A)

I suppose we're all tired of analyzing date and time to death, but I'm
wondering why there are still EDIFACT-like formats in the date.details
and time.details? References are made to ISO 8601 - supposedly meaning
the date and time will be text strings conforming to that standard.
There is no need for a format - there are only a finite number of  ways
to represent  a date (or time), and each is unambiguous (i.e., there's
none of the MMDDYY or DDMMYY nonsense).  I suggest the date.format.text
and time.format.text entities be removed from the date and time detail
components.  And the remarks for the date and time themselves should
reference ISO 8601.  If we're still unsure what ISO 8601 provides,
previous e-mails on the subject might be reviewed:

http://lists.ebxml.org/archives/ebxml-core/200007/msg00053.html
http://lists.ebxml.org/archives/ebxml-core/200012/msg00019.html
http://lists.ebxml.org/archives/ebxml-core/200101/msg00044.html
http://lists.ebxml.org/archives/ebxml-core/200101/msg00085.html

The "time zone.offset.count" seems unnecessary too - the time zone is an
unambiguous part of the ISO 8601 date-time or time expressions, though
its inclusion as a separate entity bothers me less than the
"date.adjustment.count." No one reading the spreadsheet would ever be
able to tell why such a thing was included.  A time is a time, so what's
the point of the "date adjustment?"

Now, I just happen to know that's something thrown in by the Travel biz,
but I really think it's a quirk of their business - a convenience to the
traveler who would instantly recognize that his arrival occurs on the
day after his departure.  It's an output formatting convention that I
believe is not really part of a "core" component.  If you handed me a
date and time for departure, and a date and time for arrival, I can
easily calculate and print out the itinerary with the arrival time
emblazoned with "+1 day," assuming midnight is crossed.  Nothing should
be carried along in a core component which can be easily calculated.

Finally, there's no need for the "Required (R)" column, as one can
deduce that an item is required from the MinMaxConstraints (i.e., 1..*
and 1..1 with a minimum of 1 occurrence necessarily means "required").
This would allow room on the spreadsheet for more important stuff.

William J. Kammerer
FORESIGHT Corp.
4950 Blazer Pkwy.
Dublin, OH USA 43017-3305
+1 614 791-1600

Visit FORESIGHT Corp. at http://www.foresightcorp.com/
"accelerating time-to-trade"