Open APIs

Hi all,

We observed that in TMF 622 Product Ordering API, in Product Resource model, Characteristic resource is in aggregation relationship with cardinality 0..* with Product meaning that a Product can have multiple characteristics associated to it with each specifying a "value" attribute (This value attribute is missing in the resource model Characteristic in the resource model for Product).

But, we couldn't see any reference from these characteristics to the characteristicSpecifications (productOfferingCharacteristic or prodSpecCharValueUse). As per our understanding, this would be needed in cases where we have multiple product offerings with different characteristic specifications associated to them. Having this relationship would help -

• Determine value passed for characteristic against Product actually pertains to which characteristic and whether it follows all the rules defined in the Product Catalog for that characteristic specification E.g. Adherence to -
  • Type (A Characteristic Specification defined as Integer shouldn't receive String values for characteristic in Ordering)
  • minCardinality, maxCardinality
  • regex
  • isUnique
• There are some fields defined at Characteristic Value Specification as well which can be validated for when corresponding values are received in Ordering -
  • rangeInterval
  • regex
  • valueFrom and valueTo
• Characteristics are passed against correct Products meaning that corresponding Product Offerings have the corresponding Characteristic Specifications associated to them
• Make distinction between Order Time characteristic (the characteristics which are not defined in Product Catalog) and Product Charaterisitic (Ones whose definitions are defined in Product Catalog)

------------------------------
Varun Pandhi
Infosys
------------------------------

Hi Varun

I take it that you are referring to gen5 APIs, I think I can see this from the diagrams you attached. So:

• One of the major changes in v5 was the introduction of strongly-typed characteristics. The Characteristic base class is now abstract, and indeed it doesn't have a value property. Each concrete subclass implements value according to a different JSON basic type, so StringCharacteristic has value with type string, NumberCharacteristic has value with type number, etc. Same applies at the specification (catalog) level, with characteristic spec value being an abstract base class.

The link between characteristic and characteristic spec is logical, by the name property. This is not new, it's been like this for as long as I have been involved in the Open API project, and probably longer still (many years already). The idea is that the Product has a reference to its originating offering or spec, and you should then be able to find the characteristic spec for a characteristic using the name property.

Hope this clarifies things for you.

------------------------------
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.
------------------------------