Open APIs

 View Only

  • 1.  Bounding of Integer data types in specifications

    Posted Feb 29, 2024 03:35

    This is a very specific question on the datatype for the creditRiskRating attribute of the CreditProfile in the TMF 629 version 5.0.0 specification.

    The specification defines it as an integer but the integer values are not bounded by upper and lower values. Should the TMF specification be improved to include the bounded values, and a definition for each of the integer values that can be assigned, or perhaps define a "Risk" enumeration with values "High", "Medium" and "Low".

    A more general question is whether the TMF API specifications should be regarded as baselines, and service providers feel free to extend them to suit their specific requirements.



    ------------------------------
    Mark Ussher
    Telstra Corporation
    ------------------------------


  • 2.  RE: Bounding of Integer data types in specifications

    Posted Feb 29, 2024 07:58

    Hi Mark

    I don't think it's practical to legislate the bounds of this type of attribute in the Open API standard, since the boundaries will depend on implementation. Unless we can get the entire industry to agree an a percentage scale for risk, say 0-100, in which case it would be feasible, using the "maximum" and "minimum" keywords for a "number" property.



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



  • 3.  RE: Bounding of Integer data types in specifications

    Posted Feb 29, 2024 20:19

    Could we also get a response to the more general question of...whether the TMF API specifications should be regarded as baselines, and service providers feel free to extend them to suit their specific requirements?

    Our use case is that TMF specify creditRiskRating to be an integer. However our master data stores (salesforce) store the equivalent as a string (LowRisk/MediumRisk/HighRisk). Forcing our consumers to subsequently map a string to an (arbitrary) number from our TMF API response seems onerous. What is the general approach in such circumstance?



    ------------------------------
    Mark Ussher
    Telstra Corporation
    ------------------------------

    Original Message


  • 4.  RE: Bounding of Integer data types in specifications

    Posted May 26, 2024 03:45

    Hi Mark

    First, apologies for the delayed response.

    I don't have an easy answer for this - I don't think it's healthy to redefine data types in what is a nominally published standard.

    The best I can suggest is that you add an extension attribute with your enum'ed list of values, and use that instead of the property in the published file.



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

    Original Message


Related Content