Re: civic address references

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/6>
>  https://github.com/w3c/browser-payment-api/issues/189 <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; 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.

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.
—Nick