[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Comments on Initial Core Components Catalogue Ver 1.01 (Appendix A)
i don't normally get into these message exchanges, but did want to respond to two of your comments. First, i believe that we are required by airline regulations to send the date adjustment factor (not everyone can always deduce this). Concerning your statement on 'required', in the overview document that accompanies the catalog 'required' is shown to mean ' To specify if the entity is required as part of the minimum entity data requirements.' which is somewhat different than the min/max info. paula "William J. Kammerer" To: James Whittle <wkammerer@foresigh <james.whittle@e-centre.org.uk> tcorp.com> cc: ebXML Core <ebxml-core@lists.ebxml.org> Subject: Comments on Initial Core Components 03/07/01 12:59 PM Catalogue Ver 1.01 (Appendix A) 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" ------------------------------------------------------------------ To unsubscribe from this elist send a message with the single word "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC