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


                    "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:


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

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC