[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: AW: ISO 8601 anyone?? And more on Parties.
On 2001-Apr-19 John McClure <firstname.lastname@example.org> wrote in <ebXML-core>: [2001-Apr-20] > 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> On receipt the recipient may wish the presentation in a different language, or just the day of the week, or some other variation that is different to whatever was sent, so they would ignore the presentation encoding, and use only the value data to derive what they require. Seems like a waste to send something that might not get used. > <instant value='2001-10-03T14:00'>03 Oct 01 2PM</instant> Why take something unambiguous and print it in an ambiguous way? It seems more sensible to keep to an umambiguous format end-to-end. Also, how would you guard against the 'real' and presentation values becoming different? as in... <Delivery.Date> <instant value='2001-10-03T14:00'>22 May 01 8PM</instant> </Delivery.Date> If something happens to the data - a corruption, or perhaps malicious or fraudulent editing of some part, then you may see the presentation value on screen and agree to it, without checking the underlying 'real' value means the same. If the presentation value is 'free format', then no computer could ever do this checking for you. If the presentation value has to be in a fixed format, then all you are doing is transmitting the same information in two formats... a redundancy, which wastes bandwidth. If you are transmitting data, then transmit it once, in one agreed format, not in several different representations, that may become separated or different in meaning. > <instant value='2001-10-03'>Oct. 3, 2001</instant> >> Let's use just one format, end-to-end, in the whole process. >> Avoids confusion, needs less processing. I am against repeating data in other formats. Use just one, and one that is globally unambiguous. Cheers, Ian. <email@example.com> [2001-04-20] .end
Powered by eList eXpress LLC