[ebxml-dev] Re: [ISO8601] Re: New Date Formats.

[Stephen GOULD <sggould@oic.org>]

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	sggould@oic.org
T:	(02) 9953-3583
W:	http://www.oic.org

Stephen GOULD
Partner - EII Projects
HALISA INTERNATIONAL

E:	sggould@halisa.net
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: sue.probert@commerceone.com
> 
> 
> -----Original Message-----
> From: Stephen GOULD [mailto:sggould@oic.org]
> Sent: 26 February 2002 16:35
> To: ISO8601@yahoogroups.com
> Cc: oz-ebxml@eGroups.com; ebxml-dev@lists.ebxml.org
> 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 4.3.2.1):
> > 
> > > 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>
>