WasteX specification v1.10c

Federal Ministry for Climate Action, Environment, Energy, Mobility, Innovation and Technology (BMK)

Stubenbastei 5, 1010 Vienna, Austria

Contents

Introduction

Notation

Domain background

Digitalization context and status

Purpose of the WasteX specification

Scope of the WasteX specification

Intended audience

Contact

Technical basics

Type of web service

Web service environments and endpoints

Technologies and standards stack

Payload: User messages and signal messages

Files and folders of the specification package

Files and folders

Description

Technical and organizational details

Unidirectional versus bidirectional usage

Polling

Transport layer security TLS

UTF-8 encoding

XSD validity of operation inputs and outputs

Value ranges and precision

Identification, Authentication and Authorization

Party identification

Updates, corrections and cancellations

Transmission triggers

Bulk transmissions

Sender and receiver side responsibilities

Signal message sender/receiver indication

Transmission retries

Recommended reactions to certain EDI behaviour

Specifics of the Austrian web service

Codelists

Introduction

Codelist example

Codelist characteristics

Codelist uses

Codelist languages

Codelist web service

Static and dynamic usage of codelists

Codelists which the specification uses statically

Codelists which the specification uses dynamically

Web service operations (from wastex_webservice.wsdl)

Inputs and Outputs of the web service operations (from wastex_webservice_types.xsd)

Message formats (from wastex_message.xsd)

Formal validation rules (from wastex_formalvalidationrules.sch)

Introduction

Validation process

Interoperability and cost efficiency

Subjects and characteristics of formal validation

Interpretation of formal validation results

Handling of formal validation protocols

Introduction to the formal validation rules description

List of formal validation rules

Definitions and References

Terms and Definitions

Acronyms

References

Specification history of changes

History of changes

Detailed changes (diff) compared to version 1.08

Introduction

Disclaimer

	WasteX v1.10c - simple EDI for waste shipments (candidate for v1.10)

	Copyright (C) 2023 Environment Agency Austria
	Commissioned by the Austrian Federal Ministry of Environment (BMK)

	Contact: edm-helpdesk@umweltbundesamt.at

	Licensed under the EUPL, Version 1.2 or – as soon they will be approved
	by the European Commission – subsequent versions of the EUPL (the "Licence");

	You may not use this work except in compliance with the Licence.

	You may obtain a copy of the Licence at: http://joinup.ec.europa.eu/software/page/eupl

	Unless required by applicable law or agreed to in writing, work distributed under the licence is distributed
	on an "AS IS" basis, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

	See the Licence for the specific language governing permissions and limitations under the Licence.

Notation

This specification uses the terms and acronyms defined in Definitions and References, and bases on the technical standards and legal regulations listed therein.

Domain background

Waste shipment business processes

Transboundary movements of waste, also called shipments of waste, carry the risk of adverse effects to human health and the environment.

The Basel Convention [BC] is an international treaty aimed at protecting human health and the environment against such adverse effects by strict control. The EU Waste Shipment Regulation [WSR] has the same goal and contains additional control provisions defined for the EU on top of the [BC] provisions.

Among the core provisions of [BC] and [WSR] are the following business-to-administration (B2A) business processes with information interchanges between economic operators (EOs) and competent authorities (CAs):

Amber shipments - shipments requiring prior written notification and consent

 BP_AMBER_CONSENT - Notification and consent business process

Main steps:

1. EO submits notification to CA, Art. 4 [WSR]
2. (Optional): CA requests additional information from EO, Art. 4(3) [WSR]
3. CA acknowledges receipt of a properly carried out notification to EO, and shares the notification with CAs of destination and transit, Art. 7(1) [WSR]
4. CA acknowledges receipt of a properly completed notification to EO, Art. 8(2) [WSR]
5. CA issues consent, consent with conditions or objection to EO, Art. 9 [WSR]

 BP_AMBER_INFO - Information business process for each individual amber shipment ("movement document" process)

Main steps:

1. movement announcement (MA): EO announces the shipment to CAs and other EOs, Art. 16(b) [WSR]
2. (Optional): EO provides consent and individual shipment information to CAs upon inspection and customs controls, Art. 16(c) [WSR]
3. carrier confirmation (CaC): carrier confirms taking charge of a shipment of waste, in accordance with Article 16 of the [WSR], as well as Annex IB block 8 and Annex IC paragraphs 6 and 32
4. confirmation of waste receipt (CoWR): EO confirms the receipt of waste to CAs and other EOs, Art. 16(d) [WSR]
5. confirmation of the completion of waste treatment (CoWT): EO confirms the completion of treatment of the shipped waste to CAs and other EOs, Art. 16(e) [WSR]

Green shipments - shipments that do not require prior written notification and consent

 BP_GREEN_INFO  - Information business process for each individual green shipment ("consignment information" process)

Main steps:

1. EO prepares information to accompany the shipment of waste, Art. 18(1) [WSR]
2. (Optional): EO provides prepared information to CA upon request, Art. 18(2) [WSR]

Waste shipment handling in Austria

Overview

Austria has a single designated CA for shipments of waste, the Ministry of Environment (BMK), department V/1. Since 2006, the Austrian CA uses e-Goverment solution edm.gv.at  [EDM] to manage waste shipment data and processes. [EDM] is an interconnected system of IT applications and databases by the Austrian public administration to support environment-related business processes.

EOs can exchange structured electronic waste shipment information with the Austrian CA via the [EDM] web application, and/or via [EDM] web services.

Since the end of 2017, [EDM] has an electronic data interchange (EDI) interconnection with [VeVA-Online], the e-Government solution used by the waste shipment CAs of Switzerland.

Since 2006, the Austrian CA handles all waste shipment data as structured electronic data in the [EDM]. Where needed, the CA types in data that it receives by e-mail, fax, or mail. EOs can use structured electronic data exchange with the Austrian CA instead of e-mail, fax or mail, such as via [EDM] web application online forms. The Austrian CA deals with around 1.000 notifications and around 50.000 individual waste shipments per year, with a total of around 4.000 EOs (notifiers, carriers, consignees, waste treatment parties, ...).

Amended legal requirements as of 2022

With the 2021 Circular Economy amendment to the Austrian Federal Act on sustainable waste management [AWG 2021], in 2022 Austrian EOs became obliged to exchange waste shipment information as structured electronic data with the Austrian CA. I.e., structured electronic data provision is no longer optional for Austrian CAs, and the Austrian CA no longer accepts e-mail, fax or mail for certain data exchanges with Austrian EOs.

As a result, there is an increased demand by Austrian EOs for B2A EDI with the Austrian CA. The Austrian CA meets this demand by operating the [EDM] WasteX web service. Austrian EOs can use the [EDM] WasteX web service as an alternative to using the [EDM] web application online forms.

Digitalization context and status

Status globally

The 2020 [Basel Electronic Approaches Report] provides a good global overview of the digitalization status with respect to the BP_AMBER_CONSENT, BP_AMBER_INFO and BP_GREEN_INFO business processes.

To summarize, there are multiple initiatives, including the data interchange between Swiss and Austrian CAs, [VeVA-Online] and [EDM], but as of 2022/2023 none has gained wider adoption.

Status in the EU

Waste shipments

The European Commission Directorate-General for the Environment (EC DG ENV) has a year-long history of supporting and leading waste shipment digitalization efforts. One major outcome of these efforts are Correspondents’ Guidelines No 11 [CG11], which is the specification of a data model for the electronic data interchange under the [WSR] published in 2019.

In November 2021, EC DG ENV published the proposal for a new Waste Shipment Regulation [WSR EC proposal Nov 2021]. According to this proposal, electronic processes and structured electronic data become mandatory for all CAs and EOs in the EU. As of 2023, there are expectations that a new EU Waste Shipment Regulation will enter into force in the coming years.

Since 2021, EC DG ENV has started adding waste shipment functionality to the EC operated Integrated Management System for Official Controls [IMSOC]. As of 2023, this functionality is limited to administration-to-administration (A2A) processes and unstructured data such as PDF files. However, EC DG ENV plans extending this functionality to B2A processes and structured data, making IMSOC a central hub for waste shipment data interchange in the EU. In December 2022, EC DG ENV with their consultants Trasys International held an experts meeting detailing the plans for digitalization and the new WSR.

Electronic Freight Transport Information (eFTI)

The EU Electronic Freight Transport Information Regulation [eFTI] entered into force in 2020, and foresees full application by 2025. Based on that Regulation, EOs have the right to present regulatory freight transport information electronically upon inspections, rather than on paper, and CAs have an obligation to accept regulatory freight transport information electronically. Article 2 of the [eFTI] Regulation lists the regulatory freight transport information requirements to which the [eFTI] Regulation applies. This list includes [WSR] BP_AMBER_INFO movement document and BP_GREEN_INFO consignment information inspections.

In 2020, the European Commission Directorate-General for Mobility and Transport (EC DG MOVE) started an expert group that analyses the requirements and drafts technical specifications in preparation of the [eFTI] implementing acts. Among the outputs is an analysis of [eFTI] [WSR] integration options, to which EC DG ENV and BMK contributed.

Purpose of the WasteX specification

The purpose of this specification is twofold:

1. Specification as an EDI web service interface to the Austrian CA
   
   • The Austrian CA implements and operates an [EDM] WasteX web service which complies with this specification
   • Software/service providers in the field of waste management can implement a connection with the [EDM] WasteX web service and thus enable users of their software solutions to conduct waste shipment EDI with the Austrian CA
2. Specification as resuable, extensible and interoperable EDI protocol
   • Specification so that any CA can operate a web service which complies with the WasteX specification in order to decentrally enable waste shipment B2A EDI
   • Specification so that it is easy to use parts, such as message formats, in future specifications, such as an eDelivery based specification
   • Specificiation based on existing harmonization and standardization efforts, including [CG11] and UN/CEFACT standards, in order to ascertain interoperability with future developments, such as [IMSOC] and [eFTI], as much as possible

Scope of the WasteX specification

Business processes

Coverage types:

• ✔: The current version of the WasteX specification covers these business processes
• (✔): The current version of the WasteX specification does not cover these business processes. However, the design of the current version of the WasteX specification is such that it is easily extensible for additionally covering these business processes

WasteX extensibility features:

• The majority of extensions can be done on message format level, and does not require other changes, such as additional web service operations
• When the specification covers additional business processes, this can be done backwards compatible, i.e., for implementations it can be optional to implement these additional processes

BMK will decide on covering additional business processes in WasteX based on demand. As of 2023, BMK is aware of multiple software developers' demand for accessing notification and consent data via the web service (part of BP_AMBER_CONSENT).

Data access and direction of data flows

The main purpose of WasteX EDI is EOs making waste shipment data available to CAs using EDI.

The flow of data is however not unidirectional. CAs provide EOs access to "their" data. In particular, EOs can access movement document data if they have a suitable role in the waste shipment, such as notifier, carrier, consignee or waste treatment party. The WasteX web service provides such access.

In the [EDM], identical conditions/rules/principles for EOs' access to movement document data are in place both in the [EDM] WasteX web service and the [EDM] web application.

Intended audience

The main intended audience of this specification is IT personnel, such as IT business analysts, developers and testers working for software/solution/service providers that implement an EDI connection to the [EDM] WasteX web service interface, or consider doing so.

In addition, this description targets waste management domain experts, and decision makers at software/solution/service providers in the field of waste management.

Contact

For any enquiries about this specification and the [EDM] WasteX web service get in touch with edm-helpdesk@umweltbundesamt.at.

Technical basics

Type of web service

The [EDM] WasteX web service is a [SOAP] web service with [XML] web service operation inputs and outputs.

The WasteX specification formally defines the web service operations with their inputs and outputs via [WSDL] and [XSD].

Web service environments and endpoints

To external developers, there are two environments and endpoints of the [EDM] WasteX web service:

1. Production environment: https://edm.gv.at/wastex/wastex_webservice/wastex.wsdl
2. Pre-production environment: https://vprod.umweltbundesamt.at/wastex/wastex_webservice/wastex.wsdl

The Environment Agency as operator of the [EDM] WasteX web service offers the pre-production environment to external partners - developers/operators of IT solutions - for testing web service interactions. The pre-production environment resembles the production environment, and features database contents similar to those of the production environment. Note that access to the pre-production environment and access to the production environment are different from each other - credentials and access information for one environment do not work with the other environment.

Technologies and standards stack

The web service and its specification apply the following standards:

 [Base64] 

The web service expects certain authentication [HTTP] header content in [Base64] encoding

 [HMAC] 

The web service supports hash based message authentication codes [HMAC] as one of two options for the web service client to provide evidence about its identity (about being a "known" previously register web service client). The other option is [HTTP Basic Auth]

 [HTTP]/1.1

All interactions betweens web service client and web service follow the [HTTP]/1.1 protocol. For example, a web service client invokes a web service operation with an [HTTP] request using the [HTTP] POST method, and providing certain authentication information as [HTTP] headers

 [HTTP Basic Auth] 

The web service supports HTTP Basic Authentication as one of two options for the web service client to provide evidence about its identity (about being a "known" previously register web service client). The other option is [HMAC]

 [Schematron] 2016

The web service applies formal validation to messages it receives in the input of web service operations, and reports the validation results back to the web service client. This specification uses [Schematron] as the formal language for expressing the formal validation rules

 [SOAP] 1.2

The web service follows the [SOAP] protocol, such as by using [SOAP] envelope [XML] structures for all web service inputs and outputs

 [TLS] 1.2+

The web service requires [TLS] 1.2 or higher for all client server communication. This ensures confidentiality, integrity, and authenticity. Note that the communication between secure web sites (https) and browsers uses the same [TLS] encrpytion protocol

 [UTF-8] 

The web service expects all operation inputs in [UTF-8] character encoding, and delivers all operation outputs and fault information in [UTF-8] character encoding

 [UUID] 

Web service clients must generate Universally Unique Identifiers [UUID]s and transmit them in the operation input, such as for each "transaction" (web service operation invocation)

 [XML] 1.0

Syntax of web service inputs and outputs, including messages and payload

 [XPath] 2.0

[XPath] expressions occur in [Schematron] instances (formal validation rule source) as well as in [XSLT] instances derived thereof. They provide the means of identifying and referencing specific parts and locations within [XML] instances

 [XQuery] 2.0

[XQuery] expressions occur in [Schematron] instances (formal validation rule source) as well as in [XSLT] instances derived thereof. They provide the means of accessing [XML] instance contents, such as for reading and comparing

 [XSD] 1.0

This specification uses [XSD] for the formal definition of the [XML] structures and value domains of web service inputs and outputs, including messages and payload. Note that every WasteX web service operation quits an invocation with a [SOAP] fault if according to [XSD] validation the operation input does not comply with the structures and value domains defined by the respective [XSD] instance of this specification

 [XSLT] 2.0

[Schematron] uses [XSLT]: A WasteX web service generates the formal validation results (validation protocol) for messages it receives by applying an [XSLT] transformation using an [XSLT] processor such as [RaptorXML] or [Saxon]. This specification package contains the [XSLT] transformation instance wastex_formalvalidationrules.xsl, which the web service uses for conducting the formal validation. The [XSLT] transformation instance wastex_formalvalidationrules.xsl is the result of an automated transformation of the [Schematron] formal validation rules source wastex_formalvalidationrules.sch, generated using [SchXslt]

 [WSDL] 2.0

This specification uses [WSDL] for the formal definition of the web service operations with their inputs and outputs. The [WSDL] definition uses [XSD] instances for defining structure and value domains of the inputs and outputs. There are software tools on the market which use [WSDL] instances for automating parts of web service and web service client development and testing

Payload: User messages and signal messages

Introduction

This specification distinguishes two types of payload (transmitted content):

1. User message
2. Signal message

User message

A user message contains waste shipment related data such as MA, CaC, CoWR or CoWT (see waste shipment business processes).

Each user message contains a single MA, or a single CoWR, etc.

Signal message

A signal message has a supporting role in EDI, and carries information on the following:

• information of whether or not a received user message was accepted or rejected at the receiving EDI node
• in most cases the signal message also contains the formal validation report, which the receiving EDI node’s calculates by applying formal validation to the received user message

Files and folders of the specification package

Files and folders

Description

xml_example_msg/

Contains exactly one sample message for each of the types of messages defined in the specification package.

The sample messages follow these criteria:

1. 1. The sample messages contain fictitious and conceived data
   2. In order to serve as an illustration, the specification authors have conceived the data so that it is likely to have similarities with data occurring in practice
   3. The examples use a large number of [XML] data elements to illustrate their use

xml_example_service_input_output/

Contains exactly one sample input and sample output for each operation of the packaging 3.0 web service. Also contains an example [SOAP] fault.

z_descr_img/

Folders whose names begin with "z_" are auxiliary folders. The specification [HTML] description contains links to the files contained in these auxiliary folders, and embeddings of such files. For understanding and using this specification, there is neither a need for accessing the contents of these auxiliary folders individually, nor is there any benefit of doing so.

The folder z_descr_img contains the image files used in this [HTML] description.

z_val_a_xml_example_msg_base/; z_val_b_xml_example_msg_ruletest/; z_val_c_results/

The files in these folders relate to the formal validation rules. The specification package contains a specification of formal validation rules in Schematron file wastex_formalvalidationrules.sch. Section Formal validation rules (from wastex_formalvalidationrules.sch) describes the formal validation rules via example rule violations and contains links to the contents of these folders.

The folder z_val_a_xml_example_msg_base/ contains sample input for the formal validations. These are the sample messages from the folder xml_example_msg/, enriched with so-called ValidationContext. Software receiving a message reads data related to the message at its receiving end of the transmission, e.g. company master data, reference data, or data from previously transmitted messages. The software passes this data as ValidationContext to the formal validation. For the files contained in the folder z_val_a_xml_example_msg_base/, both message contents and ValidationContext contain fictitious data. The folder z_val_a_xml_example_msg_base/ contains sample input that satisfies all formal validation rules and thus does not trigger any validation report entries.

The folder z_val_a_xml_example_msg_ruletest/ also contains sample input for the formal validation rules. The specification authors have designed these sample files as modifications of the sample files from z_val_a_xml_example_msg_base/ to specifically trigger or not trigger certain formal validation rules.

The folder z_val_c_results/ contains the results of applying the formal validation rules defined in the Schematron file wastex_formalvalidationrules.sch to the [XML] sample files from the two folders z_val_a_xml_example_msg_base/ and z_val_a_xml_example_msg_ruletest/. The results are available in the Schematron Validation Report Language (SVRL) [XML] data format, as well as in a [HTML] representation. In section Formal validation rules (from wastex_formalvalidationrules.sch), this description provides an overview of the formal validation rules specified in Schematron file wastex_formalvalidationrules.sch by means of a compilation of validation results from z_val_c_results/.

svrl.xsd

Defines the Schematron Validation Report Language (SVRL) data format for formal validation reports in the formal language [XSD].

wastex_message.xsd uses svrl.xsd, so it depends on svrl.xsd. When copying wastex_message.xsd, it is therefore necessary in most cases to also copy the file svrl.xsd into the target directory.

wastex_doc.html

The main specification document. It provides all instructions and guidance on correctly implementing, testing and operating WasteX waste shipment EDI connections.

The contents include detailed descriptions of web service operations with their inputs and outputs, of message formats and of formal validation rules, as well as descriptions of all files and folders contained in the specification package, such as [XSD] and [WSDL] files.

wastex_formalvalidationrules.sch

"Source code" of the formal validations rules defined for the WasteX EDI protocol in the formal language [Schematron].

The specification authors use [SchXslt] to create the wastex_formalvalidationrules.xsl file from this source text.

By providing this source code, the formal validation rules that the WasteX web service applies to business-to-authority-transmissions are open and transparent, such as for review as well as correction and improvement suggestions. 

wastex_formalvalidationrules.xsl

XSLT instance with which a WasteX web service applies formal validation to received messages.

The specification authors have generated wastex_formalvalidationrules.xsl automatically from the "Schematron source code" wastex_formalvalidationrules.sch via [SchXslt].

The WasteX web service applies the Schematron based formal validation to received messages only if the web service interaction meets certain preconditions, such as successful authentication and the web service operation input's compliance with the [XML] formats (XML Schema Definitions) defined in this specification - see wastex_message.xsd and wastex_webservice_types.xsd.

wastex_message.xsd

Defines, via formal language [XSD], the [XML] message formats used in the WasteX EDI protocol. When receiving messages, a WasteX web service checks these messages - as part of the validation of operation inputs - for validity with respect to the message format defined by wastex_message.xsd. Such validity is a technical prerequisite for a WasteX web service to be able to process transmitted messages.

Conversely, software connected to a WasteX web service can rely on the validity of messages delivered by the web service in operation outputs with respect to the XML message formats defined via wastex_message.xsd, and can conduct XML Schema validation for ascertaining this validity.

wastex_webservice_types.xsd

Defines, via formal language [XSD], the [XML] formats for inputs and outputs of WasteX web service operations. Has a direct dependency on wastex_message.xsd, and thus also an indirect dependency on svrl.xsd.

The validity of operation inputs with respect to the XML formats defined in wastex_webservice_types.xsd is a technical prerequisite for a WasteX web service to successfully process a web service interaction.

Conversely, software connected to a WasteX web service can rely on the validity of web service operation outputs with respect to the XML formats defined in wastex_webservice_types.xsd, and can conduct XML Schema validation for ascertaining this validity.

wastex_webservice.wsdl

Describes the operations of a WasteX web service and its inputs and outputs in the formal language [WSDL]. Uses wastex_webservice_types.xsd directly, and thus wastex_message.xsd and svrl.xsd indirectly.

Software developers may for example use the WSDL instance with [SOAP] tools such as SoapUI to automatically generate web service interactions for all WasteX web service operations.

Technical and organizational details

Unidirectional versus bidirectional usage

Introduction

To repeat from the Scope of the WasteX specification section:

1. The main purpose of WasteX EDI is EOs making waste shipment data available to CAs using EDI
2. The flow of data is however not unidirectional. CAs provide EOs access to "their" data

Using the second part is optional for EOs and web service clients. This means that web service clients can use WasteX web services in one of the following two ways:

1. Bidirectional connection: Usage for data transmission from EO to CA and for CA to EO data flows
2. Unidirectional connection: Usage for EO to CA data transmission only

CA to EO data flow use cases

There are two types of use cases for EOs to access (new) data from the CA via a WasteX web service:

1. Accessing EO's data that the CA receives in ways other than WasteX EDI transmissions, such as:
   • Data the EO added/edited via a web application GUI form
   • Data the CA added/edited, for example based on an email, fax or telephone call it received from the EO
2. Accessing data that the CA receives from other EOs or other CAs. For example, if the Austrian CA receives a MA by a Swiss EO via the Swiss CA, the Austrian consignee can access this MA via the WasteX web service

The first use case may also apply in future extension of the WasteX web service when the CA makes notification and consent information accessible via the WS.

Choosing the appropriate connection type

Apparently, if at least one of the two above mentioned uses cases of accessing (new) data from the CA via a WasteX web service is of relevance to EO users of a software solution, the software developer/provider shall implement a bidirectional connection to the WasteX web service.

Polling

Purpose

The web service features a polling operation named QueryUpdate.

Polling serves two purposes:

1. Asynchronous responses: Receiving the response to asynchronous web service operations. In particular, receiving signal messages in response to transmitting user messages
2. Data synchronization: Keeping the client in sync with data additions or changes occurring at the web service (CA) side (see CA to EO data flow use cases)

Undirectional connections only "listen" to asynchronous responses and ignore data synchronization updates.

Mode/interval of polling

Clients shall implement continuous uninterrupted polling, such as invoking the QueryUpdate operation every 5 minutes, 24 hours a day, 7 days a week.

Even in unidirectional connections, when at a specific point in time the WS client does not expect additional signal messages, the WS client shall not interrupt polling, as this could negatively impact EDI performance due to "uneven" and "cluttered" dissemination of user messages. Note that the web service does not distinguish between unidirectional and bidrectional connections - it is the WS client that ignores received user messages in an undirectional connection.

Polling frequency

WS clients shall poll (invoke the QueryUpdate operation) between every 2 minutes and every 30 minutes. Every 2 minutes is the minimum polling interval. The web service may reject a QueryUpdate invocation if less than 2 minutes have passed since the client's previous QueryUpdate invocation.

Client side state management

The querying of updates from a WasteX web service involves the management of state: “State” refers to distinguishing between the following:

1. Messages (user messages and signal messages) that the client already “knows”, that WasteX WS has already previously disseminated to the client, and that the WasteX WS therefore shall not provide to the client in the QueryUpdate output
2. Messages that the client does not yet “know”, and that the [EDM] WasteX WS shall therefore include in the QueryUpdate output

The following applies to the state management:

• The WasteX web service does not manage the state. It is the WS client that manages the state
• WS clients manage state via the [UUID] of the latest update available/known to the client
• The WS client passes such [UUID] to the WasteX WS upon each QueryUpdate invocation
• Each time the WS client receives non-empty output from a QueryUpdate invocation, i.e., each time it receives one or more updates (QueryUpdateResponse/Update), it uses the UpdateUUID from the last QueryUpdateResponse/Update element (last by sequential order within the [XML] instance) as its new state, i.e., it uses this value as the new [UUID] of the latest update available/known to the client. In short: In a series of QueryUpdate invocations, the client must use the output from one invocation as the input to the next invocation
• For the first in a series of QueryUpdate invocations, the WS client cannot use a [UUID] it knows from earlier QueryUpdate invocations. Instead, the WS client must use the InitSync operation for initalising the state [UUID] prior to the first QueryUpdate invocation in a series of invocations. The WS client passes a [UTC] timestamp as input to the InitSync operation. In its output, the InitSync operation delivers a [UUID] that best matches the [UTC] timestamp, so that the series of QueryUpdate invocations started with this [UUID] yields the all the updates (to which the WS client has access) newer than the [UTC] timestamp
• Note that a WasteX web service must keep track of updates for at least 4 weeks. Vice versa, a WasteX WS client shall pass a [UTC] timestamp to InitSync that lies anywhere between 4 weeks in the past and the current point in time

Transport layer security TLS

WS clients and the WasteX WS must use transport layer security (encryption) by applying/supporting [TLS] 1.2, and optionally applying/supporting higher versions of [TLS], such as 1.3.

UTF-8 encoding

UTF-8 character encoding provisions

The WS client must use [UTF‑8] character encoding for all input to WasteX WS operations, i.e., for [HTTP] POST request bodies and headers.

The WasteX WS must deliver all operation outputs in [UTF‑8] character encoding.

Character encoding characteristics

Note the following characteristics of character encodings:

1. There are commonly used character encodings other than [UTF‑8], such as [Latin‑1], which for certain common characters, including a-z, A-Z, comma and colon, yield the exact same encoding as [UTF-8]
2. There are byte sequences which cannot result from applying [UTF‑8] encoding to a character sequence. I.e., there are byte sequences for which [UTF‑8] decoding fails
3. Applying an encoding other than [UTF‑8] to a character sequence can result in a byte sequence for which [UTF‑8] decoding fails
4. Applying an encoding other than [UTF‑8] to a character sequence can result in a byte sequence that is a valid [UTF‑8] encoding, and for which [UTF‑8] decoding therefore works sucessfully. The character string resulting from [UTF‑8] decoding can however differ from the originally encoded character string!

Examples for these characteristics:

1. Both the [Latin‑1] encoding as well as the [UTF‑8] encoding of character sequence »Arm« result in byte sequence 41726d, provided here in hexadecimal representation
2. Byte sequence c3847261 is the [UTF‑8] character encoding of character string »Ära«. A slight modification of this byte sequence, resulting from changing a single bit, c3c47261, is however not a valid [UTF‑8] encoding. Trying to [UTF‑8] decode c3c47261 results in the »invalid continuation byte« error
3. The UTF-16 encoding of character string »Ära« is c40072006100. Trying to [UTF‑8] decode c40072006100 yields an »invalid continuation byte« error
4. The [Latin‑1] encoding of character string »RÄ®« is 52c4ae. 52c4ae is is also a valid [UTF‑8] encoding. However, applying [UTF‑8] decoding on 52c4ae yields character string »RĮ«, which is different from the orginally encoded character string »RÄ®«

Note that the effect of the first characteristic is that using a wrong character encoding can go completely undetected in EDI as long as exchanged data only contains characters such as a-z, A-Z, comma and colon, but does not contain more special characters such as ä, ö, ü, Ä, Ö, Ü or ß.

Due to these characteristics of character encodings, using a wrong character encoding in WasteX EDI, i.e., using a character encoding other than [UTF-8], can have the following effects:

1. The EDI node can not [UTF‑8] decode its input, and the operation, such as receiving a user message, fails (see case 3 above)
2. The EDI node can [UTF‑8] decode its input, but the character string resulting from [UTF‑8] decoding does not match the sender's character string (see case 4 above)
3. The EDI node can [UTF‑8] decode its input, and the character string resulting from [UTF‑8] decoding matches the sender's character string (no issues at all, see case 1 above)

Note that the WasteX WS reacts with a [SOAP] Fault (exception) if the [UTF‑8] decoding of the operation input fails (first case in the list above).

Testing recommendation

The character encoding characteristics described in the previous section lead to the following character encoding related testing recommendations:

1. Have character encoding related test cases with the transmission of "special characters", such as ä, ö, ü, Ä, Ö, Ü or ß
2. For character encoding related test cases, do not only check for successful transmission (no errors/warnings/infos), but also check the correct interpretation of characters at the receiver's end, such as in GUIs at the receiver's end. For example, verify that a transmitted »ä« indeed shows up as »ä« at the receiver's end

XSD validity of operation inputs and outputs

The WasteX WS automatically rejects any operation invocation with an operation input that is invalid with respect to wastex_webservice_types.xsd. It does so with a [SOAP] Fault (exception).

Vice versa, every WasteX WS operation output must be valid with respect to wastex_webservice_types.xsd. WS clients can automatically reject any operation output that does not comply with this provision.

Value ranges and precision

Upper size limits

The WasteX specification defines upper size limits for each of the data elements contained in messages and in operation inputs and outputs.

For example, the specification defines a maximum number of characters for each character string element, and a maximum number of decimal digits for each decimal number.

Note that the WasteX specification encodes these upper size limits in the [XSD]s , wastex_message.xsd and wastex_webservice_types.xsd. This means that a WasteX WS reacts with an [XSD] validation error [SOAP] Fault (exception) if the operation input contains one or more data elements that exceed the size limits.

The upper size limits are important for interoperability across EDI nodes. Developers of software solutions that participate in WasteX EDI shall adhere to these size limits as much as possible, such as at database level. This ensures interoperability by preventing both of the following:

1. Lack of interoperation due to the occurrence of automatic rejections caused by data instances exceeding size limits
2. Loss of data/precision in data transmissions, such as by truncating texts

Other value range restrictions and checks

For some data elements, the WasteX specification defines value range restrictions other than upper size limits. For example, most waste mass values must be greater than 0.

Note that the WasteX specification encodes such value range restrictions in the [Schematron] formal validation rules, rather than in [XSD]s. Violation of these other value range restrictions thus leads to validation protocol entries, but does not lead to [SOAP] Faults (exceptions).

As a result, there are the following options for developers of software solutions that participate in WasteX EDI:

1. Basic solution: Leave adhering to such other value range restrictions entirely to users. If a WasteX transmission violates any such a other value range restrictions, then users learn about the violation from the validation protocol, and can subsequently correct and re-transmit data
2. User friendly solution: Develop the software solution in a way that helps users with adhering to value range restrictions, such as by preventing certain input in GUIs or by pointing users to violations in GUIs prior to any EDI transmission

Accuracy and Precision

Data from different sources shall be well-suited for comparisons and aggregation. Numeric data shall have identical or similar accuracy and precision.

Even though the [WSR] does not define minimum accuracy and precision for data such as waste mass values, CAs typically expect certain minimum accuracy and precision for measured values.

Any value in WasteX messages/transmissions, which by the WasteX specification definition is the result of a measurement, or which the EO reports as the result of a measurement, shall contain only digits that are known exactly plus a final digit for which the associated uncertainty is at most ± 1.

Examples:

1. The CoWR contains the mass of received waste, together with a QuantificationTypeID of »M« for measurement, »C« for calculation and »E« for estimation, and a unitID which only supports »t« for metric ton. The mass value supports between 0 and 5 fractional digits. The following applies:
   • For a measured received mass of waste provided without fractional digits, the maximum acceptable uncertainty is ± 1 metric ton. Rounding to 10 t, i.e., just distinguising between 10 t, 20 t, 30 t, etc., would thus be insufficient!
   • For a measured received mass of waste provided with one fractional digit, the maximum acceptable uncertainty is ± 0.1 metric tons
   • For a measured received mass of waste provided with five fractional digits, the maximum acceptable uncertainty is ± 0.00001 metric tons
2. WasteX WS operation inputs and outputs contain UTC timestamps such as MessageCreationUTCTimestamp. According to the WasteX specification, such timestamps must contain exactly 6 fraction of a second decimal digits, as in 2023-06-15T10:34:02.523099Z. This means that the maximum acceptable uncertainty is ± 0.000001 seconds. Rounding to 0.00001 seconds, and creating/transmitting timestamp literals which always end in a 6th fraction of a second digit of 0, as in 2023-06-15T10:34:02.523090Z, would thus be insufficient!

Identification, Authentication and Authorization

Overview

Main principles:

1. Client Identification and Authentication: Only identified and authenticated web service clients can access/use a WasteX web service. This applies to all web service operations
2. Client Registration: Developers/operators of web service clients need to register the client with the web service prior to any interaction with the WasteX web service. Upon successful registration, developers/operators receive client credentials. The WS client must apply these credentials in each individual interaction with the WS
3. Service side EO client authorization: The WS keeps track of which WS client is allowed to represent which EO (allow list)
   • EOs can activate and deactivate registered WS clients for interacting with the WS in the name of that EO. For the time being, EOs must refer to the [EDM] helpdesk for activating and deactivating WS clients, see Contact. The BMK considers making such administration functionality available to EOs in the [EDM] GUI
   • In transmission operations (ShareMessage), the WS client must identify exactly one EO as the message creator (MessageCreationPartyID). The transmission fails if there is no entry for the combination of WS client and EO in the allow list
   • In data access operations (QueryUpdate), the WasteX WS filters the list of all updates based on the allow list and the update contents
4.  Independent user identification, authentication and authorization: Each individual WasteX EDI connection is a connection of two EDI nodes. If both EDI nodes support multiple users or even multiple parties (such as EOs), then developers/operators of the respective EDI nodes must take care of of the following concerns individually for each EDI node, and independently of the other EDI node. In particular, neither does the WasteX specification impose any specific way of addressing these concerns, nor shall the developer/operator of one EDI node impose any specific ways of addressing these concerns on developers/operators of the other EDI node. Instead, these remain concerns for which each software solution provider can and must come up with individual measures that convince and satisfy their (potential) customers:
   
   • For any user (natural person) interacting with the software solution, there is knowledge/information who the user is (identification), and there is sufficient "certainty" (extremely high probability) that the user is the one who (s)he claims to be (authentication)
   • Every user can only access the data and functionality that matches the user's role and rights with respect to an organization on behalf of which the user interacts with the software solution (authorization)
   • In a multi-party software solution, such as a cloud solution, parties (such as EOs) can only access data they are authorized to access - in particular, parties can typically only access their own data (confidentiality, authorization)

Some characteristics of these identification, authentication and authorization measures:

• Parties are in full control, such as over data access:
  • By default, WS clients cannot act in the name of any party, and cannot access any non-public data
  • A party needs to explicitly activate a WS client for a WasteX WS in order to enable the WS client to transmit and to access data for this party
  • A party can revoke a WS client activation at any time. For example, if an EO stops using a certain software solution, it can revoke WasteX WS access for that software solution
  • The WasteX WS operator can provide full transparency, such as for EOs on the activation/deactivation of WS clients and on interaction logs/statistics (which WS client has interacted for me with the WS when and in which ways). BMK as the operator of [EDM] plans to make such information available via the [EDM] GUI
• Operational security:
  • Only identified and authenticated WS clients can access a WasteX WS
  • If the WasteX WS operator identifies problems with certain WS interactions, it can identify the WS client and contact the WS client developer/operator for finding a solution
  • If certain WS interactions impair the WS operation, the WasteX WS operator can suspend the troublesome WS clients in order to keep the WS fully functional for the remaining WS clients
• Separation of concerns, modularity, interoperability - innovation-friendly and future-proof solution:
  • Keeping the individual EDI nodes' identification, authentication and authorization measures separate from each other makes it possibe to interconnect heterogenous software solutions
  • With the WasteX identification, authentication and authorization principles a large range of software solutions can participate in WasteX EDI: From multi-party&multi-user solutions, such as cloud solutions, to single-party&single-user solutions, such as standalone software solutions that anyone can download, install and use without any identification/authentication. The WasteX identification, authentication and authorization principles, in particular the service side EO client authorization, ascertain that for all such software solutions there is only authorized (data) access, and prevent any unauthorized (data) access.
  • Not mandating any specific identification, authentication and authorization measures for the individual EDI nodes makes it possible for software solution providers to offer the latest and most suitable security measures to their customers

For the sake of compactness, the WasteX specification does not describe the service side EO client authorization measures and functionalities in all detail. In case of security concerns, please refer to the [EDM] helpdesk to learn more details. See Contact.

Update synchronization and update filtering

As described in the overview, the WasteX WS keeps a "global list of updates", and decides based on data contents and EO client authorization which client "gets to see" which updates from that list:

• The allow list contains the information which WS client represents which EOs
• The WS limits the WS client's access to those updates and messages, for which at least one of the EOs that the WS client represents has the right to access the respective information
• In general, an EO has the right to access notification, decision and movement document information if, according to the notification data stored at service side, the EO occurs in at least one role, such as notifier, carrier, consignee or waste treatment party in the notification. In its current version, the [EDM] WasteX WS limits access to notifiers and waste treatment parties
• For example, if EO Waste Berlin has activated WS client WasteIT for interactions with the [EDM] WasteX WS, and if there is new/updated movement document information for a waste shipment in which Waste Berlin occurs in the waste treatment party role according to the notification stored in the [EDM] then the [EDM] WasteX WS grants the WS client WasteIT access to new or updated movement document information

The EOs in notification and consents are typically very stable in the sense that they do not change over time. However, EOs can change without requiring a new notification. For example, authorities can agree to consent an additional carrier for an existing notification with existing consents. A situation like this may require a special type of handling in the data exchange and synchronization. An illustrative example:

• We assume there is a fully consented notification N with EOs P1, P2, ..., Pn
• We assume that these EOs have completed 50 out of 100 shipments
• We assume that at this point the notifier requests to add an additional party Q to notification and consents, and that authorities consent to this request. We assume Q is an additional waste treatment party
• We assume that party Q uses WasteX client WasteIT, and that none of the parties P1, P2, ..., Pn uses WasteIT

In this scenario, the following applies:

• The first notification N related update the WasteX WS delivers to WasteIT is the update of the notification resulting from adding Q as waste treatment party to the notification
• Subsequently, the WasteX WS delivers all notification N related updates to WasteIT, such movement document data for shipments 51 to 100
• However, by regular synchronization via QueryUpdate calls in regular intervals, WasteIT will not receive any prior updates. In particular:
  • It will not receive earlier versions of the notification
  • It will not receive the authorities' earlier versions of decisions (note though that authorities will typically need to update decisions, such as by remarking that they agree to adding Q, and that WasteIT will receive such updates)
  • It will not receive movement document data for movements 1 to 50

In order for WasteIT to catch up with the earlier updates, it will need to re-synchronize updates, using an appropriate InitSync call with a start date several weeks in the past followed by a series of QueryUpdate calls. IT developers may make such re-sync functionality available to users with specific administrative roles.

Client Registration

Upon implementing and testing a connection to a WasteX WS, the WS client developer must register the client with the WasteX WS operator and use the credentials (Client-ID, Client-Secret) from client registration in each WS interaction. 

For the [EDM] WasteX web service, client developers/operators must refer to the [EDM] helpdesk for client registration. See Contact.

Note that the production and pre-production environments of the WasteX WS require different credentials.

Client Identification and Authentication

Overview

The WS client must use the credentials from registration in one of the following two ways in each interaction with the WS:

1. [HMAC]
2. [HTTP Basic Auth]

[HMAC] is the technically more secure variant.

Note that [EDM] makes the WS client's [HMAC]/[HTTP Basic Auth] authentication capabilities transparent to EOs, such as in the WS client activation GUI.

HMAC authentication

Overview

With the [HMAC] authentication method, the WS client uses the credentials from registration, Client-ID and Client-Secret, as follows:

The WS client transmits an [HTTP] Authorization Header with each web service interaction.

Note that the following is the generic pattern for [HTTP] Authorization Headers:

Authorization: <auth-scheme> <authorization-parameters>

The WS client uses a custom Authorization scheme with »EDM1« auth-scheme value and the following pattern:

Authorization: EDM1 clientID="<client-id>", clientHMAC="<hmac>"

The WS client uses the Client-ID character string from client registration as client-id value

The WS client calculates the hmac value as follows:

1. Compose the stringToSign character string
2. Calculate an [HMAC-SHA-256] value (byte sequence) from stringToSign and Client-Secret
3. Apply [Base64] encoding to the byte sequence from point 2

Composing the stringToSign

For the ShareMessage operation with user messages:

  stringToSign = transactionUUID + "\n" +
                 messageUUID + "\n" +
                 messageCreationPartyID

For the ShareMessage operation with signal messages:

  stringToSign = transactionUUID + "\n" + "\n"

For the InitSync operation:

  stringToSign = startFromUTCTimestamp

For the QueryUpdate operation:

  stringToSign = updateRangeStartUUID

The above definitions refer to the following operation input values:

transactionUUID

Content of ShareMessageRequest/TransactionUUID

messageUUID

Content of ShareMessageRequest/UserMessage/ WasteMovementUserMessage/MessageUUID

messageCreationPartyID

Content of ShareMessageRequest/UserMessage/ WasteMovementUserMessage/MessageCreationPartyID

startFromUTCTimestamp

Content of InitSyncRequest/StartFromUTCTimestamp without time-zone indication

Example: If the content of StartFromUTCTimestamp is 2021-04-19T14:35:43.699370Z, then startFromUTCTimestamp is 2021-04-19T14:35:43.699370

updateRangeStartUUID

Content of QueryUpdateRequest/UpdateRangeStartUUID

The following applies to using operation input for string composition:

• The WS client must use/insert the character strings exactly as they appear in the [XML] input to the operation. For instance, for [UUID] values the client must use the canonical representation from the [XML] input

• The WS client must use the [XML] element content only, and ignore any [XML] attributes. In particular, the web service client must ignore the registerID attribute for MessageCreationPartyID content

Calculating the HMAC-SHA-256 value

The WS client calculates the [HMAC-SHA-256] value (byte sequence) from the following two inputs:

1. data: byte sequence resulting from applying [UTF‑8] encoding to the stringToSign character sequence

2. key: byte sequence resulting from applying [UTF‑8] encoding to the Client-Secret character sequence

Applying Base64 encoding

The WS client applies [Base64] encoding to the byte sequence resulting from calculating the [HMAC-SHA-256] value. The WS client uses the following variant of [Base64] encoding:

• Variant with characters »+« and »/« for index values 62 and 63
• Variant with padding. This variant ensures that the length of the resulting character sequence is a multiple of 4. If needed, the encoding appends one or two »=« padding characters (0x3D) to the result for complying with this length constraint

Example

The client credentials for this example: Client-ID: WASTE_IT.CLOUD  Client-Secret: 6H!uU3w*hSyuzj

The ShareMessage operation input for this example (excerpt):

<soap12:Envelope>

  <soap12:Body>

    <wxt:ShareMessageRequest>

      <wxt:ClientInterfaceVersionID>1.08</wxt:ClientInterfaceVersionID>

      <wxt:ClientVersionID>3.3.2-1</wxt:ClientVersionID>

      <wxt:TransactionUUID>825afc6d-2d22-4f78-a0bf-fef1dd45d5eb</wxt:TransactionUUID>

      <wxt:UserMessage>

        <wxm:WasteMovementUserMessage>

          <wxm:MessageUUID>2ddea4a4-2ede-4734-967d-5d9ae904a02e</wxm:MessageUUID>

          <wxm:MessageCreationUTCTimestamp>2023-04-27T13:28:25.634198Z</wxm:MessageCreationUTCTimestamp>

          <wxm:MessageCreationDataFormatVersionID>1.08</wxm:MessageCreationDataFormatVersionID>

          <wxm:MessageCreationPartyID registerID="VAT.EU">IT02795790241</wxm:MessageCreationPartyID>

          <wxm:MovementAnnouncement>

For the ShareMessage operation with this input the stringToSign is:

  stringToSign = transactionUUID + "\n" +
                 messageUUID + "\n" +
                 messageCreationPartyID

In this example:

  "825afc6d-2d22-4f78-a0bf-fef1dd45d5eb" + "\n" +
  "2ddea4a4-2ede-4734-967d-5d9ae904a02e" + "\n" +
  "IT02795790241"

Applying [HMAC-SHA-256] to the [UTF‑8] encodings of stringToSign (data) and Client-Secret »6H!uU3w*hSyuzj« (key) results in the following byte sequence, represented here in hexadecimal notation:

  faea27f8df59bd2fe1cf971f9b7d0d30d017438eb11239e5ef73821ce5af754d

Applying [Base64] encoding to this value yields:

  +uon+N9ZvS/hz5cfm30NMNAXQ46xEjnl73OCHOWvdU0=

Thus, the WS client invokes the ShareMessage operation for the above-mentioned input with the following [HTTP] Header:

  Authorization: EDM1 clientID="WASTE_IT.CLOUD", clientHMAC="+uon+N9ZvS/hz5cfm30NMNAXQ46xEjnl73OCHOWvdU0="

HTTP Basic Authentication

Description

With the [HTTP Basic Auth] authentication option, the web service client uses the credentials from registration, Client-ID and Client-Secret, as follows:

The WS client transmits an [HTTP] Authorization Header with each web service interaction.

Note that the following is the generic pattern for [HTTP] Authorization Headers:

Authorization: <auth-scheme> <authorization-parameters>

The WS client uses the »Basic« auth-scheme.

Authorization: Basic <credentials>

The WS client constructs the credentials value in the following way.

1. Concatenate the following 3 character strings:
   • Client-ID
   • The character string consisting of a single character, » : « (colon, 0x3A)
   • Client-Secret
2. Calculate the byte sequence resulting from applying [UTF‑8] encoding to the concatenated character sequence
3. Apply [Base64] encoding to the byte sequence. The WS client uses the following variant of [Base64] encoding:
   • Variant with characters »+« and »/« for index values 62 and 63
   • Variant with padding. This variant ensures that the length of the resulting character sequence is a multiple of 4. If needed, the encoding appends one or two »=« padding characters (0x3D) to the result for complying with this length constraint

Example

The client credentials for this example, chosen identical to the [HMAC] authentication example for illustration purposes: Client-ID: WASTE_IT.CLOUD  Client-Secret: 6H!uU3w*hSyuzj

Concatenation of Client-ID, colon and Client-Secret yields the following character string:

WASTE_IT.CLOUD:6H!uU3w*hSyuzj

Applying [UTF‑8] encoding to the concatenated character sequence results in the following byte sequence, represented here in hexadecimal notation:

57415354455f49542e434c4f55443a364821755533772a685379757a6a

Applying [Base64] encoding to the byte sequence yields the following character string:

V0FTVEVfSVQuQ0xPVUQ6NkghdVUzdypoU3l1emo=

As a result, in this example the WS client uses the following [HTTP] header in each of its interactions with the web service:

Authorization: Basic V0FTVEVfSVQuQ0xPVUQ6NkghdVUzdypoU3l1emo=

Party identification

Introduction

Some of the payload contains the  identification of parties .

Example: The MovementAnnouncement – prior information regarding the actual start of a shipment, pursuant to Art. 16(b) [WSR] – contains, pursuant to the [WSR], information on the following parties:

• Carriers  for the particular shipment
• Waste producers  that are the origin of the particular shipment’s waste

The following applies to all WasteX  BP_AMBER_INFO messages, such as MA, CoWR and CoWT:

• The messages contain a  single party identifier for each party reference/identification , but do not contain party name and party address. Instead, every such party identifier must identify a party that the recipient already “knows”, in particular from notification/consent 

• A party’s complete identification consists of two parts

  • Party identifier

  • Register identifier, identifying the registration process from which the party identifier results and/or a specific way of looking the party up via its identifier
• The register identifier must reference an entry of ↗codelist 2237, such as VAT.EU for an EO's value added tax (VAT) identification number

Example:

    <wxm:CarrierPartyID registerID="GLN.AT">9110016663449</wxm:CarrierPartyID>

In this example, the party identifier is 9110016663449 and the register identifier is GLN.AT (for Austrian public administration Global Location Number, GLN).

Types of party identification

The WasteX specification distinguishes two types of party identification:

1. WasteX party identification scheme
2. Recipient specific party IDs

The following applies:

• Every WasteX web service MUST support the WasteX party identification scheme, and MAY support recipient specific party IDs
• Upon generating a message, software must use either the WasteX party identification scheme or recipient specific party IDs. Software MUST NOT use both WasteX scheme party IDs and recipient specific party IDs within one message
• A WasteX web service can support recipient specific party IDs for reasons such as compatibility with older data interfaces and giving users and/or implementers time for adjusting to WasteX scheme party IDs
• The [EDM] WasteX web service supports Global Location Number (GLN) assigned to parties and used in the EDM locally (EDM GLN) as recipient specific party IDs
• WasteX scheme party identifiers provide interoperability - it is possible to use them identically with any number of EDI nodes, EOs and CAs - whereas recipient specific party identifiers don't provide interoperability. The specification authors therefore strongly recommend using WasteX scheme party identifiers, and to use recipient specific party identifiers only if justified by very specific circumstances

Prerequisite of using matching parties and identifiers in notification and movement document

Important aspects with respect to party identification:

• All BP_AMBER_INFO messages contain a single party identifier for each party reference/identification, but do not contain party name and party address
• Instead, every such party identifier must identify a party that the recipient (such as CA) already “knows”
• Pursuant to the [WSR], the following applies to BP_AMBER_CONSENT/BP_AMBER_INFO: EOs must let CAs know of all (potentially) involved parties - including waste producers, notifier, carriers, consignee and waste treatment parties in advance - via the notification. In order for an individual shipment of waste to comply with CAs' consent, it is necessary that each carrier is one of the carriers from notification/consent, that each waste treatment party is one of the waste treatment parties from notification/consent, and so on
• The WasteX specification contains formal validation rules for checking if the movement document information complies with notification/consent information in the sense of the previous point; for example, to check if a carrier identified in an MA message indeed occurs in the corresponding notification/consent - see 🠖R356. These formal validation rules work by comparing party identifiers, i.e., by checking if for party identifiers occuring in WasteX movement document messages there is a respective matching party identifier in notification/consent

Practical impact on WasteX BP_AMBER_INFO EDI:

1. Identifying/referencing movement document parties not identified/referenced in the notification - such as carriers not named as carriers in the notification - leads to an automatic rejection of messages (ERROR entry in formal validation report)
2. The party identifiers from movement document messages must match party identifiers used by the recipient in relation to notification/consent information. EOs must provide all party identifiers that they intend to use in WasteX BP_AMBER_INFO EDI to CAs in the notification

WasteX party identification scheme

Main characteristics of the WasteX party identification scheme:

• Interoperability: Uniform identification of parties across all EDI nodes and involved parties
• Scalability: Usable/extensible to any number of EDI nodes and involved parties
• Decentralization/Efficiency/Reuse: The WasteX party identification scheme does neither introduce any new registration requirements, nor does it require any central registration (database)

Main principles of the WasteX party identification scheme:

1. Use of existing party identifiers from national/regional registrations, such as use of EO's tax identification numbers (VAT ID) or company identification numbers (from business registers)
2. The country of an EO's registered office determines the type of identifier to use for that EO in [WasteX] EDI

Two codelists define the WasteX party identification scheme:

1. ↗codelist 2237 distinguishes different types of party identifiers and databases/websites for looking them up, such us tax identification numbers (VAT.EU) and Global Location Numbers (GLN.AT)
2. ↗codelist 1387 maps countries (registered office countries) to party identifier types

Example:

Codelist 1387 contains the following mappings:

• AT to GLN.AT
• DE to VAT.EU
• FR to VAT.EU

This means that for EOs with the registered office located in France or Germany the WasteX relevant type of party identifier is the VAT ID, whereas for EOs that have their registered office in Austria it is the so-called public administration GLN.

Note that the WasteX specification uses ↗codelist 1387 and ↗codelist 2237 dynamically. This ensures the extensibility of the WasteX party identification scheme.

Updates, corrections and cancellations

General provisions

An EDI node can update/correct contents of a previously transmitted user message by re-transmitting that user message with updated/corrected contents.

The WasteX web service, and any WasteX EDI node receiving a WasteX user message, treats a received transmission as an update if its database already contains data for the respective IDs and types of contents (message types), in particular, in BP_AMBER_INFO, for the respective combination of notification number and waste shipment serial number (sequential number).

The following applies to updates and corrections:

• There are limits to the update ability. For example, formal validation rule 🠖R100 rejects transmissions, including updates, for cancelled shipments
• Note that according to the [WSR], all EO to CA data transmissions, including those of BP_AMBER_INFO, are transmissions of final/completed data
  • Final/completed refers to the sender's point of view at the respective point in the business process: The sender shall transmit data that she expects to be final, not requiring further supplementing or correction
  • The [WSR] does not ask for the repeated synchronization of temporary/incomplete data
  • Accordingly, the purpose of the WasteX EDI protocol is enabling the transmission of final/completed data, rather than e.g. the automatic synchronization of temporary/incomplete data instances. This approach reflects in all the specification. For example, there are formal validation rules for rejecting messages upon incompleteness, such as 🠖R489 for rejecting a confirmation of waste receipt that lacks the received mass of waste
  • Even though senders transmit data that they consider final, it can turn out that transmitted data is wrong and needs correction. It is for such cases, which occur as exceptions only, that the WasteX protocol offers update and correction capabilties to the sender
  • A high number (ratio) of updates and corrections can hint at an abuse of the WasteX protocol for the automatic synchronization/update of incomplete/temporary data, and can lead to formal validation report entries, such as by formal validation rule 🠖R342
• Note that in BP_AMBER_INFO the notifier announces a mass of waste to be shipped (MA message), and the consignee reports a received mass of waste (CoWR message). The notifier MUST NOT update/correct the MA transmission with the received mass of waste, as reported by the consignee

Movement announcement cancellation

It can happen that EOs plan a waste shipment (start date, route, etc.), announce it to CAs, but eventually realize that they cannot conduct the waste shipment. In such cases, the notifier must inform CAs about the cancellation of an announced waste shipment. The notifier can do so via WasteX EDI, by transmitting a  MovementAnnouncementStatus message. Note that new transmissions of MovementAnnouncement messages can update movement announcement contents, such as the mass of waste to be shipped, but cannot cancel the announcement.

The WasteX EDI protocol does not support the reuse of combinations of notification number and serial number (sequential number) of cancelled announcements for new announcements.

Postponing announced movements

The WasteX EDI protocol technically supports the postponing of announced movements by transmitting a new (later) shipment start date for the combination of notification number and serial number of an already announced shipment.

Note though that CAs apply a variety of policies with regard to postponing announced movements. For instance, some CAs may not accept postponing at all (and rather expect cancellations, potentially followed by new announcements), and some CAs may accept postponing only under certain conditions and/or to a certain extent.

Handling limited predicatability of movement announcements

According to the [WSR], the notifier must announce shipments of waste at least 3 working days before the shipment starts.

There are scenarios in which it is difficult to correctly "predict" the individual shipments of waste 3 working days in advance.

Example scenario: Trucks commute between an excavation site and a backfilling site in a neighbouring country, with hundreds of waste shipment per day. Apparently, it is nearly impossible in such a scenario for an EO to correctly predict the exact number of individual shipments 3 working days in advance.

There are two main approaches to handling such limited predictability:

1. Early pre-emptive announcement / allocation
   • For each day at which shipments take place, the notifier announces a sufficiently high number of shipments so that the actual number of shipments will be lower or equal
   • The notifier transmits these announcements at least 3 working days before the shipment starts, in line with the [WSR] provisions
   • Once the notifier knows the actual number of shipments at that specific day, such as by the end of that day, it cancels or postpones all "surplus"/"left-over" movement announcements
2. Just in time actual announcement
   • In the notification/procedure, the notifier asks all involved CAs for permission to provide "just in time announcements", arguing with the limited predictability of shipments
   • If the involved CAs agree to just-in-time announcements, then it is sufficient for the notifier to transmit the movement announcement at any time prior to the start of the journey. For example, transmissions can trigger automatically when a truck passes a weighbridge at the excavation site
   • There is normally no need to cancel or postpone any movement announcements

The following applies to handling limited predactability in WasteX EDI:

• Technically, WasteX supports both approaches, early pre-emptive announcement / allocation and just in time actual announcement
• As described earlier, notifiers must use the just in time actual announcement approach only upon explicit permission by all involved CAs

The WasteX specification authors strongly recommend using the just in time actual announcement approach to the greatest possible extent, and using the early pre-emptive announcement / allocation approach to the smallest possible extent. Advantages of the just in time actual announcement approach:

• It complies with the principle of transmitting final/completed data
• Easier and more efficient handling for EOs, as there is no need for pre-emptive allocation and later cancelling/postponing
• Fit-for-purpose information flows:
  • Almost no changes to inspections, environmental control, etc.
  • No dilution of movement announcement information: It is hard for EOs and CAs to distinguish between "actual" announcements and "pre-emptive" announcements - accepting or encouraging pre-emptive announcements thus dilutes all movement announcement information, whereas the just in time approach doesn't

Transmission triggers

Types of triggers

This specification distinguishes the following transmission triggers:

TRG_AUTO_DATA

This refers to an EDI node automatically triggering a message transmission as soon as new or updated data of sufficient maturity/finality becomes available at that EDI node, such as resulting from a user entering or editing data in a GUI.

This does not refer to a scenario in which a user explicitly triggers the EDI transmission of data, such as by pressing a “send” button.

TRG_AUTO_TIMER

This refers to an EDI node automatically triggering a message transmission as soon as the EDI node detects reaching or exceeding a certain point in time.

TRG_MANUAL

This refers to a software user explicitly triggering the transmission of a message by conducting a user interaction, such as pushing a “send” button.

This does not refer to a scenario in which a user interaction, such as the entering (completion/saving) of data, implicitly triggers an EDI transmission.

Triggering provisions

EDI nodes shall support TRG_MANUAL for all types of user messages as a means for (certain) users to handle transmission issues.

For announcements, in particular MAs, EDI nodes can support TRG_AUTO_DATA, TRG_AUTO_TIMER or both (in addition to TRG_MANUAL, as explained above). When supporting TRG_AUTO_DATA and TRG_AUTO_TIMER, EDI nodes may leave it to users to select the type of trigger, such as through a per-notification/consent configuration.

TRG_AUTO_TIMER for announcements refers to an automatic triggering of transmissions when reaching a certain point in time, in particular when getting close to the transmission deadline. EDI nodes will typically need to support users with data completion in time, such as through reminders. With regard to TRG_AUTO_TIMER it is important to conduct transmissions sufficiently in advance, so that in the case of unsuccessful/rejected transmissions the sender has sufficient time for correction and re-transmission prior to passing the deadline.

For reports, such as CoWR and CoWT, EDI nodes shall support TRG_AUTO_DATA but not TRG_AUTO_TIMER, as there is no point in delaying the transmission when the complete set of data is already available.

Bulk transmissions

A client to a WasteX WS may have multiple messages waiting for transmission. This specification calls an EDI node’s operation on a queue/backlog of messages waiting for transmission bulk transmission . I.e., the term refers to the (intended) transmission of a potentially larger number of messages within a short period of time, such as a few minutes or hours.

The WasteX specification defines means for real time data interchange and for the transmission of individual messages, i.e., the exchange of data when it is “finalized” and ready for transmission, independent of when that is (which day of the week, in the morning, in the night, etc.). This means that the specification does not focus on bulk transmissions. Instead, the specification authors recommend keeping bulk transmissions to a minimum, and only using bulk transmissions when necessary.

The following two are scenarios in which in which bulk transmissions can become necessary in WasteX data interchange:

1. Late transmissions for “catching up” after an interruption of the data exchange, such as after an outage of the [EDM] WasteX WS (see handling of outages)
2. Timed transmissions, such as movement announcement transmissions that automatically trigger once a day prior to reaching the transmission deadline

For the implementation of bulk transmissions, it is important to take into account the “number of transactions per unit of time” limits described under supported load. Depending on the number of messages to transmit, it may become necessary to spread the transmissions out to multiple hours of the day (transmission of n messages per hour, for each hour until all messages waiting for transmission have been sent), or even to multiple days.

For keeping bulk transmissions to a minimum, timed transmissions shall trigger at least once per day.

Sender and receiver side responsibilities

The following applies to responsibilities in relation to failed (auto-rejected) WasteX EDI transmissions:

1. It is each EDI node operator's responsibility to keep EDI nodes up and running, and to keep downtimes as short as possible
2. The sender side is responsible for initiating all attempts at resolving failed transmissions. The sender side cannot and must not rely on the receiver side to initiate any such steps
3. If a transmission fails due to an operational issue or downtime at the receiver side, then the sender side's attempt at resolving the issue shall start with simply re-attempting transmission at a later point in time (so as to check if the receiving EDI node has resumed full operation)
4. Depending on the type of issue, the sender side may need to get in touch with the receiver for resolving failed transmissions, such as for entering or correcting data at the receiver side (user level), or for re-establishing regular operation of the web service (technical operation level) prior to re-transmission

Signal message sender/receiver indication

Signal messages that signal rejection contain the ReceiverFailureIndicator indication. WS clients SHALL display this information to users as part of the signal content.

The meaning of the indicator is as follows:

• true means that resolving the (transmission) rejection is certain to require receiver side involvement, i.e., that it is certain the sender side cannot resolve the issue on its own

• false means the following:

  • The sender side may be able to resolve the issue on its own, i.e., without involving the receiver side
  • It is however not certain that the sender side can resolve the issue without involving the receiver side

The purpose of the indicator, and the expected sender side reactions:

A ReceiverFailureIndicator indication set to true means the following for sender side users:

• Depending on the signal content, sender side users may initially, such as for two hours, want to observe if automatic retries succeed
• In certain cases retries may help, but apart from that there is nothing the sender side can do on its own for fixing the issue - it will need the receiver side for doing so
• Upon noticing the transmission error and the futility of (potential) transmission retries, sender side users shall get in touch with the receiver side for fixing the issue

A ReceiverFailureIndicator indication set to false means the following for sender side users:

• In most cases, the sender side will not be able to resolve the issue by conducting transmission retries identical to the previously failed transmission
• The sender side, possibly involving sender side IT support, shall check and try if it can resolve the issue at sender side without getting in touch with the receiver side
• Only if it turns out that the sender side cannot resolve the issue on its own shall it get in touch with the receiver side for resolving the issue

Transmission retries

Automatic retries

For transmissions that fail due to an operational issue or downtime at the receiver side, the sending EDI shall keep track of such failed submissions (queue), and shall attempt automatic re-transmission at intervals such as the following:

• 20 minutes after the sending EDI node first learns about the operational issue at the addressed EDI node
• after 40 minutes
• after 60 minutes
• after that, once per day

When transmissions still fails after 60 minutes, EDI nodes shall use temporary fallback communication channels, in particular the sending of unstructured email, if the recipient supports this. In parallel, the EDI node shall keep re-trying WasteX EDI transmissions as indicated above.

Manual retries

EDI nodes shall provide the following functionality to (certain) users:

• Manual triggering of a re-transmission attempt for an individual message
• Manual triggering of a re-transmission attempt for all transmissions waiting for automatic re-transmission (see automatic retries)

Recommended reactions to certain EDI behaviour

Timeout / No response / network errors

This can occur under regular circumstances, such as during a scheduled downtime (deploy of a new version of a WasteX web service)

Sender side software reaction:

• • Automatic retries
  • Use of temporary fallback communication channels, in particular unstructured email, after 60 minutes, if the recipient supports this
  • Interrupt bulk transmission if the error occurs during bulk transmission

Sender side user reaction:

Typically no reaction required. Users may want to check back after a while if regular EDI transmissions have resumed

Sender side IT support reaction:

None required

SOAP fault

This occurs as an exception, such as in response to a malformed (non XML Schema compliant) request or in in response to failed authentication

Sender side software reaction:

• • Display information to users that a technical problem requires IT support
  • If this occurs in bulk transmissions: end/interrupt bulk transmission

Sender side user reaction:

Pass issue to sender side IT support

Sender side IT support reaction:

Try resolving the issue without getting in touch with receiver side IT support, such as by improving message generation or authentication. Only get in touch with receiver side IT support if this turns out necessary 

Missing signal

This occurs as an exception when the receiving WasteX EDI node initially reacts with a SOAP message rather than a SOAP fault, but then after that there is no signal message for more than 60 minutes

Sender side software reaction:

• • Automatic transmission retries
  • If the signal remains missing after retries: Display information to users that a technical problem requires IT support

Sender side user reaction:

If the signal remains missing after retries: Pass the issue to sender side IT support

Sender side IT support reaction:

Get in touch with receiver side IT support for resolving the issue

Rejection signal

This can occur under regular circumstances, such as when critical data is missing in transmitted messages

Sender side software reaction:

• • Display transmission status information to users, including SignalID, ReceiverFailureIndicator and SignalDescription, plus the formal validation report if available

  • Alert users that the transmission was unsuccessful and that they need to take steps (interact with the software) to resolve the cause and initiate a re-transmission attempt

Sender side user reaction:

• • Based on the information received in the signal, resolve the cause of transmission failure and initiate a re-transmission attempt
  • If needed, get in touch with receiver side users, for example, if notification/consent information is missing or wrong at the receiver side

Sender side IT support reaction:

Typically none required

Acceptance signal with INFO or WARNING formal validation result

This can occur under regular circumstances, such as when there are inconsistencies in transmitted messages

Sender side software reaction:

• • Display transmission status information to users, including SignalID, ReceiverFailureIndicator and SignalDescription, plus the formal validation report if available

  • Alert users that software validation has yielded hints at potentially problematic content, and advise users to review data, and – if necessary – to update and re-transmit data

Sender side user reaction:

• • Review data based on the information received in the signal, and, if needed, add/edit data and initiate a re-transmission

  • If needed, get in touch with receiver side users. For example, a user may find that the cause of a hint is wrong or missing data at receiver side, such as a missing consent, or a carrier missing from the consent. In such a case, the sender side user attempts re-transmission after the receiver side user has confirmed that receiver side data is fixed

Sender side IT support reaction:

None required

Acceptance signal with OK formal validation result

This occurs under regular circumstances

Sender side software reaction:

Display transmission status information to users (confirmation of successful transmission)

Sender side user reaction:

None required

Sender side IT support reaction:

None required

Specifics of the Austrian web service

Client/service

The Austrian CA operates the [EDM] WasteX web service:

• Conducting WasteX EDI with the Austrian CA requires implementation of a client to the [EDM] WasteX web service
• Conducting WasteX EDI with the Austrian CA does not require the implementation and operation of any web service
• The Austrian CA cannot currently connect to another WasteX web service as client
• Similarly, if other CAs want to offer waste shipment EDI via the WasteX EDI protocol, the specification authors recommend that the CA operates the web service, and that EOs use clients for connecting with that web service

Service level

The Austrian Environment Agency operates the [EDM] WasteX web service under the general [EDM] service level conditions. See edm.gv.at, “Technische und organisatorische Spezifikationen”, “Allgemeine Betriebsbedingungen”.

In particular, the web service can become unavailable temporarily due to scheduled maintenance on Tuesdays and Thursdays from 18:00 local time (CET/CEST).

Handling of outages

When a WS client attempts transmission to the web service, the web service may not be available. For example, a timeout may occur because of planned maintenance of the [EDM] WasteX web service.

Note that this section applies to neither of the following:

• regular reactions to web service interactions (regular [SOAP] response messages)
• receipt of signal messages indicating automated rejection

The following list contains recommendations for handling such outages. The recommendations mainly target WasteX EDI IT developers, but also affect WasteX EDI users:

1. Attempt automatic re-transmissions, rather than requiring users to re-trigger transmissions manually, for transmissions that the WS client cannot conduct due to a WasteX WS outage
2. MAs, MA cancellations and CaCs may require transmission within a short period (a few hours, the same day) for meeting the legal requirements. For [EDM] WasteX WS outages that lasts longer than 60 minutes, EDI nodes can email the information to wastex@bmk.gv.at automatically, i.e., without user interaction. Note:
   
   • The email body shall contain the information as natural language plaintext
   • The email must not contain attachments, such as PDFs
   • This applies to MAs, MA cancellations and CaCs only. EDI nodes must not send emails to wastex@bmk.gv.at for any other message types and their contents, such as CoWR or CoWT
3. The purpose of emails to wastex@bmk.gv.at is transmitting in time. Emails to wastex@bmk.gv.at do not replace electronic structured data transmissions, such as those via the [EDM] WasteX web service. Instead, when the web service returns into an operational state, the client shall conduct all previously delayed transmissions, independent of whether or not it has sent emails to wastex@bmk.gv.at for the respective transmissions
4. Note that the timing-related formal validation rules offer “timing tolerance” of a few days in order to support recovery of EDI transmission after transmission failures. For example, the formal validation rules accept MA transmissions even after the start date. This means that even with outages that last several days, the sender side can comply with all requirements by doing the following:
   • Send emails while the outage lasts – for compliance with timing requirements
   • Conduct EDI transmission once the outage ends – for compliance with the structured data transmission requirement

Supported load

The WasteX specification defines means for real time data interchange and for the transmission of individual messages, such as individual movement announcements. For the sake of a simple and clean web service with low maintenance costs, the WasteX specification does not define means for transmitting multiple messages at once.

As a result of this WasteX design decision, the number of waste shipments that EOs conduct within a particular period of time can directly (linearly) reflect in the number of interactions with a WasteX web service, such as the [EDM] WasteX WS. Accordingly, operators of a WasteX WS must adjust its load capacity to the number of shipments for which parties use the respective WS.

As of 2023, the [EDM] WasteX WS supports the following number of interactions per WS client and unit of time:

As explained under Polling, WS clients MUST NOT invoke the QueryUpdate operation more frequently than every 2 minutes.

Exceeding these limits can result in interaction rejections, i.e. [SOAP] faults.

Recipient specific party IDs

The [EDM] WasteX web service supports Global Location Number (GLN) assigned to parties and used in the EDM locally (EDM GLN) as recipient specific party IDs. There is no separate entry for this type of identifiers in ↗codelist 2237. Instead, software must use EDM GLN identifiers in combination with GLN.AT registerID attribute values.

As noted earlier, due to the lack of interoperability the specification authors advise against using recipient specific party IDs.

Unsupported contents

As of version 1.09, the [EDM] WasteX WS does not yet support the transmission of carrier confirmations. 

Note that the WS reacts with INFO validation protocol entries upon attempts of transmitting carrier confirmations. The WS "ignores" carrier confirmation contents. In particular, there is no structured storage of these contents and receiver side users do not have access to these contents.

Codelists

Introduction

For several data elements, the WasteX specification uses the codification of information and defines sets of permitted values. Examples:

• Values ACCEPTED, REJECTED in WasteMovementSignalMessage/SignalID
• Values 1 (for drum), 2 (for wooden barrel), …, 9 (for other) in MovementAnnouncement/PackagingTypeID
• Values 040 (for Austria), 276 (for Germany), 380 (for Italy), … in NationalRoute/CountryID

For several of these data elements, the WasteX specification refers to Environment Agency Austria maintained codelists with their respective 4-digit identifier. Examples:

• Reference to ↗codelist 3862 countries for data element NationalRoute/CountryID
• Reference to ↗codelist 6524 packaging types for data element MovementAnnouncement/PackagingTypeID

Codelist example

The following table illustrates the first few entries of ↗codelist 6524 packaging types:

Codelist characteristics

The following are codelist characteristics:

• A table within which each row represents attributes of an element from a set
• One or more code/ID columns
• Zero or more columns with natural language texts (names, descriptions) or other types of information (such as population sizes or other numerical information)

Codelist uses

The following are main uses of codelists in IT:

1. Lookup of characteristics: Storage and exchange of information uses codelist elements’ codes/IDs only. Where software needs to access elements’ attributes, such as name or description, it does so by looking the information up in the codelist (in: code; out: attribute)
2. Defining sets of supported/permitted values: A codelist may define the set of elements from which one element must be selected/identified in a given context
3. Good adaptability (quick, low cost, synchronized/interoperable): There are changes that can occur at any time, and to which software solutions shall adapt quickly, at low cost, and with respect to EDI in a synchronized and interoperable manner. Codelists are well-suited for providing such adaptability

One specific and commonly occurring case of lookup is translation between codified information and human-readable natural language text: For example, the use of codified information, such as packaging type codes 1 to 9, is common and advantageous in data electronic storage, access and exchange. However, the usability of user interfaces and export formats benefits from using more than just codified information, especially human-readable natural-language texts, such as names and descriptions. Software solutions use codelists for "translating" from the first of the following two items to the second:

1. The codes/IDs used e.g. in databases, data exchange, etc.
2. The natural language texts of user interfaces, export formats, etc.

Codelists are also good for combining interoperability with localization. If, for example, there is one software solution A used in Italian speaking regions, and one software solution B used in German speaking regions, then the codelist use can be as follows:

• In databases and data exchange, all software solutions use the same codes/IDs, such as 1, 2, 3, ... for types of packagings, so that there is good interoperability between the software solutions
• Software solution A uses a local codelist variant with names and descriptions in Italian, such as 1 Fusto, 2 Barile di legno, 3 Tanica, whereas software solution B uses a local codelist variant with names and descriptions in German, such as 1 Trommel/Fass, 2 Holzfass, 3 Kanister. This is a very simple and efficient approach for localization: Users can access information in their native languages, and yet there is also full interoperability

One example for adaptability via codelists is nations uniting or splitting, which apparently can occur anytime independent of any changes to waste shipment regulation. When a new country comes into existence, software solutions shall be quick to provide users with the possibility of selecting/identifiying the respective country, such as for the waste shipment country of destination. In EDI, the whole network of connected EDI nodes shall be quick and as synchronous as possible in adapting to this change, avoiding a lack of interoperability, in which the sender "understands" a new country, but the recipient does not yet "know" that new country. When striving for high levels of adaptability, it is a good practice for software developers to make codelist updates possible, effectively by replacing codelist database or file content, in the following ways:

1. without requiring new software builds or deploys
2. ideally without requiring any IT support (for instance, by automatic updates via web services and/or by letting users update codelists)

Codelist languages

The Austrian Environment Agency administrates and publishes all WasteX codelists, i.e. codelists that the WasteX specification uses/references, with natural language content - names, descriptions, etc. - in two languages, English and German.

The Austrian Environment Agency will add content in additional languages on demand.

Codelist web service

The Austrian Environment Agency publishes all codelists that this specification references not only on the [EDM] website, but also for machine access via an [EDM] codelist web service. Implementers/operators of a connection to a WasteX web service may for example choose implementing daily checks for codelist updates via this web service, so that they fully automate keeping local codelist copies up-to-date.

The specification authors advise software developers interested in using the [EDM] codelist web service to get in touch with the [EDM] helpdesk. See Contact.

Static and dynamic usage of codelists

Static usage

The following characterises the static use of codelists by this specification:

• This specification (rather than the used codelist) defines the set of supported/permitted values
• When there are updates to the underlying codelist, these updates do not automatically reflect in this specification. Instead, it is only new versions of this speciciation which may take over the updates of underlying codelists into the specification (such as in cases where this appears necessary or advisable)
• For software developers basing software on this specification, it is advisable to implement the software with good (fast, efficient) adjustability to updates of codelists used by the specification. However, for codelists that the specification uses statically this applies to a lesser degree than for codelists that the specification uses dynamically. With codelists the specification uses statically there can be cases where it is justified for software developers to "hard-wire" supported/permitted values into the software for reasons such as simplicity, performance or efficiency, thus requiring new software builds/deploys if a new version of the specification uses a different set of supported/permitted values

Dynamic usage

The following characterises the dynamic use of codelists by this specification:

• The codelist (rather than this specification) defines the set of supported/permitted values
• The files in the specification, in particular the [XSD]s, do not contain an enumeration of permitted values (xs:enumeration)
• Specification updates and codelist updates can occur independent of each other
• In particular: For implementations which follow this specification it can at any time become necessary to support an updated set of permitted values. This applies independent of the following:
  
  1. The publication of a new version of the specification. I.e., the published specification and its version can remain entirely unchanged, and yet it can become necessary for implementations to support an updated set of permitted values
  2. Further development of a software in order to support a new version of the specification. I.e., software can remain unchanged with respect to the version of the specification it implements, and yet it can become necessary for the software to support an updated set of permitted values
• Software developers shall enable fast and cost efficient updates of such sets of supported/permitted values. In particular:
  • The adjustments to support new values shall not require new software builds and/or deploys, but rather just an adjustment of database contents or configuration files
  • The adjustments to support new values shall be a matter of hours. This shall also apply in the case of a large number of running instances of the software and in cases where there is no central control over where such instances of the software are running

Example

The WasteX specification uses ↗codelist 3862, the list of countries, dynamically. This is because new countries can come into existence, and existing countries can vanish (such as when two countries unite into one new country) independent of any changes to the Waste Shipment Regulation or other waste shipment specific provisions. Hence software with waste shipment data exchange capabilities must be quickly and efficiently adaptable to new sets of countries.

Codelists which the specification uses statically

• ↗8149 Modes of transport according to the EU Regulation on Shipments of Waste and to UN/ECE Recommendation 19
• ↗6524 Packaging Types
• ↗7299 Quantification types
• ↗6099 Results of formal validation
• ↗1812 WasteX user message types

Codelists which the specification uses dynamically

• ↗1387 Assignment between registered office countries and party identification schemes according to WasteX
• ↗3862 Countries
• ↗2237 WasteX party identification schemes

Web service operations (from wastex_webservice.wsdl)

Introduction

Description of the web service operations defined by ↗wastex_webservice.wsdl. wastex_webservice.wsdl describes the web service operations with the standardised formal language ↗Web Services Description Language (WSDL) 2.0.

This description is auto-generated from an annotated variant of ↗wastex_webservice.wsdl. The specification package does NOT contain the annotated variant of the file. The specification authors make the annotated variant of the file available upon request.

Contents

Operations

ShareMessage

InitSync

QueryUpdate

Operations

ShareMessage

InitSync

QueryUpdate

Inputs and Outputs of the web service operations (from wastex_webservice_types.xsd)

Introduction

Description of the data formats defined by the XML Schema Definition wastex_webservice_types.xsd. The description covers:

1. Syntax: Data element names, structures, substructures and data types with value ranges (sets of supported values)
2. Semantics: Definition of each data element content's meaning and interpretation

This description is auto-generated from an annotated variant of ↗wastex_webservice_types.xsd. The specification package does NOT contain the annotated variant of the file. The specification authors make the annotated variant of the file available upon request.

Contents

Structures

ShareMessageRequestType

ShareMessageResponseType

InitSyncRequestType

InitSyncResponseType

QueryUpdateRequestType

QueryUpdateResponseType

FailureResponseType

Substructures

SignalMessageType

UpdateEventType

UserMessageType

Data types

FailureTypeIdentifierContentType

IndicatorContentType

PredeterminedScopeReferenceIdentifierType

Token64Type

UUIDIdentifierContentType

VersionIdentifierType

Structures

ShareMessageRequestType

ShareMessageRequestType usage occurrences: 🠖ShareMessage

ShareMessageResponseType

ShareMessageResponseType usage occurrences: 🠖ShareMessage

InitSyncRequestType

InitSyncRequestType usage occurrences: 🠖InitSync

InitSyncResponseType

InitSyncResponseType usage occurrences: 🠖InitSync

QueryUpdateRequestType

QueryUpdateRequestType usage occurrences: 🠖QueryUpdate

QueryUpdateResponseType

QueryUpdateResponseType usage occurrences: 🠖QueryUpdate

FailureResponseType

FailureResponseType usage occurrences: 🠖InitSync, 🠖QueryUpdate, 🠖ShareMessage

Substructures

SignalMessageType

SignalMessageType usage occurrences: ShareMessageRequestType, UpdateEventType

UpdateEventType

UpdateEventType usage occurrences: QueryUpdateResponseType

UserMessageType

UserMessageType usage occurrences: ShareMessageRequestType, UpdateEventType

Data types

FailureTypeIdentifierContentType

FailureTypeIdentifierContentType usage occurrences: FailureResponseType

IndicatorContentType

IndicatorContentType usage occurrences: QueryUpdateResponseType

PredeterminedScopeReferenceIdentifierType

PredeterminedScopeReferenceIdentifierType usage occurrences: InitSyncRequestType, InitSyncResponseType, QueryUpdateRequestType, QueryUpdateResponseType, ShareMessageRequestType, ShareMessageResponseType

Token64Type

Token64Type usage occurrences: PredeterminedScopeReferenceIdentifierType

UUIDIdentifierContentType

UUIDIdentifierContentType usage occurrences: QueryUpdateRequestType, ShareMessageRequestType, UpdateEventType

VersionIdentifierType

VersionIdentifierType usage occurrences: InitSyncRequestType, InitSyncResponseType, QueryUpdateRequestType, QueryUpdateResponseType, ShareMessageRequestType, ShareMessageResponseType

Message formats (from wastex_message.xsd)

Introduction

Description of the data formats defined by the XML Schema Definition wastex_message.xsd. The description covers:

1. Syntax: Data element names, structures, substructures and data types with value ranges (sets of supported values)
2. Semantics: Definition of each data element content's meaning and interpretation

This description is auto-generated from an annotated variant of ↗wastex_message.xsd. The specification package does NOT contain the annotated variant of the file. The specification authors make the annotated variant of the file available upon request.

Contents

Structures

WasteMovementUserMessage

WasteMovementSignalMessage

MessageValidationContext

DatabaseInstancePartyCollection

WithdrawalMarkCollection

Substructures

MovementAnnouncement

MovementAnnouncementStatus

CarrierConfirmation

ConfirmationOfWasteReceipt

ConfirmationOfWasteTreatment

AnnouncementIdentity

CarrierEconomicOperator

CountryList

CountryListElement

DatabaseInstancePartyList

Decision

EconomicOperator

EconomicOperatorSite

EconomicOperatorSiteIdentity

FormalValidationReport

LatestCarrierConfirmation

LatestConfirmationOfWasteReceipt

LatestConfirmationOfWasteTreatment

LatestMovementAnnouncement

LatestNotification

LatestTransportMovement

MassValueAssignmentStatement

NationalRoute

NotificationCountry

Notification

Party

TransportMovement

ValidationNodeAggregatedChangeData

ValidationNodeAggregatedContentData

ValidationNodeIndividualData

ValidationNodeReferenceData

VolumeValueAssignmentStatement

WithdrawalMarkList

Data types

CountContent

CountIdentifierContent

CountryIdentifierContent

CountryTwoLetterIdentifierContent

DateContent

DescriptionContent

EconomicOperatorIdentifier

EconomicOperatorRegisterIdentifierContent

IndicatorContent

MassNumericValue

MassUnitIdentifierContent

MovementAnnouncementStatusIdentifierContent

MaxLen1000TextContent

MovementAnnouncementUpdateStatusIdentifierContent

NameContent

PackageTypeIdentifierContent

PartyIdentifier

PartyRegisterIdentifierContent

PostalAreaIdentifierContent

QuantificationTypeIdentifierContent

RelaxedIdentifierContent

RemarkContent

ShortNameContent

SignalIdentifierContent

TimestampContentType

TransportModeIdentifierContent

TreatmentScopeIdentifierContent

UserMessageTypeIdentifierContent

UUIDIdentifierContent

ValidationResultIdentifierContent

ValueContent

VersionIdentifier

VolumeNumericValue

VolumeUnitIdentifierContent

WasteTypeIdentifier

WasteTypeIdentifierContent

WasteTypeListIdentifierContent

Structures

WasteMovementUserMessage

WasteMovementUserMessage usage occurrences: MessageValidationContext, 🠖UserMessageType

WasteMovementSignalMessage

WasteMovementSignalMessage usage occurrences: 🠖SignalMessageType

MessageValidationContext

DatabaseInstancePartyCollection

WithdrawalMarkCollection

Substructures

MovementAnnouncement

MovementAnnouncement usage occurrences: WasteMovementUserMessage

MovementAnnouncementStatus

MovementAnnouncementStatus usage occurrences: WasteMovementUserMessage

CarrierConfirmation

CarrierConfirmation usage occurrences: WasteMovementUserMessage

ConfirmationOfWasteReceipt

ConfirmationOfWasteReceipt usage occurrences: WasteMovementUserMessage

ConfirmationOfWasteTreatment

ConfirmationOfWasteTreatment usage occurrences: WasteMovementUserMessage

AnnouncementIdentity

AnnouncementIdentity usage occurrences: CarrierConfirmation, ConfirmationOfWasteReceipt, ConfirmationOfWasteTreatment, MovementAnnouncement, MovementAnnouncementStatus, WasteMovementSignalMessage

CarrierEconomicOperator

CarrierEconomicOperator usage occurrences: LatestNotification

CountryList

CountryList usage occurrences: ValidationNodeReferenceData

CountryListElement

CountryListElement usage occurrences: CountryList

DatabaseInstancePartyList

DatabaseInstancePartyList usage occurrences: DatabaseInstancePartyCollection

Decision

Decision usage occurrences: WasteMovementUserMessage

EconomicOperator

EconomicOperator usage occurrences: LatestNotification

EconomicOperatorSite

EconomicOperatorSite usage occurrences: LatestNotification

EconomicOperatorSiteIdentity

EconomicOperatorSiteIdentity usage occurrences: ConfirmationOfWasteReceipt, ConfirmationOfWasteTreatment, MovementAnnouncement, Notification

FormalValidationReport

FormalValidationReport usage occurrences: WasteMovementSignalMessage

LatestCarrierConfirmation

LatestCarrierConfirmation usage occurrences: ValidationNodeIndividualData

LatestConfirmationOfWasteReceipt

LatestConfirmationOfWasteReceipt usage occurrences: ValidationNodeIndividualData

LatestConfirmationOfWasteTreatment

LatestConfirmationOfWasteTreatment usage occurrences: ValidationNodeIndividualData

LatestMovementAnnouncement

LatestMovementAnnouncement usage occurrences: ValidationNodeIndividualData

LatestNotification

LatestNotification usage occurrences: ValidationNodeIndividualData

LatestTransportMovement

LatestTransportMovement usage occurrences: LatestMovementAnnouncement

MassValueAssignmentStatement

MassValueAssignmentStatement usage occurrences: ConfirmationOfWasteReceipt, LatestConfirmationOfWasteReceipt, LatestMovementAnnouncement, MovementAnnouncement, Notification

NationalRoute

NationalRoute usage occurrences: MovementAnnouncement

NotificationCountry

NotificationCountry usage occurrences: LatestNotification, Notification

Notification

Notification usage occurrences: WasteMovementUserMessage

Party

Party usage occurrences: Notification

TransportMovement

TransportMovement usage occurrences: MovementAnnouncement, Notification

ValidationNodeAggregatedChangeData

ValidationNodeAggregatedChangeData usage occurrences: MessageValidationContext

ValidationNodeAggregatedContentData

ValidationNodeAggregatedContentData usage occurrences: MessageValidationContext

ValidationNodeIndividualData

ValidationNodeIndividualData usage occurrences: MessageValidationContext

ValidationNodeReferenceData

ValidationNodeReferenceData usage occurrences: MessageValidationContext

VolumeValueAssignmentStatement

VolumeValueAssignmentStatement usage occurrences: ConfirmationOfWasteReceipt, LatestConfirmationOfWasteReceipt, LatestMovementAnnouncement, MovementAnnouncement, Notification

WithdrawalMarkList

WithdrawalMarkList usage occurrences: WithdrawalMarkCollection

Data types

CountContent

CountContent usage occurrences: LatestNotification, MovementAnnouncement, Notification, ValidationNodeAggregatedChangeData, ValidationNodeAggregatedContentData, ValidationNodeIndividualData

CountIdentifierContent

CountIdentifierContent usage occurrences: AnnouncementIdentity, Party, WithdrawalMarkList

CountryIdentifierContent

CountryIdentifierContent usage occurrences: CountryListElement, NationalRoute, NotificationCountry

CountryTwoLetterIdentifierContent

CountryTwoLetterIdentifierContent usage occurrences: CountryListElement

DateContent

DateContent usage occurrences: CarrierConfirmation, ConfirmationOfWasteReceipt, ConfirmationOfWasteTreatment, CountryListElement, Decision, LatestCarrierConfirmation, LatestConfirmationOfWasteReceipt, LatestConfirmationOfWasteTreatment, LatestMovementAnnouncement, LatestNotification, MovementAnnouncement, Notification

DescriptionContent

DescriptionContent usage occurrences: CarrierEconomicOperator, EconomicOperator, EconomicOperatorSite, WasteMovementSignalMessage

EconomicOperatorIdentifier

EconomicOperatorIdentifier usage occurrences: CarrierConfirmation, CarrierEconomicOperator, EconomicOperator, EconomicOperatorSite, EconomicOperatorSiteIdentity, LatestTransportMovement, Notification, Party, TransportMovement, WasteMovementUserMessage

EconomicOperatorRegisterIdentifierContent

EconomicOperatorRegisterIdentifierContent usage occurrences: CarrierEconomicOperator, EconomicOperator, EconomicOperatorIdentifier, EconomicOperatorSite, LatestTransportMovement, Party

IndicatorContent

IndicatorContent usage occurrences: ConfirmationOfWasteReceipt, Decision, LatestConfirmationOfWasteReceipt, LatestNotification, ValidationNodeIndividualData, WasteMovementSignalMessage

MassNumericValue

MassNumericValue usage occurrences: LatestNotification, MassValueAssignmentStatement, ValidationNodeAggregatedContentData

MassUnitIdentifierContent

MassUnitIdentifierContent usage occurrences: MassNumericValue

MovementAnnouncementStatusIdentifierContent

MovementAnnouncementStatusIdentifierContent usage occurrences: LatestMovementAnnouncement

MaxLen1000TextContent

MaxLen1000TextContent usage occurrences: WasteMovementUserMessage

MovementAnnouncementUpdateStatusIdentifierContent

MovementAnnouncementUpdateStatusIdentifierContent usage occurrences: MovementAnnouncementStatus

NameContent

NameContent usage occurrences: CarrierEconomicOperator, EconomicOperator, EconomicOperatorSite, NationalRoute, NotificationCountry, Party

PackageTypeIdentifierContent

PackageTypeIdentifierContent usage occurrences: LatestNotification, MovementAnnouncement, Notification

PartyIdentifier

PartyIdentifier usage occurrences: DatabaseInstancePartyList, Decision

PartyRegisterIdentifierContent

PartyRegisterIdentifierContent usage occurrences: PartyIdentifier

PostalAreaIdentifierContent

PostalAreaIdentifierContent usage occurrences: EconomicOperatorSite, EconomicOperatorSiteIdentity, Party

QuantificationTypeIdentifierContent

QuantificationTypeIdentifierContent usage occurrences: MassValueAssignmentStatement, VolumeValueAssignmentStatement

RelaxedIdentifierContent

RelaxedIdentifierContent usage occurrences: AnnouncementIdentity, CarrierConfirmation, DatabaseInstancePartyList, Decision, EconomicOperatorIdentifier, MessageValidationContext, Notification, PartyIdentifier, WithdrawalMarkList

RemarkContent

RemarkContent usage occurrences: CarrierConfirmation, ConfirmationOfWasteReceipt, ConfirmationOfWasteTreatment, MovementAnnouncement, MovementAnnouncementStatus, Notification

ShortNameContent

ShortNameContent usage occurrences: MessageValidationContext, WasteMovementSignalMessage

SignalIdentifierContent

SignalIdentifierContent usage occurrences: WasteMovementSignalMessage

TimestampContentType

TimestampContentType usage occurrences: MessageValidationContext, ValidationNodeAggregatedChangeData, WasteMovementSignalMessage, WasteMovementUserMessage, 🠖InitSyncRequestType, 🠖UpdateEventType

TransportModeIdentifierContent

TransportModeIdentifierContent usage occurrences: CarrierConfirmation, CarrierEconomicOperator, LatestCarrierConfirmation, LatestTransportMovement, TransportMovement

TreatmentScopeIdentifierContent

TreatmentScopeIdentifierContent usage occurrences: ConfirmationOfWasteTreatment

UserMessageTypeIdentifierContent

UserMessageTypeIdentifierContent usage occurrences: WasteMovementSignalMessage

UUIDIdentifierContent

UUIDIdentifierContent usage occurrences: CarrierConfirmation, MovementAnnouncement, WasteMovementSignalMessage, WasteMovementUserMessage, 🠖InitSyncResponseType

ValidationResultIdentifierContent

ValidationResultIdentifierContent usage occurrences: WasteMovementSignalMessage

ValueContent

ValueContent usage occurrences: MassNumericValue, VolumeNumericValue

VersionIdentifier

VersionIdentifier usage occurrences: MessageValidationContext, WasteMovementSignalMessage, WasteMovementUserMessage

VolumeNumericValue

VolumeNumericValue usage occurrences: LatestNotification, ValidationNodeAggregatedContentData, VolumeValueAssignmentStatement

VolumeUnitIdentifierContent

VolumeUnitIdentifierContent usage occurrences: VolumeNumericValue

WasteTypeIdentifier

WasteTypeIdentifier usage occurrences: Notification

WasteTypeIdentifierContent

WasteTypeIdentifierContent usage occurrences: WasteTypeIdentifier

WasteTypeListIdentifierContent

WasteTypeListIdentifierContent usage occurrences: WasteTypeIdentifier

Formal validation rules (from wastex_formalvalidationrules.sch)

Introduction

WasteX EDI nodes apply formal validation to received user messages. These are automated checks of formal criteria, such as whether or not the message contains a certain piece of information (data element), whether or not a value exceeds a certain threshold, whether or not a value is unique, whether or not there are matching IDs, etc.

The WasteX specification uses [Schematron] for expressing the validation rules in a formal language.

WasteX EDI nodes calculate validation reports by applying an [XSLT] transformation, wastex_formalvalidationrules.xsl, to an [XML] instance. WasteX EDI nodes at the receiving end of a user message transmission report such validation protocols back to the sending EDI node.

Formal validation can lead to automatic rejection (ERROR), but does not necessarily lead to automatic rejection (WARNING, INFO, OK). Codelist 6099 defines the possible results of formal validation, OK, INFO, WARNING and ERROR.

With the [Schematron] approach, conducting formal validation is a matter of applying an [XSLT] transformation. Thus, this approach is ideal for identical validation at different EDI nodes, avoiding both deviations and repeated implementation of the same formal validation rules.

Validation process

Step 1: Extract pieces of information such as notification number and sequential number

Step 2: Read contextual data from DB at EDI node

Step 3: Combine message and contextual data into a validation context [XML] instance

Step 4: Apply validation rules [XSLT] transformation to the validation context [XML] instance

Interoperability and cost efficiency

Using [Schematron] in the WasteX specification, and conducting validation by applying an [XSLT] transformation, serves cost efficiency and interoperability.

The approach is cost efficient, as the implementation of formal validation in any WasteX WS takes little more than conducting an [XSLT] transformation via an [XSLT] processor. There is no need for repeatedly implementing such formal validation (such as in Java, C#, etc.).

The approach is interoperable, as it leads to uniform and predictable behaviour of WasteX web services. It avoids deviations in the implementation and behaviour of WasteX web services. Such deviation would severly impair interoperability and entail significant operational costs and delays, such as in a scenario in which the transmission to the CA of dispatch goes through, but the transmission to the CA of destination does not go through due to validation deviations.

Subjects and characteristics of formal validation

The following are two main themes of formal validation:

1. Information requirements checks: For example, checks on the completeness of provided information
2. Regulatory compliance checks: Checks on the compliance of procedures, events and objects, as described and characterized by provided information, with regulatory requirements, in particular [WSR] provisions. For example, checks on the timeliness of transmissions

The following applies:

• In general, a clear distinction between the two themes, in the sense of assigning each formal validation rule distinctly and unambigously to one of the two themes, is neither desirable nor possible. In particular, it is possible that data errors, such as typos or wrong number scaling factors/units, are not detectible as an information requirements issue, but only as a regulatory compliance issue. Vice versa, something detected as a regulatory compliance issue can be the result of a data error
• For those validation rules that qualify more as information requirements checks than as regulatory compliance checks there are many that lead to the automatic rejection of transmissions (ERROR). This protects EDI nodes and their users from data not fit for the purpose, such as incomplete or inconsistent data, as the handling of such data can be costly - on technical level, user level, or both - and risky, such as prone to leading to wrong interpretations and reactions
• For those validation rules that qualify more as regulatory compliance checks than as information requirements checks, most just lead to validation protocol entries (INFO, WARNING) but not to automatic rejection (ERROR). The purpose of these formal validation rules is pointing users to potential issues, thus supporting their tasks at hand, rather than preventing transmission

Important observations on regulatory compliance check related formal validation:

• The purpose of such formal validation rule is supporting EOs and CAs, such as in detecting issues that may easily/frequently occur, and would be at risk of remaining unnoticed without formal validation
• Formal validation does not replace CA's supervision and control
• Regulatory compliance check related formal validation covers only selected regulatory provisions, where there is a high value and/or demand with pointing users to potential issues. There are many remaining regulatory provisions for which there are no automatic checks
• In some cases, regulatory compliance check related formal validation rules only approximate regulatory provisions. For example, there is the Art. 16(b) [WSR] provision of sending the movement annoucement at least three working days prior to the shipment to CAs. Precise automatic checks on this provision would have to take into account public holidays in the countries of dispatch, transit and destination. In order to keep the automatic checks simple and maintainable, they do not take public holidays into account, and thus only approximate the provision. With timing related provisions, formal validation rules also leaves further tolerance so that there is no issue with catching up after an outage of an EDI node, i.e. with late transmissions

Interpretation of formal validation results

This observations from the previous section mean the following for interpreting formal validation protocols:

• On the one hand, if a validation protocol contains hints at potential issues with regulatory compliance, this is to support parties with their task at hand, and the parties involved in the transmission shall take these hints with a grain of salt: Said hints can be the result of data errors, such as typos. Thus, it is possible that even though the validation protocol contains said hints there is nothing wrong with the waste shipment
• On the other hand, "clean" validation protocols, i.e., validation protocols that do not contain any hints at potential issues, are not at all a confirmation of regulatory compliance. For example, the shipment may violate regulatory provisions for which there are no automatic checks or for which the formal validation rules only contain an approximation of the regulatory provisions

Handling of formal validation protocols

A formal validation protocol contains a list of 0 to n entries. In an EDI transmission, the EDI node receiving a user message returns a signal message to the sender EDI node. Said signal message typically contains a formal validation protocol. 

The main content of each validation protocol entry is an English language text explaining a single hint or issue. Each entry also contains an ID of the validation rule and an INFO, WARNING, ERROR classification - see ↗codelist 6099.

The texts are plain, without markup and formatting instructions, and without carriage returns, line feed, tabulators and the like. This is so that software developers can handle the texts with ease, such as when displaying them in user interfaces.

The intended audience of these texts are regular end users at both ends of an EDI transmission. Note that said users do not need to know anything about the EDI syntax, such as XML formats. The validation protocol texts refer to data instances and data contents in a syntax neutral way. For example, such references can contain notification number, serial number, party IDs, names and addresses, location descriptions, and the like. The texts do not contain syntax specific references, such as XML paths.

EDI nodes must make validation protocols accessible to regular end users at both the sender and receiver side of a transmission, such as by displaying them in the user interface. For the receiver side, this only applies to accepted transmissions, i.e., transmissions that the receiving EDI node has not rejected automatically.

Introduction to the formal validation rules description

The next section contains a description of all the formal validation rules that the WasteX web service applies to User Message transmissions.

This description contains one or more sample validation protocol entries for each of the defined formal validation rules.

The description results from automatically applying the formal validation rules defined per Schematron file wastex_formalvalidationrules.sch to the sample XML files contained in the specification package.

Each of the validation report entries contains a link to the respective validation result in Schematron Validation Report Language (SVRL) format. These SVRL instances result from applying wastex_formalvalidationrules.xsl to the respective linked sample user messages, using one of the [Saxon] or [RaptorXML] [XSLT] processors. Applying an additional XSL transformation yields the HTML representations.

WasteX web services deliver the results of formal validation in SVRL format, as part of Signal Messages in the MessageFormalValidationReport element.

List of formal validation rules