- From: r12a <ishida@w3.org>
- Date: Fri, 2 Sep 2016 17:18:18 +0100
- To: rouslan@google.com, atkin@us.ibm.com
- Cc: www-international@w3.org, public-payments-wg@w3.org
On Thu, 1 Sep 2016 07:41:17 -0700, Rouslan Solomakhin wrote: > Why do you feel that the country code and the language code are not sufficient for formatting the address? i read the thread at https://github.com/w3c/browser-payment-api/issues/6, but i haven't read the spec in detail. for a glimpse into why you probably made a good decision not to dissect personal names, see https://www.w3.org/International/questions/qa-personal-names however, i see that you *are* trying to do this to some extent for paymentaddress, by separating out things like `city`, `region` and especially `dependentLocality`. Whereas, you don't separate out, for example, house number (which in some countries appears after the street name, and in other countries appears before it). Presumably you just rely on the person creating the `addressLine` to do the right thing there. Do you have a particular reason in mind for separating out information such as city, region and dependentLocality? If not, i would recommend letting people just write the full address as they want in a single blob - big endian, little endian, highly detailed or not. That way, no-one has to worry about how to compartmentalise the information in the input forms, how to store it in the database, how to transform it depending on the locality or addressing conventions, or how to squeeze in formats that don't quite fit the model as a user, etc. For example, the "Delivery address" given on the ERCIM office website has no region or dependentLocality information: 2004, Route des Lucioles c/o INRIA Batiment BOREL B 104 1er étage 06410 BIOT If you don't force the address to have those, i'm not sure how useful it is to capture that information generally. The above address also has careOf information, but note how it appears tucked below the street address in this case, rather than above as in others. It's not really difficult to find addresses that don't fit the model. I'm not sure why we want to split things up and then force people/apps to figure out how to put them back together again according to conventions that can differ even within the same locale. There may be some fields worth keeping separate, such as country, or perhaps postalCode, but i'm dubious about the ones i mentioned earlier. ri
Received on Friday, 2 September 2016 16:18:28 UTC