The TMF679 specification has chnaged significantly from v4 to v5.
In the v5 version the input information for the QueryProductOfferingQualification is provided through "searchcriteria", whereas the answers are provided using the "qualifiedProductOfferingItems".
This approach makes it much more clear the places used for the searchCriteria and qualifiedProductOfferingItems don't have to be the same.
The question what are the productOfferings for this geographicAddress can now be answered by ProductOffering A at geographicSite S1 and productOffering B at geographicSite S2. e.g. a VDSL based productOffering at the copper outlet and a GPON based productOffering at the fiber outlet.
I guess this means no additional pre-ordering step is required.
Regards
------------------------------
Koen Peeters
OryxGateway FZ LLCKoen Peeters
OryxGateway FZ LLC
------------------------------
Original Message:
Sent: Nov 27, 2024 08:45
From: Kristian Svalheim
Subject: Product Offering Qualification TMF679 - place: same class as request expected in response?
This question applies to TMF679 Product Offering Qualification, though also interested in generic responses.
To TMF679, one input is place, an abstract class, so Geographic Address for instance can be used.
Does the response need to use the same class for place or is there no such expectation? E.g. can the response use Geographic Site for place instead?
This question comes up as there may be multiple sites at the same address and we need to distinguish between them, allowing the consumer of the API the option to select the one they want before placing a subsequent Product Order.
Alternatively, we could introduce a pre-ordering step where the consumer retrieves the Geographic Sites using TMF674 with the Geographic Address as an input and then uses Geographic Site in the subsequent call to TMF679.
Curious to hear your thoughts!