Second eForms Technical Workshop

 

This meeting was a follow-up to the eForms technical workshop in May 2022. It provided an updated overview of eForms implementation (including the amendments to the eForms regulation), applications and technical resources.  

The usual eSenders seminar will take place online on 12 and 13 December. Further details will be communicated soon through the usual channels. 

These minutes include replies to the questions addressed during the webinar. The questions and answers have been reviewed and may have been regrouped or modified for this written version to allow a more cohesive and complete overview.  

Please note that some answers may no longer be accurate, as OP has followed upon comments made and may have modified its approach accordingly.  

The recordings of the live sessions are available in the agenda section along with the PowerPoint slides of each presentation.

 

Day 1  – 29 September

 

Current status of eForms implementation – Karl Ferrand – Publications Office of the European Union  

Practically all TED applications are developed and under installation. The Publications Office must test and get them all to go live by 14 November. Afterwards there will be still improvements and changes that could happen regularly. Major versions should not happen very often and should not change the structure of the applications.  

A Preview environment for the TED applications is available to eSenders. New releases are coming in Preview by the end of October and in principle, these versions will be the live versions made available in November.  

The Publications Office makes available various sources of information regarding the eForms, such as: Developer Docs, Software Development Kit (SDK) and the code used in the sample notice viewer or sample notice editor applications that can be used as an inspiration. However, the code of eNotices2 will not be made available to the users.  

The Publications Office will provide further documentation on all the available applications.  

The Office encourages eSenders to provide feedback, namely regarding the eForms implementation. A short survey will be sent to eSenders soon to find out more about their situation and plans.  

An amendment to the current eForms regulation is under preparation. It clarifies the transitional provision and includes a number of changes (new business terms). 

 

---

 

TED Developer Portal and using eForms APIs  – Karl Ferrand – Publications Office of the European Union  

The situation as regards TED APIs is as follows:  

• eNotices2: 
  - will replace eSentool and the current eNotices, 
  - is the reception system for eForms; notices can be submitted and managed through the web front-end or via the TED API, 
  - calls the Central Validation Service (CVS) to validate submitted notices before sending them to the internal processing system (TED Monitor) for processing and eventual publication. 
  - API documentation: https://enotices2.preview.ted.europa.eu/esenders/swagger-ui/, 
  - website: https://enotices2.preview.ted.europa.eu,  

• TED CVS (Central Validation Service): 
  - provides an API for validating eForms notices, 
  - is called by eNotices2 to check the validity of a submitted notice, but it can also be called by eSender applications to validate a notice at any time,
  - API documentation: https://cvs.preview.ted.europa.eu/swagger-ui/,   

• TED Viewer: 
  - also known as ‘TED Viewer 2022’, 
  - provides an API that allows applications to render an eForms notice in the HTML or PDF format,
  - API documentation: Swagger UI TBA,

• TED Developer Portal: 
  - currently allows eSenders to sign-up and obtain/manage their API key which is required for calling TED APIs,
  - website: https://developer.preview.ted.europa.eu/home.

The last day when TED XML notices will be accepted is 24 October 2023. Afterwards, OP will accept only the new eForms. 

 

---

Questions from the participants:  

Start date for eForms:  

• When will it be possible to send eForms notices which will be published in TED? 

Answer: From 14 November 2022 onwards.  

 

• Is there any eSender ready to send eForms starting this year? 

Answer: We are not aware of any eSender’s intention to start sending eForms this year.  

 

• The go-live date of November seems ambitious given that there is still a lot of work to be done. This means that some items cannot be tested fully. How likely is it in percentage terms that this will be ready for live with no functional issues? 

Answer: [post-event reply] We can confirm that there is a lot of pressure on our developers and teams so that OP goes live with eForms on 14 November and is able to receive and publish eForms notices on TED. We understand that eSenders have their own constraints and pressures but there should be enough information available to develop the bulk of their solutions. For example, until the 2022 regulation amendment, the eForms schema has barely changed for over a year. 

 

Amendments of eForms Regulation: 

• What will be discussed in the meeting of the Advisory Committee on Public Contracts (ACPC) on 10 October? What should be there decided about eForms? 

Answer: The meeting is about the amendment to the eForms regulation. If it is approved, we will apply it. 

 

• Based on your experience with the current amendment of the eForms regulation, do you believe that regular updates of the eForms regulation will take place in the future? 

Answer: There is likely to be an amendment in 2022 and another one in 2023. There are further requirements that need to be included in eForms.  

 

XML Generation: 

• Generating a valid XML file is one of the biggest challenges. Is there a reference implementation that shows how to create the eForms XML based on the fields.json?  

Answer: To create an XML file is not a straightforward process because the XSD does not have enough information to create the XML. The developer needs some additional information.  

We tried to put together all the information that is necessary. Such information is structured in a concept of hierarchy of notes and fields with relative Xpaths assigned to each one of them. Every field is then connected logically and technically to the developer's application with certain form elements.  

The role of the developer would be to go through the data that OP provided and get the relative Xpaths field by field and recreate the parent notes inside of an XML file.  

We are currently working on a Notice Editor application. You can find this sample application on GitHub: https://github.com/OP-TED/eforms-notice-editor.  

The sample application has three features: 

- Creating a form for filling-in a notice. 
A first iteration on this feature has been developed. 
The purpose of this feature is to demonstrate how a form can be created from the notice type definitions provided in the SDK. 

- Saving the data entered in the form as a notice XML file. 
This feature is currently under development. 
The purpose of this feature is to show how an XML file can be created from the data entered by the user by using the notice type definitions and XML structure and field metadata provided with the SDK. 

- Opening an existing form for editing. 
This feature will be implemented later. 

Please note that the code we provide in the Notice Editor Sample Application is only an example and is being created to demonstrate the use of different concepts found in the SDK. 

In parallel we are working to provide documentation on this topic in the TED developer documentation portal (https://docs.ted.europa.eu). 

One suggestion: Saxon has a Javascript implementation which can execute XSLT and therefore Schematron: https://www.saxonica.com/saxon-js/index.xml.  

 

• Can OP confirm that the eNotices2 implementation has already overcome the challenge of generating XML files? 

Answer: eNotice2 generates XML files.  

 

• Besides OP, has anyone tried to generate eForms XML? 

Answer (from a participant): There is full XML paths defined for every field in SDK. Everything is easy except arrays, you need to keep track on array indexes. This is tricky one. 

 

• Is there already a staging/testing environment to create eForms? Could you please share the URL address? 

Answer: Yes, there is a Preview environment. For each application, there is a URL. You can find out more about it in the following link:  https://docs.ted.europa.eu/home/eforms/preview/index.html.  

 

Visualisation of notices:  

• The notice viewer application works well locally; do you have plans to make a similar application available online so that a user can upload an XML file and get back an HTML file? 

Answer: There will be an application called TED Viewer 2022. The application will be available as an API. It should be available in Preview at the beginning of November, and for production use from 14 November 2022.  

 

• Will you provide a demo application to generate an HTML form to fill out (therefore in edit mode) starting from the SDK (JSON file)? Is there any example code (or documentation) for generating the actual XML, starting from a filled in form? 

Answer: We are working on a sample application for editing notices (see above).  

  

• Why can’t we use the same structure for visualization as it is for the XML? 

Answer: The XML has a certain structure based on UBL, plus extensions (specific to eForms), and if we represented it directly like that, it wouldn’t be easy for the end user. It is a challenge to represent everything in a form that makes sense to the user. Otherwise, in your applications, you can choose to show it differently to the user. 

 

Translations: 

• Last year, OP published eForms notice samples on SIMAP, but only in English. Will they be also available in other languages, or can I generate them myself using your tools? 

Answer: We don't plan to generate a set of example HTML/PDF files as it will be possible for eSenders to do it themselves via the TED Viewer API or eNotices2.  

Other language versions will be available, but they are not finalised yet. Our aim is to complete them at least partially by November 2022.   

 

• Do you translate the business rules in the different member state languages? 

Answer: The definition of the business rule itself is only available in English. We will translate the messages returned by CVS but this is not available yet. Our aim is that the end user gets the message in their language.  

 

• Under translations you have for example group_en.. Will you deliver also for example group_de and so on? 

Answer: Yes, the translations in all languages will be progressively done in the coming weeks. Business terms should be available in all languages for November 2022. 

 

• Is there any means to contribute to the translations? Finnish translations are nearly always not the ones that are used - but some a bit weird ‘Commission Finnish’. There are sometimes words that are not even used in the Directives. 

Answer: We will reflect on the best way to handle your feedback. 

 

Conversion of current TED XML forms into eForms: 

• What is the interest and the context of use of the TED-XML converter conversion module? 

Answer: The main use case is the following: you are already using eForms and you want to publish a Change Notice or a Contract Award Notice, but the previous notice is in the old TED-XML format.  

The converter would convert as much information as possible from your previous notice into eForms.  

If you have any legacy data and you want to copy everything into a simple repository which is in the eForms format, you can also use those conversions.  

The XSLTs are the actual conversions themselves and the API is the service that OP will provide that you can call to get the XSLT conversion. 

 

• Will I get a valid eForms notice ready to be published after the conversion? 

Answer: No, you will not get complete eForms because certain eForms requirements do not exist in the current TED-XML. Some mandatory fields may indeed need attention. 

 

• Can I import a converted XML into eNotices2? 

Answer: You can import an XML but you will have to continue to complete it as you will not obtain a valid eForms notice ready to be published. 

 

API authentication: 

• Why will there be only one EU Login account per eSender? This does not sound like an improvement compared to eSentool. 

Answer: This is a simplification. We require one login to manage the key that identifies the eSender.   

 

• Isn't EU Login always a personal account? How do we represent our organisation / system? 

Answer: EU Login is based on an e-mail address. We recommend that you create a specific EU Login that uses a functional e-mail address, and you log in with that email in order to represent your organisation/system. 

 

• EU Login asks for first name and last name. 

Answer: You can provide your organisation’s name in these two fields.  

 

• Is the API key personal? In other words, is there one API key for eSender, which all developers could use? 

Answer: Yes, once your organisation has logged in and got the API key, you can share the API key between your developers and applications. We would identify you all as coming from the same eSender then. In the Preview environment, you can have multiple API keys if necessary.  

 

• Can there be a primary and secondary API key? In production, it would be nice to have 2 API keys active simultaneously to avoid any problems due to key change being in progress. If the API keys expire, it will cause problems. 

Answer: Indeed, if the API key is not prolonged, it will expire. However, it is simple and quick to renew it. It is preferable to have only one API key per account.  

 

• If the API key is being used to make requests, do you still have to acknowledge annually via the portal that the API key is being used? Or is it necessary only if you don't make any requests to the API within a year? 

Answer: The API key is valid for 12 months whether it is used or not. It is important to log in once during those 12 months and extend it. 

 

• Will there be a notification before the API-Key expires? 

Answer: Yes, an email notification is sent before the API Key expires. 

 

• Do reusers have access to the API-key? 

Answer: There is no need for an API key for reusers of the public notices on the TED website. The API key is only needed for the new eForms applications used by eSenders.  

 

eNotices2:  

• Will the eNotices2 API replace the TED FTP Server for reusers? 

Answer: No, they are two separate things. If you are a reuser, you will continue to use the FTP server and that is for public notices that have been published. The eNotices2 API is restricted to notices that you have submitted; you cannot query other users’ notices. The eNotices2 application replaces eSentool and the current eNotices. 

 

Publication deadlines: 

• What will be the maximum amount of time for a successfully submitted notice (without the need for manual verification) to be published? 

Answer: The maximum deadline for publication will continue to be 5 days. However, you will be able to set a preferred publication date in the future but with a limit of three months.  

 

Size of notices: 

• What is the maximum size of notices? Please note that the current limit of 3 MB is not enough for notices with 500 lots. 

Answer: We need to set a maximum size for notices to limit the risk of underperformance, for example, due to an oversized submission with malicious intent. We nevertheless need some experience to adjust to a maximum size that can handle bigger notices while still being able to process them.  

 

• What if the XML is bigger than the limit, what can eSenders do? Won’t it be a good idea to use some compression? 

Answer: The current workaround is to split a notice into multiple notices.  

 

• The eForms specs has limits for the fields, for the repeatable elements and so on. If we are inside these limits, we expect that the XML should be accepted. Otherwise, you should lower the limits (number of lots, size of fields). It is not possible to go back to users and ask them to change things. To split a notice is not a solution, besides it is not documented at all. How to split an eForm and still ensure it is valid? 

Answer: There is information available about the limits of fields. The size of text fields and number of lots influence the size of the XML but the total size cannot be easily calculated before the XML is generated or produced. We will reflect on the necessary guidance on how to split notices for the exceptionally big cases. 

 

API Documentation: 

• When will the API documentation be available on https://docs.ted.europa.eu/home/index.html? 

Answer: [post-event update] The initial TED API documentation was made available on 3 November at https://docs.ted.europa.eu/api/index.html. We aim to further enhance the API documentation progressively. 

 

• If the API docs are only available in November, you are de facto reducing the time we have to develop a fully working application. This means that the transition period is less than a year. 

Answer: The required parameters are not very complicated. The APIs are ready and can already be used, as presented during the workshop, even if the documentation was not available until recently.  

---

 

Day 2  – 30 September

SDK 1.0 and the road to October 2023 – Ioannis Rousochatzakis – Publications Office of the European Union  

SDK 1.0.0 was published on 5 August. It will be further updated. 

OP expects to go live in November with SDK 1.3.0. This version includes the changes introduced by 

the amendment to the Regulation. 

The SDK is stable, but obviously not final – it will evolve according to the needs. 

The SDK aims to minimise the impact of change and to collectively save time and effort.​ 

 

---

 

Questions from the participants: 

Information provided in SDK updates and impacts: 

• Previously, in TED 2.0.9, every schema update included complete list of all changes, field by field, which was very useful to make sure all changes are addressed. Also, OP provided excel sheet containing all fields and rules per form, very useful as well. Now, the only source of information seems to be fields.json. It is time-consuming to understand what exactly has been changed in a new SDK version. Can OP provide a list of all single changes for every SDK update? 

Answer: It is not possible to provide a list of changes in a changelog. However, there is the SDK in GitHub: https://github.com/OP-TED/eForms-SDK and every user can compare the different versions to see the changes of any file. The path is the following: Github – eForms-SDK – [element/file] – History – any version can be compared towards any other.  

[from a participant] It's also possible to compare releases in GitHub, e.g. https://github.com/OP-TED/eForms-SDK/compare/1.1.0...1.1.1. 

 

• Is there a way we can assist with making the changelogs human-readable?  

Answer: We can try to automate the generation of changelogs of the metadata. When there is a major version, we will write down the changes but when it is a minor version, we would never have to write anything. We could generate a changelog but we don’t have a tracking system for automatically generated changelogs and therefore it cannot be provided now. We take it into consideration and hopefully we can improve it in the future. 

 

• We need the business rules to be described in a more human readable format because some of the eSender systems cannot rely on the SDK. We need to check and implement every rule in the system in a custom way. 

Answer: Since SDK 1.0, the TED Developer Docs provides more accessible (human-readable) information about the metadata reference components like business terms, business rules and codelists: https://docs.ted.europa.eu/eforms/latest/reference/index.html.  

 

• Are the codelists available in an easier/human readable format, preferably in one document, rather than in the format shared on GitHub? EU Vocab site appears to involve having to access each of the eForms codelists individually which is time consuming. 

Answer: All the codelists can be viewed in the metadata reference section of the TED Developer Docs at: https://docs.ted.europa.eu/eforms/1.2.1/reference/code-lists/index.html. They can be viewed in web format, and it is much easier than the generic code from the SDK or via EU Vocabulary. At some point in the future, we will try to provide easier formats. 

 

• Is the SDK meta-driven approach a tried and tested method or an innovative solution? 

Answer: It is a generic and well-known approach.   

 

• Do you think that the impact of SDK changes on applications that use partly the SDK will be more than for applications that are fully meta driven?  

Answer: It is important to understand what is the meaning of the ‘use’ of the SDK. The SDK is meant to be used by applications, not people. If a user is reading the documentation and they then implement the changes themselves, it is not considered to be a ‘use’.  

Having said that, it is the changes in the regulation itself or other business aspects that have an impact on every application – not the changes in the SDK itself. Normally changes in the SDK should not have any impact on the applications that do not use the SDK. 

Changes will inevitably happen; there will be another regulation amendment next year.  

The SDK is only a way for us to manage and mitigate the impact of change. What we try to do with the eForms SDK is to codify and encode everything that can change and provide a common path for coping with these changes.  

From our point of view, the users should follow the technical path that their team is most comfortable with. If you decide to use the SDK either fully or partially, you will avoid having to manage every change in the regulation by yourself. We will keep improving and updating our means of codifying and managing these changes, i.e. the eForms SDK and the processes and best practices that surround it.

 

• When will the SDK be complete and correct?  

Answer: The SDK has always been and always will be ‘complete’ and ‘correct’ at a given point in time.  

The SDK is our way of managing and mitigating the impact of changes (either changes in the law or changes required in order to fix discovered mistakes). The SDK is being developed and released in fully open and transparent open-source environment and it always will be. The versioning scheme of the SDK provides a way for our systems to properly handle these changes. For more information on the SDK versioning scheme and semantics see: https://docs.ted.europa.eu/eforms/latest/versioning.html. 

 

• Will it now be possible that TED accepts Tenders that are now correct and will be in the future of worse legally incorrect? 

Answer: OP will be able to keep several SDKs available in parallel. As long as an SDK is valid, OP will continue to accept and publish notices in that SDK. Each SDK is a complete and consistent set of information. 

The decision to deprecate an SDK version will be mainly driven by business or legal needs and sufficient early warning will be given to eSenders to upgrade to a later version. eSenders may also choose to upgrade to later SDKs to use additional information or to fix specific issues. 

  

• Do I understand right that SDK allows to build an application similar to yours? Because all the EFX rules are based on your notices structure. If I have another visual structure of my notices, e.g. other sections tree, will your EFX rules work for me? 

Answer: There are two structures to consider: the data structure which is the XML structure, and the structure used to visualise the data. 

The XML structure is the structure of the data, it is the way we store the data in an XML file. When the data is displayed on a screen, it doesn’t have the same structure. 

The logic behind the EFX is not shown in visual way but it is there to address the data structure. The EFX needs to make a calculation; it reads, compares, and provides answers. The way that the EFX searches for the data is quite abstract, it doesn’t have to be Xpath, it doesn’t have to look into the XML file. The EFX can get the value from any file. There is a symbol resolver that extracts the value of a field. The value can be anything the user needs. It needs to be implemented only once. The SDK contains all the information: https://github.com/OP-TED/eForms-SDK. 

 

• How can we use the SDK when integrating the eForms in existing .NET (non-Java) applications? What do you recommend in this case? 

Answer: The SDK contains a set of structured files (JSON, etc.) that are not specific to any programming language, so it can be used in a .NET application. It might require more work, if you need to implement features provided in related Java libraries we have created (efx-toolkit-java, and eforms-core-java). As an alternative you could possibly change your architecture, e.g. you could have a Java component on the side and call it only if necessary. For further discussion, do not hesitate to ask via GitHub: https://github.com/OP-TED/eForms-SDK/discussions. 

 

• Does it mean we must follow the data structure and field names, group names, etc. you have defined? I refer to field.json and EFX rules which use specific names. 

Answer: When it comes to the notice type definitions provided by the OP, you don’t have to display the forms like the OP defined them. The notice type definitions are designed to be used in eNotices2 and it may be reused as a concept if you wish to. 

 

• What is meant in SDK 1.0 as stable enough. Does it mean for the OP? Or for eSenders? Is there a date foreseen when the SDK is considered by OP to be complete and correct? 

Answer: Metaphorically speaking, the SDK 1.0 means that we arrived at a specific shape of a puzzle piece, the shape is stable enough, it is not going to change. However, the content of the puzzle piece will change, i.e. the information inside of the SDK might be updated in the future.  

 

• It seems your results examples in SDK are not fully correct, there are no indexes.  

Answer: Please let us know of any examples that are not correct via the GitHub discussions: https://github.com/OP-TED/eForms-SDK/discussions. 

 

• Will there be a major version update until Q3 2023? 

Answer: There are no plans for that yet. Any changes will be communicated in good time. 

 

• It seems there are going to be plenty of minor updates in the future, will there be a regular release schedule (e.g. every month/quarter)? 

Answer: There is no schedule for that. At the beginning, there might be one release per month, especially if the rules are too tight or too loose. However, there can be multiple SDKs valid at the same time and there will be always a warning before any change.  

 

• Can you tell us the estimated deadline applicable to take into account the minor versions and also the major versions of the SDK? 

Answer: Regarding the minor versions, the most significant deadline will be when we are going to deprecate it. For a new minor version, it is not going to affect you immediately. It will be first deployed in Preview so that you can test it.  

There can be two cases when a minor version becomes obsolete:
1. if the application uses the SDK, it doesn’t matter when the minor version becomes obsolete because it will update seamlessly to new versions;
2. if the application doesn’t use the SDK, it will need to be adapted, depending on what components have changed.  

Regarding the major version of the SDK, there will be a lot of warning and there will be a transitional period when both major versions will be valid and running in parallel. 

 

• Because the SKD is now not considered as complete and correct. Will it now be possible that TED accepts Tenders that are now correct and will be in the future legally incorrect? 

Answer: As long as the SDK is valid, we will continue receiving the notices. If it turns out that there is legal mistake in the SDK, it will have to be withdrawn. However, it is important to have in mind that whatever has been published will remain published. 

 

• Is there a consequence if you ignore a minor version update? 

Answer: If you go live with SDK 1.3 and, for example, we get to SDK 1.7, you don’t need to implement all the versions between. In general, you won’t need to upgrade until the version is deprecated but newer versions might have features that are useful to you, e.g. additional fields, codelist updates, bugfixes. 

 

• What happens when a notice that has been made with a major version that later on is expired, but the procurement is still ongoing and one must need to submit a new change notice, e.g. original notice submitted on date 1.1.2023 with latest major version SDK 1.3.; now after 6 months new major SDK 2.0 is released and expiration date for SDK 1.3 is set to 1.1.2024. Finally, the customer wants to submit a change notice for the original one on 2.2.2024. What happens now? How can you submit a change notice for the original notice, if the notice version is already expired? 

Answer: The user will need to complete what is needed in the later version. If SDK 1.3 has been deprecated and you want to change a 1.3 notice a year later, you have to make sure that your change version respects the new valid SDK. You will have to fill in any gaps.  

Note: a deprecated version means that a new notice cannot be submitted under that version but it can be read and reused, i.e. the data can be copied (and reused) from one version to another. 

 

• How do you plan to ‘phase out’ or deprecate a version? Isn’t the expiration date set when the version is published? 

Answer: If you call CVS, it will tell you what is the oldest and the most recent version. 

 

• It seems that the ‘puzzle piece’ only is ‘stable’ for developers who choose to use the meta driven approach. For all others even ‘colour changes’ can require a significant action from the developer. Is that correct? 

Answer: Yes, absolutely. The best way is to use the SDK as much as possible as otherwise every minor version will require lot of effort. The use of SDK allows automation, and the human factor is not necessary. 

 

• I don't understand the proposed approach of checking Maven Central for a new minor version of the SDK and ‘magically’ updating it in our application without changing, building and deploying a new version of our application. I have never seen such a use case. Let alone, having a Maven based application that uses multiple different versions of the same dependency at the same time. 

Answer: It is in Maven because it is available to everyone and the Office needs to distribute it somehow. If you need it from a different source, please inform us and we will provide it for you. We have designed our applications to manage the process automatically and limit or remove the need for manual intervention.  

[The participants also discussed amongst themselves]: 

Maven on IDEA found: 
    <dependency> 
            <groupId>eu.europa.ted.eforms</groupId> 
            <artifactId>efx-toolkit-java</artifactId> 
            <version>0.1.1</version> 
        </dependency> 

- but with this version I did no find class SdkFieldV1         
- [from OP - Christophe Roussy to everyone]: 0.1.1 predates V1V1 is 1.0.0, in other words the past does not know about the future 
- of course, but why Maven client cannot find <version>1.0.1</version> ? 

 

• Do I understand right that the API will only accept the matched SDK versions, e.g. if I use SDK 1.0.0 generate XML and send it at API but API will accept only SDK 1.1.1 so I will be refused at my request with error? 

Answer: Yes, that’s correct. Although, it is only the major and minor versions that are checked, the patch number is not concerned.  

 

• SDK is stable, but it may e.g. do changes in some fields visibility conditions or some validation rules and if you are not fully building your application, you would need to compare the versions in GitHub and find what you need to change in your app to support these changes in SDK. Could you share any code that accomplishes this? Even if it is just a POC. We (Belgium) and other countries are really struggling with this.  

Answer: We've reached a point where the SDK has an overall stability. Some changes may appear and they will mostly be reflected with data updates.  

The choice of a data centric approach has been made to simplify and streamline the alignment process with any new change. Business rules have been expressed in a technology agnostic language (i.e. EFX). Unfortunately, not all implementers went that direction and the ones who didn't may have to address manually applied changes. When changes are about rules, they may either start from the EFX expressions or from the rules expressed in natural language. The technology used to distribute information (i.e. GitHub) is very helpful when it comes to detecting differences between two different releases. There are no additional tools recommended for dealing with that and solutions are specific to each selected approach. For the organisations willing to assess rules in a natural language, it may be necessary to consolidate information from different artefacts or use information shared as part of the documentation (e.g. https://docs.ted.europa.eu/eforms/latest/reference/business-rules/index.html). 

When it comes to automation of our applications, it means that information is provided in a predefined format allowing an easy and automated information extraction. So long structure does not evolve, it is just a matter of data extraction and use. Currently, the structure evolves with the increasing number of requirements considered, what already existed is not affected. 

 

• Where will the latest acceptable version be documented? 

Answer: Via the CVS API. In the future, there will be also documentation.  

 

• How many eSenders could support EFX today? 

Answer: We are planning a survey in the coming weeks to find out more about eSenders' plans.   

 

• Have you tried to evaluate EFX on a different data structure (example: JSON)? 

Answer: Please ask about this technical question via GitHub: https://github.com/OP-TED/eForms-SDK/discussions.  

 

• National tailoring is a big problem, because now every member state needs some sort of national SDK to extend the business rules from eForms SDK. In Germany, it is called GDK (German development kit) and it doesn't implement only the business rules but delivers on top an abstraction model of the eForms model. We have to use the GDK and we do not know at the moment what parts of eForms SDK can be used. Your puzzle metaphor has to be extended with the GDK version in our case. 

Answer: Indeed, you will have your own extended data structures and you will need to import whatever data the OP provides via the SDK (or any other channel). The optimal scenario would be to merge the SDK data with your own extended data structures. There is no generic way to do that.  

The Office strives to establish something general that will correspond to everyone. We do our best that the SDK doesn’t cause any problems to you.  

 

• It seems that the project assumes that developers are using the meta-driven approach even though there is no requirement to do so. I think it would be useful with a more realistic view of the developer community concerned.  

Answer: We publish things in an SDK because we are meta-data driven for what we have to do and we believe that it helps anyone who can move towards this approach. We are trying to make it as simple as possible for the developers.  

 

• What if the original notice (e.g. a contract notice) was submitted using the current system and the change notice is an eForm? What should we put for example in efbc:ChangedNoticeIdentifier? 

Answer: In principle you will just refer to your old TED XML notice, even if you refer to a contract notice that is old.  

 

• EFX borrows so strongly from XPath that is seems infeasible to translate it to anything else. To avoid excessive traffic between our front- and back-ends, we are therefore looking into the possibility to convert a filled in notice to XML in the front end, merely to be able to evaluate EFX "offline", after each "change" made to the form values (either prefilling, debounced user input, or blur). How to translate EFX to something else, like JS? 

Answer: We developed EFX because we wanted something simpler than Xpath. There has to be some data structures, even if it is JSON file. A path is needed, the EFX is an abstraction. Many concepts can be translated into a different language (e.g. loops, operators, functions, etc.). For further discussion, do not hesitate to ask via: GitHub: https://github.com/OP-TED/eForms-SDK/discussions. 

EFX is used for business rules and their validation, and for visualisation of notices. If the validation is done via Schematron, you don’t need the EFX. Otherwise, you will need to create an EFX interpreter that works with your own data structure. OP created an abstraction of the EFX tool in Java and 90 % of the code is available, the rest depends on your own preferences and your data structures. 

 

• It's not clear how to deal with repeated groups and fields. EFX, xpathAbsolute, xpathRelative and parentNodeId all seemingly ignore that fields/nodes may be repeated. What are we not seeing? 

Answer: Simple explanation: a group is used to create a visual structure and a note is used to represent the data structure. A group (of fields) is repeatable only if it is associated with a repeatable field. The XpathAbsolute should be ignored; it is correct, but it does not provide enough information because you don’t know where to split it. By using the XpathRelative, you will know exactly what needs to repeat; for that you should read the repeatable property form in fields.json. For more information about the repeatable nodes and repeatable groups, please visit: https://docs.ted.europa.eu/eforms/latest/guide/xml-generation.html. 

 

Technical identifiers: 

• Do we have to maintain the IDs used inside an eForm during the whole procedure: for example, if an organization is ORG-0002 in the contract notice, then the same organization must have the same ID (ORG-0002) in the contract award notice? 

Answer: All the technical identifiers (ORG-, LOT-, etc.) have to be consistent within the whole notice. You can use your own internal identifiers, e.g. if you call it ‘LotA’ in your contract notice, you have to call it ‘LotA’ in the contract award notice too, to be able to refer to it between notices. In the notices themselves, the same lot could have a different technical identifier, e.g. 'Lot A' could be LOT-0063 in the contract notice and LOT-0002 in the contract award notice; this is not a problem as long as it is consistent within the notice. The user only needs to keep track of the technical identifiers used in the notice, which might be generated by the application, like in eNotices2.   

 

• Each Groups of Lots, Lot, and Part, has its information in its dedicated "cac:ProcurementProjectLot" element whose identifier is built using the appropriate scheme from Table 1. These technical identifiers are unique within a notice and may not evolve (i.e. the same Lot will have the same technical identifier from the start to the end of the procurement procedure). Something like this will be useful: S2-01-06: Maximum number of lots that may be awarded to one tenderer: cannot be higher than Maximum number of lots or the total number of lots (S2-02). https://docs.ted.europa.eu/eforms/1.0/schema/procedure-lot-part-information.html 

Answer: [post-event update] Statistics were initially foreseen to be reported at the level of the Lot or Group of lots instead of the LotResult so that it was possible to report figures for lots and group of lots. Now this is not possible anymore as this is at Result level. We won't be able to distinguish statistics for Lots from the ones for group of lots. The text has been removed from the table in a previous version of the documentation. 

 

• Will you extend the concept of adding codelists to fields by allowing conditions to codelists with SDK 1.2. or 1.3? The concept of parent and child codelists could nicely be used in any tailoring to further tile large codelists according to the directives where only some entries are required.  

Answer: A codelist is a dynamic property and therefore there might be a condition added but we don't have the capacity to handle this in the coming months. 

 

Validation: 

• Please give a sample, how does CVS point to an array item, e.g. some field being a part of some organization or lot.  

• How do you understand results of validation? There is no reference to the specific organization. I am looking at the Schematron validation results taken from SDK, see below, how to understand which Organization from many is affected. 

<svrl:fired-rule context="/*/ext:UBLExtensions/ext:UBLExtension/ext:ExtensionContent/efext:EformsExtension/efac:Organizations/efac:Organization/efac:Company/cac:Contact/cbc:Telephone"/> 

   <svrl:failed-assert id="BR-BT-00503-0052" 

                  location="/ContractAwardNotice/ext:UBLExtensions/ext:UBLExtension/ext:ExtensionContent/efext:EformsExtension/efac:Organizations/efac:Organization/efac:Company/cac:Contact/cbc:Telephone" 

                       role="ERROR" 

                       test="matches(normalize-space(.),'^((\(\+?[0-9]+\))|\+?[0-9]+)( - |-| )?(((\(\d+\))|\d+)( - |-| )?)*(\d+)( )?$')"> 

      <svrl:text>rule|text|BR-BT-00503-0052</svrl:text> 

   </svrl:failed-assert> 

Answer: In SVRL validation reports, the exact ‘Organization’ element that is affected by a rule failure is indicated by its position in the XML, indicated in the "location" attribute. So for example, if the second ‘Organization’ is affected : location=".../efac:Organization[2]/...’. If there only one element in the XML, there is no ambiguity, so the ‘[1]’ is omitted. The same mechanism is applied for any element that can appear multiple times. 

 

• Are there any rules that validate data between different versions of the same notice (contract notice version 01, and contract notice - change v02) or between contract award notice and the correspondent contract notice for the same procedure? Are these rules documented? 

Answer: Yes, there are certain rules. When you change a notice or continue a procedure, there are a few fields that cannot be changed, e.g. legal basis. The rules are documented in the Schematron and in the metadata reference. 

 

Cancel notice: 

• If the contracting authority cancels a lot inside a procedure, should we send a change notice without the cancelled lot and use the cbc:ReasonCode: cancel in the ‘Changes’ section?  

Answer:  
1. The procedure to cancel a notice varies depending on the status of the notice:  

 - If the notice is in Submitted status and has not been published yet, users can stop its publication and resubmit it. It can be done only until it enters the daily export to TED and OP has initiated the process of publication of the next OJ S (which happens around 16:00 CET on workdays).  

- If the notice has already been published (or entered the daily export), it can only be cancelled through a Change notice. The Change notice is a reproduction of the original notice with an extra section to advertise changes to the procurement and procurement documents and for correction of clerical errors. If a Change notice is submitted with the reason ‘Notice cancelled’, it means that the original notice is null and void, as if it should never have existed. Buyers should use their change reason with care as it may have implications for the procedure, for example, deadlines may need to be changed.  

 
2. To cancel the procedure or lot, the buyer must submit a Contract Award Notice with no winner – regardless of whether the submission deadlines have been reached or not – along with a reason. The use of the Change notice to cancel a procedure as proposed in the eForms Policy Implementation Handbook would create the risk of inconsistencies and was therefore not implemented. 

 

8-digits publication number change: 

• Is there going to be a change from 6 to 8 digits in the OJS Publication number? If so, when?   

Answer: [post-event update] After 14/11/2022, the bulk FTP will have both formats.  

 

• Is there a way to differentiate which notices are in each format prior to collecting? Is there a special naming convention? Or they will all be mixed together?  

Answer: The TED website currently allows a maximum of 999 999 notices to be published per year (i.e. 6 digits, e.g. 1-2022, 654321-2022). 
To enable more than one million notices to be published per year, we have increased the publication number to 8 digits (e.g. 1-2024, 87654321-2024). 
Due to this extension, the XML packages will contain two formats of the XML files: 
- for eForms notices the format will have 8 digits (e.g. 00654321_2022.xml) 
- for TED schema notices the format XML file will have 6 digits (e.g. 123456_2022.xml). 
The publication number will have 8 digits for eForms notices and 6 digits for TED schema notices.  

•  Is there going to be a new release of the TED XSD schema? 

Answer: There will be no change for the current TED XML notices. 

 

• Does the digit extension to 8-digit impact user input in web forms, e.g. in the section ‘Previous publication concerning this procedure’ – ‘Notice number in the OJ S’? 

Answer: Yes, if you are referring to a previous notice, you will have to allow for 8-digit references, you could put two leading zeros.  

 

• Does the digit extension to 8-digit impacts the generation of the no_doc_ext number in the xml? 

Answer: No, the No_Doc_Ext is the eSender’s reference.  

 

• Where will we find the documentation on the 8 digit change? 

Answer: [post-event update] More information can be found at: SIMAP - Developers' corner for eSenders and Reusers (europa.eu).   

 

• Do we understand correctly that the length of the OJS-number will also change for the current forms? 

Answer: No, it will continue to be 3 digits (365 days of the year).  

  

FAQ:  

• Are these questions/answers published somewhere? FAQ or some sort of Q&A page on GitHub? 

Answer: Yes, these questions and answers are published online on the workshop website. Some of them contribute to updating the FAQ on the TED Developer Docs: https://docs.ted.europa.eu/home/eforms/FAQ/index.html and further technical questions can be handled through GitHub discussions at: https://github.com/OP-TED/eForms-SDK/discussions. 

 

Other: 

• Is there a new, complete Celex file available with all new BT's present somewhere? 

Answer: Once the 2022 amendment to the eForms regulation is adopted, an updated version of the extended annex Excel ("Celex file") will also be published. 

 

---

Ms CRUZ concluded the workshop by thanking all participants for sharing their questions, comments and concerns. She emphasised that there is still a lot to be done and the team is doing their best to complete everything on time. She pointed out that the priority was put on automation and sharing information with the users as soon as possible. She reminded that the OP remains supportive to eSenders and that the communication channel established for the best support possible is through the TED Helpdesk and via GitHub for technical questions.  

---

During the workshop participants answered some Slido questions, which provided valuable feedback for OP.  

---

 

Last update: 31 October 2022.
Published: 23 February 2023.