Question on UUID for Repeatable Question Sub Group

[vidhyaneel]

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:
cac:TenderingCriterion
<cbc:ID schemeID="criterion" schemeAgencyID="EU-COM-GROW" schemeVersionID="3.0.0">005eb9ed-1347-4ca3-bb29-9bc0db64e1ab</cbc:ID>
<cbc:CriterionTypeCode listID="criterion" listAgencyID="EU-COM-GROW" listVersionID="3.0.0">crime-org</cbc:CriterionTypeCode>
cbc:NameParticipation in a criminal organisation</cbc:Name>
cbc:DescriptionHas the economic operator itself or any person who is a member of its administrative, management or supervisory body or has powers of representation, decision or control therein been the subject of a conviction by final judgment for participation in a criminal organisation, by a conviction rendered at the most five years ago or in which an exclusion period set out directly in the conviction continues to be applicable? As defined in Article 2 of Council Framework Decision 2008/841/JHA of 24 October 2008 on the fight against organised crime (OJ L 300, 11.11.2008, p. 42).</cbc:Description>
cac:TenderingCriterionPropertyGroup
<cbc:ID schemeID="criterion" schemeAgencyID="EU-COM-GROW" schemeVersionID="3.0.0">7c637c0c-7703-4389-ba52-02997a055bd7</cbc:ID>
<cbc:PropertyGroupTypeCode listID="PropertyGroupType" listAgencyID="EU-COM-GROW" listVersionID="3.0.0">ON*</cbc:PropertyGroupTypeCode>
cac:TenderingCriterionProperty
<cbc:ID schemeID="criterion" schemeAgencyID="EU-COM-GROW" schemeVersionID="3.0.0">c31b6447-bf88-4172-901a-f9b105205391</cbc:ID>
cbc:DescriptionYour answer</cbc:Description>
<cbc:TypeCode listID="CriterionElementType" listAgencyID="EU-COM-GROW" listVersionID="3.0.0">QUESTION</cbc:TypeCode>
<cbc:ValueDataTypeCode listID="ResponseDataType" listAgencyID="EU-COM-GROW" listVersionID="3.0.0">INDICATOR</cbc:ValueDataTypeCode>
</cac:TenderingCriterionProperty>
cac:SubsidiaryTenderingCriterionPropertyGroup
<cbc:ID schemeID="criterion" schemeAgencyID="EU-COM-GROW" schemeVersionID="3.0.0">f5276600-a2b6-4ff6-a90e-b31fe19dae41</cbc:ID>
<cbc:PropertyGroupTypeCode listID="PropertyGroupType" listAgencyID="EU-COM-GROW" listVersionID="3.0.0">ONTRUE</cbc:PropertyGroupTypeCode>
cac:TenderingCriterionProperty
<cbc:ID schemeID="criterion" schemeAgencyID="EU-COM-GROW" schemeVersionID="3.0.0">a1534624-95cf-4519-bdaa-856d5acf59b6</cbc:ID>
cbc:DescriptionDate of conviction</cbc:Description>
<cbc:TypeCode listID="CriterionElementType" listAgencyID="EU-COM-GROW" listVersionID="3.0.0">QUESTION</cbc:TypeCode>
<cbc:ValueDataTypeCode listID="ResponseDataType" listAgencyID="EU-COM-GROW" listVersionID="3.0.0">DATE</cbc:ValueDataTypeCode>
</cac:TenderingCriterionProperty>
cac:TenderingCriterionProperty
<cbc:ID schemeID="criterion" schemeAgencyID="EU-COM-GROW" schemeVersionID="3.0.0">f36ee1fb-210b-4786-b351-e0194ba2df89</cbc:ID>
cbc:DescriptionReason</cbc:Description>
<cbc:TypeCode listID="CriterionElementType" listAgencyID="EU-COM-GROW" listVersionID="3.0.0">QUESTION</cbc:TypeCode>
<cbc:ValueDataTypeCode listID="ResponseDataType" listAgencyID="EU-COM-GROW" listVersionID="3.0.0">DESCRIPTION</cbc:ValueDataTypeCode>
</cac:TenderingCriterionProperty>
cac:TenderingCriterionProperty
<cbc:ID schemeID="criterion" schemeAgencyID="EU-COM-GROW" schemeVersionID="3.0.0">05bd1155-a780-4eef-9526-09d90b1b5359</cbc:ID>
cbc:DescriptionWho has been convicted</cbc:Description>
<cbc:TypeCode listID="CriterionElementType" listAgencyID="EU-COM-GROW" listVersionID="3.0.0">QUESTION</cbc:TypeCode>
<cbc:ValueDataTypeCode listID="ResponseDataType" listAgencyID="EU-COM-GROW" listVersionID="3.0.0">DESCRIPTION</cbc:ValueDataTypeCode>
</cac:TenderingCriterionProperty>
cac:TenderingCriterionProperty
<cbc:ID schemeID="criterion" schemeAgencyID="EU-COM-GROW" schemeVersionID="3.0.0">5969410e-0884-41c6-ae13-e7f4666b2e81</cbc:ID>
cbc:DescriptionLength of the period of exclusion</cbc:Description>
<cbc:TypeCode listID="CriterionElementType" listAgencyID="EU-COM-GROW" listVersionID="3.0.0">QUESTION</cbc:TypeCode>
<cbc:ValueDataTypeCode listID="ResponseDataType" listAgencyID="EU-COM-GROW" listVersionID="3.0.0">PERIOD</cbc:ValueDataTypeCode>
</cac:TenderingCriterionProperty>
</cac:SubsidiaryTenderingCriterionPropertyGroup>
</cac:TenderingCriterionPropertyGroup>

[psotofer]

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

<cac:SubsidiaryTenderingCriterionPropertyGroup >
<cbc:ID schemeID="criterion" schemeAgencyID="EU-COM-GROW" schemeVersionID="3.0.0">f5276600-a2b6-4ff6-a90e-b31fe19dae41</cbc:ID>
<cbc:PropertyGroupTypeCode listID="PropertyGroupType" listAgencyID="EU-COM-GROW" listVersionID="3.0.0">ONTRUE</cbc:PropertyGroupTypeCode>
<cac:TenderingCriterionProperty >
<cbc:ID schemeID="criterion" schemeAgencyID="EU-COM-GROW" schemeVersionID="3.0.0"> UUID-1</cbc:ID>
<cbc:Description>Date of conviction</cbc:Description>
<cbc:TypeCode listID="CriterionElementType" listAgencyID="EU-COM-GROW" listVersionID="3.0.0">QUESTION</cbc:TypeCode>
<cbc:ValueDataTypeCode listID="ResponseDataType" listAgencyID="EU-COM-GROW" listVersionID="3.0.0">DATE</cbc:ValueDataTypeCode>
</cac:TenderingCriterionProperty>
...
</cac:SubsidiaryTenderingCriterionPropertyGroup>

<cac:SubsidiaryTenderingCriterionPropertyGroup >
<cbc:ID schemeID="criterion" schemeAgencyID="EU-COM-GROW" schemeVersionID="3.0.0">f5276600-a2b6-4ff6-a90e-b31fe19dae41</cbc:ID>
<cbc:PropertyGroupTypeCode listID="PropertyGroupType" listAgencyID="EU-COM-GROW" listVersionID="3.0.0">ONTRUE</cbc:PropertyGroupTypeCode>
<cac:TenderingCriterionProperty >
<cbc:ID schemeID="criterion" schemeAgencyID="EU-COM-GROW" schemeVersionID="3.0.0">
UUID-2</cbc:ID>
<cbc:Description>Date of conviction</cbc:Description>
<cbc:TypeCode listID="CriterionElementType" listAgencyID="EU-COM-GROW" listVersionID="3.0.0">QUESTION</cbc:TypeCode>
<cbc:ValueDataTypeCode listID="ResponseDataType" listAgencyID="EU-COM-GROW" listVersionID="3.0.0">DATE</cbc:ValueDataTypeCode>
</cac:TenderingCriterionProperty>
...
</cac:SubsidiaryTenderingCriterionPropertyGroup>

the RESPONSE to each QUESTION must be answered with the referred UUID like follows:

<cac:TenderingCriterionResponse>
<cbc:ID schemeID="ISO/IEC 9834-8:2008 - 4UUID" ...>...</cbc:ID>
<cbc:ValidatedCriterionPropertyID schemeID="Criterion" schemeAgencyID="EU-COM-GROW" schemeVersionID="3.0.0"> UUID-1</cbc:ValidatedCriterionPropertyID>
<cac:ResponseValue>
<cbc:ID schemeID="ISO/IEC 9834-8:2008 - 4UUID"...>...</cbc:ID>
<cbc:ResponseDate>XXXX-XX-XX</cbc:ResponseDate>
</cac:ResponseValue>
</cac:TenderingCriterionResponse>

cac:TenderingCriterionResponse
<cbc:ID schemeID="ISO/IEC 9834-8:2008 - 4UUID" ...>...</cbc:ID>
<cbc:ValidatedCriterionPropertyID schemeID="Criterion" schemeAgencyID="EU-COM-GROW" schemeVersionID="3.0.0"> UUID-2</cbc:ValidatedCriterionPropertyID>
<cac:ResponseValue>
<cbc:ID schemeID="ISO/IEC 9834-8:2008 - 4UUID"...>...</cbc:ID>
<cbc:ResponseDate>XXXX-XX-XX</cbc:ResponseDate>
</cac:ResponseValue>
<</cac:TenderingCriterionResponse>>

Please, let us know if you require further detail.

[mkrynski]

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?

[psotofer]

Greetings,
If UUIDs are unchanged in the RESQUEST document they can be reused.
However, the same UUIDs provided in the REQUEST must be referred in the answer provided (if any) in the RESPONSE document.

Please advise if this answer your doubt.

[acolomer]

This issue is closed as a duplicate of issue 311 (#311), since both of them are related to the use of UUIDs.

[psotofer]

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.
Best regards.

[psotofer]

Greetings,
As we discussed in the last OUC meeting, this is a first proposal to define a reusable identifier to replace all the dynamic UUIDs present in the current version of the ESPD-EDM.

We propose to use a new identifier following a hyphen separated format, similar to the UUID currently in use.
Format:
CCCCCCCC-XXXX-SSSS-EEEEEEEE-RRRRRRRR
[8] [4] [4] [56] [56]

• CCCCCCCC (REQUEST): Criterion coded with CRC32 hash function. For instance, crime-org would be coded as 4908c6dc;
• XXXX (REQUEST): Fixed unique code. This value will be defined in the ESPD criteria to ensure identifiers are collision-safe;
• SSSS (REQUEST): Sequence value needed to address multiple cardinality. This value is local to the group with multiple cardinality;
• EEEEEEEE (RESPONSE): EO identifier + Country coded with SHA224 hash function;
• RRRRRRRR (RESPONSE): Response coded with SHA224 hash function;

For instance, we would find this identifier in a REQUEST element:
4908c6dc-a52d-0001

The previous example would be updated in the RESPONSE element with EO+Country and the response value like this:
4908c6dc-a52d-0001-
84113de743e6d6f4e09ed430576ee18ef5ff786524778ecf482c86b3-
cf655931d7b5dd0a2880633ab7be2f4395857f67edddd7f5ad6ede0c

Following this example, we would change from this current identification model

to this other model with the new hash values:

The identifier defined for the REQUEST is enough for uniquely identify every element while the identifier blocks added in the RESPONSE represent added information that would allow to store and reuse response values.

We are currently analysing the performance cost associated in the hash calculations and will come back to you with the results.

Any comments or ideas you would share with us regarding this proposal are more than welcome.
Thank you.

[psotofer]

Greetings,
We will be very please to hear about any suggestion or question you have regarding this topic.
Thank you.

[mkrynski]

Hi, we are reviewing your proposal. We will share our thoughts in the next comment.

[psotofer]

Greetings,

We will be very please to hear about any suggestion or question you have regarding this topic.
Please, let us know in advance so we can best answer any doubt in the incoming 7 October OUC.
Thank you.

[mkrynski]

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.

[hricolor]

Greetings,

As discussed during the Open User Community meeting on 7th October, here we include additional information regarding the Issue.

First of all, how are the UUID managed currently:

ESPD-criterion document declares UUIDs for QUESTION elements subject to multiple cardinalities as blank fields. This defines those particular Identifiers as values to be initialized dynamically at the moment the ESPDRequest is created.

Those UUIDs dynamically generated for each QUESTION are provided as a unique UUID in the REQUEST document and need to be referred afterwards in the RESPONSE in the related cac:TenderingCriterionResponse.

The following example shows that a criterion with two cac:SubsidiaryTenderingCriterionPropertyGroup> includes two dynamic UUIDs, one per cac:TenderingCriterionProperty (UUID 1 and UUID 2).

And then, the answer in the ESPD response looks like:

(Note that as stated before, these UUIDs generated in the request are generated automatically and randomly. This means that every single procurement procedure would create a new random UUID that would not allow the reuse)

In this approach, similar to our previous solution, we propose:

Use an identifier following a hyphen separated format, like the UUID currently in use.

Format:
CCCCCCCC-XXXX-SSSS-RRRRRRRR

• CCCCCCCC (REQUEST): Criterion coded with CRC32 hash function. For instance, crime-org would be coded as 4908c6dc;
• XXXX (REQUEST): Fixed unique code. This value will be defined in the ESPD criteria to ensure identifiers are collision-safe;
• SSSS (REQUEST): Sequence value needed to address multiple cardinalities. This value is local to the group with multiple cardinalities;
• RRRRRRRR (RESPONSE): Response coded with SHA224 hash function;

For instance, we would find this identifier in a REQUEST element:

0416ea49-e90a-001

The previous example would be updated in the RESPONSE element with the response value like this:

0416ea39-e90a-0001-04cr4e5c6790d60392d3468b2e4c24fd1e84b4a4a2cbcef3b17f33

In the following example for the yearly turnover in both models, the current and the proposed

• The UUID assignment following the actual dynamic generation would give the following results:

• With the new model option, the code would be as shown below

Pros and cons for the new proposal (codifying only the response values):

Pros: (1) Allows reusing information on both sides; (2) Reduces redundancy when providing the information of the economic operator and the country. (3)
All UUIDs are defined in one ESPDRequest document.

Cons: (1) Major change: No UUID standard compliant code. Completely new identifier generation process; (2) In case of full code refactoring, new conde registration will be needed in eCertis.

[hricolor]

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:

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.

It was discarded as it is deemed better to define a global solution that is not constrained with specific constants that might become obsolete.

[konstantinosraptis91]

Greetings,

We have discussed and prepared an alternative approach within the InterProc consortium.

Overview

This approach aims to preserve the benefits of fixed Question IDs (e.g. reusability of an ESPD Response artefact) and provide an alternative solution, due to some issues the CEF Action INTERPROC consortium has detected in the Publication Office (OP)'s proposed solution.

The approach presented below identifies problems in the OP solution, states the goals of the solution, presents the pre-requisites and assumprions, and details an alternative solution together with an example to show re-use.

Issues detected in the OP proposed solution

1. The first issue is that it deals with the problem at a microscopic level and not at a macroscopic as it should be more appropriate. This means that it focuses on the Question and not on the Question Group. In our approach, the focus should be on the Question Group and not on the Question, because the context is what matters and someone, who wants to reuse a Question will use it in the context of its Question Group and not independent of the context. For example, let's consider that we have the Questions 1...4 from the figure below:

According to what already said, if the owner of an ESPD Response wants to reuse some of the Questions of the crime-org Criterion, let's assume those in the orange rectangle, he/she will never reuse a particular Question only. The most logical approach is to reuse the whole context (e.g. the whole Question Group), which for the above example contains the Questions 1...4:

• → The Date of conviction
• → The Reason
• → Who has been convicted
• → The length of the period of exclusion

2. The second issue regards the implementation of the OP proposal, It is most likely that complex code will be needed, in order to implement the OP proposed solution, because of all of the different hashing steps that should be followed. So the major concern here is the complexity burden that it carries with it.
3. Our third concern refers to the validation of those newly proposed hashed question identifiers.

Goals

The goals of the approach are the following:

• To have mappable pre-defined structures of Criteria (Questions & Question Groups), and
• To re-use elements from an old ESPD Response in a new ESPD Request

Prerequisites and assumptions

The assumptions we make in our approach are the following:

• Question Group UUIDs map to a specific Question Group with a specific structure.
• Questions and Question Groups order matters.

Criteria Taxonomy V3.0.0 (EG-Convictions)

Proposed Solution

The solution we propose for the construction of the Question fixed IDs is simple hierarchical indexing.

The Question ID format consists of three main parts.

• PART 1 → The Criterion Element Code from Taxonomy e.g. crime-org.
• PART 2 → The Question Group path separated by slashes. The cardinality of the Question Group will be provided by using the original position number of the Question Group (position of the Question group as displayed in the Taxonomy) and an index, separated by double colon. It should be noted that the reason an extra index is needed, is due to the fact that within a specific criterion there is a possibility to have multiple Question Groups with cardinality 1..n at the same level. The extra index helps to distinct Criteria's original structure, according to the Criteria Taxonomy excel sheet.
• PART 3 → The Question original position number, according to the Criteria Taxonomy excel sheet. It should be noted that there is no need for an extra index like in the PART 2, because there is not a case in the current Criteria Taxonomy structure v.3.0.0, where a Question Group contains more than one Question with cardinality 1..n. There is a case where a Question Group contains more than one Question and one of those has cardinality 0..1, but in these cases, the structure persists at XML level and therefore there is no chance to have an order mismatch issue.

Below, we present a visualization of the above description. The ID of a Question in the ESPD Request will look like:

As for the ESPD Response, the ID remains the same for the Question and the answers.

For the Questions 1...4 from the first figure, the ESPD Request XML part will look like:

and the ESPD Response XML part (the answers) will look like:

ESPD Response re-use process

Below we present how the re-use of the ESPD Response works. Let's consider that we have:

1. An old ESPD Response with specific Question Groups answered mappable with UUIDs (Assumption 1).
2. A new ESPD Request that needs to be answered, by using an old ESPD Response. A check is done whether Question Group with the same UUIDs exists on both artefacts. if the answer is yes, then it copies simple indexed response (the actual answer).

Below there is an example on how to use an answer (response) from an old ESPD Response with a new ESPD Request in order to create a new ESPD Response.

, , : Question Groups with the same UUIDs, within the same Criterion

The steps in order to re-use an answer are:

1. For Criteria that are common, both in the new ESPD Request and in the old ESPD Response, map the Question Group structures, by using the Question Group UUID (marked in an orange rectangle in the image above).
2. Search for common Questions in those mapped Question Groups.
3. Select the elements (answers) that you would like to re-use.
4. Apply the answers to a new ESPD Response, that has the appropriate structure, which is based on the new ESPD Request.

[pascalinelaur]

 

Following discussions in the OUC, various proposals for addressing multiple cardinalities in the response have been discussed:  

• "Encrypted Pattern ID" proposal, see comment above of the 3rd September 2021.  
• "XML Path Like" proposal, see comment above of the 22nd November 2021. This proposal was presented during the OUC meeting of the 27th January 2022, see report and presentation .  
• “XML Path Like Variant”proposal, following the discussions in the OUC meetings of the 31st March 2022, see report and presentation . This proposal is further presented below.  
• "UUID Variant" : new proposal, after having analysed the previous proposals. This proposal is further developed below. 

 

Description of the "XML Path Like Variant" proposal 

We have further developped this variant with additional features: 

• Short Tags for Criterion Elements and Elements Numbering; 
• Additional TenderingCriterionResponse IDs; 
• Requirements IDs.  

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.  

 

Criterion Element Short Tag Name	Criterion Element	UBL Element
C	CRITERION  (Exclusion Grounds EG, Selection Criterion SC)	cac:TenderingCriterion
SBC	SUBCRITERION	cac:SubTenderingCriterion
L	LEGISLATION	cac:Legislation
CA	CAPTION	cac:TenderingCriterionProperty
Q	QUESTION	cac:TenderingCriterionProperty
RQ	REQUIREMENT	cac:TenderingCriterionProperty
QG	QUESTION_GROUP	cac:TenderingCriterionPropertyGroup
QSG	QUESTION_SUBGROUP	cac:SubsidiaryTenderingCriterionPropertyGroup
RG	REQUIREMENT_GROUP	cac:TenderingCriterionPropertyGroup
RSG	REQUIREMENT_SUBGROUP	cac:SubsidiaryTenderingCriterionPropertyGroup
R	RESPONSE (OCCURRENCE)	cac:TenderingCriterionResponse
RV	RESPONSE VALUE	cac:ResponseValue
RES	(RESPONSE) EVIDENCE SUPPLIED	cac:EvidenceSupplied
RAP	(RESPONSE) APPLICABLE PERIOD	cac:ApplicablePeriod

 

The sample below shows the tagging and numbering of the criterion C1 EG crime-org. 

 

 

• XML Path Like for Question ID provided by the Buyer 

• C1_EG_crime-org/QG1/QSG1/Q1  
• C1_EG_crime-org/QG1/QSG1/Q2  
• C32_SC_spec-year-to/RG1/QSG2/Q2  

• XML Path Like for Economic Operator responses  

• C1_EG_crime-org/QG1/QSG1/Q1/R1  
• C1_EG_crime-org/QG1/QSG1/Q1/R2  
• C32_SC_spec-year-to/RG1/QSG2/Q2/R2/RV  

 

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".  

• Occurrence representation with UUID: Pattern: UUIDx/Rn 
• The letter "R" is used as a tag to indicate a response occurrence 
• The letter R is followed by the number related to the response occurrence. 

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). 

• b65e5cf9-a2cd-43f8-9e3b-c678d749827c/R1 ​ 
• b65e5cf9-a2cd-43f8-9e3b-c678d7498222/R2  ​ 

 

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.