The sample payloads for TMF641 have now been modified for path field (as per RFC6901). This is now with Pierre for review.
Original Message:
Sent: Jan 23, 2024 22:44
From: Dan d'Albuquerque
Subject: Discrepancy in TMF641 Service Order category/serviceType fields
As an aside, the TMF641v5 also has inconsistencies regarding the new modifyPath feature for Service Orders that modify an existing service, e.g. serviceCharacteristics, using action=modify.
The example of the use of modifyPath in the spec is as follows...
The path field should be based on JSON pointer (RFC6901) according to the JSON Patch spec (RFC6902). The path should contain a series of tokens separated by a slash rather than using dot notation. Also it is mandatory to have a leading slash - I appreciate that TM Forum restricts the modification to only fields within the serviceOrderItem.service, but I think it is confusing to deviate from the RFC unnecessarily. Also, TM Forum design guidelines Part 5 "JSON Patch extension" v4 also relies on the use of JSON pointer for the path field and I have not seen any changes to v5 that allows for dot notation instead.
Thanks!
------------------------------
Dan d'Albuquerque
Individual
Original Message:
Sent: Jan 23, 2024 21:04
From: Dan d'Albuquerque
Subject: Discrepancy in TMF641 Service Order category/serviceType fields
Hi Jonathan
I have just noticed that the TMF641v5 has been passed over to Pierre for final review yet this issue with the serviceType and category fields has not been resolved.
In actual fact, the example no longer references the (optional) serviceType or category fields, but the description for serviceType/category is still misleading and now inconsistent with many implementations.
Please can you let me know of any decisions resulting from the JIRA request you raised?
Thanks
Dan.
------------------------------
Dan d'Albuquerque
Individual
Original Message:
Sent: Sep 14, 2023 01:44
From: Jonathan Goldberg
Subject: Discrepancy in TMF641 Service Order category/serviceType fields
Dan thanks for raising this. Strictly speaking, your observation applies to the embedded Service entity, so we should raise it against TMF638 Service Inventory.
I personally am not happy with this category String field. In catalog APIs, we have a full Category model with trees of categories and subcategories. Having a category property that doesn't relate to the Category model can be confusing.
Also the serviceType property is not well-defined, and the example does not shed much light on this.
I'm opening a JIRA for discussion within the Open API team.
------------------------------
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: Sep 12, 2023 00:24
From: Dan d'Albuquerque
Subject: Discrepancy in TMF641 Service Order category/serviceType fields
Hi All
The TMF641 SOM API seems to suggest that the category field is used to determine whether the Service Order is for a CFS or RFS, yet the example Service resource representation has this value stored in the serviceType field as below. Is the example incorrect? Thanks in advance!
#General
------------------------------
Dan d'Albuquerque
Individual
------------------------------