TM Forum Community

 View Only

  • 1.  Extension Pattern in TMF

    Posted 20 days ago

    Hi all,

    TMF630 Part 2 says allOf should be used to extend objects, and base collection operations can create/return concrete subtypes using @type.  And hence if we need to add new optional fields to the standard TMF object, it has to be extended.

    Using TMF630 extension pattern (allOf + @type), if I extend Agreement to AgreementExtended and also extend nested child objects such as PartyRef to PartyRefExtended ,what is the recommended request/response pattern?

     
    Example:

    • root payload has @type = AgreementExtended
    • child payload needs to have @type = PartyRefExtended

    Questions:

    1. Is this the recommended TMF modeling pattern for extending both root and child objects?
    2. Should request/response schemas still reference the base object and rely on runtime @type?
    3. Or should endpoint schemas explicitly expose base + extended variants  using oneOf  at endoint level?
    4. For nested objects, should the child return its extended @type when extra fields are present?

    Would appreciate any examples from TMF APIs or implementation guidance.

    #General

    ------------------------------
    Bhavik Parekh
    Infosys
    ------------------------------


  • 2.  RE: Extension Pattern in TMF

    Posted 10 days ago
    Hi Bhavik,
     
    Before going down the extension path, I would recommend first sharing the specific use case here - the forum community may be able to help find a simpler solution. For example, TMF schemas already provide generic extensibility mechanisms like `characteristic` (key-value pairs) or `note` that can often accommodate additional data without needing a custom subtype.
     
    That said, if extension is genuinely required after evaluating the use case:
     
    - `allOf` is the correct and recommended pattern per TMF630 Part 2 for extending objects - both at the root level (Agreement → AgreementExtended) and for nested child objects (PartyRef → PartyRefExtended).
     
    - `oneOf` is a different pattern altogether - it is intended for polymorphic type hierarchies where subtypes are mutually exclusive, such as PaymentMethod which can be CashPayment, CardPayment, or BankTransfer. It is not the right fit for simply adding optional fields to an existing type.
     
    So to directly answer your questions: yes, `allOf` + `@type` at both root and child levels is correct when extension is needed. But the first question to ask is whether extension is needed at all.
     
    Hope this helps!



    ------------------------------
    Subhanshu Shukla
    Asst Vice President
    ------------------------------



Related Content