Open APIs

Hello,

In TMF620 v5.0 the ProductSpecCharacteristic inside ProductSpecification does not mandate an id attribute-only name, valueType, and @type are mandatory.
For a ProductOffering (and ProductOfferingPrice), the prodSpecCharValueUse object is mandatory if present and must contain both id and name.

When a specification omits id, how should the server validate that the prodSpecCharValueUse truly references the correct characteristic? Is matching by name alone considered normative?

Would TMF recommend treating id on ProductSpecCharacteristic as best-practice mandatory in real implementations, even though the Conformance Profile lists it only as "M if present"?

If a client posts a prodSpecCharValueUse whose id cannot be found in the related ProductSpecification, but the name matches, is that request valid, or should the server return 400 Bad Request?

Conversely, if the name mismatches but the id matches, which attribute has precedence?

Any guidance (or references to previous discussions) would be greatly appreciated.

Best regards,
Emir
ZIRA Group

hi,

just use Id when there is an Id an Value when you have nothing else.

I admit I'm not fan of how TMF has chosen the attributes' name or whether Id should be there or not.

The CRM and BSS I have used were more consistent and would have exposed PSCVU like this:

{
  "prodSpecCharValueUse": [
    {
      "name": "SRV_BROADBAND:BANDWIDTH",
      "id": "80e770a9-30a9-49b8-b000-ea3f675c5d1e",
      "@type": "ProductSpecificationCharacteristicValueUse",
      "productSpecCharacteristicValue": [
        {
          "name": "500/500 Mbps",
         "id": "1-PPL81",
          "@type": "StringCharacteristicValueSpecification"
        }
      ]
    }
  ]
}

I added "name": "500/500 Mbps" but it's only for convenience. For us, it's really not necessary to have any name or any description attributes in the API.
we typically use a CMS to provide user-friendly (depending on sales channels/device/country/preferred language/etc) but for machine to machine communications, CMS is not needed.

for the charValue, id would be nice our BSS has an id for each value. but since we only have valuein the API, we came up with this compromise "value" stores an unique Id that's also understandable by developers, logging etc:

      "productSpecCharacteristicValue": [
        {
          "value": "500_500",
          "@type": "StringCharacteristicValueSpecification"
        }
      ]

we don't allow client to "omit" an attribute and expect the "server" to be clever and try to use "name" if "id" is forgotten. Client must provide was is required as agreed in the API contract. else it's 400 for you right back at you!

But we've never had this situation, except maybe during development.

I probably misunderstand this particular question.
I understand the (prodSpecChar) "Id" is mandatory only if you have a PSCVU sub-resource under the PO, it must have the "Id"  of the prodSpecChar entity. 

my 2 cents!

------------------------------
Kind regards,

Matthieu Hattab
Digital Sales Domain Architect
Lyse Tele AS
------------------------------

Thanks a lot — this clears it up!

Your explanation confirms our assumption that prodSpecCharValueUse is meant to restrict existing characteristics and values, not redefine or override them. We'll ensure our validation strictly enforces consistency for value, valueType, @type, and unitOfMeasure, and only allow contextual overrides for flags like isDefault, validFor, and configurable.

Really appreciate the practical insight — it helps us shape a much cleaner implementation!

Best regards,
------------------------------
Emir Torlak
ZIRA Ltd.
------------------------------