Proposition of design evolution

[GillesInnov35]

Possible evolution

Regarding the first design version I'd propose to discusss about 2 propositions

1. Indicate the document type concerned by the identifier

      individualIdentification : {
           identificationId : string,
           identificationType : string (enum : passport, nationalIdentityCard,…)
    }

2. group attributes according to what they refer

A new design of the Match request could be bellow. Grouping attributes according to what they define. This approach is close to TMF designing specifications and wording

phoneNumber
individual : { 
   individualIdentification : {
      identificationId : string,
      identificationType : string (enum : passport, nationalIdentityCard,…)
   },
   gender: male
   name: "Federica Sanchez Arjona"
   giventName: Federica
   middleNames: Sanchez
   familyName: Sanchez Arjona
   familyNameAtBirth: YYYY
   nameKanaHankaku: federica
   nameKanaZenkaku: Ｆｅｄｅｒｉｃａ
   birthdate: '1978-08-22'
   email: abc@example.com
},
geographicAddress : {
    address: Tokyo-to Chiyoda-ku Iidabashi 3-10-10
    streetName: Nicolas Salmeron
    streetNumber: 4
    houseNumberExtension: VVVV
    postalCode: 1028460
    region: Tokyo
    locality: ZZZZ
    country: Japan
}

[ToshiWakayama-KDDI]

Hi @GillesInnov35 ,

Thank you for the proposals.

Regarding No.2, grouping results in nested structure, which may mean easines for people to see but complexity for compuptes to handle. I am not quite sure if it is good.

At least, how to group / grouping categories should be discussed.

If we use this grouping for match request, how are the results returned?

Thanks, Toshi

[GillesInnov35]

hi @ToshiWakayama-KDDI , thanks for your questions

• attributes could be grouped according existing schemas such as TMF specifications, as you see the proposed design is close to TMF party/individual resource specifications.
• match response should also proposed same group for match result attributes.

[ToshiWakayama-KDDI]

Hi @GillesInnov35 , thanks for your reply.

attributes could be grouped according existing schemas such as TMF specifications, as you see the proposed design is close to TMF party/individual resource specifications.

I am not familiar with TMF specifications. Could you advise which TMF specifications I can refer to, for this grouping?

Best regards, Toshi

[GillesInnov35]

Hi @ToshiWakayama-KDDI , see bellow links to TMF web site and API specifications on which I've based a draft proposal of new design. TM Forum web site and API Dashboard https://www.tmforum.org/oda/open-apis/table

Specifications of Geographic Address Management TMF673 https://tmf-open-api-table-documents.s3.eu-west-1.amazonaws.com/OpenApiTable/4.0.0/user_guides/TMF673_Geographic_Address_Management_API_v4.0.0_user_guides.pdf

geographicAddress : { address: Tokyo-to Chiyoda-ku Iidabashi 3-10-10 streetName: Nicolas Salmeron streetNumber: 4 houseNumberExtension: VVVV postalCode: 1028460 region: Tokyo locality: ZZZZ country: Japan }

Specifications of Party Management TMF632 https://tmf-open-api-table-documents.s3.eu-west-1.amazonaws.com/OpenApiTable/5.0.0/user_guides/TMF632_Party_userguide.pdf

individual : { individualIdentification : { identificationId : string, identificationType : string (enum : passport, nationalIdentityCard,…) }, gender: male name: "Federica Sanchez Arjona" giventName: Federica middleNames: Sanchez familyName: Sanchez Arjona familyNameAtBirth: YYYY nameKanaHankaku: federica nameKanaZenkaku: Ｆｅｄｅｒｉｃａ birthdate: '1978-08-22' email: abc@example.com }, Thanks BR Gilles