Hi Shubham
It's a great discussion point, thanks for raising.
For each API, the API designers are tasked with deciding what are the minimum sensible and feasible criteria for passing conformance.
No-one will realistically claim that this minimum conformance will enable you to run a telco business.
For this API, I take responsibility, and my explanation is as follows:
- For entities, a product catalog is feasible even without the Catalog and Category entities - but I cannot survive without offerings and their building blocks - specs and prices. Also import and export are not absolutely essential.
- For attributes, it is extremely difficult to determine which should be mandatory. I can in principle have product specs with no characteristics, for example. And not all POPs have actual price amounts - usage charges for example will not have price amounts.
Thanks for your concern, I hope this clarifies things.
------------------------------
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: Jan 19, 2022 08:15
From: shubham saraswat
Subject: TMF620 Conformance
As per the document TMF620B_Product_Catalog_API_Conformance_Profile_v4.1.0, for TMF620 conformance, only resources to be supported via TMF620 are
Product Offering, POP and Product Specification.
Also if we see POST operation, only mandatory attribute is Name. There are 1 or 2 conditional mandatory fields but basically just Name is mandatory. So for conformance, is support of only Name field be sufficient for all the 3 resources? Because for Get I see a big table with many mandatory fields.
------------------------------
shubham saraswat
Hansen Technologies
------------------------------