TED schemas. Governance and latest updates

Transcription

1 TED schemas Governance and latest updates Enric Staromiejski Torregrosa Carmelo Greco 9 October 2018

2 Agenda 1. Objectives 2. Scope 3. TED XSD Technical harmonisation of all TED artefacts Code lists Business rules and XML restriction rules 4. Governance New release: one year implementation cycle Change requests collection cycle Transition plan

3 1. Context 3 Where we come from R2.0.8 R2.0.9 TED XSD evolution Impacts Design Reapproach Considerations R3.0.0

4 1. Context 4 Current development OP esenders (re)users TED XSD evolution Impacts Design Reapproach Considerations R3.0.0

5 1. Objectives 5 1. To develop a new version of the TED XML schemas (TED XSD's 3.0.0) using the current TED XML schemas specification to adapt it: i. Using better practices which minimise or eliminate the issues ii. iii. Reducing to the minimum the effort of maintenance of the TED schemas Evolving and partially redesigning the current XML schemas using the externalised reference data 2. To deliver a full set of technical documentation to maintain: i. The TED XML schemas ii. The content validation iii. The reference data (code list) iv. Naming and design rules v. Implementing guidelines and rules Consequently, minimise the impacts on the esenders, OP and other stakeholders.

6 2. Scope 6 Only one schema (TED XSD 3.0.0) will contain all the forms. Forms included in the new version Defence: F16, F17, F18, F19 F01 to F08, F12 to F15, F20 to F25 Transport: T01, T02 DEVCO: D01, D02, D03, D20 Small forms (new development) Total: 31 forms Annual list of contractors Call for expression of interest European economic interesting grouping Information notice about European company

7 3. TED XSD Technical harmonisation of all TED artefacts Apply same NDR (Naming and Design Rules) to all schemas Example 1, change of the element name NUTS to REGION: R2.0.9.S03 R3.0.0.S01 Example 2, change the forms filenames and root elements from F02_2014 to F02 : R2.0.9.S03 <TED_ESENDERS xmlns:xsi=" xsi:schemalocation="ted/r2.0.9.s02/reception TED_ESENDERS.xsd" xmlns="ted/r2.0.9.s02/reception" VERSION="R2.0.9.S02"> <SENDER> </SENDER> <FORM_SECTION> <F02_2014 LG="SV" CATEGORY="ORIGINAL" FORM="F02"> R3.0.0.S01 <TED_ESENDERS xmlns:xsi=" xsi:schemalocation="ted/r3.0.0.s01/reception TED_ESENDERS.xsd" xmlns="ted/r3.0.0/reception VERSION="R3.0.0.S01"> <SENDER> </SENDER> <FORM_SECTION> <F02 LG="SWE" CATEGORY="ORIGINAL" FORM="F02">

8 3. TED XSD Technical harmonisation of all TED artefacts Use of simple XSD data types instead of ad-hoc proprietary elements Example 3, instead of using the ad-hoc data type date_full, use xs:date. The implementation of the XML is the same XSD in both versions: R2.0.9.S03 <xs:group name="time_frame_tender_valid"> <xs:choice> <xs:element name="date_tender_valid" type= date_full"/> R3.0.0.S01 <xs:group name="time_frame_tender_valid"> <xs:choice> <xs:element name="date_tender_valid" type="xs:date"/> XML <DATE_TENDER_VALID> </DATE_TENDER_VALID> <DATE_TENDER_VALID> </DATE_TENDER_VALID> Example 4, instead of using the ad-hoc data type empty, use xs:boolean : R2.0.9.S03 R3.0.0.S01 XML <CONTRACT_COVERED_GPA/> <NO_CONTRACT_COVERED_GPA/> <CONTRACT_COVERED_GPA>true</CONTRACT_COVERED_GPA> <CONTRACT_COVERED_GPA>false</CONTRACT_COVERED_GPA>

9 3. TED XSD Technical harmonisation of all TED artefacts Extract into XSLT files the rules, codes and constraints Example 5, restriction in cardinalities have been extracted into XSLT validation rules: XSD R2.0.9.S03 <xs:group name="procurement_address"> <xs:sequence> <xs:sequence minoccurs="0"> <xs:element ref="address_contracting_body_additional" maxoccurs="500"/> <xs:element ref="joint_procurement_involved"/> <xs:element ref="procurement_law" minoccurs="0"/> </xs:sequence> <xs:element ref="central_purchasing" minoccurs="0"/> </xs:sequence> </xs:group> R3.0.0.S01 <xs:group name="procurement_address"> <xs:sequence> <xs:sequence minoccurs="0"> <xs:element ref="address_contracting_body_additional" maxoccurs="unbounded"/> <xs:element ref="joint_procurement_involved"/> <xs:element ref="procurement_law" minoccurs="0"/> </xs:sequence> <xs:element ref="central_purchasing" minoccurs="0"/> </xs:sequence> </xs:group> XSLT - XSLT: R995 Element cardinality limit exceeded. Consequently, changes in these type of restrictions will not produce a new version of the TED XSD.

10 3. TED XSD Technical harmonisation of all TED artefacts Do not use attributes as value placeholders, but as metadata of the element XML <CPV_CODE CODE=" "/> <LANGUAGE VALUE="SV"/> R2.0.9.S03 <CPV_CODE> </CPV_CODE> <LANGUAGE>SWE</LANGUAGE> R3.0.0.S01

11 3. TED XSD Code lists All code lists will be available in a unique single source (MDR) All code lists will be imported from MDR and will be in one single new XSD file: Codelist.xsd will be used to import code lists from MDR. Each code list will be an XSD file (XSD enumeration) R2.0.9.S03 (common.xsd) R3.0.0.S01 (codelist.xsd) XML <xs:complextype name="ca_type"> <xs:attribute name="value" use="required"> <xs:simpletype> <xs:restriction base="xs:string"> <xs:enumeration value="body_public"/> <xs:enumeration value="eu_institution"/> <xs:enumeration value="ministry"/> <xs:enumeration value="national_agency"/> <xs:enumeration value="regional_agency"/> <xs:enumeration value="regional_authority"/> </xs:restriction> </xs:simpletype> </xs:attribute> </xs:complextype> Importation of the code list from MDR: <xs:import namespace=" y-type" schemalocation="code_lists/t_authority-type_publicprocurement.xsd"/> Get the values from this code list file: <xs:simpletype name="ca_type"> <xs:restriction base="aa:t_authority_type_tedschema"/> </xs:simpletype>

12 3. TED XSD Business Rules Business rules are not modified in the scope of this version. Examples: S : Procurement documents: not foreseen if prior information notice only. S : Maximum number of lots: cannot be higher than the total number of lots (S2-02). Business rules are coded as in previous versions (XSLTs) but have been enriched with a few new rules. XML Restriction Rules (new) Externalisation of the hard-coded rules in the schema. Restriction on data types, cardinalities Examples: Element cardinality limit exceeded. The element does not have the expected value.

13 4. Governance 13 New release: one year implementation cycle. Announce the new release October Transition period Questions and answers from the esenders Go-live June The release available for tests March Development of the Release November The release is available for public review January

14 4. Governance 14 Change requests collection cycle Announce the new release October Transition period Questions and answers from the esenders Close Go-live the cycle June The release available for tests March Development Open of the the cycle Release November The Capture release the change is available requests for for public the next review release

15 4. Governance 15 Transition plan for the release Transition period eforms R3.0.0 R2.0.8 R / /2019??/202? Estimated date for the go-live??/202?

16 16 Thank you. Questions?