-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question on UUID for Repeatable Question Sub Group #312
Comments
Greetings, As you pointed out, every QUESTION to be answered must be provided in the REQUEST by the CA. Following the case you provided, a QUESTION_SUBGROUP criterion element with 0..n cardinality (with value f5276600-a2b6-4ff6-a90e-b31fe19dae41) the fixed UUID must be kept for every occurrence of the QUESTION_SUBGROUP. In the other hand, the UUIDs created dynamically for each dependent QUESTION (ie, Date of conviction, Reason...) must be unique and this unique UUID is the one that will be used in the cac:TenderingCriterionResponse. In the snippet you provide if the REQUEST HAS two cac:SubsidiaryTenderingCriterionPropertyGroup for f5276600-a2b6-4ff6-a90e-b31fe19dae41
the RESPONSE to each QUESTION must be answered with the referred UUID like follows:
Please, let us know if you require further detail. |
Thanks @psotofer for your last comment here. But this means that the suppliers won't be able to reuse any existing xml response for the questions for which UUIDs are generated dynamically. They will have to populate these fields in the UI manually, correct? |
Greetings, Please advise if this answer your doubt. |
This issue is closed as a duplicate of issue 311 (#311), since both of them are related to the use of UUIDs. |
Greetings, We reopen this issue to address the reuse of xml you pointed out in your last message: we are currently working on this and will come back to you when we have the final results of our analysis. |
Greetings, |
Hi, we are reviewing your proposal. We will share our thoughts in the next comment. |
Greetings, We will be very please to hear about any suggestion or question you have regarding this topic. |
Hi, the proposed solution seems to be a valid one assuming that the number of responses to the questions is not limited. If we could limit it then we could have the constant number of questions (eg. 10) - each of them with its UUID what ultimately would allow for reusing response values. |
Additionally to the comment above, during the last OUC (07-10-2021) it was discussed the possibility of limiting to a certain number of possible questions was discarded. Find as a quote the topic discussed and discarded:
It was discarded as it is deemed better to define a global solution that is not constrained with specific constants that might become obsolete. |
Following discussions in the OUC, various proposals for addressing multiple cardinalities in the response have been discussed:
Description of the "XML Path Like Variant" proposal We have further developped this variant with additional features:
The proposal provides a path to a target criterion element (criterion elements can be captions, questions, requirements, responses, etc. see column 1 below). This proposal is based on a pre-defined short tag name for each element and a numbering according to the position within the tree structure. The table below shows the criterion elements’ short tag and corresponding UBL element.
The sample below shows the tagging and numbering of the criterion C1 EG crime-org.
The sample below shows a corresponding XML extract related to the "TenderingCriterionProperty" (structure) for the Question "Date of conviction" of Criterion C1 EG crime-org.
The sample below shows a corresponding XML extract related to a "TenderingCriterionResponse" (contents) for the Question "Date of conviction" of Criterion C1 EG crime-org.
The sample below shows a corresponding XML extract relating to a "Requirement" for the "Number of fiscal years" of Criterion C32 SC spec-year-to. Requirement values are nested within the structure and therefore can apply to a specific question, question group or to the complete structure.
The responses provided are validated against these requirements (constraints).
Description of the "UUID Variant" proposal This proposal keeps the framework of the UUID (fixed and dynamic), but changes the way the link between the Request and the Responses are managed. This proposal restores a direct link between the request and its various responses by re-using the same dynamic UUID from the request for all the occurrences of the target element (Question) in the responses. In order to distinguish among occurrences within the response, semantics are injected into the contents for each "TenderingCriterionResponse".
The sample below shows patten related to a "TenderingCriterionResponse" ID for the Question “Date of conviction” of Criterion C1 EG crime-org (adapting the UUID currently in use).
The sample below shows a corresponding XML extract related to the "TenderingCriterionProperty" (structure) for the "UUID Variant" proposal (Question "Date of Conviction" of Criterion C1 EG crime-org). This extract is the same for the “UUID As-Is".
The UUID for each response contents is different. However, it is related to the structure (Question) via the ValidatedCriterionPropertyID. The sample below shows the XML extract related to a "TenderingCriterionResponse" (contents) for the "UUID Variant" proposal (Question "Date of Conviction" of Criterion C1 EG crime-org).
The sample below shows the XML extract related to the "Requirement" "Number of fiscal years" of Criterion C32 SC spec-year-to). Requirement values are nested within the structure and therefore can apply to a specific question, question group or to the complete structure.
Comparison of the XML Path Like Variant proposal and the UUID Variant proposal The XML Path Like Variant proposal is a structure-based approach that aims at replacing the dynamic UUID. Each time, the structure changes, the paths have to be recomputed. On the other hand, the UUID Variant proposal keeps the dynamic UUID, but adds semantics. The property used for validation (ValidatedCriterionPropertyID) has a constant UUID. However, the dynamic UUID for the response contents (TenderingCriterionResponse ID) has a tag added (Rn) to differentiate the various response occurrences.
|
Hello @konstantinosraptis91, The solution was implemented in ESPD-EDM v4.0.0 via XML path like IDs replacing dynamic UUIDs. |
Hi,
Referring to the Exclusion Criteria , pasted below. If the Contracting Authority provides only one set of Questions for Question SubGroup (Row 13) (See XML snippet from Request below) in the ESPD Request
and if the EO wants to provide multiple responses , how will he generate the UUID to be put in the
<cbc:ValidatedCriterionPropertyID schemeID="Criterion" schemeAgencyID="EU-COM-GROW" schemeVersionID="3.0.0">478e8188-04dd-4da4-961f-835165b2ab15</cbc:ValidatedCriterionPropertyID>
for the 2nd or 3rd set of questions, as the CA has provided only one set in the Request.Or does the CA have to provide the unique number of TenderingCriterionProperty and subsequent questions for the EO to answer against ?
Request Snippet:
The text was updated successfully, but these errors were encountered: