Hi Ashish,
If it is recommended to use the Composite / Atomic ProductOfferingSpecification to describe the composition, it is because it provides much better flexibility to change and improve the offers.
Indeed, the offer layer has all the capacity to support the cardinality in the composition of offers.
But if we don't have this capacity at the Product level, it's because the choices of "is it mandatory or not?", "how many can be ordered?"… are commercial choices as well as the price and commitment. All the commercial choices must be described at offer level.
If you would implement the composition at a Product level adding the capacity to support cardinality, for Hankit example of SIP, you would have:
· 1 instance of ProductOfferingSpecification,
· 1 instance of CompositeProductSpecification
· 2 instances of AtomicProductSpecification
So you have a total of 4 instances.
If you simply use SID model with its current capacities at offer level, you would have:
· 1 instance of CompositeProductOfferingSpecification,
· 2 instances of AtomicProductOfferingSpecification,
· 2 instances of AtomicProductSpecification
So you have a total of 5 instances.
In my opinion, I don't think that having 5 instances instead of 4 instances is a big deal today.
And the main point is that you describe commercial constraint at offer level.
Contrary to what you said, the AtomicProductOfferingSpecifications are not technical offers and are completely sellable in many CompositeProductOfferingSpecifications.
One of the main advantages of the clear separation between Offers and Products is the fact that you can sell the same ProductSpecification through many ProductOfferingSpecifications with different constraints and prices, such as having an offer for the mass market and another one for B2B or even a specific one for employees.
I can tell you there isn't any plan to introduce cardinality at product level.
Of course, you can attend SID calls to propose an evolution for this. In this case, you would need examples that justify the need of evolution.
See you,
Cécile Gérardin (previously Ludwichowski)
SID Learder
------------------------------
Cecile Gerardin
Cécile Gérardin
------------------------------
Original Message:
Sent: Mar 28, 2025 13:49
From: Ashish Maheshwari
Subject: GB922 Product - Composite & Atomic ProductSpecifcations
@David Milham @Jonathan Goldberg and other experts - wish to get your view on a topic ... IG1233 recommends not to use Composite Product Specification and i believe rational for this could be lack of support / introduction of cardinality at Composite Product Spec layer and also TMF 620 and TMF 622.
Currently composability is recommended at Offering layer with support of cardinality at this layer by TMF however this enforces indirectly for not composing PS and rather creating Offering for every atomic PS to achieve flexibility of composition but this results into many technical ( non - sellable Offers).
Many modern COTS packages have been extending TMF SID and APIs to enable cardinality at Composite Product Spec as this gives more flexibility and agility with a choice of composition at both PO and PS layer.
Wanted to know your perspective about this and what's the reason for TMF not introducing cardinality at Composite Product Spec layer and is there any plan / possibility of introducing it in future?
Thanks in advance,
Regards, Ashish
------------------------------
Ashish Maheshwari
Infosys
Original Message:
Sent: Mar 08, 2023 04:07
From: David Milham
Subject: GB922 Product - Composite & Atomic ProductSpecifcations
The referenced IG1233 has an Orange email worked exemplar which addresses some of the points you raise .
------------------------------
Dave Milham
TM Forum, Chief Architect
Original Message:
Sent: Mar 07, 2023 17:33
From: ANKIT MADAN
Subject: GB922 Product - Composite & Atomic ProductSpecifcations
Hi Jonathan
Thanks for your response , to extrapolate this further I am potentially looking at use cases where in you might want to define something as product spec but not necesaarily as a product offering as it is not sold independently in the market , the case in point I took here which is a SIP offering with offcourse number ranges .
Now in example I gave the intention is SIP PS will have all voice trunk related features like CLI , Overstamping , NUmber of channels etc whereas number ranges is primarily about the numbers associated with the SIP Trunk , business wants the flexibility to be able to order "n" number of ranges independently from the lifecycle of the Trunk ,which is even when a Trunk product is with a status of in progress I should be able to order number ranges as a MAC action , currently the product defintion is tightly coupled and hence it doesnt allow us to do the same , and thats the reaosn to be able to separate this out into two product specifications .
Now again quoting the GB922 Product guide
"For example, a composite high-speed internet ProductSpecification may include email and personal web pages atomic ProductSpecifications which are not instantiated as separate offerings but still must be instantiated as Products. This is also necessary if a ProductSpecification not instantiated as a ProductOffering has configurable characteristics or prices associated with one or more characteristics"
This gives me the feeling GB922 allows such a construct(potentially by defining order actions on the PS level) and hence the reason of my query .
Thanks !!
------------------------------
ANKIT MADAN
Optus
Original Message:
Sent: Mar 07, 2023 13:13
From: Jonathan Goldberg
Subject: GB922 Product - Composite & Atomic ProductSpecifcations
Hi Ankit
The construct that you refer to, a composite product specification, allows the definition and instantiation of complex product structures within an offering. But this does not imply that you can do MACD orders on a product inside the substructure. In my understanding, an inventory product can be the target of a MACD product order only if it was instantiated from a product offering. Certainly this is true if the order will have commercial impact, which is encapsulate in the product offering and associated prices.
Possibly, in your example, it might make sense to allow a MACD order on the number range, but what, exactly, would such an order do? Expand the range would surely have a pricing impact, no?
------------------------------
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:
Sent: Mar 07, 2023 04:17
From: Dave Milham
Subject: GB922 Product - Composite & Atomic ProductSpecifcations
Have a look at this best Practice Guide based on BT and Orange experiences
------------------------------
Dave Milham
TM Forum, Chief Architect
Original Message:
Sent: Mar 06, 2023 22:06
From: ANKIT MADAN
Subject: GB922 Product - Composite & Atomic ProductSpecifcations
Hi Experts
I want your opinions on the below , I was reading through GB922 SID model for product and it has this concept of a Product being an instantiation of a Product Oferring Or Product Specfication.
As shown in the class diagram below .

Now ijust to quote a few things from the document .
- "For example, a composite high-speed internet ProductSpecification may include email and personal web pages atomic ProductSpecifications which are not instantiated as separate offerings but still must be instantiated as Products. This is also necessary if a ProductSpecification not instantiated as a ProductOffering has configurable characteristics or prices associated with one or more characteristics."
- "There are typically a number of ProductOfferings associated with a single ProductSpecification, for example to reflect offers to the market for different time periods. In cases where a ProductSpecification's value to the business is solely as a component part of a CompositeProductSpecification, it does not have a ProductOffering associated with it as it is not be sold on its own. Cases where these items are supplied to the Customer separately as 'spares', e.g., under warranty, are covered under Product below."
Now here is the question reading through the document it seems it is possible to have Product Specs which are not related to any offering but exists only as a atomic product specs insode a Composite Spec (which is related to an Offering), however this atomic product spec can still be instantiated as a Product .
If that is case I am hoping once a Atomic Product Spec is instantiated as product and is part of the customer's subscription inventory , it allows MACD operation on that product instance .
A very simple example below , We have a SIP Product offer which is what is sold to the end customer containing a SIP PS(Composite) and a Number Range (Atomic) , the SIP PS is associated to the SIP Product Offer , where as the Number Range PS is not associated to any offer , so when sold the below structure will create twp product instances one for SIP and the other one for the Number Range and will allow MACDs separately on the Number Range instance .
Your inputs on this will help clarify the context on the GB922 Product doc .
Thanks in advance .

#General
------------------------------
ANKIT MADAN
Infosys
------------------------------