Annex I: XML Validation

Introduction to ISO Schematron

Schematron is a rule-based validation language to specify validation processes against XML documents. ISO Schematron is an ISO (ISO/IEC 19757-3:2006) and open standard. Please visit the ISO Schematron web-site for the technical specification and details.

ESPD Business Rules

The ESPD-EDM uses Schematron to validate business rules identified in ESPD_TestCases_v10.docx and ESPD_TestCases_mapping_v10.docx documents. The input for these business rules is the e-Sens ESPDint Business Document.

These business rules can be typified as:

  1. Semantic validations: e.g. The "cac:TenderingCriterionResponse" matches one of the "cac:TenderingCriterionProperty" elements in the XML.

  2. Assertions about the presence or absence of patterns in XML documents: e.g. All Business Rules that applies to identifier nodes: mandatory attributes, structure of the identifier, etc.

  3. Code lists validations: e.g. values for each code list element.

  4. Other validations that an XSD cannot do: e.g. Validates that one of the nodes has at least 1 child.

The following image shows different examples of validations:

Non-code list business rules

The validation of code lists is explained in sections below.

Code list validation Architecture

Business rules related to code list validates:

Code list business rules

Architecture for Code List validation

The validation of the code lists needs an extra step on the process before executing the Schematron process. This is because it needs Genericode (GC) as input files.

  1. The first step is the generation of Genericode (GC) files. These files contains information about the values and identifiers of each code list.

    1. GC files are found in the Validation folder.

  2. Design and implementation of the CVA files. CVA stands for Context and Value Association:

  3. Execution of the implemented validations in the CVA files:

    1. Transformation of CVA files into SCH files.

    2. Continue with the Schematron execution process: (1) transformation of SCH files into XSLT and execution of the validations using the XSLT files to get the final report.

Architecture for code list validation

What does SCH files contain?

  1. Association between one or more elements of the XML and one or more code list (specified in the Genericodes).

  2. The declaration of which attributes of the XML identify information of the Genericode.

The implementation of the CVA file has the following structure:

CVA example

Execution

As a basis of the implementation, it has been taken into account:

  1. Schematron implementation of CVA files for validation from CRANE SOFTWRIGHTS LTD

Execution files

This example describes the execution of the validation process using the Saxon library to execute XSLT files and the XSLT provided as a basis:

Execution of the validation process in code lists

I.3 Execution

As a basis of the implementation, it has been taken into account:

  1. Schematron implementation of CVA files for validation from CRANE SOFTWRIGHTS LTD.

Execution files

The following image shows the libraries, XSL files and the process to be able to execute the validation:

Execution of the validation process

ESPD Validation Architecture

The validation of a ESPD XML has the following life-cycle:

ESPD Schematorn lyfe-cycle

  1. The validation of the XML starts by ensuring that the input XML follows the structure defined by the XSD: QualificationApplicationRequest.xsd XSD Schema or QualificationApplicationResponse.xsd XSD Schema. These schemas can be found under the folder dist/xsdrt/maindoc (or the equivalent documented xsd folder).

    1. If the validation of the structure is not successful, the process stops and sends the report with the list of errors.

    2. If the validation of the structure is successful, the process continues with the code list validations and business rules. All errors found (if any) are listed in the report.

  2. Depending on the type of application (ESPD Request or ESPD Response), and independently of the qualification application type code (either regulated or self-contained), different types of validations are executed:

ESPD architecture

ESDP Request (Regulated or Self-contained)

  1. XSD Validation against UBL-QualificationApplicationRequest-2.2-Pre-award.xsd

  2. Code list validations. These are common for both, Request and Response:

    1. Validation of the code list values: 01 ESPD-codelist-values.cva

    2. Validation of the identification of the code list: 01 ESPD Common CL Attributes.sch

  3. Business rules related to the cardinality of the schema, that cannot be controlled using the XSD: 02 ESPD Req Cardinality BR.sch

  4. Business rules used to validate the criteria taxonomy:

    1. Validations common for Request and Response: 03 ESPD Common Criterion BR.sch

    2. Validations specific for Request applications: 03 ESPD Req Criterion BR.sch

  5. Other business rules:

    1. Other validations which are common to Request and Response applications, such as the mandatory use of the attribute schemeAgencyID for identifiers: 04 ESPD Common Other BR.sch

    2. Specific business rules for Request applications, in this case, the validation of the correct value for cbc:CutomisationID element: 04 ESPD Req Other BR.sch

    3. Business rules related to the procurer: 05 ESPD Req Procurer BR.sch

    4. Specific business rules for Self-contained application type: 05 ESPD Req Self-contained BR.sch

ESDP Response

  1. XSD Validation against UBL-QualificationApplicationResponse-2.2-Pre-award.xsd

  2. Code list validations. These are common for both, Request and Response:

    1. Validation of the code list values: 01 ESPD-codelist-values.cva

    2. Validation of the identification of the code list: 01 ESPD Common CL Attributes.sch

  3. Business rules related to the cardinality of the schema, that cannot be controlled using the XSD: 02 ESPD Resp Cardinality BR.sch.sch

  4. Business rules used to validate the criteria taxonomy:

    1. Validations common for Request and Response: 03 ESPD Common Criterion BR.sch

    2. Validations specific for Response applications: 03 ESPD Resp Criterion BR.sch

  5. Other business rules:

    1. Other validations which are common to Request and Response applications, such as the mandatory use of the attribute schemeAgencyID for identifiers: 04 ESPD Common Other BR.sch

    2. Specific business rules for Response applications, in this case, the validation of the correct value for cbc:CutomisationID element: 04 ESPD Resp Other BR.sch

    3. Business rules related to the economic operator: 05 ESPD Resp EO BR.sch

    4. Specific business rules for Self-contained application type: 05 ESPD Resp Self-contained BR.sch

    5. Specific business rules for economic operators registered in a pre-qualification system: 05 ESPD Resp Qualification BR.sch

    6. Specific business rules depending on the role: 05 ESPD Resp Role BR.sch

UUID Criterion Validation

Each Criterion is defined in e-Certis and must use the Universally Unique Identifier (UUID) supplied by e-Certis:

  1. These UUIDs are 'constant', meaning that they are maintained by DG GROW and need to be used compulsory as they were issued by DG GROW.

  2. The value of each UUID are defined in the spreadsheets:

    1. Criteria Taxonomy (Regulated ESPD)

    2. Criteria Taxonomy (Self-contained ESPD)

ESPD validates that the UUID defined in the ESPDRequest XML or ESPDResponse XML are the ones supplied by e-Certis:

Spreadsheet row

XSD Path

{CRITERION

cac:TenderingCriterion/cbc:ID

{QUESTION_GROUP

cac:TenderingCriterion/cac:TenderingCriterionPropertyGroup/cbc:ID

{QUESTION_SUBGROUP

cac:SubsidiaryTenderingCriterionPropertyGroup/cbc:ID

Every QUESTION_GROUP and QUESTION_SUBGROUP that has the same structure (meaning, QUESTION or QUESTION_SUBGROUP), share the same UUID, as they are the same.

Tendering Criterion

The validation of each criterion (cac:TenderingCriterion element) has the aim to check:

  1. cbc:ID, cbc:CriterionTypeCode, cbc:Name and cbc:Description are mandatory;

  2. cbc:ID and cbc:CriterionTypeCode values match with the ones supplied by e-Certis;

  3. cac:TenderingCriterionPropertyGroup structure matches with the QUESTION_GROUP supplied by e-Certis (see Tendering Criterion Property Group and Subgroup section).

Tendering Criterion Property Group and Subgroup

The same validations are executed for the first level group of properties and sub-groups of properties. The rules applied are:

  1. The cbc:ID and cbc:PropertyGroupTypeCode are mandatory elements and their values are the ones supplied by e-Certis in the corresponding cbc:TenderingCriterion;

  2. cac:TenderingCriterionProperty structure matches with QUESTION supplied by e-Certis (see Tendering Crtierion Property section);

  3. cac:SubsidiaryTenderingCriterionPropertyGroup matches with QUESTION_SUBGROUP supplied by e-Certis (for each property group, the same validations are applied).

Tendering Criterion Property

The validation of Tendering Criterion Property (cac:TenderingCriterionProperty element) is checked as follows:

  1. cbc:TypeCode and cbc:ValueDataTypeCode are mandatory elements and match with the ones supplied by e-Certis;

  2. cbc:ID and cbc:Description elements are mandatory, although their values are not validated;

  3. If cbc:TypeCode value is "CAPTION" or "REQUIREMENT", cbc:ValueDataTypeCode value must be "NONE".

TED Developer Docs

This website is managed by: Publications Office of the European Union

Need Help?

Follow us

Legal

About us

Other services

Discover more on europa.eu

Contact the EU

Social Media

EU institutions and bodies