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