Hi Jan and Johnson
I remind you that at least for GET, you can use the expand and depth directives on the query param string to include referenced entities by value, even if the schema has only xxxRef. So this whole discussion becomes relevant only when there is a need to pass the value as input (or in the rare cases when you want the value in output of a POST or PATCH).
As a general guideline we use RefOrValue when we feel that there may be a need to pass the information in by value. Let's take some extreme examples:
- References from inventory item to catalog item - e.g. Product has a reference to ProductSpecification. Here it is clear that RefOrValue would be not be appropriate. When POSTing a Product you would never provide catalog information by value
- References from order to inventory item - e.g. ProductOrder has a reference to Product. Here it is clear that RefOrValue is essential, since when the order for a new product (provide) is created or submitted the product will not be in the inventory, so it has to be passed in by value
In your particular example, I guess that there is a tacit assumption that places affected by the service problem are known places in some GIS or other address management system, and hence there is no need to pass by value, only by ref. If you feel that this is incorrect, feel free to submit CRs for those particular areas where RefOrValue is needed.
Hope it helps
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
------------------------------
Original Message:
Sent: Aug 26, 2021 01:48
From: Jan Lemmermann
Subject: TMF656 Service Problem Management v4.0.0 | RelatedPlace vs RelatedPlaceRefOrValue
Hi,
That's a good point. I have noticed such differences between APIs as well. We always prefer if the API supports RefOrValue patterns instead of only one of the variants (Ref or Value only).
So here and there we have already customized the TMF OpenAPIs on our own. Same with RelatedParty by the way, where a RelatedPartyRefOrValue would also make some things easier.
I am curious if there are plans to unify the APIs.
Regards,
Jan
------------------------------
Jan Lemmermann
OSS Lead Architect
EWE TEL GmbH
Original Message:
Sent: Aug 25, 2021 20:44
From: Johnson Drago
Subject: TMF656 Service Problem Management v4.0.0 | RelatedPlace vs RelatedPlaceRefOrValue
Hi There,
The API user guide resource model for TMF656 Service Problem Management v4.0.0 depicts "affectedLocation" relationship as RelatedPlace sub-resource, but there is no provision to supply "affectedLocation" by values such as street address etc. Would this be better aligned to TMF640 v4.0.0 where the place is referred as a RelatedPlaceRefOrValue sub-resource?
------------------------------
Johnson Drago
Telstra Corporation
------------------------------