it makes sense, thanks.

Ken Holman Kenneth Bengtsson can we discuss this in the UBL TC meeting?

Kees Duvekot: Yep, will put it on the agenda for this week.

Roberto Cisternino, in continuation of our email conversation. You wrote:

For instance the DigitalAgreementID cound be a unique ID for a precise the PEPPOL release (e.g. BEPPOL BIS 3.0 summer 2019) 

I'm still trying to understand what information is contained in "PEPPOL BIS 3.0 summer 2019", and which isn't already covered by the CustomizationID and the ProfileID. If I try to examine the information provided in the value, then:

PEPPOL BIS 3.0 in itself doesn't provide any information. It is just the title of a library that contains a number of PEPPOL specific customizations of business profiles and business document requirements. In order to retrieve any specific information out of "PEPPOL BIS 3.0", I need to know the document type and the business profile it is part of. Let's say for example that it is an order response and that it is part of the BIS 3.0 ordering profile. Then the UBL CustomizationID will tell me that this is a BIS 3.0 order response document:

<cbc:CustomizationID>urn:fdc:peppol.eu:poacc:trns:order_response:3</cbc:CustomizationID>

And the UBL ProfileID will tell me that the order response is part of the BIS 3.0 ordering profile:

<cbc:ProfileID>urn:fdc:peppol.eu:poacc:bis:ordering:3</cbc:ProfileID>

So I understand that the key here is that this is a "summer 2019" release of BIS 3.0, which would supposedly be different from a "spring 2019" release.

Now both the CustomizationID and the ProfileID are of data type Identifier, which "identify and distinguish uniquely, one instance of an object in an identification scheme from all other objects in the same scheme". So consequently, if the summer 2019 release of BIS 3.0 is different from the spring release of BIS 3.0, its corresponding CustomizationID and/or ProfileID would also have to be different. And again, there is no information in the "PEPPOL BIS 3.0 summer 2019" value that I don't already have in the CustomizationID and/or the ProfileID.

Perhaps you can provide a specific example where the DigitalAgreementID is useful and not already covered in UBL?

This would be a major change to ALL documents and I do not see a real need for this right now based on what I have already written in the issue. So we either postpone this to a later release, or decided to close the issue because it can be solved in a different way.