Thanks Jonathan for your reply.
So indeed we would like to use fully detailed geographic address (with PostCode, Street, House#) in input request for the Place entity (when role = "installationAddress").
There are 2 scenarios under which other projects would also like to use fully detailed address instead of id :
1. Combination of 1 or more elements in the address serves to identify the unique address (for ex. Countries like Netherlands where PostCode+HouseNumber serves as the unique way to identify an address . PostCode : 1121AB, Houser Number : 33)
2. The APIs are hosted by OSS system which is a separate Network company / organization and BSS (from various OTT operators) would like to check Service Availability on a given address from this Network company and they dont share the common address master database and hence must supply the full address in the request.
Considering above need, if we look at the documentation of v18.0, it indeed exactly solves our problem, however the element
"@referredType" is missing in the v18.5 documentation, and is showing as
"@type": "GeographicAddress" in the example (refer above).
So with documentation it is not clear if we should use structure A or B below as per v18.5 documentation?Structure A Structure B
Appreciate your inputs and would be nice to have it also in the documentation both possibilities?
------------------------------
Kailash Mali
Ericsson Inc.
------------------------------
Original Message:
Sent: Mar 31, 2019 04:23
From: Jonathan Goldberg
Subject: TMF-645 : geographicAddress in the request
The Place resource is conceptually a base class, that could be a GeographicalAddress (or GeoLocation or GeoSite).
As such, when passing a Place as input, you can pass the GeographicalAddress by value (structured fields), or refer to an existing address by ID. You would set the @type attribute to GeographicalAddress, so that the provider will understand that you are passing in such an address.
For ServiceQualification one could argue that you would always want to check service feasibility for an existing and validated address, so as not to waste resources on dealing with an invalid address, and the example in the R18.5 spec indeed shows reference to an existing address. But the ability to pass address by value has not been removed.
Hope it helps.
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Original Message:
Sent: Mar 28, 2019 13:06
From: Kailash Mali
Subject: TMF-645 : geographicAddress in the request
Hi All,
I was anaylzing TMF645_Service_Qualification_Management_API_R18.0.1.pdf document vs TMF645_Service_Qualification_Management_API_REST_Specification_R18.5.0 version and I observed that in v18.0.1 there was a possibility to receive the structured address for checking technical service availability (see below json from pdf).
However now in v18.5.0 this is not possible anymore (see screenshot below).
Is there a reason to remove this and how is it then expected to pass structured address (the most important input) in the service qualification request?
Kindly advice !
------------------------------
BR,
Kailash Mali
Ericsson Inc.
Netherlands
------------------------------