TOOP Requirements related to the ESPD

[mondorf]

This issues proposes to extend the ESPD EDM version 2.1.0 to create interoperability with the TOOP project. To achieve this, it is proposed to include multiple elements and classes to the Response and Evidence classes of the ESPD EDM. In this way it will be possible better describe the evidence and to convert TOOP Responses into ESPD Responses when an Economic Operator settles references to national databases and registers (through the TOOP Architecture) when creating an ESPD for a Contracting Authority. Moreover it will be possible for the Contracting Authorities to request evidences from these Data Providers (Registers/National Databases) later on when evaluating the ESPD. The requests to these Data Providers will be again done through the information established in the ESPD by using the TOOP Architecture. In order to perform the Routing in the TOOP Architecture, it is for example necessary that the Economic Operator describes the Data Provider in the ESPD including for example the endpointID and country of the Data Provider.
The suggested changes are summarized in the following document: http://wiki.ds.unipi.gr/display/TOOP/ESPD+Interoperability+-+ESPD+Extension

The document illustrates the changes and provides a mapping suggestion to the UBL syntax. Most elements could be easily mapped.

Remark: In fact only one element was a little difficult, the document validity period. While UBL works with start-end date to describe the validity period, TOOP uses a free text field at the moment (this could be also changed in TOOP). The document referenced above distinguishes between Start-date of the validity period and issue date and assumes that the contracting authority will lookup the validity period in eCERTIS because the validity period is usually bound to a certain procedure like eProcurement. Thus the end-date cannot be determined by the Data Provider in most cases. It should be discussed wether the issue date of an evidence is sufficient determining as well the start date of the validity period. If the answer is yes, only one of the two elements would be required.

The figure below illustrates the changes proposed by TOOP

[JosePRevenga]

We understand that TOOP, similarly to other projects like Open PEPPOL, may need this additional information requirements. However, these changes would go to the XSD UBL schema and would need to be proposed to the UBL TC. Besides, your description of the workflow implicit in your issue (the role of e-Certis) seems to contain conceptual errors in our opinion. We would need to discuss it with you and the e-Certis team.

In the meantime, we will find a temporary solution for v2.1.1.

[mondorf]

We are looking forward for a discussion. May I add two comments.

In our opinion, the current UBL scheme is suitable to fulfill our proposed requirements. Actually we have already implemented this in parts based on the current UBL version, created XSLTs for mapping between TOOP EDM and ESPD EDM and described how we do the mapping in the following document: http://wiki.ds.unipi.gr/display/TOOP/Using+the+TOOP+EDM+in+eProcurement - particularly section relevant for the extension is "Creating ESPD Response out of TOOP Response (Step 2)".

The role of eCERTIS and implicit workflows described above was just a side note for a specific element (the validity of an evidence) which can be further discussed. If you are interested in how we see the role of eCERTIS in TOOP, have a look to the following document (pls. do not care about the long example of the eCERTIS API, I just exported the document from Jira where you have a shrinked view on this) TOOP-eCertisAdoptioninTOOP-270919-1527-37.pdf

[JosePRevenga]

Dear TOOP team,

1. • About the Period: if you look into the UBL Period data structure you will observe that all the data are optional. This means that you could use the cbc:Description element only, or cbc:StartDate cbc:EndDate, or all of them. So, the way you use this Period element would be controlled by an externalised rule, e.g. Schematron one, as the Period element gives you all the flexibility you need. This also means that your class Evidence should not contain the attributes start date, issue date and remarks. In the ESPD model, we "delegate" to cac:DocumentReference, as many meta data about the Evidence as possible. Hence, the validity period you are including in your Evidence class would be equivalent to the UBL cac:ValidityPeriod aggregated to cac:DocumentReference.
2. • Similarly, we understand that your class equivalent to cac:DocumentReference would be "Evidence document". In this "Evidence document" class you add two attributes as if they didn't exist in the UBL model, but in fact they do. The "external document type code" could be mapped to /cac:Evidence/DocumentReference/cbc:DocumentTypeCode, while "external document mime type code" would be mapped to /cac:Evidence/DocumentReference/Attachment/ExternalReference/cbc:MimeCode
3. • Your class "Evidence provider" does not have an equivalent termed class in the UBL cac:Evidence class. However, the fact is that the current UBL model has the possibility of referring to "Issuer parties" in two different placeholders:
   • cac:Evidence/cac:EvidenceIssuingParty
   • cac:Evidence/cac:DocumentReference/cac:IssuerParty

Our proposal would be a twofold action. On the one hand, we propose to use the cac:EvidenceIssuingParty to indicate who is the provider of the Evidence and you document it in a very conspicuous manner. On the other hand, we will propose to the UBL Technical Committee to change the naming of cac:EvidenceIssuingParty to cac:EvidenceProviderParty.

About the "Evidence provider endpoint ID": the UBL Party class aggregates a 0..1 cbc:EndpointID element, so this would also be covered by element cac:EvidenceIssuingParty (to be renamed as cac:EvidenceProviderParty).

About the "Evidence provider administrative unit": the UBL Party doesn't seem to provide anything similar to this, but we wonder whether this should go or not to the "Contact details" class.

About the "Evidence provider postal address" class: this is covered by the UBL Party.

About the "Contact details" class: the UBL Party class has a Contact aggregated with anything you need in your model. By the way, the UBL cac:Contact/cbc:Name could be used to refer to the "Administrative unit". Additionally, you could extra information about the unit or anything else referring to the "Contact point" in the cbc:Note field.

Conclusion: except for the renaming of the cac:EvidenceIssuingParty, every information requirement included in your proposal is actually already covered by the current UBL model.

Looking forward to having your reactions on this conclusion.

[JosePRevenga]

Quick update: cac:EvidenceIssuingParty naming change has been proposed for v3.0.0, as v2.3 discussion has already been closed. Notwithstanding, the TC has pointed out that if this is not an actual technical problem, the solution must be documenting properly how the mapping is.

[JosePRevenga]

For everyone's information:

• For the ESPD-EDM v2.1.1, a spreadsheet has been created to map the above-mentioned TOOP requirements. All of them are fully mappable to the UBL 2.2, used in both v2.1.0 and v2.1.1. The spreadsheet is accessible from this link, or also in the new UBL-2-2 and TOOP Requirements section of the new 2.1.1 release online documentation.

• For v3.0.0 a further and deepest analysis will be made, as TOOP and ESPD integration will be assessed together with the other EU e-Procurement solutions (i.e., e-Certis, e-Forms).

[mfontsan]

We can close the issue, as this issue was already addressed in version 2.1.1 of ESPD-EDM. The new works done in TOOP and the resulting changes are described in the issue #277 .