[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: tpaml spec
David, Your points are well taken and right on the mark. I have inserted replies in the appended copy of your email. Everyone, please keep the questions and comments coming. Regards, Marty ************************************************************************************* IBM T. J. Watson Research Center P. O. B. 704 Yorktown Hts, NY 10598 914-784-7287; IBM tie line 863-7287 Notes address: Martin W Sachs/Watson/IBM Internet address: mwsachs @ us.ibm.com ************************************************************************************* David Boreham <david_list@boreham.org> on 07/18/2000 11:49:39 AM To: ebxml-transport@lists.ebxml.org cc: Subject: Re: tpaml spec > As promised at the Boston meeting, here is the latest tpaml specification. > Pleas read and comment via the list. Some things strike me as very strange, but this could well be due to my relative cluelessness in this field: 1. Dates in "United States format" ? There is no single US format (all three "orders" are in use in the US). Why not use one of the existing standard date and time formats ? e.g. ISO8601 (http://www.whatis.com/isodatef.htm). or RFC1123 or ASN.1 GeneralizedTime. MWS: Quite right. tpaML started as an IBM Research proof of concept prototype. For expediency, we used dates and other parameters that we were familiar with, knowing full well that a standardization working group would have to do something about them. 2. Same point but relating to physical addresses. US format only ???? Addresses are quite hard to represent, but surely something better than US format only can be done ? Can all address formats be "converted" to US format ? MWS: Again, as a cop-out, we assumed that local software would be able to deal with address conversion as long as enough fields are present. 3. Same point but relating to telephone numbers. ITU E.164 is your friend. MWS: Ditto - for our purposes, phone numbers applicable to the US-Canada- Caribbean were sufficient. An earlier version of the spec (prior to public distribution included a paragraph discussing phone number formats and suggesting that ISO standard formats might be preferred in the future. I'm guessing that the intention is to remove these type definitions from this spec at some point (seems strange to be defining the essence of a telephone number in a specification for a trading prototol !), but that for expediency they're defined in-line at present. I couldn't however find a note to that effect in the text. MWS: Removing them is a good possibility. The question has come up before inside IBM. An organization using electronic TPAs is likely to have a database containing this kind of trading-partner information so the value of having it in the TPA is questionable. We decided to let a standardization working group make the decision.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC