IMMC v3 Communication protocol specifications

Transcription

1 Directorate A Core Business Services A.1 Enterprise Architecture, Methods and Formats Formats, Computer Linguistics and Metadata IMMC v3 Communication protocol specifications 8 April 2016

2 DOCUMENT HISTORY Version Release Date Author Description Maria Kardami Creation Maria Kardami Update Maria Kardami Update Maria Kardami Update Maria Kardami Release of draft version for validation Maria Kardami Integration of OP Units comments Maria Kardami Integration of A2 comments Maria Kardami Updated the documentation of the element cmt:environment Release of version P a g e

3 Contents Contents... 3 Definitions, Abbreviations and Acronyms Introduction Purpose of the Document Scope IMMC v3 communication protocol overview IMMC package naming conventions IMMC request types IMMC notifications The <cmt:receipt> element Technical validation Successful notifications (Technical ACK) Rejection notifications (Technical NACK) Business validation Successful notifications (Business validation ACK) Rejection notifications (Business validation NACK) Processing Status notification (response) P a g e

4 Definitions, Abbreviations and Acronyms ABBREVIATIONS AND ACRONYMS Abbreviation AT FRBR FTP OP XML LA LSEU PCS Meaning Authority Table produced by the Publications Office Metadata Registry team Functional Requirements for Bibliographic Records File Transfer Protocol Publications Office EXtensible Markup Language Legal Analysis Summaries of EU legislation Production Control System DEFINITIONS Definition IMMC IMMC data channel IMMC package IMMC transmission IMMC Transmission identifier id) Technical validation Business validation Meaning The Interinstitutional Metadata Maintenance Committee (IMMC) is responsible for the harmonisation and standardisation of metadata to facilitate the information exchanges between and amongst the institutions at European level. Unique communication path between two stakeholders using the IMMC protocol. A ZIP format archive which must contain the IMMC file. The archive may optionally contain data files which must be referenced in the IMMC file. Exchange of IMMC packages over an IMMC data channel. An XML file, which validates against the IMMC schema following the specific IMMC parsing rules. Identifier of the IMMC, which must be used by applications for a valid transmission follow up. Applications must ensure its uniqueness within the IMMC data channel. Controls that concern the structure of the IMMC package (mandatory contents, IMMC package naming conventions and parsing of the IMMC ). Controls that concern the data included in the IMMC and any data files that are included in the IMMC package. 4 P a g e

5 1 Introduction 1.1 Purpose of the Document The purpose of this document is to describe the IMMC v3 communication protocol i.e. the messages exchanged between the institutions, the Publications Office and its contractors for the transmission of documents and their metadata. 1.2 Scope The current specifications provide an overview of the messages exchanged in IMMC v3, but mainly concern the technical and business validation messages as well the ones which indicate the final status of an exchange e.g. after the publication of the resources on the internet by the Publications Office. 2 IMMC v3 communication protocol overview The IMMC communication protocol defines the exchanged message types between a sender and a recipient for the completion of one-way transfers. The protocol is described in the diagram below: SENDER Request Response Technical Validation NACK Detect IMMC OK? Parse Technical Validation ACK Business Validation Business ACK Validation NACK RECIPIENT Process OK? Validate OK? Figure 1: IMMC v3 communication protocol diagram Senders transfer their IMMC packages over a data channel (FTP, e-trustex, etc.) and expect an answer from the recipient over the same channel. 5 P a g e

6 Recipients have to apply the following controls 1 upon reception of an IMMC package: Detect the IMMC. Each IMMC package shall contain only one file named after the name of the package and bearing the extension "_immc.xml". This file is expected to be the IMMC. In case the has not been detected the recipient has to notify the sender that an invalid package has arrived either manually or automatically 2. In case of an automatic answer, the message will use the <cmt:receipt> element (cf ). Parse the IMMC. The root element of the IMMC is expected to contain the "schemalocation" attribute, which shall point to the exact version of the schema to which it conforms e.g If the IMMC is not containing the schemalocation attribute, the parsing shall be done against a default IMMC v3 schema, which has to be agreed in advance between the stakeholders. In case there are parsing errors the recipient has to report back to the sender the parsing errors requesting redelivery either manually or automatically. In case of an automatic answer, the message will use the <cmt:receipt> element (cf ) and shall include the parser's report. Send an (optional) reception notification. The reception notification will be sent using the <cmt:receipt> element (cf ). It is strongly recommended to send the reception notification only for packages that have successfully passed the parsing step in order to be able to include also the business identifiers. Validate the IMMC package, following the specific business automatic validation rules that have been defined between the two stakeholders (sender and recipient). Senders and recipients can decide on the specific automatic validation rules, which will be applied for every particular data transfer. Successful validation notifications are optional but validation errors shall be always reported. All automatic validation notifications will be sent using the <cmt:receipt> element (cf and 3.3.2). Process the IMMC package, following the specific processing rules that have been defined between the stakeholders. 1 Failure of a step means that the subsequent steps cannot be executed. 2 Stakeholders have to agree in advance if these notifications will be done manually or automatically. They may decide to use only manual notifications for the technical errors if they agree that these errors are rare, can occur only during testing phases or, due to their importance and gravity, they shall be always validated manually by a system operator (e.g. system technical problems shall always be addressed by systems or network administrators and we cannot rely on an automatic answer in case such problems occur) 3 The IMMC XML schemas, together with the samples and the documentation are organized in different directories, according to the domain (e.g. Case Law, General Publications etc.) and published on the MDR website ( IMMC3 schemas are accessible online at 6 P a g e

7 Respond (optionally) back to the recipient providing processing status information. Process status notifications will be sent using the specific response element of each stakeholder. The response may consist of one or more IMMC packages (to be defined by the stakeholders). 2.1 IMMC package naming conventions All messages exchanged within the context of the IMMC communication protocol have to be wrapped in a ZIP archive, which filename must adhere to one of the following naming conventions: {filename}.zip {filename}_immc.zip The IMMC of the IMMC package must be named {filename}_immc.xml Every application that generates IMMC packages must ensure the uniqueness of the package filename within the IMMC data channel. The IMMC protocol recommends a generic naming convention for the {filename} part 4 i.e. <transmission id>_<date_time>_immc.zip <transmission id>_<date_time>_immc.xml Recommended date_time format is: YYYY-MM-DDThhmmssmmm, where: YYYY Year 4 digits MM Month 2 digits DD Day 2 digits T Start of the required time section literal hh Hour 2 digits mm Minutes 2 digits ss Seconds 2 digits mmm Milliseconds 3 digits 4 Other naming convention rules for the {filename} part can be defined by the stakeholders. 7 P a g e

8 2.2 IMMC request types The IMMC request type is mainly defined with the element //cmt:workflow/cmt:phase_workflow. The phase workflow indicates a step in the flow of the messages exchanged within a data channel. Its use facilitates the handling and dispatching of the messages to the correct workflow. It has been initially introduced in IMMC version 2 for indicating the different production steps of the OJ production chain. In IMMC version 3 the list of values has been enhanced in order to cover other production chains and workflows. Each value can either be used as standalone and provide a specific handling instruction by itself or require the use of additional fields to precise the request. For example, the phase workflow "metadata" is not accompanied by additional publication request instructions, is standalone and implies that the sender requests to update the metadata of a work in CELLAR. On the contrary, the phase workflow "publication" is always accompanied by specific instructions inserted in the *:t_publication_request_extension e.g. produce_formex, produce_pdf etc. The supported values and their usage are further explained in the table below: phase_workflow Description Use cases metadata Request that concerns/contains only the metadata. caselaw early reading Request for the correction of a work prior to its publication. Normally this phase is accompanied by a more precise request in the IMMC i.e. with the element for_correction, which can be also combined with an early diffusion on eur-lex. GenPub caselaw publication Request for the production of a publication. caselaw delete Request to delete a work from CELLAR. cancellation Request to cancel the production of a publication. caselaw publication reference delivery automatic validation manual validation redelivery Value used in response notifications for the final reference to the publication in the CELLAR / EUR-Lex. Value used by the contractors when delivering the products which OP has requested e.g. PDF/FORMEX, legal analysis, summary of EU legislation. Value used in business notifications informing the automatic validation status. Value used in business notifications informing the manual validation status. Value used by the contractors when redelivering the products which OP has rejected due to insufficient quality. The stakeholders, based on the contractual agreement, will define caselaw caselaw LA LSEU newceres contractor newceres PCS caselaw LA LSEU 8 P a g e

9 its specific semantics, the counting of attempts etc. 3 IMMC notifications 3.1 The <cmt:receipt> element The <cmt:receipt> root element will be used for: Reception (successful) notifications (technical ACK messages), without specific indication on the validation or processing status of the package. It is expected, however, that reception notifications correspond only to valid IMMC packages (i.e. they have passed the parsing step). Rejection notifications (technical NACK messages) due to early-processing unrecoverable technical errors (missing IMMC, parsing errors, etc.). The sending (either manual or automatic) of negative (NACK) replies is mandatory. Both positive and negative business validation replies (ACK & NACK messages) that are generated by a processing system as a reaction to an IMMC transmission: o the sending of positive (ACK) replies is optional (unless explicitly requested for a particular exchange from an IMMC stakeholder). Recipients may ignore positive ACKs. o the sending of negative (NACK) replies is mandatory, whenever an IMMC package cannot be processed through its expected workflow. Recipients are expected to always react on NACK messages. The IMMC s with the <cmt:receipt> root element must contain the business identifiers when the replying system has correctly processed and identified them (i.e. for all business validation replies). In all cases the <cmt:response_transmission> element must indicate the transmission identifier or the package filename to which an ACK/NACK message responds. The validation reply shall be provided at the corresponding level (transmission/workflow/work/expression/manifestation) to which it has been executed and where the validation error occurred. No data will be transmitted to the original sender. If this occurs it is implied that it corresponds to an initiative message. The sender must keep the original packages at least until a successful validation messages is transmitted. 3.2 Technical validation Successful notifications (Technical ACK) Scenario: The system has received an IMMC package. It was able to detect a valid IMMC, recognize the business identifiers and wants to notify its reception 9 P a g e

10 Actions recipient sender responds to sender with a new IMMC package acknowledging the reception of the sender's IMMC package N/A The new IMMC package must contain only the IMMC, which consists of the following elements: Element Root element Description Optional attribute which can be used to indicate the version of the schema against which the IMMC is valid. If used, its value has to be the MDR release (specific version) identifier. cm:version_schema="cm " allowed namespaces cmt:date_time cmt:sender cmt:institution xmlns:cmext=" urce/core-metadata-extensions/v3" xmlns:cmt=" ce/core-metadata-transmission/v3" xmlns:cm=" e/core-metadata/v3" xmlns:xsi=" The transmission identifier has to be unique within the IMMC data channel. Each sender is responsible for the definition of the identifier values. Date and time of the transmission adhering to the format: YYYY-MM-DDThh:mm:ss.sss. Contains the filename of the original package (type="package") to which this new message replies to. An IMMC stakeholder has transmitted an IMMC package with the filename {filename}.zip. This package filename will be the value of the element "cmt:response_transmission". <cmt:response_transmission type="package">o01_61997cc0172_ell_ T _production_request_immc.zip</cmt:re sponse_transmission> The stakeholders of the IMMC data channel have to agree on the exact values of its subelements. Mandatory element which has to contain either: - the code of a European institution or body (value derived from the at-corporate-body.xsd) or 10 P a g e

11 cmt:service cmt:context cmt:environment cmext:name - "cmt:private" (fixed value if the sender is a contractor) Mandatory element which has to contain the name of the service sending the transmission (e.g. for Commission: SG Greffe A.1). Mandatory element which has to contain the name of the application sending the transmission (e.g. for Commission: e-greffe). Optional element which has to contain one of the values "ACCEPTANCE" or "PROD", for indicating the test or production environment respectively. Both sender and recipient shall use the element when test data are exchanged. If the exchange concerns production data the element may not be transmitted. Mandatory element which has to contain a physical person's name, ideally of the person who sent the transmission and who will be able to follow up any issues. cmext:phone_number Optional element which has to contain a physical person's phone number, ideally of the person who sent the transmission and who will be able to follow up any issues. cmext: _address Optional element which has to contain a physical person's address, ideally of the person who sent the transmission and who will be able to follow up any issues. cmt:recipient cmt:institution cmt:service cmt:context cmt:environment cmext:name cmext:phone_number cmext: _address cmext:comment cmt:workflow Corresponds to the sender of the message to which we respond (see sub-elements below) Optional element which has to contain one of the values "ACCEPTANCE" or "PROD", for indicating the test or production environment respectively. Both sender and recipient shall use the element when test data are exchanged. If the exchange concerns production data the element may not be transmitted. Optional element which the sender can use in order to express any additional information concerning the transmission. <cmt:comment>reception Notification</cmt:comment> 11 P a g e

12 cmt:phase_workflow The element shall not be used cm:work If present, copy from the sender's IMMC all values of its sub-elements which belong to the "cm:" namespace. cm:procedure / cm:event / cm:work If present, copy from the sender's IMMC all values of their sub-elements which belong to the "cm:" namespace Rejection notifications (Technical NACK) Scenario: The system has received a digital object that was supposed to be an IMMC package. It was not able to open the package (unzip failed), detect or parse the IMMC, nor recognize the business identifiers Actions recipient sender responds to sender with a new IMMC package 5 indicating the problem sends a corrected IMMC package The new IMMC package must contain the IMMC and optionally a validation report. The IMMC consists of the following elements: cmt:receipt Root element Description Optional attribute which can be used to indicate the version of the schema against which the IMMC is valid. If used, its value has to be the MDR release (specific version) identifier. cm:version_schema="cm " allowed namespaces xmlns:cmext=" urce/core-metadata-extensions/v3" xmlns:cmt=" ce/core-metadata-transmission/v3" xmlns:cm=" e/core-metadata/v3" xmlns:xsi=" The transmission identifier has to be unique within the IMMC data channel. Each sender is responsible for the definition of the identifier values. 5 In this scenario the IMMC is either missing or it is corrupted (not parsable IMMC file). It is expected that, by using other means (i.e. data channel configuration) the recipient is able to identify the original sender and that a reply via IMMC has to be provided (see also section 2). 12 P a g e

13 cmt:date_time cmt:sender cmt:institution cmt:service cmt:context cmt:environment cmext:name Date and time of the transmission adhering to the format: YYYY-MM-DDThh:mm:ss.sss. Contains the filename of the original package (type="package") to which this new message replies to. An IMMC stakeholder has transmitted an IMMC package with the filename {filename}.zip. This package filename will be the value of the element "cmt:response_transmission". <cmt:response_transmission type="package">o01_61997cc0172_ell_ T _production_request_immc.zip</cmt:re sponse_transmission> The stakeholders of the IMMC data channel have to agree on the exact values of its subelements. Mandatory element which has to contain either: - the code of a European institution or body (value derived from the at-corporate-body.xsd) or - "cmt:private" (fixed value if the sender is a contractor) Mandatory element which has to contain the name of the service sending the transmission (e.g. for Commission: SG Greffe A.1). Mandatory element which has to contain the name of the application sending the transmission (e.g. for Commission: e-greffe). Optional element which has to contain one of the values "ACCEPTANCE" or "PROD", for indicating the test or production environment respectively. Both sender and recipient shall use the element when test data are exchanged. If the exchange concerns production data the element may not be transmitted. Mandatory element which has to contain a physical person's name, ideally of the person who sent the transmission and who will be able to follow up any issues. cmext:phone_number Optional element which has to contain a physical person's phone number, ideally of the person who sent the transmission and who will be able to follow up any issues. cmext: _address Optional element which has to contain a physical person's address, ideally of the person who sent the transmission and who will be able to follow up any issues. cmt:recipient cmt:institution cmt:service cmt:context Corresponds to the sender of the message to which we respond (see sub-elements below) 13 P a g e

14 cmt:environment cmext:name cmext:phone_number cmext: _address cmext:comment ation" Optional element which has to contain one of the values "ACCEPTANCE" or "PROD", for indicating the test or production environment respectively. Both sender and recipient shall use the element when test data are exchanged. If the exchange concerns production data the element may not be transmitted. Optional element which the sender can use in order to express any additional information concerning the transmission. In this specific message, the element will not be used as there are more specific elements (validation extensions) to indicate any issues related to the transmission. The validation extension must be added at the transmission level in order to notify the sender of the problem with the package. The value of the element cmext:outcome_validation must be selected from a closed list and set to "FAILED". If it is possible to provide more information concerning the error, this can be either stated in the element cmext:validation/cmext:comment or in an external file which filename must be referenced in the element cmext:validation/cmext:report_validation. <cmt:extension xsi:type="cmt:t_transmission_validation"> <cmext:comment>no IMMC found in the package</cmext:comment> </cmt:extension> <cmt:extension xsi:type="cmt:t_transmission_validation"> <cmext:report_validation>{filename}.txt</cmext:report_validation> </cmt:extension> cmt:workflow The element is mandatory, but it will be left empty (<cmt:workflow/>) because no business workflow has been identified. 14 P a g e

15 3.3 Business validation Successful notifications (Business validation ACK) Scenario: The system has received an IMMC package. It was able to detect an IMMC, recognize the business identifiers and successfully validate content and metadata adhering to the established validation rules Actions recipient sender responds to sender with a new IMMC package acknowledging the successful business level validation N/A The new IMMC package must contain only the IMMC, which consists of the following elements: Element Root element Description Optional attribute which can be used to indicate the version of the schema against which the IMMC is valid. If used, its value has to be the MDR release (specific version) identifier. cm:version_schema="cm " allowed namespaces cmt:date_time xmlns:cmext=" urce/core-metadata-extensions/v3" xmlns:cmt=" ce/core-metadata-transmission/v3" xmlns:cm=" e/core-metadata/v3" xmlns:xsi=" The transmission identifier has to be unique within the IMMC data channel. Each sender is responsible for the definition of the identifier values. Date and time of the transmission adhering to the format: YYYY-MM-DDThh:mm:ss.sss. Contains the filename of the original package (type="package") to which this new message replies to. An IMMC stakeholder has transmitted an IMMC package with the filename {filename}.zip. This package filename will be the value of the element "cmt:response_transmission". <cmt:response_transmission type="package">o01_61997cc0172_ell_ T _production_request_immc.zip</cmt:re sponse_transmission> 15 P a g e

16 cmt:sender cmt:institution cmt:service cmt:context cmt:environment cmext:name The stakeholders of the IMMC data channel have to agree on the exact values of its subelements. Mandatory element which has to contain either: - the code of a European institution or body (value derived from the at-corporate-body.xsd) or - "cmt:private" (fixed value if the sender is a contractor) Mandatory element which has to contain the name of the service sending the transmission (e.g. for Commission: SG Greffe A.1). Mandatory element which has to contain the name of the application sending the transmission (e.g. for Commission: e-greffe). Optional element which has to contain one of the values "ACCEPTANCE" or "PROD", for indicating the test or production environment respectively. Both sender and recipient shall use the element when test data are exchanged. If the exchange concerns production data the element may not be transmitted. Mandatory element which has to contain a physical person's name, ideally of the person who sent the transmission and who will be able to follow up any issues. cmext:phone_number Optional element which has to contain a physical person's phone number, ideally of the person who sent the transmission and who will be able to follow up any issues. cmext: _address Optional element which has to contain a physical person's address, ideally of the person who sent the transmission and who will be able to follow up any issues. cmt:recipient cmt:institution cmt:service cmt:context cmt:environment cmext:name cmext:phone_number cmext: _address Corresponds to the sender of the message to which we respond (see sub-elements below) Optional element which has to contain one of the values "ACCEPTANCE" or "PROD", for indicating the test or production environment respectively. Both sender and recipient shall use the element when test data are exchanged. If the exchange concerns production data the element may not be transmitted. 16 P a g e

17 cmext:comment ion" Optional element which the sender can use in order to express any additional information concerning the transmission. In this specific message, the element will not be used as there are more specific elements (validation extensions) to indicate any issues related to the transmission. The validation extension will be added only at the transmission level notifying that the IMMC package has passed all the business validation controls. The value of the element cmext:outcome_validation must be selected from a closed list and set to "PASSED". <cmt:extension xsi:type="cmt:t_transmission_validation"> <cmext:outcome_validation>passed</cmext:outcome_validation> </cmt:extension> cmt:workflow cmt:phase_workflow It will take the values: "automatic validation" when the message is generated after automatic validation controls or "manual validation" when the message is generated after manual verification controls. cm:work If present, copy from the sender's IMMC all values of its sub-elements which belong to the "cm:" namespace. cm:procedure / cm:event / cm:work If present, copy from the sender's IMMC all values of their sub-elements which belong to the "cm:" namespace Rejection notifications (Business validation NACK) Scenario: The system has received an IMMC package. It was able to detect an IMMC, recognize the business identifiers and wants to notify the violation of the established business validation rules either after automatic or manual validation Actions recipient sender responds to sender with a new IMMC package indicating the business level validation problems sends a corrected IMMC package The new IMMC package must contain the IMMC and the necessary validation report(s). The IMMC consists of the following elements: 17 P a g e

18 Element allowed namespaces cmt:date_time cmt:sender cmt:institution cmt:service cmt:context cmt:environment Root element Description Optional attribute which can be used to indicate the version of the schema against which the IMMC is valid. If used, its value has to be the MDR release (specific version) identifier. cm:version_schema="cm " xmlns:cmext=" urce/core-metadata-extensions/v3" xmlns:cmt=" ce/core-metadata-transmission/v3" xmlns:cm=" e/core-metadata/v3" xmlns:xsi=" The transmission identifier has to be unique within the IMMC data channel. Each sender is responsible for the definition of the identifier values. Date and time of the transmission adhering to the format: YYYY-MM-DDThh:mm:ss.sss. Contains the filename of the original package (type="package") to which this new message replies to. An IMMC stakeholder has transmitted an IMMC package with the filename {filename}.zip. This package filename will be the value of the element "cmt:response_transmission". <cmt:response_transmission type="package">o01_61997cc0172_ell_ T _production_request_immc.zip</cmt:re sponse_transmission> The stakeholders of the IMMC data channel have to agree on the exact values of its subelements. Mandatory element which has to contain either: - the code of a European institution or body (value derived from the at-corporate-body.xsd) or - "cmt:private" (fixed value if the sender is a contractor) Mandatory element which has to contain the name of the service sending the transmission (e.g. for Commission: SG Greffe A.1). Mandatory element which has to contain the name of the application sending the transmission (e.g. for Commission: e-greffe). Optional element which has to contain one of the values "ACCEPTANCE" or "PROD", for indicating the test or production environment respectively. 18 P a g e

19 cmext:name Both sender and recipient shall use the element when test data are exchanged. If the exchange concerns production data the element may not be transmitted. Mandatory element which has to contain a physical person's name, ideally of the person who sent the transmission and who will be able to follow up any issues. cmext:phone_number Optional element which has to contain a physical person's phone number, ideally of the person who sent the transmission and who will be able to follow up any issues. cmext: _address Optional element which has to contain a physical person's address, ideally of the person who sent the transmission and who will be able to follow up any issues. cmt:recipient cmt:institution cmt:service cmt:context cmt:environment cmext:name cmext:phone_number cmext: _address cmext:comment ation" Corresponds to the sender of the message to which we respond (see sub-elements below) Optional element which has to contain one of the values "ACCEPTANCE" or "PROD", for indicating the test or production environment respectively. Both sender and recipient shall use the element when test data are exchanged. If the exchange concerns production data the element may not be transmitted. Optional element which the sender can use in order to express any additional information concerning the transmission. In this specific message, the element will not be used as there are more specific elements (validation extensions) to indicate any issues related to the transmission. The validation extension notifies that the IMMC package has failed one or more of the business validation controls. Yet, it will be added at the transmission level, if and only if, - the validation concerns the full package (e.g. naming convention of the package) or it was not possible to identify the exact level in the IMMC for adding the validation results, and - the result was negative i.e. "FAILED" The value of the element 19 P a g e

20 cmext:outcome_validation must be selected from a closed list and set to "FAILED". <cmt:extension xsi:type="cmt:t_transmission_validation"> </cmt:extension> cmt:workflow cmt:phase_workflow cm:work It will take the values: "automatic validation" when the message is generated after automatic validation controls or "manual validation" when the message is generated after manual verification controls. If present: 1. copy from the sender's IMMC all values of its sub-elements which belong to the "cm:" namespace 2. add validation extensions a. one extension per work, if and only if, the validation was performed at the work level and the result was negative i.e. "FAILED" <cm:extension xsi:type="cmext:t_work_validation"> </cm:extension> b. one extension per expression, if and only if, the validation was performed at the expression level and the result was negative i.e. "FAILED" <cm:extension xsi:type="cmext:t_expression_validation"> </cm:extension> c. one extension per manifestation, if and only if, the validation was performed at the manifestation level and the result was negative i.e. "FAILED" <cm:extension xsi:type="cmext:t_manifestation_validation"> </cm:extension> cm:procedure / cm:event / cm:work If present: 1. copy from the sender's IMMC all 20 P a g e

21 values of their sub-elements which belong to the "cm:" namespace 2. add validation extensions a. one extension for the procedure, if and only if, the validation was performed at the procedure level and the result was negative i.e. "FAILED" <cm:extension xsi:type="cmext:t_procedure_validation"> </cm:extension> b. one extension for the event, if and only if, the validation was performed at the event level and the result was negative i.e. "FAILED" <cm:extension xsi:type="cmext:t_event_validation"> </cm:extension> c. one extension per work, if and only if, the validation was performed at the work level and the result was negative i.e. "FAILED" <cm:extension xsi:type="cmext:t_work_validation"> </cm:extension> d. one extension per expression, if and only if, the validation was performed at the expression level and the result was negative i.e. "FAILED" <cm:extension xsi:type="cmext:t_expression_validation"> </cm:extension> e. one extension per manifestation, if and only if, the validation was performed at the manifestation level and the result was negative i.e. "FAILED" <cm:extension xsi:type="cmext:t_manifestation_validation"> </cm:extension> Additional information for the validation result can either be inserted in the comment field of the validation extension (cf. case 1) or inserted in a validation report(s) file whose filename(s) will be referenced in the element "cmext:report_validation" (cf. case 2). Case 1: 21 P a g e

22 <cm:extension xsi:type="cmext:t_manifestation_validation"> <cmext:comment>missing manifestation</cmext:comment> </cm:extension> OR Case 2: <cm:extension xsi:type="cmext:t_manifestation_validation"> <cmext:report_validation>ecr_61997cc0172_de_01.vpd.report.xml</cmext:report_validation> </cm:extension> 3.4 Processing Status notification (response) Scenario: The system has received an IMMC package. It was able to detect an IMMC, recognize the business identifiers, successfully validate content and metadata and complete the transaction Actions recipient sender responds to sender with a new IMMC package notifying the process status after the transaction completion The transaction is considered closed. Any further action will have to trigger a new IMMC exchange (to be defined by the stakeholders) The response IMMC package must contain the IMMC and optionally any other data content as defined by the stakeholders. The IMMC consists of the following elements: Element *_transmission_response Root element Description The response root element will be different per stakeholder. When OP is responding, the root element is: Optional attribute which can be used to indicate the version of the schema against which the IMMC is valid. If used, its value has to be the MDR release (specific version) identifier. cm:version_schema="cm " allowed namespaces xmlns:cmt=" ce/core-metadata-transmission/v3" xmlns:cm=" 22 P a g e

23 cmt:date_time cmt:sender cmt:institution cmt:service cmt:context cmt:environment cmext:name e/core-metadata/v3" xmlns:cmext=" urce/core-metadata-extensions/v3" xmlns:xsi=" When OP is responding, the additional two namespaces have to be added: xmlns:opext="urn:eu:op:extensions" xmlns:optrans="urn:eu:op:transmission:response " The transmission identifier has to be unique within the IMMC data channel. Each sender is responsible for the definition of the identifier values. Date and time of the transmission adhering to the format: YYYY-MM-DDThh:mm:ss.sss. Contains the filename of the original package (type="package") to which this new message replies to. The idea is that the system replies to the processed IMMC package. An IMMC stakeholder has transmitted an IMMC package with the filename {filename}.zip. This package filename will be the value of the element "cmt:response_transmission". <cmt:response_transmission type="package">o01_61997cc0172_ell_ T _production_request_immc.zip</cmt:re sponse_transmission> The stakeholders of the IMMC data channel have to agree on the exact values of its subelements. Mandatory element which has to contain either: - the code of a European institution or body (value derived from the at-corporate-body.xsd) or - "cmt:private" (fixed value if the sender is a contractor) Mandatory element which has to contain the name of the service sending the transmission (e.g. for Commission: SG Greffe A.1). Mandatory element which has to contain the name of the application sending the transmission (e.g. for Commission: e-greffe). Optional element which has to contain one of the values "ACCEPTANCE" or "PROD", for indicating the test or production environment respectively. Both sender and recipient shall use the element when test data are exchanged. If the exchange concerns production data the element may not be transmitted. Mandatory element which has to contain a physical person's name, ideally of the person who sent the transmission and who will be able to follow up any issues. 23 P a g e

24 cmext:phone_number Optional element which has to contain a physical person's phone number, ideally of the person who sent the transmission and who will be able to follow up any issues. cmext: _address Optional element which has to contain a physical person's address, ideally of the person who sent the transmission and who will be able to follow up any issues. cmt:recipient cmt:institution cmt:service cmt:context cmt:environment cmext:name cmext:phone_number cmext: _address cmext:comment cmt:workflow cmt:phase_workflow Corresponds to the sender of the processed message (see sub-elements below) Optional element which has to contain one of the values "ACCEPTANCE" or "PROD", for indicating the test or production environment respectively. Both sender and recipient shall use the element when test data are exchanged. If the exchange concerns production data the element may not be transmitted. Optional element which the sender can use in order to express any additional information concerning the transmission. To be defined by the stakeholders. When OP is responding the following values apply: "early reading": after proofreading "publication reference": after metadata ingestion and/or work ingestion in CELLAR cm:work If present, copy from the sender's IMMC all values of its sub-elements which belong to the "cm:" namespace up to the expression level. When the response concerns the early reading, the "cmext:t_work_common_extension" has to be copied form the sender's IMMC and a new extension "opext:t_expression_early_reading" has to be added. A new DOC manifestation has to be added referencing the corrected document. When the response concerns the publication request, the extension "opext:t_work_case_report_reference" at the expression level and the extension 24 P a g e

25 "opext:t_manifestation_publication_reference" at the manifestation level have to be added. New manifestations have to be added referencing the CELLAR URLs. When the response concerns the metadata no additional information will be provided, the publication reference workflow implies the ingestion and publication of the metadata. cm:procedure / cm:event / cm:work If present, copy from the sender's IMMC all values of their sub-elements which belong to the "cm:" namespace and follow the instructions defined for the level of the cm:work. 25 P a g e