[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ebxml-dev] Re: [ISO8601] Re: New Date Formats.
Sue - the problem is in the implementation. ISO 8601 is too wide in how it can be interpreted by software developers. With large companies the IT department and the end user can work out how to place a date in a field on a form. Dates can either be generated by a computer systems or entered by an end-user: 1 generated by the customer application eg date of order and required date of delivery 2 generated by the supplier system eg likely date of delivery, date of payment and date of discount payment 3 entered by the end user eg required date by end user You can either 1 allow the end user to type the required date or 2 provide a standard drop down venue that automatically places the date in the right ISO 8601 format However most SMEs do not have IT Departments they rely on software developers. This is why we are proposing a standard ISO 8601 format drop down menu for SME ebXML software developers. Most SMEs when they are setting up their systems do not put in the time differential into their e-mail software programs. The National Telecoms all provide telephone books with the time differentials for each region. Microsoft provides this as part of the Windows operation system. Perhaps a location code is required for E-business applications to calculate the difference between GMT and local time. This location code could be provided by the ISP as part of the service. This could be the zip code in the US or postcode in UK and Australia. It is part of the UN/EDIFACT address structure. However the name and address structure of UN/EDIFACT is very basic and designed before the arrival of the Internet and systems with local intelligence [PCs] drop down menus providing users with choice selections rather than keying in data. The framework of the UN/EDIFACT structure is very good in that it outlines a 3 ch code for each field. However it does not go far enough with modern disciplines like workflow automation to define the documents (and code the documents) in each industry information cycle. Keith FINKELDE Chair of ebXML Australia has pointed out at a number of meetings that the UN/EDIFACT structure is not suitable for ebXML Applications. However after 12 months there does not seem to be any progress in re-defining the address structure of UN/EDIFACT http://www.oic.org/EB/mswg1 (This is on the OIC site rather than ebXML Australia site because for the last 18 months we have informed ebXML Australia that you cannot read the minutes with Netscape. Many of our members are software developers. A number have an aversion to using Microsoft products like Internet Explorer particularly Unix and Linux developers. We have passed on the complaints to ebXML Australia) CONCLUSION If the objective of ebXML includes enabling SMEs to use the Internet for E- business then SME software developers with specific industry application knowledge need to be provided with the tools to develop ebXML applications quickly. Those tools include: 1 A standard Business and Individual ebXML name module 2 A standard ebXML Address module 3 A standard ebXML Date module These should be drop down menus (eg Mr, Ms, Mrs, Prof, Dr) and free type eg Peter HENRY (with a separate field for each name so a sort can be carried out on surnames for different reports and the surname in caps so that everyone knows that the letters in caps are the surname) The OIC background with E-commerce and XML can be reviewed on http://www.oic.org/3a4a.htm My background over the last 15 years with EDI and SMEs can be reviewed on http://www.halisa.net/G/C/HINGCAH2.htm regards Stephen GOULD ebXML Representative OPEN INTERCHANGE CONSORTIUM 11:42 W 27/02/2002 Syd 2089 E email@example.com T: (02) 9953-3583 W: http://www.oic.org Stephen GOULD Partner - EII Projects HALISA INTERNATIONAL E: firstname.lastname@example.org M: 0403-492-849 W: http://www.halisa.net On 26 Feb 02, at 1:10, Probert, Sue wrote: > Hi > > The UN/ECE Recommendation No 7 which can be accessed at > http://www.unece.org/cefact/ is a clear, well-established, recommendation by > UN/CEFACT to use ISO 8601 for formatting dates/times in all information > exchanges related to cross-border or international trade whatever their > syntax e.g. UN/EDIFACT, XML... > > BTW the other UN/ECE Recommendations also offer useful advice relevant for > e-business which are definitely worth investigating! > > regards > > Sue > > Sue Probert > Senior Director, Document Standards, Commerce One Labs > Commerce One > Tel: +44 1332 342080 > email: email@example.com > > > -----Original Message----- > From: Stephen GOULD [mailto:firstname.lastname@example.org] > Sent: 26 February 2002 16:35 > To: ISO8601@yahoogroups.com > Cc: oz-ebxml@eGroups.com; email@example.com > Subject: [ebxml-dev] Re: [ISO8601] Re: New Date Formats. > > > Issue is Communications Time & Resource Cost not storage > > I suggest the issue with dates in E-commerce applications is not disk > storage > but communication time and costs. > > As Ed said ISO 8601 was initially proposed as a data interchange standard - > see > below message. > > If you have been keeping track with what is happening with Space exploration > ref > "E-mail the final frontier" the real issue is to minimise communications > time and > resource costs > http://www.oic.org/V/uveaeca1.gif > > Ian has pointed out in his e-mail on 14 Jan 2001 that very few XML books > refer to > the issue of ISO 8601. We are trying to address that issue by involving the > XML > development groups around the world. > > Hence the proposal for a uniform coded date structure based on ISO 8601 > format. > > As most Data Interchange applications have 3 or 4 date fields eg date of > invoice, > date of delivery, date of order, date of payment due, date of early payment > discount etc uniform date codes, particularly for international trade, are > vital > hence the work carried out by OIC members to provide a uniform date calendar > > based on ISO 8601 for Data Interchange applications > http://www.oic.org/cpt/CPTAEDM1.htm > > It is not designed for genealogy applications but for E-business > applications > which was the purpose behind ISO 8601 > > Do the XML & E-commerce developers think ISO 8601 is the way to go ? > > regards > Stephen GOULD > > On 26 Feb 02, at 0:45, Ed Davies wrote: > > > bam wrote: > > > > > ... Unfortunately, ISO 8601 > > > is far from compact, partly due to leading zeroes in > > > two fields and also due to required punctuation. > > > > Can't argue that ISO 8601 often requires leading zeros but > > the punctuation is not required. It defines two formats: > > "basic" which normally has no punctuation (except in some > > less common cases where punctuation is required to avoid > > ambiguity) and "extended" which does have punctuation. I > > guess the idea is that the choice between the two should > > be made on a trade off between compactness and human > > readability. > > > > Basic: 20020225 > > Extended: 2002-02-25 > > > > Frankly I wonder if compactness has much benefit these > > days. You'd need to store an awful lot of dates for > > two extra characters for each to take much of a bite out > > of a 40GB disk. Putting a sensible standard compression > > scheme into MIME seems more useful than discussing whether > > or not dates should contain a few dash characters. > > > > > (Futhermore, pre-emption of the dash makes that character > > > unusable in its customary role as an indicator for ranges > > > of values -- but that's an issue for another day. ;^> > > > > ISO 8601 uses '/' for ranges of values. Both '/' and '-' > > are commonly used for both date punctuation and for > > indicating ranges though '/' is somewhat more common in > > many national date notations, so perhaps use of '-' is > > an advantage for a "new" date format, giving extra distinction > > to avoid confusion between old and new. > > > > > .... > > > P.S. In all of these schemes, there is also a > > > range problem, which I don't know how to address. > > > While I'm not too worried about Y10K, which may > > > invalidate ISO 8601 after 9999-12-31, I am unsure > > > how (or whether) ISO 8601 refers to the date of > > > Aristotle's birth (much less, the date of the > > > Permian extinction) > > > ... > > > > ISO 8601 starts: > > > > > 1. Scope > > > > > > This International Standard specifies the representation of > > > dates in the Gregorian calendar and times... > > > > It says later (para 22.214.171.124): > > > > > The use of this calendar for dates preceding the introduction > > > of the Gregorian calendar (i.e. before 1582) should only be > > > done by agreement of the partners in information interchange. > > > > Para 4.7 says: > > > > > By mutual agreement of the partners in information interchange > > > it is permitted to expand the component identifying the calendar > > > year, which is otherwise limited to at most four digits. > > > ..... > > > When expanded representations are used, provisions should be > > > made to prevent confusion of the expanded representations, with > > > other date and time representations used by the application. > > > > It says the expansion should be in the form of a sign and(/or?) > > one or more extra digits in the year. > > > > I think they've taken a fairly realistic view of producing a > > workable notation for most applications - leaving the more unusual > > cases to extensions to be defined in the context. > > > > Remember, ISO 8601 is intended primarily for data interchange - > > not for applications intended purely for human consumption. > > > > However, extending its use into this area is a good idea for > > a number of reasons: a) to avoid international component order > > ambiguities, b) to get people used to the format so when they > > come across it in cases where it is intended both for machine > > and human use they are not too surprised, c) to easily allow > > stuff which was originally intended only for human use to be > > understood by machines (e.g., web search engines parsing text > > documents) d) to allow easy sorting, etc. > > > > Adding "BC" or whatever stops a date being strictly in ISO 8601 > > format but most of the above arguments for following the standard > > layout still apply to at least some extent. > > > > A chap went into a museum and asked the age of a dinosaur. The > > keeper told him seventy five million and three years old. "Oh", > > he replied "I didn't realise they could be dated so accurately". > > "Well", said the keeper, "when I joined it was seventy five > > million years old and I've worked here three years now". > > > > Do you want to represent the date of the Permian extinction > > using year, month and day of month, or year, week and day of > > week? I suppose it was global enough that the time zone was > > not too important, particularly as days were quite a bit > > shorter then, I think. They'd have had to apply lots of > > negative leap seconds every day. > > > > Ed. > > > > > > > > ------------------------ Yahoo! Groups Sponsor ---------------------~--> > > Tiny Wireless Camera under $80! > > Order Now! FREE VCR Commander! > > Click Here - Only 1 Day Left! > > http://us.click.yahoo.com/nuyOHD/7.PDAA/yigFAA/zCsqlB/TM > > ---------------------------------------------------------------------~-> > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > > > > > > > ---------------------------------------------------------------- > The ebxml-dev list is sponsored by OASIS. > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.ebxml.org/ob/adm.pl> > > ---------------------------------------------------------------- > The ebxml-dev list is sponsored by OASIS. > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.ebxml.org/ob/adm.pl> >
Powered by eList eXpress LLC