Open APIs

 View Only

  • 1.  Clarification on mandatory @type field in characteristicValueSpecification (TMF620 v5.0)

    TM Forum Member
    Posted 27 days ago

    Hello,

    According to the TMF620 v5.0 Conformance Profile, the @type field is marked as mandatory under the productSpecCharacteristic.characteristicValueSpecification object - specifically:

    @type – Mandatory when parent is present.

    I would appreciate clarification on the following:


    Does this mean that it is valid and compliant to define a characteristicValueSpecification object with only the @type field present - without any value, valueFrom, valueTo, valueType, or other supporting attributes?

    If yes, what would be the functional or expected purpose of such a minimal object? In practice, it seems this would result in an incomplete or non-functional characteristic configuration.

    My current interpretation is that @type is required to allow correct polymorphic deserialization (e.g., NumberCharacteristicValueSpecification, StringCharacteristicValueSpecification, etc.).

    However, in real-world use cases, an object that includes only @type and no value or valueType is likely not meaningful or useful.

    Therefore, I assume that although only @type is marked as mandatory, implementations should also include at least:

    valueType, and

    either value, or a range (valueFrom / valueTo), or rangeInterval.

    Would you agree with this interpretation, or is there a specific case where @type alone is sufficient?

    Thanks in advance for your guidance.

    Best regards,

    Emir
    Zira Group



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


  • 2.  RE: Clarification on mandatory @type field in characteristicValueSpecification (TMF620 v5.0)

    TM Forum Member
    Posted 26 days ago

    Hi,

    Does this mean that it is valid and compliant to define a characteristicValueSpecification object with only the @type field present - without any value, valueFrom, valueTo, valueType, or other supporting attributes?

    If yes, what would be the functional or expected purpose of such a minimal object? In practice, it seems this would result in an incomplete or non-functional characteristic configuration.

    An example could be MSISDN (phone number for telephony).

    in our case, I would not even bother to have a characteristicValueSpecification object at all. valueType also exists at characteristicSpecification level in case you want to control the type of data for this characteristic.

    I would be careful to state that  value, or a range (valueFrom / valueTo), or rangeInterval should be mandatory.

    continuing on the MSISDN characteristic, I cannot say value is mandatory in the catalogue because you have no value to store in the catalogue. However we do need to specify that value is mandatory.... at runtime:

    • Design-time (catalogue): MSISDN must exist as a characteristic but with no pre-set value so value cannot be mandatory

    • Runtime (cart/order/quote): must be filled in, and possibly validated so value is mandatory but only in the cart/order...

    This has puzzled me for some time now and I have posted a question about this in the frameworx community.



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

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

    Original Message


  • 3.  RE: Clarification on mandatory @type field in characteristicValueSpecification (TMF620 v5.0)

    TM Forum Member
    Posted 25 days ago

    Hello,

    Thank you for the detailed answer regarding the use of characteristics like MSISDN that are expected to be filled at runtime rather than defined with fixed values in the catalog.

    To make sure we are aligned with TMF620 v5.0 principles, I'd like to confirm the correct way to handle such template characteristics in ProductOffering and ProductSpecification.

    For example:
    We have a characteristic like MSISDN with valueType: string and configurable: true, but we do not want to predefine any values in the catalog. The actual value will be entered by the customer or agent during quote or order capture.

    In this case:

    1. Is it sufficient to define the characteristic in ProductSpecification with valueType, @type, and configurable: true, but without any characteristicValueSpecification?

    2. In the ProductOffering, is it correct to refer to this characteristic (via productOfferingCharacteristic or prodSpecCharValueUse) even if no value is predefined, just to make it visible to runtime systems?

    3. If we include the characteristic in prodSpecCharValueUse, but there is no value to reference, what would be the best practice?

      • Use a placeholder like value: "" or "<to be filled>"?

      • Omit the productSpecCharacteristicValue block entirely?

      • Or avoid prodSpecCharValueUse and rely solely on productOfferingCharacteristic?

    We want to ensure the characteristic is:

    • visible in the offering,

    • correctly derived from the specification,

    • and open for runtime input.

    Any guidance or confirmation on this design approach would be greatly appreciated.

    Thanks again,
    Emir
    ZIRA Group



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

    Original Message