II. The ESPD Exchange Data Model
Design approach
The ESPD Exchange Data Model (ESPD-EDM) was designed to implement the data requirements expressed in the Annex 2 of the COMMISSION IMPLEMENTING REGULATION (EU) 2016/7 of 5 January 2016 (from now on "the Annex to the Regulation 2016/7"), establishing the standard form for the European Single Document. Additionally to these requirements, the model took also into account the Information Requirements Model specified by the CEN/BII-Workshops.[1] (namely Workshop 3), and the latest developments relating to the Virtual Company Dossier (VCD) in e-Sens.[2].
One premise that has ruled the design and implementation life-cycle of the ESPD-EDM has been ''not to reinvent the wheel''. Thus some very early key decisions were: (1) select a mature business language for the naming, design and implementation of the ESPD-EDM; (2) reuse as much as possible existing information components and libraries ''as-they-are''; (3) for those entities that are not defined in any standard specification, design new components in such a way that they can be reused in other situations and domains, both in e-Procurement and beyond e-Procurement.
OASIS UBL-2.1 standard was chosen as the best candidate to base the ESPD-EDM upon. The main reasons for this decisions were: (1) The European Commission is already using (and recommending) UBL-2.1 for e-Documents.[3] ; (2) Most of the concepts and components necessary for the ESPD documents were already defined by UBL specifically for e-Procurement; (3) Methodology and tools are available for the development of new documents, the extension of the existing UBL libraries, the semantic validation of XML instances, etc.
Data architecture overview
The ESPD Exchange Data Model re-uses three other models, that were defined in parallel to the ESPD, the Core Criterion Data Model, the Core Evidence Data Model, and the OASIS UBL-2.1 common information components.
This approach ended up in the development of a ''data architecture''; i.e. different layers of data components. The figure below presents a high-level view of this data architecture for the entire ESPD-EDM. The blocks coloured in green represent libraries of components defined by the UBL-2.1 Technical Committee (TC), whilst the rest have been defined from scratch by COM’s ESPD development team.
The blocks represented in the figure above represents either a document (e.g. ESPDRequest and ESPDResponse) or a library (the rest of the blocks). Per each document or library one XSD Schema has been implemented. Each Schema has been assigned its own namespace and a specific prefix representing the namespace.
The table below lists the file names corresponding to each block, schema, namespace and namespace-prefix.
| Data Package | XSD file names | Namespace | Prefix |
|---|---|---|---|
ESPDResponse |
/xsd/maindoc/ESPDResponse-1.0.xsd |
urn:grow:names:specification:ubl:schema:xsd:ESPDResponse-1 |
espd |
ESPD Aggregate Components |
/xsd/common/ESPD-CommonAggregateComponents-1.0.xsd |
urn:grow:names:specification:ubl:schema:xsd:ESPD-CommonAggregateComponents-1 |
espd-cac |
Core Criterion Vocabulary Aggregate Components |
/xsd/common/ESPD-CommonAggregateComponents-1.0.xsd |
urn:isa:names:specification:ubl:schema:xsd:CCV-CommonAggregateComponents-1 |
ccv-cac |
Core Evidence Vocabulary Aggregate Components |
/xsd/common/CEV-CommonAggregateComponents-1.0.xsd |
urn:isa:names:specification:ubl:schema:xsd:CEV-CommonAggregateComponents-1 |
cev-cac |
UBL-2.1 CAC Common Aggregate Components |
/xsd/common/UBL-CommonAggregateComponents-2.1.xsd |
urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2 |
cac: |
ESPD Common Basic Components |
/xsd/common/ESPD-CommonBasicComponents-1.0.xsd |
urn:grow:names:specification:ubl:schema:xsd:ESPD-CommonBasicComponents-1 |
espd-cbc: |
CCV-CBC Core Criterion Vocabulary Common Basic Components |
/xsd/common/CCV-CommonBasicComponents-1.0.xsd |
urn:isa:names:specification:ubl:schema:xsd:CCV-CommonBasicComponents-1 |
ccv-cbc: |
CEV-CBC Core Evidence Vocabulary Common Basic Components |
/xsd/common/CEV-CommonBasicComponents-1.0.xsd |
urn:isa:names:specification:ubl:schema:xsd:CEV-CommonBasicComponents-1 |
cev-cbc: |
UBL-2.1 Common Basic Components |
/xsd/common/UBL-CommonBasicComponents-2.1.xsd |
urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2 |
cbc: |
The example below shows how these namespaces and prefixes are specified schemas of the in the ESPDResponse XSD Schema, as well as how the different layers of schemas specified in the ESPD-EDM data architecture are imported (see line 2 in ESPDResponse-1.0.xsd):
<xsd:schema xmlns="urn:grow:names:specification:ubl:schema:xsd:ESPDResponse-1" xmlns:espd="urn:grow:names:specification:ubl:schema:xsd:ESPDResponse-1" (1)
xmlns:espd-cac="urn:grow:names:specification:ubl:schema:xsd:ESPD-CommonAggregateComponents-1" (2)
xmlns:espd-cbc="urn:grow:names:specification:ubl:schema:xsd:ESPD-CommonBasicComponents-1" (3)
xmlns:ccv="urn:isa:names:specification:ubl:schema:xsd:CCV-CommonAggregateComponents-1" (4)
xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2" (5)
xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2" (6)
xmlns:ext="urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2" (7)
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:grow:names:specification:ubl:schema:xsd:ESPDResponse-1" (8)
elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0"> (9)
<xsd:import namespace="urn:grow:names:specification:ubl:schema:xsd:ESPD-CommonAggregateComponents-1" schemaLocation="../common/ESPD-CommonAggregateComponents-1.0.xsd"/>
<xsd:import namespace="urn:grow:names:specification:ubl:schema:xsd:ESPD-CommonBasicComponents-1" schemaLocation="../common/ESPD-CommonBasicComponents-1.0.xsd"/>
<xsd:import namespace="urn:isa:names:specification:ubl:schema:xsd:CCV-CommonAggregateComponents-1" schemaLocation="../common/CCV-CommonAggregateComponents-1.0.xsd"/>
<xsd:import namespace="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2" schemaLocation="../common/UBL-CommonAggregateComponents-2.1.xsd"/>
<xsd:import namespace="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2" schemaLocation="../common/UBL-CommonBasicComponents-2.1.xsd"/>
<xsd:import namespace="urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2" schemaLocation="../common/UBL-CommonExtensionComponents-2.1.xsd"/>
<xsd:element name="ESPDResponse" type="ESPDResponseType"/>
<xsd:complexType name="ESPDResponseType">
<xsd:sequence>
<xsd:element ref="ext:UBLExtensions" minOccurs="0"/>| 1 | "espd", default prefix representing the document ESPDResponse |
| 2 | "espd-cac", prefix for the Common Aggregate Components defined by COM for the ESPD, e.g. "espd-cac:EconomicOperatorParty" |
| 3 | "espd-cbc", prefix for the Common Basic Components defined by COM for the ESPD, e.g. "espd-cbc:SMEIndicator" |
| 4 | "ccv", prefix for the Core Criterion Vocabulary elements, e.g. "ccv:Criterion" (elements belonging to the Core Evidence Vocabulary are used by |
| 5 | "cac", prefix for the Common Aggregate Components defined in UBL-2.1, e.g. "cac:ContractingParty" |
| 6 | "cbc", prefix for the Common Basic Component defined in UBL-2.1, e.g. "cbc:TypeCode" |
| 7 | "ext", default prefix defined in UBL-2.1 for non-standard extensions of the schema (see OASIS UBL-TC documentation) |
| 8 | targetNamespace matching to the default schema namespace, aligned to UBL practice |
| 9 | use of "qualified", "unqualified" and "version" defaults aligned to the best practices, as in UBL |
This other example below illustrates the header of an ESPD Response XML document instance that implements the namespaces of the above schema:
<espd:ESPDResponse
xmlns:espd="urn:grow:names:specification:ubl:schema:xsd:ESPDResponse-1"
xmlns:espd-cac="urn:grow:names:specification:ubl:schema:xsd:ESPD-CommonAggregateComponents-1">
xmlns:espd-cbc="urn:grow:names:specification:ubl:schema:xsd:ESPD-CommonBasicComponents-1"
xmlns:ccv="urn:isa:names:specification:ubl:schema:xsd:CCV-CommonAggregateComponents-1"
xmlns:ccv-cbc="urn:isa:names:specification:ubl:schema:xsd:CCV-CommonBasicComponents-1"
xmlns:cev-cbc="urn:isa:names:specification:ubl:schema:xsd:CEV-CommonBasicComponents-1"
xmlns:cev="urn:isa:names:specification:ubl:schema:xsd:CEV-CommonAggregateComponents-1" (1)
xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
xmlns:ext="urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2">
<cac:ContractingParty>
<cac:Party>
<cac:PartyName>
<cbc:Name>Executive Agency ...
<ccv:Requirement responseDataType="EVIDENCE_URL">
<cbc:ID schemeID="CriterionRelatedIDs" schemeAgencyID="EU-COM-GROW" schemeVersionID="1.0">03bb1954-13ae-47d8-8ef8-b7fe0f22d700</cbc:ID>
<cbc:Description>URL</cbc:Description>
<ccv:Response>
<cev:Evidence> (1)
<cev:EvidenceDocumentReference>
<cbc:ID>6e9aa856-836e-4c9e-a74b-b7c63cba91b8</cbc:ID>
<cac:Attachment>
<cac:ExternalReference>
<cbc:URI>http://kbopub.economie.fgov.be/kbopub/zoeknummerform.html?lang=en&nummer=0825+811+478&actionLu=Zoek</cbc:URI>
</cac:ExternalReference>
</cac:Attachment>
</cev:EvidenceDocumentReference>
</cev:Evidence>
</ccv:Response>
</ccv:Requirement>| 1 | Notice that in the XML instance namespaces that are not referred to in the XSD schema of the ESPDResponse document are needed as they instantiate elements from other inner schemata of the data architecture, e.g. "cev:Evidence" |
The Core Criterion and Core Evidence Data Models and Vocabularies
When creating a new ESPD Request XML document, the Contracting Authority (CA) [4] specifies the series of exclusion and selection ''criteria'' that the Economic Operator (EO) has to satisfy for a specific Procurement Project. In the ESPD Response, the EO MAY provide where to get evidences that prove it satisfies the criteria required by the CA.
Two new data models were defined from scratch by the European Commission (COM), the Core Criterion Data Model and the Core Evidence Data Model. Once implemented as XSD schemata these Data Models are named ''Core Criterion Vocabulary'' and ''Core Evidence Vocabulary''. Both Data Models (and therefore the vocabularies too) are interrelated. The figure below shows a (high-level) simplified overview of these two data models and how they interrelate.
The Core Criterion and Core Evidence Data Models were designed to be reused in cross-border and cross-sector interoperability. In other words, they are ''business agnostic''. Two domains where the concepts Criterion and Evidence are relevant are the e-Certis and ESPD Services. Therefore these two domains (and systems) have been originally used as Study/Business Cases for the development and testing of the Core and Evidence Data Models and Vocabularies. During the development other cases in other business domains were identified as potential re-users of the Core Vocabularies (e.g. CAMSS, Common Assessment Method for Standards and Specifications or the Grants Assessment System, both developed by COM; amongst other).
The ESPDResponse uses the complete set of elements defined in the CCV and the CEV (i.e. the ones depicted in the high-level diagram above).
From the modelling perspective the main difference between the ESPDRequest and the ESPDResponse is that the ESPDRequest does not use the Response element, and therefore neither the XML Core Evidence Vocabulary. Thus, for the ESPDRequest, the model represented above in Figure above is reduced into this other one below:
////
