OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

bdxr message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [bdxr] Question on the differences of the data model between Peppol SMP and OASIS SMP 2.0


Hi Philip,

good to hear that Peppol is looking into the possibilities of using the OASIS SMP 2.0 specification!

The data-model indeed changed in the SMP 2.0 version to add more flexibility in the relationship between Services and Processes. Although the structure is not back-wards compatible we made sure that functionally everything that could be expressed in the old version can still be expressed in the new version. See also our answers to your questions below.

a) Is our understanding on that topic correct?

No, also in the OASIS SMP 2.0 Standard you can use the Process to identify which Endpoint should be used for a specific Document. As you see in the class diagram presented in figure 3 there is the ProcessMetadata class which can contain zero or more references to a Process in which the Document is used and which all share the same Endpoint. If different Endpoint are used for different Processes multiple ProcessMetadata instances should be contained in the ServiceMetadata instance.

b) Have you foreseen a way to mimic the Peppol SMP endpoint structure?

From a logical perspective the Peppol structure can be easily mapped to the SMP 2.0 structure as the Process ID block from you first diagram can be represented by the ProcessMetadata class.

The advantage of the SMP 2.0 datamodel however is that when the Document is used in multiple Processes but received on the same Endpoint in SMP 2.0 you just need one ProcessMetadata instance that includes the Endpoint and that references all Processes instead of repeating the Endpoint for each Process.

c) If you answered b) with "no", do you plan to support the Peppol SMP endpoint structure in future version?

N/A

d) If you answered c) with "no", do you see a chance if a respective request comes in, to change back to the old structure?

N/A

Groet,
Viele GrÃÃe,
Regards,

Sander Fieten

On 07/09/2023 13:53, Philip Helger wrote:

Hi guys,

OpenPeppol is currently looking into the OASIS SMP 2.0 specification in detail and stumbled upon an issue, where we would need your input.

We were studying the data model of the SMP Endpoint information and stumbled upon a difference we cannot completely assess.

In the Peppol SMP specification (latest version: https://docs.peppol.eu/edelivery/smp/PEPPOL-EDN-Service-Metadata-Publishing-1.2.0-2021-02-24.pdf ) and the BDXR SMP 1.0 version an SMP endpoint is uniquely identified via the quadruple of:

a) Service Group ID

b) Document Type ID

c) Process ID and

d) Transport Profile

In comparison to that, the data model of SMP 2.0 looks slightly different and uses a unique key consisting of a triple:

a) Service Group ID

b) Document Type ID

c) Transport Profile


From our perspective we are loosing an element of customizability (Process ID) and wanted to ask if:

a) Is our understanding on that topic correct?

b) Have you foreseen a way to mimic the Peppol SMP endpoint structure?

c) If you answered b) with "no", do you plan to support the Peppol SMP endpoint structure in future version?

d) If you answered c) with "no", do you see a chance if a respective request comes in, to change back to the old structure?


Thanks and BR,

Philip




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]