Open APIs

Within TMF620, for the productOffering response, the subresource `productSpecCharacteristicValue` has a field called `Value` which is of type `Any` (it can be of any type).  

This has led some of our partners to code this to string type for flexibility, but our underlying system has a more structured model and treats these as Objects (to manage as structured but flexible arrays).
The conformance profile for this TM Forum API states the rule is it needs to be present as "Array of CharacteristicValueSpecification - there must be at least one value in this array."
So is it acceptable in a TMF compliant implementation to require that the system calling GET for TMF678 resources use an object/array here rather than take license from the "any" designation and use other types like string?  Or to be compliant must my underlying system take any type here and find some way to convert it to the structured model of an array?  Ultimately, can a member offer a "TM Forum Open API" compliant solution that requires certain types be used where the standard allows for ANY or does the standard require that constituents truly support any field type in these situations?

Thanks in advance!

------------------------------
Michael Judge
Aria Systems Inc.
------------------------------

Hi Michael

I don't think that this will help for v4 APIs. But for Gen5 APIs (some already published) we have completely revamped the characteristic value and specification value model. Any has now gone away, and the values are strongly-typed subtypes of Characteristic and CharacteristicSpecificationValue. The types are based around json schema basic types, and they do include Object and Array of Objects, as well as basic types such as String, Array of Number, etc.

To be honest, though, I don't know how this is reflected in the CTK itself.

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

Thank you, Jonathan.  We did notice the change in the new version and all of our connector services built after will adopt that...and we're likely to upgrade our exiting ones once clients are ready.  This question was due to an existing connector where the partner integrating their TMF620 calls to it understood "any" to mean we had to support all types (and convert them behind the scenes) to be considered compliant.  I'm hoping its acceptable to remain compliant while still instructing users to define that as an array.

------------------------------
Best Regards,
Michael Judge
Aria Systems Inc.
------------------------------

Original Message:
Sent: Mar 19, 2024 12:51
From: Jonathan Goldberg
Subject: Supporting TMF fields where type is "ANY" (e.g. TMF620's productSpecCharacteristicValue)

Hi Michael

I don't think that this will help for v4 APIs. But for Gen5 APIs (some already published) we have completely revamped the characteristic value and specification value model. Any has now gone away, and the values are strongly-typed subtypes of Characteristic and CharacteristicSpecificationValue. The types are based around json schema basic types, and they do include Object and Array of Objects, as well as basic types such as String, Array of Number, etc.

To be honest, though, I don't know how this is reflected in the CTK itself.

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