The e-Document building block (BB) is a container component used to wrap business content or documents for e-delivery. It supports different types of e-documents: structured, unstructured, images, binary sequences and others. The e-SENS e-Document approach is based on the results of previous Large Scale Pilots (LSPs) and incorporates pre-existing modules. e-SENS e-Documents is not intended to replace existing solutions for e-document containers, but it will create the possibility of a consolidated cross-domain solution. In the four-corner model adopted under the e-SENS project, e-Documents provide a standard only for the communication path between gateways; nonetheless the e-SENS e-Document BB may support data exchange between gateways and entities if this is required by a Member State. The e-Document consolidated component is expected to address a number of different objectives: support for multiple payloads, e-signatures assigned to payloads, e-delivery routing information, and metadata describing payloads. The diagram below shows a conceptual model for the e-SENS e-Document container.

One of the crucial functions of the e-Document BB is to identify the issuer and the receiver of the container to be passed to the e-Delivery component. This information is needed by the Gateway for addressing and service discovery purposes. The information should be provided in an easily accessible format and in clear text (not compressed). The UN/CEFACT Standard Business Document Header (SBDH) element can be used for this purpose. The SBDH is used as an XML envelope around the compressed container. Another crucial function of the e-Document BB is to arrange payloads and to add signatures that are generic and not specific to any of the piloting domains. The ASiC standard (by ETSI), which uses the Open Document Packaging standard (by OASIS), can be used for this purpose. ASiC describes how to use Open Document Packaging when the payload has to be signed. These standards describe the metadata necessary to organise payloads and signatures in a compressed folder/file structure.

e-Documents architecture

Two levels of metadata are envisaged in this conceptual model of the e-Document container:

  • mandatory metadata set inside the containers with issuer, sender, receiver, information on payload and file MIME types;
  • optional, domain-specific metadata, which is external, and can contain very detailed information about the payload structure for further processing.


The domain-specific metadata detached from the container should be presented in RDF/XML format, and payloads inside containers must be associated with it, which is in line with the Open Document Package – a standard which also caters for the RDF-XML format for metadata: “A document or subdocument that is stored in a package may contain any number of metadata files. The content of a metadata file shall conform to the [RDF-XML] specification. Implementations that are consumers as well as producers should preserve all metadata files. All metadata files of a document or subdocument shall be listed in a separate metadata manifest file, which has the file name ‘manifest.rdf’. This file enumerates metadata files and their relationships to other files in an OpenDocument package.” General architecture of the e-Document HBB

The conceptual model is based on previous LSP pilot experiences, using ASiC container specifications from e-CODEX and additional extensions which are necessary to build a consolidated cross-domain solution. The extensions use an open standard solution such as SBDH envelopes for compressed containers and Oasis Open Document Packages.

e-SENS e-Documents will be delivered as:

  • a set of architecture building blocks, defined technical specifications and proof of concept;
  • a solution building block that implements the specifications in a software product to be used by pilots.


The following are the architecture building blocks of e-Documents:

  • Document Provisioning – this recommends specifications and standards that will aid and support the defined process models and their corresponding functionalities. Its main objective is to ensure technical, syntactic and semantic interoperability in the field of e-Documents.
  • Document Business Envelope – this provides the information required to electronically route e-Documents between participants in the transaction, thus supporting the automation of business processes. For e-SENS routing functionality, the recommended standard is UN/CEFACT Business Document Header SBDH.