RE: civic address references

I support Nick’s comments on the need for standards.



We must avoid that any implementer can decide e.g. what the length of a street address field is, or how long the fractional part of a currency is, or…



Given we are not starting from a ‘financial’ standard, we shall need to provide a mapping.  A mapping should be lossless. This means in our case that the source W3C spec must be unambiguous, for example the value space of the source elements must be specified. I did not see this but then again I am not OASIS savvy.



I searched for an OASIS financial repository of some sort, to understand better the business model behind these elements. Can someone point me to that, as I couldn't find it.



Thanks!





-----Original Message-----
From: Ian Jacobs [mailto:ij@w3.org]
Sent: 04 April, 2017 2:59 AM
To: Nick Doty
Cc: public-payments-wg@w3.org
Subject: Re: civic address references





> On Apr 3, 2017, at 5:59 PM, Nick Doty <npdoty@ischool.berkeley.edu<mailto:npdoty@ischool.berkeley.edu>> wrote:

>

> On Apr 3, 2017, at 8:46 AM, Ian Jacobs <ij@w3.org<mailto: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:

  https://lists.w3.org/Archives/Public/public-payments-wg/2016Feb/0465.html




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

--

Ian Jacobs <ij@w3.org<mailto:ij@w3.org>>

https://www.w3.org/People/Jacobs/


Tel: +1 718 260 9447