Restored a correction introduced in release 1.2.3 that was accidentally lost in 2.0.0

Corrected (amended) the types of representation to reflect the changes included by the amended version of the eIDAS regulation. This was already reflected by chapter 2.1.2.3.

2.1.2.6

Restored a clarification introduced in release 1.2.3 that was accidentally lost in 2.0.0 

Mentioned the version of eIDAS sample implementation that supports the OOTS sector specific attribute "PowerOfRepresentationScope".

2.3.4

Minor editorial corrections, including capitalisation and wording updates.

3.3.2

Extended checks for LCM rule R-LCM-SUB-S096

In combined LCM, added checks in R-LCM-SUB-S096 for Classification Schemes at both Procedure and EvidenceTypeList levels, in addition to EvidenceProviderClassification, as MS Schemes can be applied at different levels. Thereby the rule R-LCM-SUB-S096 was downgraded from Fatal to Caution role.

3.6.3

49d3dad7 

Updated version information of Procedures codelist 2.0.1 due to spelling improvements for the SK translations.

3.5.1

Restored a correction introduced in release 1.2.3 that was accidentally lost in 2.0.0

Changed description of IssuingDate. The description contained "date and time" but the data type is of "date" type only; "time" was removed.  

4.5.2

Correction of AdminUnitLevel1 Cardinality within Address component

Updated the cardinalities of the (mandatory) AdminUnitLevel1 within the (optional) Address component, in the specification documentation to align with the XSD, existing business rules and validation logic. The AdminUnitLevel1 was incorrectly shown as an optional element in the specifications.

In specific business scenarios governed by Schematron rules (e.g. Agents classified as Evidence Requester (ER), Evidence Provider (EP), or Error Provider), an Address becomes mandatory and therefore AdminUnitLevel1 must also be provided. In other scenarios the Address can be omitted. However, if an Address is provided, the AdminUnitLevel1 must be provided too.

This is an editorial correction only; no changes to the XSDs or Schematrons are required and no breaking changes are introduced. 

4.5.1

4.5.2

Improved description of signature algorithm used for signing SMP responses

OASIS SMP 2.0 requires that SMP response are signed using XML Signature.  It recommends, but does not require, RSA SHA 256 as signature algorithm. The certificate profile already indicated that OOTS will use ECDSA (using P-256) or Ed25519. Added some additional explanation in the specification text. 

4.7.3.2

Corrected old title in SR metadata 

In the SR metadata of the v2.0.0 XSD there was still a reference to 1.2. 

4a4a78ba

Corrected ConformsTo in MS-CLASS returning error if pointing to non-prod URL.

71a80579

Fixed issue concerning ResponseAvailableDateTime Slot absence not triggering error in case of empty RegistryObjectList on Evidence Response.

3c0432aa

Aligned Birth Example Response language with the  language that was used in the Request.

07ee0f39

Updated Request-Response Birth Example with correct language response flow

833f2007

Some rules apply to both Unavailable and Success responses. @status='urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success' was removed from multiple rules in EDM response structure rules.

56665767

3dc089aa

Updated EvidenceTypeClassification value in Evidence Response Education full xml example.

9f59cceb

Fixed Regression Testing snippet checking RegistryPackageType type for an existing RegistryObject.

e7554a1b

Procedures codelist 2.0.1 with spelling improvements for the SK translations

b58f2d8a

New version of SDG-GenericMetadataProfile-v2.0.1.xsd

Removed vc:minVersion="1.1" from Generic metadata profile of the SDG and changed version to SDG-GenericMetadataProfile-v2.0.1.xsd. The field was not necessary but caused problems in some validators. No breaking change. 

The file oots_driver_v2.0.1.xsd and oots_driver_v2.0.1_local_imports.xsd have been updated too and the HTML documentation was regenerated.

49d3dad7

6021b5b5  

212062e7

Fixed schematron problems with ResponseAvailableDateTime Slot absence that did not triggering error in case of empty RegistryObjectList on Evidence Response.

In case of empty RegistryObjectList (No Evidence), samples contain already ResponseAvailableDateTime. On the Schematrons, the omission of the Slot is not triggering any error.

3c0432aa

56665767

49d3dad7

Fixed schematron problems with DSD conformsTo statements of EUDI

The schematron rules for conformsTo statements in the DSD used a wrong value. Wiki states the value is eudi-pubeaa-is:1.0 but the schematron rules (2.0.0) checked for eudi-pubeea-is:1.0. The error was corrected.

• R-DSD-RESP-C015
• R-DSD-SUB_RF-C023

Fixed Regression Testing snippets issues related to DSD conformsTo statements of EUDI: R-DSD-RESP-C015 and R-DSD-SUB_RF-C023.

3e0cf529

3feec013

In LCM, enabled the inclusion of MS specific classification schemes not linked to other objects.

20d3c8aa

41b141b3

Updated Business Rules. 

a98c53f3

Fixed issue related to multiple languages in cross-validation and added regression testing XML example.

10ea1428

7ab592e4

21cc55e6

New Access Service Discovery Service

Included the new dynamic discovery service based on eDelivery SMP in the architecture

1.3.3

1.6.7

Misc editorial

Fixed broken links, removed or updated obsolete references, aligned terminology.

1

Introduction of key functional changes in existing components 

Language information in DSD, language selection in evidence requests; packaging of evidences and associated documents in evidence responses; SR-centric approach to filtering/transformation.

6.3

7

Clarifications on eIDAS Unique Identifier exclusion list.

2.1.2.3.1.1

Support for MS-specific classification system in Evidence Broker (Jurisdiction of ReferenceFrameworks)

Removing AdminUnitLevel2 & 3 and replacing it with new concept "AdditionalJurisdictionClassification" as a multi purpose element that can be connected to any MS-specific classification system having cardinality 0..n. 

Adding "listID" attribute to "AdditionalJurisdictionClassification" to support use of MS-specific classifications systems for Jurisdiction in the Evidence Broker. Changes are applied to the following

• AdditionalJurisdictionClassification has been included and AdminUnitLevel2 & 3 are removed.
• The query parameters 'jurisdiction-admin-l2' and 'jurisdiction-admin-l3' are removed from the Get List of Requirements Query, because AdditionalJurisdictionClassification are not known upfront to a client. Clients need to filter the result set themselves. Removing EB:ERR:0004 which linked to wrong Jurisdiction query parameters.
• A 'listID' attribute has been included to the 'AdditionalJurisdictionClassification' of Jurisdiction. Data models, Implementation Guidelines and Examples have been updated.

Linking Evidence Types to Structured Evidence Type Distributions (OOTS Data Models)

Adding new class Structured Evidence Type Distribution (OOTS Data Model) and relating it to EvidenceType with "ConformsTo" and "Format" information. Detailing how structured evidence types are declared in the EB, exchanged, and linked to requirements. The updates include:

• Description of registration func of OOTS data models, subsets, and conformance profiles in the Semantic Repository as a pre-condition. Illustration of necessary documentation of authoritative artifacts (schemas, code lists, XSLTs, and version control) in the repository.
• Governance of OOTS Data Model–requirement associations based on Semantic Repository metadata as pre-condition to link Evidence Types with OOTS Data models.
• Clarification of process on linking Evidence Types to Structured Evidence Type Distributions (OOTS Data Models) and related subsets, conformance profiles and versions.

3.2.4 (4.3, 4.7), New section 4.3.4

Revision of 3.2.3

Rework of 'DistributedAs' used in DSD 

Refined the use of 'DistributedAs' class to better align with Structured Evidence Type Distribution (OOTS Data Model) declarations done in the EB for an EvidenceType. 

• Removed the 'Transformation' element, the functionality is expressed using 'ConformsTo'. Every Transformation (e.g. profile, customization, subset, version of an OOTS Data Model), supported by a Data Service shall be declared as separate Distribution and under different URI and 'ConformsTo' statement. 
• Indicating that if a Distribution with 'ConformsTo' statements is added for a Data Service, there MUST be a Structured Evidence Type Distribution (OOTS Data Model) that was already linked to the corresponding Evidence Type in the Evidence Broker.
• Adding Language element to declare the available languages of a Distribution in the DSD.

3.1.4 (4.3, 4.4.3, 4.8)

Rework of section 4.3.2.1

Added sdg:MatchType and sdg:MatchDescription to EvidenceTypeList.

matchType enables systems to express whether evidence in a given jurisdiction satisfies a requirement (including explicit NoMatch for empty lists), while MatchDescription provides a human-readable explanation for the match decision.

• Inclusion of sdg:MatchType and sdg:MatchDescription to specifications. 
• Provison of additional Explanatory Description of sdg:MatchType and sdg:MatchDescription  in secton 4.3.5.

3.2.4 (4.3, 4.3.5)

Restructured jurisdiction modelling by moving Jurisdiction from EvidenceType to EvidenceTypeList 

Moved Jurisdiction from EvidenceType to EvidenceTypeList, to express the context of the List and to facilitate Jurisdiction for empty EvidenceTypeLists (NoMatch).

Replaced AdminUnitLevel2 and AdminUnitLevel3 with a flexible AdditionalJurisdictionClassification element (0..n) using listID to express the classification type (e.g., language community, region, sector). This enables multiple jurisdictional contexts based on MS-specific classification systems and supports more granular EvidenceTypeLists.

3.2.4 (4.3, 4.7)

Added clarification that the MatchType and MatchDescription elements should be considered as technical preparation for potential future use only. The functionality is still under definition, has not yet been decided in the RFC process, and, if approved, will be scheduled and planned accordingly.

3.2.4.3

3.2.5.4

Introduction of return-incomplete query parameter

Revised requirement-query behavior by replacing the previous implicit handling of incomplete requirements with an explicit return-incomplete Boolean parameter.

When set to true, the EB returns draft (incomplete) requirements that lack a reference framework, allowing development teams to identify and complete these items through LCM or the CS Admin UI. When set to false (default), only complete requirements are returned. Previously, only the non-use of these optional parameters led to implicitly incomplete requirements being output. This change ensures clearer, predictable query semantics.

3.2.4 (4.2)

Removed 'DistributedAs' from DSD:ERR:0005

The DistributedAs class was removed from DSD:ERR:0005. This is a left over of an incorrect cardinality within the XSD. DistributedAs is DataService specific information and the DSD:ERR:0005 can only aggregate Distribution Information on this level.

Removed 'EvidenceProviderJurisdictionDetermination' and 'Jurisdiction/AdminUnitLevel2&3' from DSD

Duplicate Feature with Introduction of EvidenceProviderClassifcation and MS-specific classification schemes. MS could introduce any JurisdictionClassification that is needed and suitable (e.g. language community, administrative level, sector, company type, company size). If needed, NUTS/LAU codes relevant for a Publisher can be expressed through Supported Value and MS-Specific Classification Schemes.

• Removed 'EvidenceProviderJurisdictionDetermination' and 'Jurisdiction/AdminUnitLevel2&3' from all specifications, descriptions and examples provided in 3.1.3 and 3.1.4.

3.1.3

3.1.4

Enable EUDI verification protocol support using TS 119 478

Added specification identifiers for support for verification of attributes against authentic sources or designated intermediaries using the mechanisms defined in ETSI TS 119 478.

3.1.4

New Content

Update of DSD LCM

The DSD LCM Interface Specification was updated. The MS-specific classification system was removed - it was added as separate LCM component, as  MS-specific classification system are now used in both the EB and DSD. Additionally, the DSD LCM has been modified to incorporate new/modified features (Language of DistributedAs) and removed features (JurisdictionDetermination, AdminLevelUnit1/2, Transformation).

3.1.6

New Content

Update of EB LCM

The EB LCM Interface Specification was updated. The MS-specific classification system was referenced as a possible component to markup Jurisdiction capabilities of EvidenceTypeList and ReferenceFramework. Additionally, the EB LCM has been modified to incorporate new/modified features (Jursidiction of ETL, StructuredEvidenceTypeDistribution, MatchType, MatchDescription) and removed features (Jurisdiction of ET)

3.2.5

Correction

Update of the implemented SR functionalities by checking the relative checkboxes and improved the clarity of the non-functional requirements.

3.3.1

New content

Updated SR functionality for SR v1.7.

Removal of "contentLanguage", "transactionType", "transactionComponent", "transactionSubject", "theme" and "issuingCountry" query parameters. Introduction of "constraintScope", "constraintSubjectMessage", "constraintSubjectMessagePart", "provenanceCountry" query parameters.

3.3.2

Removal of query parameter "showVersions" and introduction of "showLatestVersion" query parameter.

Revised search behavior to return all the versions of the assets by default.

When showLatestVersion is set to true, then search will return only unversioned assets or asset versions marked as “currentVersion”. When set to false or if it is not indicated as parameter (default) then search will return all different versions of matched assets.

Editorial revisions to enhance clarity on the parameters of the Search Assets method. Improvement to support maximum results per page in the response.

Created a new section Response Signature for SR (3.3.2.4.4) that references the new section 3.6.2.7 on Response Signature for Common Services in general.

Editorial revisions to enhance clarity on the error titles and descriptions of the GetAssetMetadata, RedirectToAssetDistributionAccessURL and Search Assets methods.

Editorial revisions to enhance clarity on the types of assets included (and to be included) in the four SR sub-repositories. Description of the artefacts comprising an OOTS data model and of the assets supported in version 1.7 of the underlying SR data model.

Updates of SR data model, controlled vocabularies in use and examples of versioning and associative asset relations for v1.7

• Removal of classes sr:Transaction and sr:Location and of their associated properties; addition of properties sr:applicableFormalSpecification, sr:contraintScope, sr:constraintSubjectMessage; sr:constraintSubjectMessagePart, sr:documentation, sr:isExampleOf, sr:isValidatedBy, sr:packageFormat, sr:provenanceCountry, sr:representationTechnique; replacement of v1.6 sr:ReferenceFramework with sr:LegalResource and sr:applicableLegislation to align with ELI specs.​
• Withdrawal of controlled vocabs linked to deleted properties; definition of five new controlled vocabs for the newly introduced properties; updates of asset types one to​
• Updates of the examples illustrating how versioning and associative relationships between assets are captured in version 1.7

Addition of sr:replaces property to the SR data model to explicitly capture cases where an asset replaces (supersedes) another (3.3.4) and of illustrative usge example (3.3.4.2).

Editorial changes to the controlled vocabulary for the sr:constraintSubjectMessage range values and corresponding adjustments to the accepted parameter values of the SR Search method.

New Content

New section 3.5.3 for LCM Interface Specification for Member State-specific Classification Schemes

The MS-specific classification system was decoupled from the DSD LCM. Lifecycle Management of MS-specific classification schemes has been separated from DSD artefacts, and a dedicated LCM method for MS-specific classifications has been introduced.

As a result of this separation, MS-specific classification schemes are now managed as independent registry artefacts. Despite this decoupling, MS-specific classification schemes are intended to be used in conjunction with Data Service Directory (DSD) and Evidence Broker (EB) artefacts.

To ensure semantic consistency and effective use of classifications, MS-specific classification schemes MUST be submitted either:

• as a standalone LCM submission; or

• as part of the same LCM submission transaction as the related DSD artefacts.

3.5.3

Editorial

De-duplicated response signature sections

Created a new section 3.6.2.7 on Response Signature for Common Services in general. The existing Response Signature sections for DSD (3.1.4.6) and EB (3.2.4.5) now reference to this new section.

3.6.2.7

New content

Certificate profile for Common Services sealing certificate

Created a profile for the certificate used by the Common Services to sign Common Services response.

3.6.2.7

New content

Specification for use of eDelivery and LCM with dynamic configuration

Added specification for using eDelivery with dynamic configuration for LCM.  Mostly the same as for evidence exchange, except for the Service/Action related parameters and the scope. 

3.6.3.6

Editorial

Minor editorial 

Editorial corrections based on sub-group review

3.1.3

3.2.3

New content

OOTS country code list

EEA country code list is renamed and extended to OOTS country code list

3.1.4
3.1.6
3.2.4
3.3.2
3.4
3.5
3.5.1
3.6.3

Correction

Removal of EB:ERR:0004 from EBErrorCodes

The error code "The jurisdiction level code query parameter is invalid or unknown" is not needed anymore as the query parameters for NUTS and LAU were removed from the specs. 

3.2.4

3.5.1

Chapter 4, Evidence Exchange

Changes to exchange of preview return location and use of HTTP methods:

• Return URL is exchanged in the second evidence request using a new slot "ReturnLocation", rather than encoded as an additional parameter to the preview location.  
• Preview method and return method are limited to GET method: removal of preview method Slot and return method parameter from Evidence Error Response. 

4.5.1.1

4.5.1.2.8

4.5.3.2.7

4.5.4.3.3

4.9

New Evidence Packaging Feature in Evidence Request and Evidence Response

The Evidence Packaging Feature enables the structured delivery of such compound Evidence while preserving explicit semantic relationships between the Main Evidence and its associated documents. This allows Evidence Providers to respond flexibly to explicit requests from Evidence Requesters and to accommodate cases where multiple artifacts are inherently needed to fully represent an Evidence instance. Documents related to the main Evidence which can be requested and provided are HumanReadableVersion, Translation and Annex. Typical examples include an educational diploma with a diploma supplement, a machine-readable XML Evidence with a human-readable PDF version, or an Evidence provided with translations into different languages.

To implement this, the profile adopts the rim:RegistryPackageType from ebXML RegRep Version 4.0 (ebRIM) as a structured container grouping all RegistryObjects of the same logical Evidence. The role of each document and its relationship to the Main Evidence are made explicit using standard classifications and associations. This approach relies solely on standard ebRIM constructs—rim:RegistryPackageType, rim:Classification, and rim:AssociationType

• New AssociatedDocumentRequest element to request specific supplementary documents HumanReadableVersion, Translation and Annex in the Evidence Request.
• New cardinality of DistributedAs (1..1 → 1..n) to request multiple distributions in the Evidence Request.

• New feature to group all documents related to a single Evidence instance within a rim:RegistryPackageType of the Evidence Response.

• Distinguish the Main Evidence from supplementary documents by explicit classifications.

• Describe semantic relationships between documents using standard associations.

• Describe the rules for Evidence Metadata applicable to Main Evidence and supplementary documents.

4.5.1 (1, 3.5)

4.5.2. (1, 2.1, 2.6, 3.3, 4)

Typo for name of Requirements slot

Fixed a wrong reference to a slot "Requirement" to "Requirements". 

4.5.1.3.1

Wrong datatype definition of slot "Procedure"

Changed datatype definition from multilingual string to string value type because codelist is used with multilingual version. 

4.5.1.2.4

Clarified cardinality of Requirement in Requirements slot

Explained the semantics and benefits to the user of including multiple requirements in a single evidence request.

4.5.1.3.1

New Language element in DistributedAs and removal of transformation

Removed lang element from QueryRequest header and introducing new Language element in DistributedAs class to support the request of specific language distributions that are defined in the DSD. Removal of transformation element. 

4.5.1 (2, 3.5)

Clarification of sdg:IsAbout in case of representation

If the user in the OOTS procedure is a user who authenticated as a person representing another person, the sdg:IsAbout MUST relate to the represented person.  

4.5.2

Introduce new optional support for eDelivery AS 2.0 and eDelivery SMP 2.1,

Enable a future transition towards the latest eDelivery AS4 version and introduction of optional support for eDelivery SMP 2.1.  Some  initial profiling for use in OOTS is provided.   

4.7

Removed requirement to re-use MIME content identifier in RegRep

The MIME content identifier of the MIME part containing the RegRep message in the XML content of that message is used in the PartInfo/@href attribute. The UUID does not have to be used in the RegRep payload. 

4.7.1

Introduced a new correlation identifier (ExchangeId) as eb:Property[@name="ExchangeId"] in the ebMS header.
Previously, message correlation relied solely on ConversationId, which was used for both user-session–level correlation and individual evidence exchanges.
The updated specification now distinguishes these two scopes:

• ConversationId is retained exclusively for correlating messages belonging to a user-related conversation or session.

• ExchangeId is newly defined to correlate all messages belonging to a single Evidence Request–Response exchange, including complex flows such as preview.

4.7

4.7.1 + 4.7.2

4.4

Introduced a new Specification identifier (SpecificationId) as eb:Property[@name="SpecificationId"] in the ebMS header.

The SpecificationId message property identifies the version of the TDD specification applicable to the message and MUST always correspond to the specification identifier of the main ebMS payload message, the ebXML RegRep document with MimeType property with application/x-ebrs+xml. The presence of the SpecificationId message property enables the receiving Access Point, in particular one supporting multiple TDD specification versions (e.g. 1.2 and 2.0), to determine the applicable processing logic, including schema selection, Schematron rule set, and content handling, before loading or parsing the XML payload.

4.7

4.7.1 + 4.7.2

Editorial

Values for DocumentID and ProcessID in SMP

The values for DocumentID and ProcessID in eDelivery SMP 2.1 document follow from the eDelivery SMP mapping and RegRep AS4 bindings, but for convenience we specify the values. 

4.7.3.2

Correction

Scope identifier for SMP authorization for evidence exchange

Change the value for authorization scope from "oots" to the more granular value "oots-query".

4.7.3.2

New content

Certificate profiles for SMP

Access Point SMP client certificate, OAuth token signing certificate profile, OAuth TLS server certificate profile, SMP response signing certificate profile provided.

4.7.3.2

Generalized security profiling and new certificate profiling

Created a new section 4.7.4 for eDelivery security profiling and moved the existing 4.7.4 into a new subsection 4.7.4.1 (network and transport layer security).  New separate subsection for OOTS use with eDelivery 1.16 (4.7.4.2)  and eDelivery 2.0 (4.7.4.3).  

4.7.4

Minimum eDelivery AS4 version for use with SMP

The new optional support for eDelivery SMP 2.1 requires support for discovery based on a known C3 in a four-corner topology. This was already enabled in eDelivery AS4 2.0. To allow this feature to be used with the previous version 1.x of eDelivery AS4, implementations must support version 1.16.  

4.7.4.1

Updated minimum key length 

The referenced eDelivery guidance on certificates has an outdated recommendation to use 2000 bits RSA public key length. (Applies to eDelivery AS4 1.15 and 1.16).

4.7.4.2

Certificate profiles for Access Points for use with eDelivery AS4 2.0

New XML signing, XML encryption and TLS server certificates profiles for use with eDelivery AS4 v2.0.

4.7.4.4

Correction of certificate profile 

Minor corrections to eDelivery certificate profile based on expert review.

4.7.4.3

OOTS country code list

EEA country code list is renamed and extended to OOTS country code list (see below)

4.5.1
4.5.2
4.5.3
4.5.4
4.7.1

Prepare for authentication using EUDI Wallet ​

Prepared OOTS for eIDAS 2.0 and EUDI Wallet authentication by introducing semantic mapping from the current eIDAS identity model to the Person Identification Data (PID) model defined in Regulation (EU) 2024/2977. The new rule set is activated via schemeID = "eidas2" and is available for testing only; production use is subject to confirmation of a suitable legal basis.

4.5.1

Updated OOTS-EDM XML Examples of the Evidence Exchange v2.0.0 

Integrated all changes related to TDD v2.0.0 into the Examples provided for the Evidence Exchange

4.5.4

Added hyperlink for eDelivery AS4 1.16

eDelivery OMB approved eDelivery AS4 1.16, so it can be referenced using its public links. 

4.7.7

Correct a bad step reference in the sequence diagram

A reference from one step in the procedure to another one in the sequence diagram was using the wrong step number. 

4.9

Updating XML examples of the Exchange Data Model

Added Evidence Packaging capabilities to Secondary Education XML request and response examples.

Adding/Removing features of TDD 2.0.

74f6519d

1f96a7ae

98894f45

0a442c22

Updated XSD with changes required for TDD version 2.0

Modified the sdg XSD by adding Evidence Packaging capabilities, modifying Distribution and Jurisdiction components and removing EvidenceProviderJurisdiction. 

• Added AssociatedDocumentRequest to DistributedAs.
• Modified Jurisdiction and linking it to EvidenceTypeList.
• Included MatchType and Description.
• Modified EvidenceType with Distribution.
• Inclusion of listID attribute to CodeType.
• Changed cardinality of DistributedAs. 
• Removal of EvidenceProviderJurisdictionDetermination.
• Included language element to DistributedAs.
• Removed transformation elements.
• Changed cardinality of Format.
• Made IsAbout, IssuingAuthority, IsConformantTo, IssuingDate optional.

86069c7c

c770eed3

7b4796bd

Modified Business Rules for the OOTS 

New Version of Business Rules has been provided for every transaction and every business rule sheet.

7b4796bd

a704addd

f6bf4a86

554fab8d

0aaa6e78

908c9d10

d5d83ba6

6a82c7b0

554fab8d

d61e7c0e

45e97d06

a8c4023c

0c9b453c

0a1e9c51

2127bc2c

c30fce1c

Added updates to EDM-ebMS schematron file concerning  eb:Property/@type, the new correlation identifier (ExchangeId) as eb:Property[@name="ExchangeId"] in the ebMS header and SpecificationId.

In EDM-REQ-C schematron file, the query:QueryRequest xml:lang attribute and Transformation were removed. The DistributedAs element became mandatory, and the 'AssociatedDocumentRequest' and 'Language' elements were added.

Also, some rules were removed in both schematron files.

In EDM-REQ-S the ReturnLocation was added as optional but mandatory if PreviewLocation is present. 

784240a5

cc6c819d

7b85540d

ed4cff51

eea9e88f

6e99516c

bc9fee89

e47bfe1d

New content Correction

Updated EDM-RESP-C and EDM-RESP-S schematron rules.

Added Document Packaging Structure and removed Transformation from In EDM-RESP-C and EDM-RESP-S.

f371d634

Updated XML examples by adding RegistryPackage capabilities and removed Transformation from Distribution.

f26f8c91

29d06a6a

d6e633e2

Created and updated EDM-RESP-C and EDM-RESP-S regression testing snippets according to the schematron updates.

369ff880

554a1686

Added rule for checking the 'sdg:Address' in EDM-ERR-C schematron

ea8b8714

Added and updated regression testing snippets for EDM-ERR-C

11bf80b7

JurisdictionContextId, Transformation, and JurisdictionLevel, AdminUnitLeve2 and 3, were eliminated from the DSD-RESP-C schematron.  Added rules for sdg:DistributedAs/sdg:Language and modified rule for rim:Slot[@name='SpecificationIdentifier'].

The rules for DistributedAs have been incorporated into DSD-RESP-S.

9ff8afb5

The full XML examples for DSD-RESP-C and DSD-RESP-S have been updated to align with the latest schematron updates.

42ac8457

The DSD-RESP-C and DSD-RESP-S regression testing snippets were created and updated in accordance with the schematron updates.

2cc7aea1

bfd7ab64

JurisdictionContextId, Transformation, and JurisdictionLevel, AdminUnitLeve2 and 3, were eliminated from the DSD-ERR-C schematron.

The UserRequestedClassificationConcepts element was added to DSD-ERR-S rules and  JurisdictionDetermination was removed.

cd89666a

DSD-ERR005 xml examples were updated.

26fe9d06

The DSD-ERR regression testing snippets have been updated.

7b69d439

Removed AdminUnitLevel2 and 3 from EvidenceType, added AdditionalJurisdictionClassification, added Jurisdiction sdg for EvidenceTypeList, added rules for ConformsTo, Format and MatchType in EB-EVI-C schematron.

Added rule on MatchType, Removed Language from StructuredEvidenceTypeDistribution in EB-EVI-S schematron.

a0b38358

d5aca55c

Updated full XML examples for EB-EVI, Get Evidence Types for Requirement Query.

578ccbb8

Created new and updated regression testing snippets for EB-EVI, Get Evidence Types for Requirement Query.

3bc65f9a

89af107d

Removed Transformation from LCM, DSD full examples

17ee30c4

278c0bbf

Removed: JurisdictionContextId, JurisdictionLevel, AdminUnitLeve2, and AdminUnitLevel3 from EB-REQ-C. Added rule for sdg:DistributedAs/sdg:Language  and  AdditionalJurisdictionClassification.

Updated error message for checking the presence of ReferenceFramework in EB-REQ-S.

41617036

Updated EB-REQ full xml examples.

503abea9

Updated and created new regression testing snippets for EB-REQ rules.

8f5dc56e

be82ee43

Updated the OOTS driver to sdg XSD version 2.0.0.

9c6c524b

d1f02f2c

Updated oots_driver_v2.0.0_local_imports.xsd, used by the regression testing system.

a34c9724

In LCM EB-SUB-C schematron file, the following elements have been removed: Transformation, JurisdictionContextId and JurisdictionLevel, AdminUnitLeve2 and 3. New rules have been added for MatchType, AdditionalJurisdictionClassification and ConformsTo.

In LCM EB-SUB-S rules, DistributedAs has been removed, and NoMatch and StructuredEvidenceTypeDistribution rules have been added.

d62b13ed

In LCM EB-SUB all full XML examples have been updated.

77ddffdf

Created new and updated regression testing snippets for LCM EB-SUB.

739a9154

Removed oots driver v1.2.0.nhb

99703673

Removed AdminLevel2 and 3 and Transformation from LCM Submit Objects

96ef9d6d

Updated in all updated schematrons file version number, version notes and oots:cs version to 2.0.0

5c4a24bc

763dcba6

bbe21bba

In LCM-SUB-S have been added new rules for DistributedAs, MatchType and StructuredEvidenceTypeDistribution. AdminUnitLevel2 and 3 and ClassificationConcept were removed. Classification Scheme attribute values have been updated.

4d63a0f8

Updated LCM XML examples and regression testing snippets.

65fff45b

53fca8d2

Removed the phased out Jurisdiction Determination xml examples.

10536897

Implemented fixes for some regression testing snippets in EDM, EB, DSD and LCM.

69372f77

The rim:Value of Procedure has been changed, a rule for ReturnLocation has been added, and PreviewMethod has been removed in EDM.

739c4256

Added ClassificationScheme in LCM EB-SUB rules and removed it from DSD.

6a453406

bcbdb361

8e9f8f73

Updated EB and DSD LCM examples and regression testing snippets.

b7d357c8

061eda56

87bcc217

574b7f0d

06a7c006

c4c6a46e

5df327c1

a87b844e

bae33cba

2bf50742

c294e7c4 

0a2cc606

ee41b4cc

84ca5618

New rule R-MS-CLASS-062 to check that a value for the name-Value column only uses Latin characters 

New rule R-MS-CLASS-063 to check that the language for agency long name is EN 

7ae934ee

ad099575 

New procedure codes V5, X7 and X9

Additional SDG Annex II procedure codes:

• V5: Acquiring and renewing a driving licence, added by Directive (EU) 2025/2205. 
• X7: Declarations by hosts for registration procedures in relation to short-term accommodation rental services, added by Regulation (EU) 2024/1028.  
• X9:   Registration as a repair service, seller of refurbished goods or purchaser of refurbished goods, added by Directive (EU) 2024/1799. 

b22d0c6b

Fixed issue rule R-EB-EVI-C015 in EB

259989c3

b88127fb

7d3194f3

New content

OOTS country code list

Generalized the EEA country code list to a new code list for (current and potential future) OOTS countries that includes EEA countries and the code "EU".  

fbdb3780

New content

Implemented 2.0.0 updates in crossvalidation:

• Added new  and updated rules for schematron files
• Updated xml examples
• Created new Regression Testing xml snippets.
• Updated crossvalidation Business Rules excel

2745a088

8b603298

90138963

09405170

a388d602

454b60ef

ddb74cca

New content

Added Gender and eidas2 rules for test in EDM-REQ. Added regression testing snippets

b84c80ef

Correction

Added AdminLevel2 for EDM-ERR

abc3cdf4

Correction

Added rule for checking presence of RegistryPackageType in EDM-RESP-S schematron

f43fc81d

Correction

Added rules for checking consistency of ConformsTo and Format in DSD vs EB for the same EvidenceTypeClassification

95fe3c37

Editorial

Regenerate automatically derived artefacts:

• Code list Genericode
• Filtered Schematrons and XSLT

e7e2ea35

618f930d

75e3c4be

New content

New procedure code AM1

Procedure code list for Directive 2005/36/EC on recognition of professional qualifications

• AM1: Recognition of professional qualifications, including vocational education and training

Regenerated GC and Schematron codelist includes

b3c0f36d

af1bd6a9

Correction

Change of XSD datatype for sdg:Gender

Minor structural and semantic differences between the eIDAS SAML Attribute Profile and eIDAS 2.0 Person Identification Data (PID) were resolved during semantic mapping. In particular, differing Gender/Sex representations were aligned by changing the XSD datatype of Gender from xs:choice to sdg:CodeType linking to a unified gender codelist supporting both eIDAS and eIDAS 2.0 values.

c975164c

Correction

Updates Business Rules

cfb7fdc9

Correction

Fixed the issue in testing snippets

df664481

Correction

Removal of EB:ERR:0004 from EBErrorCodes

The error code "The jurisdiction level code query parameter is invalid or unknown" is not needed anymore as the query parameters for NUTS and LAU were removed from the specs. 

Correction

Fixed error in EDM-REQ_EDM-RESP crossvalidation rule.

Correction

Renamed crossvalidation business rules file.

Editorial

Regenerated HTML business rules.

Correction

In EDM and DSD in some schematron files it were not implemented the rules for checking NUTS codes. The missing rules were implemented.

Correction

Updated rule R-ebMS-EDM-RESP-05 in crossvalidation for corner cases.

New content

Correction

Correction

Correction

Added missing business rules that were left out in DSD Error, EB Error, LCM ERR and LCM Success and removed  duplicate rules or rules that are proven by XSD

Made validation of URLs friendly to various environment of Semantic Repository

Updated business rules to consider multiple environments in URLs pointing to the semantic respository for Requirements, Evidence Type Classifications, MS-specific classification systems, ConformsTo statements and Transformations. In case of URLs that are not pointing to production, a Caution Error is created. 

Preventing use of URLs in codes of MS-specific classication systems

Provided another rule that provides a CAUTION error when creating MS-specific classification systems that plans to use URLs as codes. These URLs then MUST be used in string values and follow up query which provides a security risk in many systems and processing of these URLs cannot be guaranteed. It should be avoided whereever possible. 

Included notes in specifications and XML examples that Identifiers and schemeIDs of Publisher and AccessService are case-sensitive.

New content

Updated SR functionality for SR v1.6, adding new search parameter

3.3.3

Adjusted description on reverse routing in eDelivery configuration and ebMS Header implementation guideline.

Amended note on exceptions related to reverse routing in of the Evidence Error Response to make clearer that reverse routing may not be applied especially if the Evidence Error Response is created by an Intermediary Platform or Gateway. Made clear that for technial reasons and national routings, some Intermediate Platforms or Gateways do not align orginalSender data of the ebMS header with the Error Provider data of the Evidence Error Response Message.

Validation of lang attribute of Agent

Updated business rules to include validation rule language attributes for Agent/Name. The lang attribute was already specified in the corresponding specifications but it was never formally tested in the business rules.  

Made validation of URLs friendly to various environment of Semantic Repository

Updated business to consider multiple environments in URLs pointing to the semantic respository for Requirements, Evidence Type Classifications, MS-specific classification systems, ConformsTo statements and Transformations. In case of URLs that are not pointing to production, a Caution Error is created. 

Remove duplicate rules or rules that are already proven by XSD

Included notes in specifications and XML examples that Identifiers and schemeIDs of Publisher and AccessService are case-sensitive.

Included additional notes that the Evidence Provider may only be technical responsible for providing the Evidence to the Evidence Requester. In this cases, the Issuing Authority of the Evidence Metadata shall be used to indicate the actual issuer of the Evidence. 

0eeb5d0a

42c969f5

f0e8a186

Developed a python script to compare Business Rules numbers from excel with business rules numbers implemented in schematron to check discrepancies.

Updated BR excel with findings from comparison excel and schematrons

Fix rules IDs in MS-CLASS wrongly named. For example  R-MS-CLASS-C001 instead of R-MS-CLASS-001.

Fixed inconsistencies in schematron files discovered after running the comparison excel-schematron script.

25530eff

8a58740e

7b03cba4

aac2781a

Modify Reverse Routing logic for Evidence Error Response in Cross Message Validation

Updated Cross Validation Rules to modify logic for reverse routing. In the Evidence Error Response reverse routing is not be applied in all cases. Thus, also in ebMS header it may not be applied or it may differ from values used Evidence Error Response. Rules provide CAUTION errors instead of FATAL errors in these cases. 

Corrected wrong association of descriptions to rules in Cross Message Validation

The association of description to rules where mixed up in relation to "From/To" and "finalRecipient/originalSender" in Business rules and corresponding schematron for ebMS-ERR_ebMS-REQ2.sch. All description had to be flipped.

Validation of lang attribute of Agent

Updated schematron rules to include validation rule language attributes for Agent/Name. The lang attribute was already specified in the corresponding specifications but it was never formally tested in the business rules.  

 57deeb13

73e73d83

f6f9e5c2

7f121bcd

5d2eb116 

82185521

caa863a5

db054435

2b1d50e2

f0156c91

db054435

3cc95aa3

e1d81050

a049e699

Regenerated derived formats for business rules and Schematron

Generated the filtered Schematron rules, XSLTs , XSLTs for cross-validation and HTML for business rules.

9f16507a

ca849267

Updated README.md for Schematrons with correct version numbers

02132fe1

Removed an obsolete warning on generated XSLT 

3310c663

Included Note on Recommendations and Constraints for Cross-Message Validation Rules

Clarified that cross-message validation rules are primarily for design-time use and should not block runtime processing. Recommended using the latest rule versions regardless of TDD version and ensuring validation results in logs only to avoid unnecessary transaction failures.

A.1 Cross-Message Validation Framework

Clarification on use of network security rules for eDelivery 

Clarified that the guidance on network security rules applies to situations where network security rules are used (they are not mandatory) and that it applies to inbound and outbound connections.

Added '00' as valid procedure code for production tests in relevant schematrons rules (R-EB-EVI-C012, R-EB-REQ-C012, R-EB-SUB-C023, R-EDM-REQ-C003, R-EDM-REQ-C081)

a6c85183

Aligned Schematron (R-EDM-ERR-C011) with Business Rules and Specifications to allow more than one Exception in Evidence Error Response

0ba48032

4655dcab

Cleanup of snippets for regression testing of Schematrons for MS-specific classification scheme 

dcf6a80d

Alignment of description of schematron rule (R-EDM-REQ-C055, R-EDM-ebMS-006, R-EDM-ebMS-021) with description of business rules

9f920713

Chapter 2

Chapter 3

Added additional notes about dependencies between the EvidenceType of the EB and DataServiceEvidenceType of the DSD

The DataServiceEvidenceType  of the DSD is linked to the EvidenceType  of the EB. An EvidenceType must exist in the EB, before it can be referred in the DSD by the DataServiceEvidenceType. The DataServiceEvidenceType uses a similar EvidenceTypeClassification, Title  and Description . The EvidenceTypeClassification  is used to identify the EvidenceType. If Title or Description will be updated for an existing DataServiceEvidenceType through an DSD LCM SubmitObjectsRequest, the corresponding EvidenceType in the EB will be updated too. This will happen automatically if the Member States uses the Common Services provided by the European Commission. The following requirements should be taken into account:

• The internal systems operated by the Member States to populate the Common Services shall take note of this dependency.
• Consistency must be ensured. Thus, for every DataServiceEvidenceType a corresponding EvidenceType must exist. This applies for combined LCM too (see section 3.6.3 and subsection 3.5) .
• If Member States operate their own instance, or distributed instances it must ensure similar behavior (see section 3.4).  

3.1.6.3.1

3.2.5.2.1

Requirement to change conformance prefix when using mixed versions CS 1.2 and EDM 1.0

When using a DSD 1.2 response using a ConformsTo element with content having prefix https://sr.oots.tech.ec.europa.eu/datamodels/ should be modified to create an EDM 1.0 request,  the value should be modified to use the [https://sr.oots.tech.ec.europa.eu/distributions/ prefix instead.  

Improving the definition of Access Service.

The current definition lead to misunderstandings. The Access Service is linked to a single EvidenceProvider and enables to express which distributions of an Evidence Type can be delivered by the Evidence Provider and in which version, an Evidence Exchange can be carried out.

Clarify case sensitivity of party identifier and scheme/type

Party identifiers and identifier types (or schemes) MUST be processed as case sensitive.

Commission services secured using TLS follow the IT technical standard Transport Layer Security (TLS) 

New content

Included a Description for the Requirement element. 

An optional multilingual Description was included to the Requirement information entity of the EB Query Response and LCM specification of the EB to provide further details about the requirement. The element uses the language codelist to classify the language of the description. Corresponding models guidelines, XML examples and business rules were adjusted. 

3.2.4

3.2.5

New content

Change of cardinality for AccessService from 1..n to 1..1

The cardinality of AccessService changed from 1..n to 1..1, which is backward compatible but affects the structure of DSD query responses. Each EvidenceProvider will now return a RegistryObject with the root element rim:slot"DataServiceEvidenceType", whereas previously, multiple providers could be grouped under it. Models, XML examples, and business rules were updated accordingly.

3.1.4

New content

Revision of chapter 3.1.3. with new model for Evidence Provider Classification

• Detailed description of the Evidence Provider Classification Concepts
• Replacing mostly all XML examples
• Illustrating three different methods for Evidence Provider Discovery using Evidence Provider Classification

3.1.3

New content

Revision of chapter 3.1.4 with new model for Evidence Provider Classification

• Restructuring of query description and removing query parameter "evidence-type-id"
• Removal of "ClassificationConcept" from Publisher
• New Rule for sdg:DataServiceEvidenceType/sdg:Identifier: Every registry object must have a unique identifier
• Removal of sdg:DataServiceEvidenceType/sdg:Identifier from DSD:ERR:005
• Assigning SupportedValue to EvidenceProviderClassification and removal of "DateValue" from SupportedValue
• Replacing mostly all XML examples
• Separating XML examples into A) EvidenceProviderClassification and B) EvidenceProviderJurisdictionInformation
• Updating Business Rules and Implementation Guideline for EvidenceProviderClassification and SupportedValue and removed ClassificationConcept
• Included new XML example illustrating MS-specific classification scheme in section 4.4.3.3
• Restructured section 4.8 A DSD Interaction Example Flow

3.1.4

New content

Revised set of Business Rules for EB and DSD

3.1.7 

3.2.6

3.6.3

New content

Added new specification for the creation of MS-specific classification schemes in section 2.

3.5

New content

New DSD LCM data model including new RegistryObject "ClassificationScheme" to be used for MS-specific classification schemes. 

• Inclusion of RegistryObject "ClassificationScheme" in section 6.3.4 and 6.5
• Removal of "ClassificationConcept" from Publisher
• Assigning SupportedValue to EvidenceProviderClassification and removal of "DateValue" from SupportedValue
• Replacing mostly all XML examples 
• Updating Business Rules and Implementation Guideline for EvidenceProviderClassification, SupportedValue and removed "ClassificationConcept"

3.1.6

Editorial

New long name of NUTS codelist indicating that its a EEA subset only.  Change of NUTS codelist version from 1.0.0 to 1.0.1

3.5

New content

Removed AdminUnitLevel2 and AdminUnitLevel3 to from /sdg:EvidenceType/sdg:Jurisdiction in EB EvidenceTypes for Requirement Query. 

The unused feature was unclear and conflicted with Evidence Provider Discovery in DSD. Now, MS must define an abstract, country-specific Evidence Type in the EB and query it across different Evidence Providers in the DSD. Regional and local Evidence Types can also be defined in the EB and linked to relevant providers in the DSD.

Note: The query parameter was only removed in the 4.3. Get Evidence Types for Requirement Query for EvidenceType. The Jurisdiction parameters in the 4.2. Get List of Requirements Query for ReferenceFramework remain unchanged

3.2.4

3.2.5

Editorial

Removed some text from a previous version relating to optional parameters removed in this version.

3.2.4.7.2

New Content

Updated SR functionality for SR v1.5, including new XSD link for metadata model, updated response examples and new search parameters

3.3.3

New Content

Updated the description of Codelist assets included in the Semantic Repository to make explicit that these can also include MS-specific ones. 

3.3.4

New content

Updated the Semantic Repository metadata model for the SR 1.5 release to include the representation of the country in which an asset is issued along with the revision of certain typing and cardinality constraints.

3.3.5

New content

Updated information about the SpecificationIdentifier from oots-cs:v1.1 to oots-cs:v1.2 in all DSD and EB components and XML examples

3.1.1

3.2.1

3.6

Editorial

HTTP headers are case-insensitive

Headers like "Accept-version" or "Accept-Version" that only differ in use of lower/upper case are notational variants as in HTTP headers are case-insensitive.

3.6.2

Chapter 4

Refined classification of complex evidence exchange flows  and use of correlation identifiers including  ConversationId 

Clarified the types of complex flows in evidence exchange and how the related messages can be correlated using identifiers in the OOTS payloads and eDelivery message header. At a minimum, implementations must provide base functionality that covers only the evidence request and response messages, so up to four message in case of exchanges using preview. Optional but recommended extended functionality adds reuse of the identifier for retrieving multiple pieces of evidence of different types or from different providers, or even for late response.     

4.4

4.7

Corrected a cross-reference to a step in the sequence diagram

There was a reference to procedure step that had not been updated after an update to the diagram.  

Described Timeouts for Evidence Requester (ER) and the Evidence Provider (EP) participating in an Evidence Exchange under the Once-Only Principle (OOP) system.

New content

Included a Description for the  Requirement element. 

An optional multilingual Description was included to the Requirement information entity of the Evidence Request to provide further details about the requirement. The element uses the language codelist to classify the language of the description. Corresponding models guidelines, XML examples and business rules were adjusted. 

Editorial

Rephrased the definition of false for PossibilityToPreview to: "there is no requirement to give the user the option to preview the provided evidence"

Editorial

Clarified that the xml:lang attribute on QueryRequest relates to the requested evidence(s).  

Correction

Presence of ResponseAvailableDateTime slot

The slot ResponseAvailableDateTime MUST be present if and only if the status of the QueryReponse is set to urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Unavailable

Correction

Cardinality of RegistryObjectList

The TDDs never assumed more than 1 RegistryObjectList could be present in a QueryResponse, but the class diagram and content table suggested a possible cardinality 0..n for RegistryObjectList in QueryResponse.  In the RegRep XSD it is constrained to be 0..1.  

Editorial

Clarify case sensitivity of party identifier and scheme/type

Party identifiers and identifier types (or schemes) MUST be processed as case sensitive.

4.5.1

4.5.2

Editorial

Updated reference to eDelivery guidance on certificates

New content

Party identifiers and identifier types (or schemes) MUST be processed as case sensitive.

Correction

Wrong MIME type in example

The example response included two evidences. The first had a ConformsTo and Transformation but its MIME type was set to application/pdf. Corrected to application/xml and removed the second evidence. Also aligned the two evidence requests.

New content

Info on potential future deprecation of HTTP methods other than GET in preview and return URLs

Added a note that methods other than GET may be removed in future versions of OOTS, reflecting the fact that current implementations use GET. Would also remove the need for the PreviewMethod slot.

New content

Updating Business Rules and Implementation Guideline for EvidenceProviderClassification and SupportedValue

New content

Updating XML Examples related to EvidenceProviderClassification and SupportedValue

New content

Revised set of Business Rules for Evidence Exchange

New content

Updated information about the SpecificationIdentifier from oots-edm:v1.1 to oots-edm:v1.2 in all EvidenceExchange components and XML examples

4.5

Related Artifacts

Moved the WS-Addressing XSD to its own folder, 

It was in the XML folder,  but is not really a core XML XSD.

XSD change cardinality of ConformsTo and AccessService in DataServiceEvidenceType

ConformsTo:  1..n (instead of 1..1) to align the XSD with the specification. Additionally Access Service was modified to  1..1 (instead of 1..n).  The restriction is backwards compatible but it results in a different structure of the result set of DSD query responses. For each EvidenceProvider, the DSD query response will return with a RegistryObject with the root element rim:slot"DataServiceEvidenceType".  Previously it was possible to group EvidenceProviders below the DataServiceEvidenceType. Corresponding models XSD and XML examples and regression tests were adjusted. 

3bc83020

758a85f0

3e6a235e

XSD change: Added Description to Requirement

As in other elements, 0..n Description elements can be added within the EB query response, the EB LCM submission and the Evidence Request. The element uses the language codelist to classify the language of the description. Corresponding models business rules, Schematrons, XML examples were adjusted. .  

6a0e76ea

999f8f59

Facilitate use of cross-validation rules involving ebMS header

Changed the rules referencing the eb:Messaging header to not require the header to be the root element. This allows use in situations where a user of the test platform adds a complete SOAP envelope. 

Better compatibility support for "datamodels" and "distributions" when using CS 1.0​

To handle potential cases where  an existing ER implementation uses CS 1.0 also allow "distributions" in SR URIs instead of just "datamodels" in R-EDM-REQ-C.

Add missing invalid snippet for rule R-EDM-ERR-S030.

Remove XML examples that are not used by the Regression Testing. In the initial version of Regression Testing we used duplicates of full XML examples. But because it proved to be difficult to maintain in sync same file in two places, we chose to update only the XML examples in the tdd_chapters/OOTS-EDM/xml/Request-Response Samples folder. Thus, the copies of full XML examples were not used any more but still present in the Regression Testing. These were removed.

Cross-validation improvement for cases involving multiple agents

Fixed Cross-Validation issues that occur when the Error Provider (Original Sender) differs from the Evidence Provider (Final Recipient of the 2nd Evidence Request). Rule relaxation implemented and the following rules are now WARNINGS not FATAL to accommodate distinct agents for Error and Evidence Providers:​ R-ebMS-ERR_ebMS-REQ2-07​ R-ebMS-ERR_ebMS-REQ2-08.

Some regression testing snippets are missing for EDM-REQ1_EDM-REQ2. As many tests are repetitive, a test for each context type is sufficient. Some rules which are present in the Schematrons but missing from the Cross Validation BR were added to the excel file.

XSLTs for cross-validation

As per single-message validation, we now also provide compiled XSLTs for the Schematron files. 

Fixed inconsistency in Secondary Education XML full example Step 3 for Agent/Identifier value.

Updated Regression Tests and Business Rules with new Description element for Requirement and update also BR excel

cc6f7a1f

9fd0b5f2

Presence of ResponseAvailableDateTime slot

The slot ResponseAvailableDateTime MUST be present if and only if the status of the QueryReponse is set to urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Unavailable

08edd6c0

bd32f95e

DSD content rules support future EDM versions

Instead of checking for EDM specific versions like oots-edm:v1.0 and oots-edm:v1.0, the rules check that the value matches oots-edm:v<MAJOR>.<MINOR>  to  support future EDM versions.  

b7fd9226

6698d168

Added support for EUDI Wallet services

In DSD-RESP-C allow support for two EUDI services, complementing the regular "oots-edm"

a96d2433

Specification identifiers updated for version 1.2 of oots-cs and oots-edm

Updates in XML, SCH, and XSL.    

4b47ff30

2cd43e91

4f1b40e3

Updated Regression Testing configuration files to use  oots-cs:v1.2 and oots_driver_v1.2.0.xsd instead of v1.1

Updated Regression Testing examples to ensure consistency with business rules and Schematron updates.

16016e96

3645db96

Fixed Schematron rules not checking properly if LocatorDesignator has the minimum length 1 in EDM, EB and DSD. 

08836858

Removed snippets not used due to removal of some business rules in DSD.

27b4e86c

New cross-validation rule R-EDM-REQ_EDM-RESP-18

If evidence is requested in a specific language, and language is specified for the evidence, the requested language must be (one of) the specified language(s) 

db0e33d8

Correction in example

Correction of the source for the example in section 4.5.4.3.4 of the specification

b01ea83c

e9854601

Regenerated XSD documentation, filtered Schematrons and XSLTs.

31043d35

8f813d2b

b11c7e65

Developed the Schematron rules set that validates the structure of a Genericode file used to describe MS-specific classification schemes.

08c1220b

Corrected XML examples Genericode files used to describe MS-specific classification schemes.

68640229

New Version of Business Rules - OOTS Transaction TDDv120 March 2025.xlsx

3304f88c

3da5eff9

c9c9dfdb

269dbbfd

2ffbd813

47717f93

97f92240

3db0bf8e

3063ee9e

74cb3405

a0b869f5

25f74f87

97a19242

defa395b

6ba35b12

05c3216d

Revision of all XML Examples related to Evidence Provider Classification and restructuring of directory. Changes were carried out in the following sections

• Complete XML examples DSD
• Snippets - 3.1.1 Data Service Directory
• 3.1.6 LCM Interface Specification of the DSD - Refactored
• 3.5 The RegRep LCM Submit Objects
• Snippets - 3.4 Evidence Provider Classification slot and example
• Updating all XML Request-Response Samples that contained Evidence Provider Classification
• Putting EMREX and EvidendeProviderJurisdictionDetermination Examples into subdirectories

1c8c1ff3

0df4bff8

7e4c02de

3da5eff9

47717f93

2e2a9866

af2e7908

New section and new XML examples related to MS-specific classification schemes in XML directory

9743a149

7e4c02de

b8e0f9cd

47717f93

9f76e06f

919a90b8

e0927e16

dd4a65b4

25f74f87

74cb3405

97a19242

New repository for MS-specifc classification schemes that are submitted by MS to the CS. These will be stored outside the tdd_chapters in the following repository.

https://code.europa.eu/oots/tdd/ms_assets

Removed AdminUnitLevel 2 and AdminUnitLevel 3 from EvidenceType in EB XML examples and updated BR rules sheet 

477d494a

Changed XSD to make DataServiceEvidenceType (DSET) Identifier optional and included BRs to prove cardinality in different transactions. 

The change was necessary as in the current design in DSD:ERR:005 the different DSET linking to the same EvidenceTypeClassification are merged without the individual DSET Identifiers.

47717f93

Correction of XML examples that where missing AdminLevelUnit2 values where AdminLevelUnit3 values were present

0a793fa4

Included a copy of the OASIS Genericode XSD.

Genericode is used as basis for MS-specific classification schemes and other codelists.

97a19242

Implemented new Schematron rules for Evidence Provider Classification in EDM, DSD and LCM.

ed3ad488

0bd831c0

Developed Regression Testing examples and snippets for MS-specific classification schemes (MS-CLASS.sch).

807c71d6

Updated Schematron Rules for EvidenceProviderClassification, SupportedValue and removed "ClassificationConcept"

878a954f

Implemented Regression Testing updates for Evidence Provider Classification in EDM, DSD and LCM

22f0bc17

6531ae3a

675bdf62

1054b0b5

27471f3b

7dc50fe9

Removed AdminUnitLevel 2 and 3 from Evidence Type in EB and updated examples and Regression Testing snippets.

060cdd5c

76142a92

Updated DSD XML examples according to recent BR updates.

a962c94c

Removed from Regression Testing JSON file the DSD baseline examples.

515df4e0

Removed ClassificationConcept from LCM DSD bulk submission XML example.

73cc5a2d

Removed duplicate rules in DSD-SUB_RF-C as these were present also in MS-CLASS.

2b21552f

AuthorizedRepresentativeLegalPerson was missing in a list of allowed slots in query:Query in a rule in EDM-REQ-S.

fd9f9cc4

Minor fixes to MS-CLASS xml examples. 

3b2a8409

784f73f8

Fixed issue related to presence of schemeID in EvidenceProviderClassification Identifier.

73ce68a7

Fixed issue in Regression Testing config file.

03e08ae0

Fixed ConformsTo in MS-CLASS schematron to point to production environment instead of acceptance.

9f392c8f

506a99d5

70e891bb

1

Once-Only Technical System High Level Architecture

-

1.0.0

 1.2.0

2.0.0

2.0.0

Wiki

HLA

Architecture

HLA

Mandatory

2.0.1

July 2026

2.1

Identity and Record Matching

-

1.0.0

 1.2.0

 1.2.0

2.0.1

Wiki

eID

Specification

eID

Mandatory

2.0.1

July 2026

2.2

OOTS eID additional security services

-

1.0.0

1.0.1 

1.0.1 

1.0.1 

Wiki

eID

Specification

eID

Mandatory

2.0.1

July 2026

2.3

Representation

-

1.0.0

 1.1.0

 1.1.0

 2.0.1

Wiki

eID

Specification

eID

Mandatory

2.0.1

July 2026

3.1.1.-3.1.4

Data Service Directory

-

1.0.0

 1.2.0

 2.0.0

 2.0.0

Wiki

DSD

Specification

DSD

Mandatory

2.0.1

July 2026

3.1.4

Query Interface Specification of the DSD

4.2. Query: Find Data Services of Evidence Providers for a specific Evidence Type Classification

1.0.0

 1.2.2

2.0.0

2.0.0

Wiki (Subsec.)

DSD

Specification

DSD

Mandatory

2.0.1

July 2026

3.1.4

Query Interface Specification of the DSD

4.3. Query Response of the DSD

1.0.0

 1.2.2

2.0.0

2.0.0

Wiki (Subsec.)

DSD

Specification

DSD-RESP

Mandatory

2.0.1

July 2026

3.1.4

Query Interface Specification of the DSD

4.4 Query Error Response of the DSD

1.0.0

 1.2.2

2.0.0

2.0.0

Wiki (Subsec.)

DSD

Specification

DSD-ERR

Mandatory

2.0.1

July 2026

3.1.6

LCM Interface Specification of the DSD - Refactored

-

1.0.0

 1.2.2

2.0.0

2.0.0

Wiki

DSD

Specification

DSD-SUB

Mandatory

2.0.1

July 2026

3.1.7

Business Rules (DSD)

1. DSD-RESP-C

1.0.2

1.2.2 

 2.0.0

 2.0.1

Git

DSD

Schematron (Business Rule)

DSD-RESP

Mandatory

2.0.1

July 2026

3.1.7

Business Rules (DSD)

2. DSD-RESP-S

1.0.2

 1.2.0

2.0.0

2.0.0

Git

DSD

Schematron (Business Rule)

DSD-RESP

Mandatory

2.0.1

July 2026

3.1.7

Business Rules (DSD)

3. DSD-ERR-C

1.0.0

 1.2.3

2.0.0

2.0.0

Git

DSD

Schematron (Business Rule)

DSD-ERR

Mandatory

2.0.1

July 2026

3.1.7

Business Rules (DSD)

4. DSD-ERR-S

1.0.3

 1.2.0

2.0.0

2.0.0

Git

DSD

Schematron (Business Rule)

DSD-ERR

Mandatory

2.0.1

July 2026

3.1.7

Business Rules (DSD)

7. DSD-SUB_RF-C

1.0.1

 1.2.3

2.0.0

2.0.1

Git

DSD

Schematron (Business Rule)

DSD-SUB_RF

Mandatory

2.0.1

July 2026

3.1.7

Business Rules (DSD)

8. DSD-SUB_RF-S

1.0.3

 1.2.3

2.0.0

2.0.0

Git

DSD

Schematron (Business Rule)

DSD-SUB_RF

Mandatory

2.0.1

July 2026

3.2.1-3.2.4

Evidence Broker (EB)

-

1.0.0

 1.2.0

2.0.0

2.0.0

Wiki

EB

Specification

EB

Mandatory

2.0.1

July 2026

3.2.4

Query Interface Specification of the EB

4.2. Get List of Requirements Query

1.0.1

 1.2.0

2.0.0

2.0.0

Wiki (Subsec.)

EB

Specification

EB-REQ

Mandatory

2.0.1

July 2026

3.2.4

Query Interface Specification of the EB

4.3. Get Evidence Types for Requirement Query

1.0.0

 1.2.0

2.0.0

2.0.0

Wiki (Subsec.)

EB

Specification

EB-EVI

Mandatory

2.0.1

July 2026

3.2.4

Query Interface Specification of the EB

4.4. Query Error Response of the Evidence Broker

1.0.0

1.2.0 

 2.0.0

 2.0.0

Wiki (Subsec.)

EB

Specification

EB-ERR

Mandatory

2.0.1

July 2026

3.2.5

LCM Interface Specification of the EB

-

1.0.0

 1.2.0

2.0.0

2.0.0

Wiki

EB

Specification

EB-SUB

Mandatory

2.0.1

July 2026

3.2.6

Business Rules (EB)

1. EB-EVI-C

1.0.0

 1.2.2

2.0.0

2.0.0

Git

EB

Schematron (Business Rule)

EB-EVI

Mandatory

2.0.1

July 2026

3.2.6

Business Rules (EB)

2. EB-EVI-S

1.0.3

 1.2.0

2.0.0

2.0.0

Git

EB

Schematron (Business Rule)

EB-EVI

Mandatory

2.0.1

July 2026

3.2.6

Business Rules (EB)

3. EB-REQ-C

1.0.0

 1.2.2

2.0.0

2.0.0

Git

EB

Schematron (Business Rule)

EB-REQ

Mandatory

2.0.1

July 2026

3.2.6

Business Rules (EB)

4. EB-REQ-S

1.0.3

 1.2.0

2.0.0

2.0.0

Git

EB

Schematron (Business Rule)

EB-REQ

Mandatory

2.0.1

July 2026

3.2.6

Business Rules (EB)

5. EB-ERR

1.0.0

1.2.2

 2.0.0

 2.0.0

Git

EB

Schematron (Business Rule)

EB-ERR

Mandatory

2.0.1

July 2026

3.2.6

Business Rules (EB)

6. EB-SUB-C

1.0.0

1.2.2 

 2.0.0

 2.0.0

Git

EB

Schematron (Business Rule)

EB-SUB

Mandatory

2.0.1

July 2026

3.2.6

Business Rules (EB)

7. EB-SUB-S

1.0.3

1.2.2

 2.0.0

 2.0.0

Git

EB

Schematron (Business Rule)

EB-SUB

Mandatory

2.0.1

July 2026

3.3.1

Semantic Repository (SR)

-

1.2.0

 1.6.0

 2.0.0

 2.0.0

Wiki

SR

Specification

SR

Mandatory

2.0.1

July 2026

3.4

Common Services Distribution

-

1.0.0

1.0.1 

 1.0.1

 1.0.1

Wiki

CS

Specification

CS-Distribution

Mandatory

2.0.1

July 2026

3.5 (section 1)

Code Lists

LanguageCode

2020-04-17

 1.0.0

 1.0.0

 1.0.0

Git

Codelist

Internal Codelist

-

Mandatory

2.0.1

July 2026

3.5 (section 1)

Code Lists

EAS

2023-11-15

15.0 

 15.0

 15.0

Git

Codelist

External Codelist

-

Mandatory

2.0.1

July 2026

3.5 (section 1)

Code Lists

Nuts

2023-11

2024

 2024

 2024

Git

Codelist

External Codelist

-

Mandatory

2.0.1

July 2026

3.5 (section 1)

Code Lists

CountryIdentificationCode

2023-11

 1.0.0

 1.0.0

 1.0.0

Git

Codelist

Internal Codelist

-

Mandatory

2.0.1

July 2026

3.5 (section 1)

Code Lists

EEA_Country

2023-11

 1.0.1

Replaced by new OOTS_Country Code List

Replaced by new OOTS_Country Code List

Git

Codelist

Internal Codelist

-

2.0.1

3.5 (section 1)

Code Lists

Procedures

2024-02

 2.0.0

 2.0.0

 2.0.1

Git

Codelist

Internal Codelist

-

Mandatory

2.0.1

July 2026

3.5 (section 1)

Code Lists

AgentClassification

2024-02

 1.0.0

 1.0.0

 1.0.0

Git

Codelist

Internal Codelist

-

Mandatory

2.0.1

July 2026

3.5 (section 1)

Code Lists

OOTSMediaTypes

2023-11

 1.0.0

 1.0.0

 1.0.0

Git

Codelist

Internal Codelist

-

Mandatory

2.0.1

July 2026

3.5 (section 1)

Code Lists

LoA

2023-11

 1.0.0

 1.0.0

 1.0.0

Git

Codelist

Internal Codelist

-

Mandatory

2.0.1

July 2026

3.5 (section 1)

Code Lists

IdentifierSchemes

2023-11

 1.0.0

 1.0.0

 1.0.0

Git

Codelist

Internal Codelist

-

Mandatory

2.0.1

July 2026

3.5 (section 1)

Code Lists

JurisdictionLevel

2023-11

 1.0.0

Discontinoued

Discontinoued

Git

Codelist

Internal Codelist

-

2.0.1

3.5 (section 1)

Code Lists

DSDErrorCodes

2023-11

 1.0.0

 1.0.0

 1.0.0

Git

Codelist

Internal Codelist

-

Mandatory

2.0.1

July 2026

3.5 (section 1)

Code Lists

ErrorSeverity

2023-11

 1.0.0

 1.0.0

 1.0.0

Git

Codelist

Internal Codelist

-

Mandatory

2.0.1

July 2026

3.5 (section 1)

Code Lists

EDMErrorCodes

2023-11

 1.0.0

 1.0.0

 1.0.0

Git

Codelist

Internal Codelist

-

Mandatory

2.0.1

July 2026

3.5 (section 1)

Code Lists

EBErrorCodes

2023-11

 1.0.0

 2.0.0

 2.0.0

Git

Codelist

Internal Codelist

-

Mandatory

2.0.1

July 2026

3.5 (section 1)

Code Lists

LCMErrorResponseCodes

2023-11

 1.0.0

 1.0.0

 1.0.0

Git

Codelist

Internal Codelist

-

Mandatory

2.0.1

July 2026

3.5 (section 1)

Code Lists

LAU

2023-11

 1.0.0

Discontinoued

Discontinoued

Git

Codelist

Internal Codelist

-

2.0.1

3.5 (section 1)

Code Lists

SRSearchErrorCodes

1.0.0

 1.0.1

 1.0.1

 1.0.1

Git

Codelist

Internal Codelist

-

Mandatory

2.0.1

July 2026

3.5 (section 1)

Code Lists

UIDSuppressionCountry

-

1.2.3

1.2.3

1.2.3

Git

Codelist

Internal Codelist

-

Optional

2.0.1

July 2026

3.5 (section 1)

Code Lists

Gender

-

-

1.0.0

1.0.0

Git

Codelist

Internal Codelist

-

Mandatory

2.0.1

July 2026

3.5 (section 1)

Code Lists

OOTS_Country

-

1.0.0

1.0.0

Git

Codelist

Internal Codelist

-

Mandatory

2.0.1

July 2026

3.5 (section 2)

Code Lists

MS-specific classification schemes

-

1.2.2

2.0.0

2.0.0

Wiki

Codelist

Specification

 -

Mandatory

2.0.1

July 2026

3.5 (section 3)

 Code Lists

LCM Interface Specification for Member State-specific Classification Schemes 

-

-

2.0.0

2.0.0

Wiki

Codelist

Specification

-

Mandatory

2.0.1

July 2026

3.6

Common Services API Specification

2. Query Interface Specification

1.0.0

1.2.0

 2.0.0

 2.0.0

Wiki (Subsec.)

CS

Specification

CS-API

Mandatory

2.0.1

July 2026

3.6

Common Services API Specification

3. The Lifecycle Management Specification

1.0.1

1.2.2

 2.0.0

 2.0.0

Wiki (Subsec.)

CS

Specification

CS-LCM

Mandatory

2.0.1

July 2026

3.6

Common Services API Specification

3.6 eDelivery Configuration (LCM)

1.0.0

1.0.0 

 2.0.0

 2.0.0

Wiki (Subsec.)

CS

Specification

CS-eDelivery

Mandatory

2.0.1

July 2026

3.6

.. / 3.7. Business Rules of the Regrep LCM

1. LCM-ERR

1.0.1

 1.2.2

2.0.0

2.0.0

Git

CS

Schematron (Business Rule)

LCM-ERR

Mandatory

2.0.1

July 2026

3.6

.. / 3.7. Business Rules of the Regrep LCM

2. LCM-SUC

1.0.0

1.2.2 

 2.0.0

 2.0.0

Git

CS

Schematron (Business Rule)

LCM-SUC

Mandatory

2.0.1

July 2026

3.6

.. / 3.7. Business Rules of the Regrep LCM

3. LCM-SUB-S

1.0.1