W3C home > Mailing lists > Public > public-payments-wg@w3.org > April 2017

Re: civic address references

From: Ian Jacobs <ij@w3.org>
Date: Mon, 3 Apr 2017 19:59:09 -0500
Cc: public-payments-wg@w3.org
Message-Id: <53144739-F7E4-4E72-99A8-61F6BEEB87CD@w3.org>
To: Nick Doty <npdoty@ischool.berkeley.edu>

> On Apr 3, 2017, at 5:59 PM, Nick Doty <npdoty@ischool.berkeley.edu> wrote:
> On Apr 3, 2017, at 8:46 AM, Ian Jacobs <ij@w3.org> wrote:
>>> ## Addresses (not privacy-related)
>>> Is this an entirely new civic address standard? It would be preferable to cite an existing standard, rather than proliferating yet another way to represent civic addresses; existing standards may also help with worldwide usability.
>> The group has discussed this, see:
>>  https://github.com/w3c/browser-payment-api/issues/6
>>  https://github.com/w3c/browser-payment-api/issues/189
> Is the conclusion documented somewhere? Issue 6 / PR 147 makes it sound like OASIS xAL was selected

Here’s a relevant thread:

The sense I get from the thread is that there are a lot of standards. We use a subset of OASIS xAL, but perhaps
modified somewhat by what Chrome does for autofill.

> ; Issue 189 makes it sound like neither ECML nor xNAL are being followed, so the group is now just choosing its own names for each field. The editor's draft has no reference to any civic address standards. "dependentLocality" is a field, even though there is no "locality" and "dependent locality" isn't referred to in either ECML or xNAL.
> It's common to refer to other standards in a spec itself so that the reader knows the relationship to / compatibility with them. It'll also help reviewers like me to not repeat topics you've already discussed and be confident that the spec will cover a broad set of existing use cases. If the conclusion was just to explicitly not coordinate with or refer to any other standards, maybe that's less likely to be reflected in the text of the spec, but you might list that conclusion explicitly in an issue somewhere.
> BCP 47 is referred to but not linked. It should probably be a normative reference.

Ok; I’ll mark that as an issue.

> Why is the shipping address just an instance of the PaymentAddress interface? I could imagine shipping addresses as having different kinds of fields than payment addresses, but in any case, it doesn't seem like a shipping address *is a* payment address, maybe they're just both civic addresses with the same fields. (It seems like this came up briefly when considering Geolocation's Address interface, but even if you're not re-using that existing interface, you could define a CivicAddress interface which both shipping and payment are instances of or inherit from.)
> I do sincerely apologize if this is repeating discussion that already happened within the group, but I can't follow the reasoning or find documentation of the conclusions.

(I welcome the Editors to weigh in on this thread as well.)

Ian Jacobs <ij@w3.org>
Tel: +1 718 260 9447
Received on Tuesday, 4 April 2017 00:59:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:43:25 UTC