originalSender and finalReceipient /@type is mandatory

[JesperLarsenOO]

Hi Oxalis team (Frode),
We have learned that there is a problem in the way Oxalis is stating the upis scheme in relation to originalSender and finalReceipient in the AS4 message Header

Basically the CEF AS4 profile mandates use of /@type:

Like this
eb:MessageProperties
<eb:Property name="originalSender" type="iso6523-actorid-upis">9914:abc</eb:Property>
<eb:Property name="finalRecipient" type="iso6523-actorid-upis">0088:505068900011111</eb:Property>
</eb:MessageProperties>

Oxalis is doing this:

eb:MessageProperties
<eb:Property name="originalSender">iso6523-actorid-upis::9914:abc</eb:Property>
<eb:Property name="finalRecipient">iso6523-actorid-upis::0088:505068900001111</eb:Property>
</eb:MessageProperties>

So having the upis scheme in the /@type and not in the value would be conformant to the AS4 profile of CEF and Peppol

Best,
Jesper - Peppol OO

[eriklundin]

Where is this documented? This directly contradicts the rules in eBMS 3.0. Only name is allowed.

Forking an existing project and keeping the orginal name/version number is simply wrong.

https://github.com/difi/Oxalis-AS4/blob/master/src/main/xsd/ebxml/ebms-header-3_0-200704.xsd

A new name and version should be chosen that indicates the changes from the original version. Type as a attribute on the Property tag is not allowed in eBMS 3.0. So therefor it's not eBMS 3.0. It's possibly an extension from it but it's not the same.

[FrodeBjerkholt]

I was given this link: https://issues.oasis-open.org/projects/EBXMLMSG/issues/EBXMLMSG-2?filter=allissues

Jesper can probably give you a link to the documentation.

Maybe I should rename the file in the Oxalis-AS4 project to ebms-header-3_0-200704_with_property_type_attribute.xsd ?

[FrodeBjerkholt]

The reference implementation (Domibus) also has this property type atttibute and the change has been confirmed by commitee members. But I have also addressed the problem, why there is no official release published.

[eriklundin]

There's a lot of problems connected to changing critical structures related to validating.

1. Should the namespace be changed in the xml-data sent between peppol nodes to make it clear that it's not the original structure that should be used for validation? It's very confusing when refering to a namespace that's not compatible with the actual data.

2. The documentation on https://docs.peppol.eu/edelivery/as4/specification/ should be updated to reflect that it's not eBMS 3.0 that should be used. Perhaps link to the actual xsd describing the format that should be used? Maybe a pdf that describes the difference from eBMS 3.0?

3. Maybe hold a version number for the fork so that multiple changes doesn't confuse even more?

[FrodeBjerkholt]

I am not representing Peppol, but I can forward your suggestions to them.

[phax]

Dear @eriklundin et al,

The link to the updated XSD is indeed part of the Peppol AS4 profile, but well hidden at https://docs.peppol.eu/edelivery/as4/specification/#_footnotedef_1

The namespace cannot be changed, as this is still an OASIS standard, and the specification itself is the mandatory part. The specification names the "type" attribute and as such it is mandatory to be supported. The updated XSD is also provided by OASIS and as such "official". A new namespace would be a task for OASIS, not for Peppol.

Since the Peppol specification clearly indicates the requirement of the attribute, the not-supporting of this attribute is a bug in Oxalis and as such it is unfortunate, that the change required a change in the underlying XSD. Sorry.

hth, Philip (on behalf of OpenPeppol)