Question about 1..n requirements #interproc

OP-TED / ESPD-EDM

The European Single Procurement Document enables accelerated processing of preliminary evidence in EU public procurement. The ESPD EDM enables applications to integrate with national ESPD service providers.

http://docs.ted.europa.eu/ESPD-EDM/

European Union Public License 1.2

39 stars 52 forks source link

Question about 1..n requirements #interproc #383

Closed arunas-z closed 1 year ago

arunas-z commented 1 year ago

Hello,

we would like clarification on requirements with ..n cardinalities.

Our understanding is that ..n for question is to indicate that this question can have multiple answers.

For responses this is no problem as TenderingCriterionResponse is separate from questions so one question can have multiple answers.

However for requests the "answers" to requirements are present in TenderingCriterionProperty and XSD currently allows only one occurence of ExpectedDescription etc. Therefore to provide multiple requirement values we are supposed to duplicate TenderingCriterionProperty for each requirement value?

pascalinelaur commented 1 year ago

Hello @arunas-z ,

Your understanding is correct. For Requirement with multiple cardinality, the request will have as many TenderingCriterionProperty as needed, and each TenderingCriterionProperty will have a different identifier.

Kind regards, The ESPD Team.

Nikanoras commented 1 year ago

Hello @pascalinelaur , Can you provide an example how IDs' will look in version 4.x if we would have 2 instances of this requirement?

Kinds regards, Nikanoras

pascalinelaur commented 1 year ago

Hello @Nikanoras , Hello @arunas-z

The image of the initial question is related to the sheet "SC-References". Hence, for the criterion C37 work-perform, 2 occurrences of the requirement at line 16 will have an XML PATH LIKE ID that will look like the following :

- first occurrence : C37_SC_work-perform/RG1/RSG1/RSG1/RSG1/RQ1/R1
- second occurrence : C37_SC_work-perform/RG1/RSG1/RSG1/RSG1/RQ1/R2

If we assume that we have an extra layer for describing lots, we will then have two occurrences of the pattern "Rn" at the end of the path to describe the occurrence semantics, as follows:

- first occurrence : C37_SC_work-perform/RG1/RSG1/RSG1/RSG1/RQ1/R1/R1
- second occurrence : C37_SC_work-perform/RG1/RSG1/RSG1/RSG1/RQ1/R1/R2

Kind regards, The ESPD Team.

Nikanoras commented 1 year ago

Does the same logic apply to Questions of cardinality 1..n, f.e. of type "EVIDENCE-ID"? For every evidence we create an instance of TenderingCriterionProperty? or we create one TenderingCriterionProperty which points to one TenderingCriterionResponse which has reference to Evidence which has as many instances of DocumentReference as there were evidences?

pascalinelaur commented 1 year ago

Hello @Nikanoras ,

Thank you again for you follow up question.

In the Request :

For questions, there will always be only one instance of "TenderingCriterionProperty" for a given question, because question occurrences are defined in the Response.
For requirements, there will be as many instances of "TenderingCriterionProperty" as we have occurrences of requirements.

In the Response:

For questions, there will be as many instances of "TenderingCriterionProperty" as we have occurrences of questions.
For requirements, it is the replication of the structure that we have in the Request.

Regarding the "TenderingCriterionResponse", the ESPD practice is to have one "TenderingCriterionResponse" for each answer value. Hence, many "TenderingCriterionResponse" can be related to the same question but for different occurrences.

Please let us know if you need further clarifications.

Kind regards, The ESPD Team.

pascalinelaur commented 1 year ago

As we have no more comments, we proceed to close this issue.