Thanks for the input, Philip. And good timing! We are just about to meet face-to-face next week to discuss new requirements for SMP, among other things :-)
Both use cases seem clear to me. But just to further my understanding: In what situations would you need to implement use case “a” at SMP level instead of simply pointing to the new SMP from the SML? And additionally:
if I remember correctly, then the SMP Redirect function was implemented to overcome the 1:1 Participant-SMP limitation in the old Peppol SML specification. Have you thought about implementing support for both use cases at SML/BDXL level?
/Kenneth
From:
bdxr@lists.oasis-open.org <bdxr@lists.oasis-open.org> on behalf of Philip Helger <philip@helger.com>
Date: Thursday, September 21, 2023 at 12:47 PM
To: bdxr@lists.oasis-open.org <bdxr@lists.oasis-open.org>
Subject: [bdxr] Proposal for an extension of the data model of SMP 2.0
Hi guys,
Thanks for the response on the previous matter - these things are now clear to us.
While further progressing we came about one more thing that would make sense to us in the context of "Redirect" in the data model.
From a Peppol perspective there are two major use cases for the "Redirect" element:
a) A Participant was migrated from one SMP to another, that means all queries should be redirected to the new SMP. Currently, to our understanding, that can only be done based on a Document Type (ServiceMetadata/ID) but not for all Document Type IDs.
b) A Participant wants to handle one or more Document Types on a different SMP that is not registered in the SML (due to the 1:1 relationship between Partcipant and SMP). That can be done with the current data model.
So have you considered adding the Redirect class directly as a child to the ServiceMetdata class as depicted below (of course making it a choice between ProcessMetadata and Redirect):
Thanks and BR,
Philip