Open APIs

 View Only
  • 1.  Mandatory elements on extensions (TMF630).

    TM Forum Member
    Posted Mar 02, 2023 07:31

    Hello,

    It's clear that we have the polymorphic mechanism that allow us to provide extensions to the provided basic models.

    In the context of extensions/modifications, the questions are:

    1 - Are we allowed to include new mandatory sub-elements into the flows as per the TMF guidelines?

    2 - Are we allowed to introduce new mandatory attributes to the models already provided by the TMF APIs?

    3 - Are we allowed to change the mandatory/optional aspects of attributes presented in the basic models?

    Thanks!



    ------------------------------
    Marcos Donato da Silva
    Ericsson Inc.
    ------------------------------


  • 2.  RE: Mandatory elements on extensions (TMF630).

    TM Forum Member
    Posted Mar 06, 2023 10:28

    Hi Marcos,

    That is indeed an interesting question and please do not consider the thoughts that I express as authoritive.

    I see two conflicting requirements here:

    1. Adding new mandatory attributes or sub-elements breaks the current conformance testing
    2. Not making certain new attributes or sub-elements mandatory will allow API users to create entities that won't pass as valid for the sub-sequent functionality and business logic

    My approach to this is to differenciate between entities representing tasks and business interactions and those that represent pure repository entities (catalog or inventory).

    For repository entities I tend to make extensions always optional but restrict access to the Create, Update Delete functionaltiy to associated business interactions. (e.g. Only Product Order Management is allowed to update Product Inventory. For the Business Interactions creation of a business interaction is possible with all extensions optional but a semantic validation phase will either acknowledge or reject the business interaction.

    Using this approach will allow to fuflil both these conflicting requirements in many cases. I would like to say it solves all the cases but that is based on anecdotal evidence of the implementations I was involved with only.

    Regards



    ------------------------------
    Koen Peeters
    OryxGateway
    ------------------------------



  • 3.  RE: Mandatory elements on extensions (TMF630).

    TM Forum Member
    Posted Mar 07, 2023 08:11

    Hey Koen,

    I thank you for your time to answer my question.

    Indeed, the APIs I've implemented so far we used a similar approach by usually:

    • Use the TMF base element as @baseType.
    • Inherit all of the base elements in the new @type.
    • Not changing the mandatory vs optional constraints from @baseType elements.
    • Not adding new mandatory attributes in the extended new @type.

    However, at some situations, it's hard in the extensions, not to deal with the elements we consider as mandatory as per our business logic (which may be either new added elements or, elements which were optional in the base-TMF definition that we do need in our application).

    So, some exceptions are there sometimes, when for instance we can't assume default values for "optional elements which we consider as mandatory but, we declared as optional not to break API backward compatibility"

    Therefore, I miss a clear statement in the TMF 630 part-2 to guide us on how to deal with the three questions from my original post, as I've seen implementers taking different paths on this by giving distinct interpretation over the words extracted from the TMF documents such as:

    From TMF630-part-2:

    (..) Extending the basic schema of an entity like Product to create a subclass in that case all the mandatory attributes and relationships of the base schema should be present in the extension. (..)

    From TMF620:

    (..) The following tables provides the list of mandatory and non-mandatory attributes when 
    creating a ProductOffering, including any possible rule conditions and applicable default 
    values. Notice that it is up to an implementer to add additional mandatory attributes.
    (..)



    ------------------------------
    Marcos Donato da Silva
    Ericsson Inc.
    ------------------------------



  • 4.  RE: Mandatory elements on extensions (TMF630).

    TM Forum Member
    Posted Mar 07, 2023 12:18

    This is a tricky one - vendors (like Ericsson, Amdocs, and more) are motivated to express their unique IP and business capabilities by expanding the Open API entity model. In some cases this cannot easily be done without making an extension mandatory, and then we run up against the CTK failure.

    On the other hand, if TMF will allow mandatory extensions, the result is that interoperability, one of aims of the Open API project, is impaired.

    I don't have a good answer here, sorry.



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



  • 5.  RE: Mandatory elements on extensions (TMF630).

    TM Forum Member
    Posted Mar 08, 2023 07:32

    Thanks Jonathan,

    I remember some years ago mentions around planned API conformance levels (e.g.: back to 2019, at TMF633B document: "Filtering is mandatory for first compliance level (L1) and ..." )

    I was wondering whether this (future introduction of conformance levels as today we have on/off only) could be of any help in questions such these ones.

    e.g.:

    Some hypothetical Conformance Levels:

    • 5: This is the canonical TMF implementation.
    • 4: This is the TMF implementation without optional elements.
    • 3: This is the TMF implementation with extensions introducing mandatory fields.
    • 2: This is the TMF implementation with changes over pre-defined optional/mandatory attributes.
    • ...



    ------------------------------
    Marcos Donato da Silva
    Ericsson Inc.
    ------------------------------