Increase specificity for Order's shipping address tag

[amunrarara]

Address strings, which are the value of an 'address' tag on an Order event, don't yet have a specific format.

[calvadev]

I think this should be fine, but with one comment on state: I often see province as an alternative wording on it, so not sure if that should be represented as an additional field or only specified client-side. If specified client-side, we should make sure to make it explicit that the fields will be consistent, but the front-end definitions need not be.

[amunrarara]

I think this should be fine, but with one comment on state: I often see province as an alternative wording on it, so not sure if that should be represented as an additional field or only specified client-side. If specified client-side, we should make sure to make it explicit that the fields will be consistent, but the front-end definitions need not be.

You totally read my mind. I had state/province written out at first but decided to consider 'em as JSON keys. The thinking is, a client should be able to generate and consume the object properly, so pickin' one is probably in best interest. Whaddya think of stateOrProvince as the key?

[ericfj2140]

spec should not mandate an address schema in JSON IMO. this is highly jurisdiction specific and will invite many more of the types of discussions above with no global solution....

however what might help interop is some "MAY" guidance like this, using tags that are more indexable:

address: free-form human-readable shipping address. [remains]
Clients MAY additionally include structured components using these tags:
address_name
address_line1
address_line2
address_city
address_region (state/province/region)
address_postal or address_zip
address_country (ISO 3166-1 alpha-2)
address_note (delivery instructions)
...Clients MAY add additional address_* tags as needed. Clients may implement richer address handling (e.g., pickup points, lockers, customs metadata) out of band.