address 2.0

[stansmith907]

"address".

Changes:

1. "address" is an array of type CI_Address. "address" was a single object in mdJson 1.0.
2. "addressType" is a new required array of type "adiwg_addressType". "adiwg_addressType" is a new codelist included in mdCodes.
3. "description" is a element of type string. Definition: "description of the address which may be used to differentiate between multiple addresses.

{
   "address": [
      {
         "addressType": [""],
         "description": "",
         "deliveryPoint": [""],
         "city": "",
         "administrativeArea": "",
         "postalCode": "",
         "country": ""
      }
   ],
   "electronicMailAddress": [""]
}

see ISO XML example responsibleParty -3.xml

[stansmith907]

Now that we allow multiple addresses do we need to include 'type'?

[jlblcc]

Probably. Enum?

[stansmith907]

Sure ...

• mailing
• physical
• street
• main
• other

Any to add/subtract?

[stansmith907]

Think we should build a codelist 'addressType' to use in mdEditor?

[jlblcc]

No enum. An array of strings, like phone->service.

[stansmith907]

Got a problem with 'addressType'. Our address block parallels ISO organization which includes email addresses. Email addresses may be the only addresses in the block - no mailing or physical address. Doesn't seem quite right to add another type 'email'. Either we assume some default for 'addressType' - mailing would be my vote - or we move electronicMailAddresses into its own element parallel to address.

[jlblcc]

Well, I always thought it was weird having e-mail in the same object. Especially with it being increasingly common these days to have entities without an address. We could just wrap all the "address" properties into another, e.g. "location". Could make it an array too so you can associate multiple address with your e-mail at once. That way we can have e-mail without a location(address).

[stansmith907]

So, which are you thinking? ...

{
   "address": [
      {
         "addressType": [""],
         "deliveryPoint": [""],
         "city": "",
         "administrativeArea": "",
         "postalCode": "",
         "country": ""
      }
   ],
   "electronicMailAddress": [""],
   
   "location": [
      {
         "address": [
            {
               "addressType": [""],
               "deliveryPoint": [""],
               "city": "",
               "administrativeArea": "",
               "postalCode": "",
               "country": ""
            }
         ],
         "electronicMailAddress": [""]
      }
   ]
}

How much advantage is there to having multiple email blocks? I can't see much advantage unless we expand the address block again and make address more like a true location by adding a 'locationName' in additon to 'addressType'. This would associate email addresses with a location not an address. Otherwise just more work to collect all the email addresses and decide which to use. See below ...

{
   "location": [
      {
         "locationName": "",
         "address": [
            {
               "addressType": [""],
               "deliveryPoint": [""],
               "city": "",
               "administrativeArea": "",
               "postalCode": "",
               "country": ""
            }
         ],
         "electronicMailAddress": [""]
      }
   ]
}

Is this getting out of control?

[jlblcc]

I was actually thinking:

{
  "address": [{
    "location": [{
      "addressType": [""],
      "deliveryPoint": [""],
      "city": "",
      "administrativeArea": "",
      "postalCode": "",
      "country": ""
    }],
    "electronicMailAddress": [""]
  }]
}

Just adding the location[{}] wrapper.

[stansmith907]

In that case I would argue (politely) that 'location' creates multiple addresses for multiple address blocks without distinction to why there are is any difference. Might as well just go with elevating the 'electronicMailAddress' element to the level of 'address[]' - first example.

[stansmith907]

After further discussions (on the phone) we decided elevate 'electronicMailAddress' to the base of 'contact'. Although it is shown in the model above it is no longer officially part of 'address'. See 'contact 2.0' issue #48.