Subject: RE: AW: ISO 8601 anyone?? And more on Parties.
The presentation text for an item is as much a 'data element' as is an 8601-formatted string, and that is the definition of a core component as given by the CC Naming document. I hear you that specific syntax is not on the table, but sometimes a picture is worth a thousand words. My point Mike was that issues of regional differences in presentation are separable from whether there is an 8601 string in the datastream or not. Thanks, John > -----Original Message----- > From: Mike Rawlins [mailto:email@example.com] > Sent: Thursday, April 19, 2001 11:23 AM > To: ebXML core > Subject: Re: AW: ISO 8601 anyone?? And more on Parties. > > > Excuse me if this is a dumb question, but what does this > discussion have to do > with "syntax neutral" core components? I don't see any relevance > other than to > settle whether or not the dates/times referenced as Core > Components always need > to be in a specific format. The ebXML Requirements Spec doesn't > mandate ISO > 8601 specifically, but it does implicitly by mandating the use of > appropriate, > existing international standards. > > Whether dates are presented as elements or attributes in an > instance document, > and whether or not they also have presentation formats, seem to me to be > implementation issues that might be relevant for other efforts > (EWG, X12, OAG, > etc.), but not for ebXML. > > John McClure wrote: > > > Again, I think that both encodings -- a presentation encoding > and an 8601 > > encoding -- are necessary. What's the problem with > > > > <instant value='2001-01-01'>New Year's Day</instant> > > <instant value='2001-10-03T14:00'>03 Oct 01 2PM</instant> > > <instant value='2001-10-03'>Oct. 3, 2001</instant> > > > > If a publisher wants to put the 8601 string into the content > then, by all > > means, let them. Don't force 'my way or the highway' (as > Frankie would say). > > That's not how standards are developed. Gather requirements. Meet the > > requirements. I daresay that the requirements include what I have just > > outlined. > > > > > -----Original Message----- > > > From: Ian Galpin [mailto:firstname.lastname@example.org] > > > Sent: Wednesday, April 18, 2001 7:59 PM > > > To: ebXML core > > > Cc: Andreas Schultz; Aron Roberts > > > Subject: Re: AW: ISO 8601 anyone?? And more on Parties. > > > > > > > > > On 2001-Apr-17 Andreas Schultz <Schultz.DKV@t-online.de> wrote in > > > <ebXML-core>: > > > > > > > > > > I also agree with what Sharon said about the CONTENT. But - the > > > possibility > > > > we have within EDIFACT allows people to write Date - > > > information in a format > > > > they are used to. Limiting this to just one format, even if it > > > may (or may > > > > not as Eduardo points out) be stated by W3C (who as we at > least since > > > > Washington all know does not have the same status as UN/CEFACT > > > EWG or ISO) > > > > seems to be a poor solution. I would not expect the Europeans > > > (mostly using > > > > DDMMYYYY)to change the format they are used to, especially not while > > > > exchangig data within Europe. > > > > > > > > > Under CEN regulations, all European and Scandinavian > countries have now > > > adopted the EN 28601 standard, which has the same words as > ISO 8601. It > > > should not be a problem to use Year-Month-Day across the > whole of Europe. > > > Lets get rid of the dd/mm/yy - mm/dd/yy ambiguity for ever. > Although W3C > > > does not have the status of ISO, many W3C recommendations > incorporate the > > > ideas from common ISO standards.. ISO 8601, ISO 3166, ISO > 4217, ISO 8859, > > > ISO 10646 and so on. In Germany, DIN (the German standards authority) > > > revised the DIN 5008 standard in 1996 to outlaw the old '20 > VIII 97' date > > > format in favour of '1997-08-20' a la ISO 8601 & EN 28601 > standards. DIN > > > 5008 is the standard for typographical date formats, used in letters, > > > contracts, invoices, publications, and so on, in Germany. It > has no ISO or > > > EN equivalent (yet!). > > > > > > > > > > > > > So, I guess the solution only can be to give > > > > informations about the format a date is expressed in (even if this > > > > is not compliant to W3C or ISO 8601 but at "least" with UN/EDIFACT). > > > > > > Let's use just one format, end-to-end, in the whole process. > > > Avoids confusion, needs less processing. > > > > > > > > > > > > Cheers, > > > > > > > > > Ian A.N. Galpin. > > > > > > *Sadly my middle two initials don't repeat, but > > > *my first three initials do spell my first name ;-> > > > > > > > > > <email@example.com> > > > > > > > > > [2001-04-18] > > > > > > .end > > > > > > > > > > > > ------------------------------------------------------------------ > > > To unsubscribe from this elist send a message with the single word > > > "unsubscribe" in the body to: firstname.lastname@example.org > > > > > > > ------------------------------------------------------------------ > > To unsubscribe from this elist send a message with the single word > > "unsubscribe" in the body to: email@example.com > > -- > Michael C. Rawlins, Rawlins EC Consulting > http://www.metronet.com/~rawlins/ > > > > ------------------------------------------------------------------ > To unsubscribe from this elist send a message with the single word > "unsubscribe" in the body to: firstname.lastname@example.org >
Powered by eList eXpress LLC