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

------------------------------
Emir Torlak
ZIRA Ltd.
------------------------------

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,

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

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

Thank you - this is very clear and confirms what we expected.

We'll treat prodSpecCharValueUse strictly as a restriction mechanism and will validate that all values match those defined in the associated ProductSpecification. We'll also ensure core attributes like value, valueType, @type, and unitOfMeasure are treated as immutable, and we'll only allow contextual overrides like isDefault where appropriate.

Appreciate the practical input - it's extremely helpful in shaping our implementation policy.

Best regards,
Emir

------------------------------
Emir Torlak
ZIRA Ltd.
------------------------------

Original Message:
Sent: May 21, 2025 10:06
From: Matthieu Hattab
Subject: Override and validation rules for characteristic values in prodSpecCharValueUse

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,

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

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