Open APIs

Hello ,

In TMF620 v5.0, the prodSpecCharValueUse.productSpecCharacteristicValue object is used to define a list of characteristic values specific to a ProductOffering.

The Conformance Profile states this list must be a strict subset of values defined in the related ProductSpecification.productSpecCharacteristic.valueSpecification.

I'd like clarification on two key aspects:

Which attributes in productSpecCharacteristicValue are allowed to differ in the ProductOffering context?
For example:

Can fields like isDefault, validFor, or configurable be safely overridden?

Are fields like value, valueType, @type, and unitOfMeasure immutable and must match exactly what's in the specification?

How should an implementation validate whether a value in prodSpecCharValueUse corresponds to a value in the ProductSpecification?

If id is present in both: should matching be based on id only?

If id is missing: should matching rely on a tuple like (value, valueType, @type, unitOfMeasure)?

If no match is found in the specification, should the server:

a) reject the request with 400 Bad Request, or

b) silently ignore the unmatched value?

Any guidance or best practices would be much appreciated.

Thanks,
Emir
ZIRA Group

You have the freedom to make these decisions. I highly doubt that TMF620 dictates how data must be stored in your Product Catalogue application.

From the API perspective, productSpecCharacteristicValueUse (PSCVU) serves three specific purposes:

1. To restrict the list of characteristics available in a Product Offering

2. To restrict the list of characteristic values available in a Product Offering

3. To restrict a specific price to a specific characteristic value

Restriction is the key concept here.

Using PSCVU to override a characteristic value defined in the Product Specification is not its intended purpose.

(Also, characteristic values don't have unique IDs,  so if you override the char value name, you break the link with the char value defined in the Product Specification.)

That said, I have used PSCVU to override the "isDefault" flag in my implementation. It was a conscious design choice. While it doesn't align with the intended use of PSCVU, it doesn't technically break anything either.

My 2 cents,

Hello ,

In TMF620 v5.0, the prodSpecCharValueUse.productSpecCharacteristicValue object is used to define a list of characteristic values specific to a ProductOffering.

The Conformance Profile states this list must be a strict subset of values defined in the related ProductSpecification.productSpecCharacteristic.valueSpecification.

I'd like clarification on two key aspects:

Which attributes in productSpecCharacteristicValue are allowed to differ in the ProductOffering context?
For example:

Can fields like isDefault, validFor, or configurable be safely overridden?

Are fields like value, valueType, @type, and unitOfMeasure immutable and must match exactly what's in the specification?

How should an implementation validate whether a value in prodSpecCharValueUse corresponds to a value in the ProductSpecification?

If id is present in both: should matching be based on id only?

If id is missing: should matching rely on a tuple like (value, valueType, @type, unitOfMeasure)?

If no match is found in the specification, should the server:

a) reject the request with 400 Bad Request, or

b) silently ignore the unmatched value?

Any guidance or best practices would be much appreciated.

Thanks,
Emir
ZIRA Group