eForms SDK 0.4.2

SDK 0.4.2 Release Notes

Because of specific requirements of our internal projects, we needed to create a version of the SDK with all the additions and improvements that are included in version 0.5.0, but without the breaking changes in the structure of the fields.json file. So we are publishing this version as 0.4.2.

Please note that we will not maintain version 0.4.2 any further, and we encourage you to use version 0.5.0 (or later) of the SDK.

Version 0.4.2 includes the following changes:

• The SDK now includes codelists that are used to restrict the possible values of some fields in eForms notices. This includes also tailored codelists, which represent a subset of items from another codelist.
• The SDK now includes structured information on the various specific types of notices (or subtypes) that are defined in the eForms regulation.
• Information on the physical structure of XML notices is now available in the fields.json file, along with the location of each field in that structure.
• New schematron rules have been added for information that is allowed or mandatory only under certain conditions.
• Various schematron rules have been corrected.
• New notice examples were added, and the validation reports were regenerated.
• The identifier of a field has been corrected to OPT-050-Lot, to fix the capitalisation.
• Translations for several items in codelists have been updated.

eForms SDK 0.5.0

SDK 0.5.0 Release Notes

Below is a list of the major updates made to the SDK in this release.

The documentation for the SDK is available at https://docs.ted.europa.eu. The source for this documentation is maintained in the eforms-docs repository.

Codelists

The SDK now includes codelists that are used to restrict the possible values of some fields in eForms notices.

This includes also tailored codelists, which represent a subset of items from another codelist. For example the codes for EU official languages are in a tailored codelist that is based on the "language" codelist. More codelists will be added in future releases.

You can find more information about codelists in the corresponding section of the documentation.

eForms schemas

Minor issues were corrected in the eForms extensions defined in the schemas:

• The type of efbc:TenderSubcontractingRequirementsDescriptionType is changed to udt:TextType.
• The unused element efac:EvaluationCriterion is removed.
• The efac namespace is added in the references to 2 elements, for consistency. This has no impact on XML instances.

Schematron rules

New rules

New rules have been added for information that is allowed or mandatory only under certain conditions.

UBL documents must not contain any element devoid of content or containing null values. This is now enforced with a specific rule.

Codelist rules

The rules that check that a value is part of a codelist now make use of the content of tailored codelists when appropriate.

Corrections

The pattern matching rules that have identical contexts are now grouped in the same rule element.

The field for "Awarding CPB Buyer Indicator" was incorrectly forbidden for T01 and T02 notices, it is now allowed for those notices.

The field for BT-706 "Winner Owner Nationality" was incorrectly indicated as mandatory.

Example Notices

The XML notices in the "examples" folder have been updated to take into account the updated schematron rules.

New examples were added:

• Contract award notice with several lots and "unpublished" (withheld) information.
• Change notice that voids/cancels the procurement procedure
• Contract notice with a large number of lots
• Prior information notice with publication information

The validation reports have been regenerated, incorporating all the changes listed above.

Fields

The representation of constraints in fields.json has been reworked. This new structure is more consistent for the various types of constraints. It is also more flexible, so that new types of constraints can be added without breaking backwards compatibility.

Information on the physical structure of XML notices is now available in the fields.json file, along with the location of each field in that structure.

The identifier of a field has been corrected to OPT-050-Lot, to fix the capitalisation.

You can find more information about the field metadata in the corresponding section of the documentation.

Notice types

The SDK now includes structured information on the various specific types of notices (or subtypes) that are defined in the eForms regulation.

This defines the content and structure of the forms notice authors can fill in, in a way that is not directly coupled to the structure of XML notices.

You can find more information about this in the corresponding section of the documentation.

Translations

Translations for several items in codelists have been updated.

You can find more information about this in the corresponding section of the documentation.

eForms SDK 0.4.1

SDK 0.4.1 Release Notes

The following issues were corrected in version 0.4.1:

• The translation files field_*.xml included by mistake labels for business terms. They have now been corrected and contain a label for each field.
• Incorrect references to some notice subtypes have been removed from fields.json.
• The XPaths for fields BT-01(c)-Procedure and BT-01(d)-Procedure have been corrected, removing the 'or' clause in the predicate.

eForms SDK 0.4.0

SDK 0.4.0 Release Notes

Below is a list of the major updates made to the SDK in this release.

The documentation for the SDK is available at https://docs.ted.europa.eu.

The source for this documentation is now maintained in a separate repository: eforms-doc.

eForms schema

• Add new elements for the identifiers of contracts and tenders used by the buyer (efac:ContractReference and efac:TenderReference).
• Add missing efac:FieldsPrivacy​ under efac:ReceivedSubmissionsStatistics, to allow indicating that this information is not public.
• Allow multiple occurrences of the contract title, so that it can be indicated in more than one language.

Schematron rules

The schematron rules have been updated to reflect the schema changes listed above, along with numerous improvements and corrections.

Addition of conditional rules

New rules have been added for information that must be present under certain conditions. These rules corresponding to the indication "CM" in the extended annex to the eForms Regulation.

In an upcoming version we will also add rules for information that must not be present under certain conditions.

Addition of warnings

For information that must be present if it exists, we have added rules that will indicate a warning (with role="WARN") if the information is not present. These rules corresponding to the indication "EM" in the extended annex to the eForms Regulation.

New rules enforcing consistency between values

New rules have been added to check the consistency of the values indicated for:

• dates for various steps in the procurement process
• contract duration
• number of lots allowed and awarded
• highest and lowest tender value

New rules on languages used

For textual information that can be indicated in multiple languages, new rules check the consistency of the languages used with the notice official languages (BT-702).

Length restrictions on numerical values

Rules that limit the number of characters for numerical values have been removed. They will be re-added in the future in the form of minimum and maximum allowed values.

Corrections

Several rules requiring the presence of specific parties (mediator, eSender, etc.) have been corrected.

Example Notices

The XML notices in the "examples" folder have been updated to incorporate the schema changes listed above, and the updated schematron rules.

A new notice example was added for a Contract Award Notice with multiple buyers.

The validation reports have been regenerated, incorporating all the changes listed above.

Fields

The SDK now includes information on the fields that compose an eForms notice, in a structured format (JSON).

You can find more information about this in the corresponding section of the documentation.

Translations

The SDK now includes the translations of various labels and short texts used in eForms notices.

You can find more information about this in the corresponding section of the documentation.

eForms SDK 0.3.1

SDK 0.3.1 Release Notes

An older version of the schematron rules was included by mistake in version 0.3.0.

Version 0.3.1 includes the latest version of the schematron rules.

eForms SDK 0.3.0

SDK 0.3.0 Release Notes

Below is a list of the major updates made to the SDK in this release.

The documentation is available as separate Asciidoc files, one per section.
The eForms SDK Documentation website is generated from this source using Antora.

Please note: in this release, the website is a single HTML page containing all the documentation.
In the next release, the website will have separate HTML pages for each major section of the documentation.

Changes to the eForms schema

Elements used to describe changes in a Change Notice and a Contract Modification Notice

The elements in a Change Notice and a Contract Modification Notice were remodelled to better reflect the usage of Change Notices.

• Element efac:Change was renamed to efac:Changes, and its cardinality restricted to "0 or 1".
• Element efac:ChangedElement was renamed to efac:Change.
• The cardinality of element efbc:ChangedSectionIdentifier was expanded to "0 to many".
• The elements efbc:ProcurementDocumentChangeIndicator and efbc:ProcurementDocumentChangeDate were moved to occur inside element efac:Change.
• The cardinality of element efac:ChangeReason was restricted to "0 or 1".

Removed unused elements

The elements efbc:PaidAmount and efbc:ReasonCode were removed from the schema as they were not being used.

Changes to the schematron rules

The schematron rules have been updated to reflect the schema changes listed above, along with numerous improvements and corrections.

Requiring use of time zones

All dates or times specified in Notices must now include time zones. This is to ensure consistency, understanding and fairness in the published Notices.

New rules enforcing use of code lists

Many elements are used to define indicators or codes. The content of these elements should be limited to one of a set of values in each case. Code lists, taken from or derived from those published in EU Vocabularies, define the acceptable values. New schematron rules have been added to restrict the content of many elements to the values in the relevant code lists. Please note this work is incomplete; more such rules will be implemented in future releases of this SDK.

New pattern-matching rules

New schematron rules have been implemented which check that the content of some elements match specific patterns. These elements and patterns are listed in section "9. Identifiers and References" in the schema documentation.

• Elements within the Notice Information section at the beginning of a Notice, identifying the UBL and Customization versions, the Notice Identifier, and the publication identifiers.
• Elements identifying sections within a Notice, and elements which link to those sections.
• Elements referencing previous Notices must use either the Publication Identifier or a combination of the Notice Identifier plus the Notice Version of the Notice being referred to.

New length restrictions

New schematron rules have been added which restrict the maximum length of the content of most elements. The limits chosen have been generous, and should not hinder notice creators from including sufficient details.

Example Notices

The XML notices in the "examples" folder have been updated to incorporate the schema changes listed above, and the updated schematron rules.

Codes used for Exclusion Grounds

The code list for Exclusion Grounds used in ESPD has been adopted into eForms. The notice examples have been updated to use these codes.

New Notice examples were added for:

• PIN, Contract Notice and Contract Award Notice under Directive 2009/81/EC

Validation Reports

The existing validation reports have been regenerated, incorporating all the changes listed above.

New validation reports have been generated for the new example notices listed above.

eForms SDK 0.2.1

SDK 0.2.1 Release Notes

This release is a minor release affecting only the documentation.

The documentation has been converted from a single Microsoft Word document to separate Asciidoc files, one per section.
The eForms SDK Documentation website is generated from this source using Antora.

Please note: in this release, the website is a single HTML page containing all the documentation.
In the next release, the website will have separate HTML pages for each major section of the documentation.

Reasons for the change in format

Developing and maintaining the SDK documentation in Asciidoc has several advantages:

Non-proprietary format and software

In line with the Open Source Software Strategy of the European Commission

• Asciidoc is a free, open-source documentation format
• Antora is software available under the Mozilla Public License
• HTML is an open standard

Easy viewing of changes

The source format Asciidoc is a text-based format, which allows users to utilise the
version-control aspects of GitHub to easily view changes between different releases of the documentation.

Installation on local servers

The HTML documentation website can easily be hosted on local servers or offline computers.

eForms SDK 0.2.0

SDK 0.2.0 Release Notes

Below is a list of the major updates made to the SDK in this release. Further details about these updates can be found in the documentation contained in this release.

Changes to the eForms schema

Notice and procedure identifiers as UUID

Notice and procedure identifiers are used to associate different notices for a single procedure together. There will be a single unique procedure identifier common to all notices related to a procedure. Notice identifiers are used to relate a change notice or a modification notice with the exact notice that is being changed or modified. Both these identifiers need to be globally unique. We have decided to use UUID version 4 for notice and procedure identifiers.

Notice subtype

The "Notice Subtype" concept has been introduced to provide an identification of the exact type of a notice, in order to precisely determine the information requirements of the notice and the rules which need to be applied. The values to be used are those in the second row of the table in Annex II of Regulation (EU) 2019/1780 ("1" to "40"; "E1" to "E5", etc.)

More details can be found in chapter 2.3 of the documentation.

Organizations centralized

In order to avoid repetition of information within a notice, the common data for organizations, such as address and contact details, has been centralized. Only the functional details specific to particular contexts are needed in those contexts; unique identifiers for each organization link to the structures holding the common information. As organizations may have multiple offices handling different functions within a procedure, the concept of a Touchpoint has been introduced. The contact details for each additional office or function is held in a TouchPoint element, which has a unique identifier to be used in each relevant context.

To enable reporting of the mandatory nationality (and optionally other information) of the beneficiary owner of a winning organization, a new structure "UltimateBeneficialOwner" has been introduced.

More details can be found in chapter 4.6 of the documentation.

New structure for result notices

There is a complex web of information which can be recorded in a Result notice, involving numerous lots, tenderers and contracts. Multiple tenderers may bid for a single Lot, of which there can be multiple winners. A single tenderer may bid for multiple Lots, and may be included in multiple contracts. In order to avoid duplication while recording the necessary information, a new structure for Result notices has been defined. This structure provides discrete blocks of elements for tenders, tenderers, contracts, and results for Lots. Each of these blocks is defined using a new extension element defined in the eForms schema.

More details can be found in chapter 4.5 of the documentation.

Elements renamed

Following a review of the naming of elements in the previous version of the eForms schema, two elements have been renamed to more accurately reflect their purpose.

The element efac:AwardCriterionStatistics has been renamed to efac:AwardCriterionParameter to reflect that each instance of the element contains information on a single parameter, rather than statistical information. It contains the elements efbc:ParameterCode and efbc:ParameterNumeric.

The element efbc:StatisticalNumeric has been renamed to efbc:StatisticsNumeric, to align with the names of the various parent elements, and with the name of the sibling element efbc:StatisticsCode.

New elements

A new repeatable element efac:TenderSubcontractingRequirements, and a non-repeatable child element efbc:TenderSubcontractingRequirementsCode have been created to hold BT-651, the subcontracting information a tenderer must specify in its tender. A textual description for each requirement can be included using cbc:TenderSubcontractingRequirementsDescription, which is repeatable only for different languages.

UBL version used

The version of UBL used has been updated to version 2.3 OASIS Committee Specification 1 (2.3 CS01) to reflect the fact that UBL version 2.3 has now been adopted by OASIS as a Committee Specification. This change of UBL version does not impact any elements within the eForms schema.

Change of elements used (BT-65, BT-755, BT-777)

• BT-651 "Subcontracting Tender Indication": changed element used from cac:TenderPreparation/cbc:Description to efac:TenderSubcontractingRequirements/efbc:TenderSubcontractingRequirementsCode
• BT-755 "Accessibility Justification": changed from cbc:Description to cac:ProcurementAdditionalType/cbc:ProcurementType
• BT-777 "Strategic Procurement Description": changed from cbc:Description to cac:ProcurementAdditionalType/cbc:ProcurementType

Removed unused UBL schema files

Several UBL schema files in the /common folder related to digital signatures were included in the last release of the eForms SDK. These files are not used in eForms, so they have been removed from this release.

Renamed schema for "Society Registration Information Notice"

The schema for "Society Registration Information Notice" is replaced with "Business Registration Information Notice". This change is to maintain alignment with developments in UBL, and does not affect the standard eForms Notices.

Other changes

Updated schematron rules

The schematron rules have been updated to reflect the schema changes listed above, along with numerous improvements and corrections.

In stage-3.sch, rules checking that a value is part of a code list have been temporarily removed. We are currently working on them and they will be added back in the next release.

In stage-4.sch, some rules related to result notices have been temporarily removed. We are working on them, and they will be added back in a future release.

Example Notices

The XML notices in the "examples" folder have been updated to incorporate the schema changes listed above, and the updated schematron rules.

Two new example notices for the Regulation 1370/2007 on public passenger transport services have been added:

• t01_PRT.xml - "Prior information notice for public service contract"
• t02_ESP.xml - "Information notice for award of public service contract"

Validation reports for all examples have been updated using the new schematron rules.

eForms SDK 0.1.1

This release fixes some incorrect version indicators in the schema, documentation and the example files provided.

eForms SDK 0.1.0

The eForms SDK bundles several components of eForms including the eForms schema, documentation, sample files and validation rules in Schematron format. This is the first release of the eForms SDK.