Postal services - Hybrid Mail - XML definition of encapsulation of letters for automated postal handling

The purpose of this Technical Specification is to define the syntax rules for a data stream for the submission of printing data to a Hybrid Mail operator or between Hybrid Mail operators. The Technical Specification defines a XML Schema Definition (XSD) describing the data stream.
The description is based upon the XML (eXtended Mark-up Language) definition of rules and semantics for defining an XSD. The purpose of this is to offer a generalised syntax description that can provide seamless integration with a number of existing applications generating data that is liable to be forwarded to or from a Hybrid Mail operator.
The use of an XSD will ensure that the documents confirm to the standard defined and that the output has the correct syntax. Software manufacturers can use an XSD to program applications that will produce "correct" outputs.
This Technical Specification defines the syntax for creating a data stream that will eventually be converted into a deliverable. The overall object (a batch) can be divided into one or more objects that again can be divided into objects. The hierarchy includes bundles that contains a common part and letters. Each object has a number of characteristics attached to it.
This diagram shows the structure of a HML (Hybrid Mail Language) document: each letter is self-contained (contains all the necessary information to be delivered on a certain destination).

Postalische Dienstleistungen - Hybrid mail - XML Definition für die Verkapselung von Briefen zur automatischen Postbearbeitung

Services postaux - Courrier hybride - Définition XML de l'encapsulation des lettres pour le traitement automatisé du courrier

Poštne storitve - Hibridna pošta - Definicija oblike dokumenta XML za stranke/uporabnike pri ponudniku: skupno uporabni seznam označb

General Information

Status
Withdrawn
Publication Date
09-May-2006
Withdrawal Date
05-May-2015
Technical Committee
Current Stage
9960 - Withdrawal effective - Withdrawal
Completion Date
06-May-2015

RELATIONS

Buy Standard

Technical specification
-TS CEN/TS 14014:2007
English language
49 pages
sale 10% off
Preview
sale 10% off
Preview
e-Library read for
1 day

Standards Content (sample)

SLOVENSKI STANDARD
SIST-TS CEN/TS 14014:2007
01-januar-2007
3RãWQHVWRULWYH+LEULGQDSRãWD'HILQLFLMDREOLNHGRNXPHQWD;0/]D
VWUDQNHXSRUDEQLNHSULSRQXGQLNXVNXSQRXSRUDEQLVH]QDPR]QDþE

Postal services - Hybrid Mail - XML definition of encapsulation of letters for automated

postal handling

Postalische Dienstleistungen - Hybrid mail - Document Typ Definition (DTD) für Kunden

zum Dienstanbieter: Eine allgemein verwendbare Auflistung von vordefinierten Regeln

Services postaux - Courrier hybride - Définition XML de l'encapsulation des lettres pour

le traitement automatisé du courrier
Ta slovenski standard je istoveten z: CEN/TS 14014:2006
ICS:
03.240 Poštne storitve Postal services
35.240.99 8SRUDEQLãNHUHãLWYH,7QD IT applications in other fields
GUXJLKSRGURþMLK
SIST-TS CEN/TS 14014:2007 en

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------
TECHNICAL SPECIFICATION
CEN/TS 14014
SPÉCIFICATION TECHNIQUE
TECHNISCHE SPEZIFIKATION
May 2006
ICS 03.240; 35.240.99 Supersedes ENV 14014:2001
English Version
Postal services - Hybrid Mail - XML definition of encapsulation of
letters for automated postal handling

Services postaux - Courrier hybride - Définition XML de Postalische Dienstleistungen - Hybrid mail - Document Typ

l'encapsulation des lettres pour le traitement automatisé du Definition (DTD) für Kunden zum Dienstanbieter: Eine

courrier allgemein verwendbare Auflistung von vordefinierten
Regeln

This Technical Specification (CEN/TS) was approved by CEN on 4 March 2006 for provisional application.

The period of validity of this CEN/TS is limited initially to three years. After two years the members of CEN will be requested to submit their

comments, particularly on the question whether the CEN/TS can be converted into a European Standard.

CEN members are required to announce the existence of this CEN/TS in the same way as for an EN and to make the CEN/TS available

promptly at national level in an appropriate form. It is permissible to keep conflicting national standards in force (in parallel to the CEN/TS)

until the final decision about the possible conversion of the CEN/TS into an EN is reached.

CEN members are the national standards bodies of Austria, Belgium, Cyprus, Czech Republic, Denmark, Estonia, Finland, France,

Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania,

Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
Management Centre: rue de Stassart, 36 B-1050 Brussels

© 2006 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 14014:2006: E

worldwide for CEN national Members.
---------------------- Page: 2 ----------------------
CEN/TS 14014:2006 (E)
Contents Page

Foreword..............................................................................................................................................................3

Introduction .........................................................................................................................................................4

1 Scope ......................................................................................................................................................5

2 Normative references ............................................................................................................................7

3 Terms and definitions ...........................................................................................................................7

4 Symbols and abbreviated terms ..........................................................................................................7

5 Meta-syntax ............................................................................................................................................8

6 Definition ..............................................................................................................................................10

Annex A (normative) List of elements ..........................................................................................................14

Annex B (informative) HML description .......................................................................................................16

Annex C (informative) Differences between this Technical Specification and ENV 14014......................38

Annex D (informative) HML definition, copy of the HML XSD.....................................................................39

Bibliography ......................................................................................................................................................49

---------------------- Page: 3 ----------------------
CEN/TS 14014:2006 (E)
Foreword

This Technical Specification (CEN/TS 14014:2006) has been prepared by Technical Committee CEN/TC 331

“Postal services”, the secretariat of which is held by NEN.

This Technical Specification supersedes ENV 14014:2001. An explanation of the differences between this

Technical Specification and ENV 14014 is given in Annex C.

According to the CEN/CENELEC Internal Regulations, the national standards organizations of the following

countries are bound to announce this CEN Technical Specification: Austria, Belgium, Cyprus, Czech Republic,

Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,

Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden,

Switzerland and United Kingdom.
---------------------- Page: 4 ----------------------
CEN/TS 14014:2006 (E)
Introduction

Hybrid Mail is the technology whereby input in one communication medium is converted for delivery on

another communication medium according to the sender’s instructions and/or the recipient’s capabilities. The

typical application of Hybrid Mail is to provide a Hybrid Mail operator with printing data as well as processing

and delivery instructions, and request the operator to secure the print, enveloping and delivery of the physical

letters. Hybrid Mail operators may also exchange data.

The transfer of data to a Hybrid Mail operator or between Hybrid Mail operators requires that the printing data

be linked to a number of data items related to the management, production, finishing etc. of the data to be

printed. Such data items secure that all relevant information is accompanying the printing data. Also it will

enable the Hybrid Mail operator to automate his processes with customers and other Hybrid Mail operators.

There is a need for a standardised yet flexible way to present the data to the Hybrid Mail operator or to

exchange data between Hybrid Mail operators. This will enable customers and Hybrid Mail operators to have

a seamless exchange of information. It will allow makers of applications for document creation (letters,

marketing mailing etc.) and output management from other applications (accounting systems, production

management etc.), to add here to the same data presentment and to offer the seamless data interchange.

---------------------- Page: 5 ----------------------
CEN/TS 14014:2006 (E)
1 Scope

The purpose of this Technical Specification is to define the syntax rules for a data stream for the submission

of printing data to a Hybrid Mail operator or between Hybrid Mail operators. The Technical Specification

defines a XML Schema Definition (XSD) describing the data stream.

The description is based upon the XML (eXtended Mark-up Language) definition of rules and semantics for

defining an XSD. The purpose of this is to offer a generalised syntax description that can provide seamless

integration with a number of existing applications generating data that is liable to be forwarded to or from a

Hybrid Mail operator.

The use of an XSD will ensure that the documents confirm to the standard defined and that the output has the

correct syntax. Software manufacturers can use an XSD to program applications that will produce “correct”

outputs.

This Technical Specification defines the syntax for creating a data stream that will eventually be converted into

a deliverable. The overall object (a batch) can be divided into one or more objects that again can be divided

into objects. The hierarchy includes bundles that contains a common part and letters. Each object has a

number of characteristics attached to it.

This diagram shows the structure of a HML (Hybrid Mail Language) document: each letter is self-contained

(contains all the necessary information to be delivered on a certain destination).

---------------------- Page: 6 ----------------------
CEN/TS 14014:2006 (E)
Figure 1 — Structure of a HML (Hybrid Mail Language)

Each letter can have one contact. Each contact can have multiple alternatives for delivery.

This Technical Specification does not define the specific services offered by local operators (Hybrid Mail

operators).

This Technical Specification does not define the communication method used. It does only define the format

of Hybrid Mail as such.
---------------------- Page: 7 ----------------------
CEN/TS 14014:2006 (E)
2 Normative references

The following referenced documents are indispensable for the application of this Technical Specification. For

dated references, only the edition cited applies. For undated references, the latest edition of the referenced

document (including any amendments) applies.

ISO/IEC 10646, Information technology — Universal Multiple-Octet Coded Character Set (UCS)

3 Terms and definitions

For the purposes of this Technical Specification, the following terms and definitions apply.

3.1
mailbag

data structure that contains bundles as well as administrative and other data common to all bundles

NOTE One HML document will contain one mailbag. A mailbag may contain one or several bundles.

3.2
bundle

data structure that contains letters that are processed as a group as well as administrative and other data

common to these letters. A bundle is equivalent with a batch. Usually a sender is sending a mailbag with only

one batch
NOTE A bundle may contain one or more letters.
3.3
letter

data structure that contains the data to be rendered as one integral piece of information which is to be

delivered to one recipient in physical or electronic format
3.4
contact
data structure that contains delivery information for letters

NOTE The contact may be relevant to only one letter or may be shared between several letters.

3.5
target language

language to be defined in this Technical Specification and to be later used for writing documents, and the

result of a possible translation of existing data structure(s). In this Technical Specification the target language

is HML.
NOTE Clause 4 gives further description of the syntax of the target language.
4 Symbols and abbreviated terms

For the purposes of this Technical Specification, the following symbols and abbreviated terms apply.

AFP Advance Function Presentation – PDL defined by IBM
HML Hybrid Mail Language
IEC International Electrotechnical Commission http://www.iec.ch
---------------------- Page: 8 ----------------------
CEN/TS 14014:2006 (E)
ISO International Organization for Standardization
PCL Print Control Language – PDL defined by HP
PDF Portable Document Format – PDL defined by Adobe
PDL Print Description Language
PI Processing Instruction – part of the XML standard
SGML Standard Generalized Mark-up Language
UCS Universal Coded Character set
URL Universal Resource Locator
W3C World Wide Web Consortium – see http://www.w3.org/
XML eXtensible Mark-up Language
XSD XML Schema Definition
XSL eXtensible Stylesheet Language
5 Meta-syntax

This clause introduces a syntactic notation, later used in this Technical Specification. The notation is adopted

to define the syntactic rules of the target language: in this sense, the notation is a meta-syntax for the syntax

of the target language.

HML is based on XML version 1.0 as described in [XML-2004]. This is a subset of Standard Generalized Mark

up Language (SGML) as defined in ISO 8879.

For the sake of generality, in the following the term target language will be used for specifying the language

to be defined and to be later used for writing documents.
In this Technical Specification the target language is HML.

Syntactic rules of the target language are defined by means of syntactic clauses, classified as either element

declarations, attribute list declarations or comments. In the following, the first two of these syntactic clauses

will be described in detail. Here, only their abstract characteristics are introduced.

Element declarations define elements, which are logical parts of the documents.

Elements may contain other elements, to be considered as sub-parts of the first ones. To describe this

relationship among elements, element declarations can define elements in terms of other elements.

The whole document itself is considered as an element, and is described by an element declaration: this

element is the unique root, which all the other elements start from.

On the other side, elements not further subdivided in parts are simply streams of characters allowed in the

documents. They are defined as well by element declarations.

In this way, element declarations express the inner structure of documents: this structure can be easily

reconstructed by going through the chain of element declarations, starting from the one that declares the root

element.
---------------------- Page: 9 ----------------------
CEN/TS 14014:2006 (E)
An element declaration is defined by the following syntactical construction:





where element_name is the name of the element defined and contentspec is the list of elements which

constitute the set of elements which defines the named element.
Attribute list declarations define characteristics of elements.
In describing the notation, some rules will be followed.
In the syntactic clauses:

• syntactic items independent of the particular target language (i.e. keywords, symbols and so on) are

written in regular font (that is, without using bold or italic forms);

• identifiers used as placeholders for other things to be later made actual in the syntax of the target language

(as for example syntactic items dependent of the particular target language) are written in italic font.

In the examples:

• syntactic items independent of the particular target language (i.e. keywords, symbols and so on) are

written in regular font (that is, without using bold or italic forms)

• syntactic items dependent of the particular target language (as for example constant names of the target

language) are written in italic font.
An attribute declaration is defined by the following syntactical construction:

where the element_name identifies which element the attributes belong to, attribute_name is the name of the

attribute, attribute_type is the type of the attribute and default_decl informs whether the attribute has a default

value that is used if the attribute is not present.
For a more detailed description of the syntax of XML please see [XML-2004]
---------------------- Page: 10 ----------------------
CEN/TS 14014:2006 (E)
6 Definition
6.1 General

In this clause, syntactic rules of HML are given in XML. They completely define the concrete syntax of HML.

The structure of the HML XSD is illustrated in Figure 2:
Figure 2 — Illustration of the structure of the HML XSD
---------------------- Page: 11 ----------------------
CEN/TS 14014:2006 (E)
6.2 General rule for HML documents
6.2.1 General

HML is based on eXtensible Markup Language (XML) version 1.0 as described in [XML-2004]. This is a

subset of Standard Generalized Markup Language (SGML) as defined in ISO 8879.

As HML is specified as an XSD, the general rules for XML compliant XSD’s apply to HML. However this

chapter specifies how a compliant HML document shall be processed when using the following components

from the XML standard, which are not unique to HML:
• Comments
• Processing Instructions
• Name Spaces
6.2.2 Comments
Comment ::= ''

A conforming HML system shall make the comments in a conforming HML document available to external

processors on request.
6.2.3 Processing Instructions
PI ::= '' Char*)))? '?>'
PITarget ::= Name - (('X' | 'x') ('M' | 'm') ('L' | 'l'))

A conforming HML system shall ensure that the processing instructions are presented to the relevant

processor if this is available. This can either be pre- or postprocessor. Otherwise the processing instructions

shall be ignored.
6.2.4 Name space

The use of name spaces in HML shall comply with the W3C recommendations – see [XML-names-2004]. The

processing of names from other name spaces than the HML name space shall be accepted and either be

handled by the HML system or alternatively by a pre- or postprocessor.
6.2.5 Hybrid Mail Language (HML) Extensions:

In the future new equipment shall be controllable in Hybrid Mail operations. To include new features to make

use of this equipment and to fulfil the Hybrid Mail Language it is allowed to include new elements.

The way of doing this is make use of the defined way as mentioned in Chapter 2.8 of the [XML-2004]: the

document type declaration can point to an external subset containing mark-up declarations.

6.3 General elements
6.3.1 General

The encoding for any text strings in this Technical Specification is the ISO/IEC 10646-1. This will have to be

specified in the XML header section of the HML document.
---------------------- Page: 12 ----------------------
CEN/TS 14014:2006 (E)
6.3.2 acknowledgement

This is an optional tag to provide a contact point for a recipient of bundle acknowledgement information. The

preference attribute is a list of references defined in the contact to specify the preference of the media on

which the delivery should be made. If there is none specified then the delivery order is the order of the defined

entries in the contact element.
6.3.3 addressee

The addressee section contains the possible contact points of the recipient. The preference attribute is a list of

references defined in the contact to specify the preference of the media on which the delivery should be made.

If there is none specified then the delivery order is the order of the defined entries in the contact element.

6.3.4 batchname
Is an identifier for the bundle.
6.3.5 binary_data

Holds data of any sort, base64 encoded. See [Base64] for details. This can be used for data that is not XML

structured.
6.3.6 bundle

Represents a collection of letters and their common properties. An HML document may contain a number of

bundles. A bundle contains a number of letters.
6.3.7 common

Contains the data and information that is common to all the letters of a bundle. Similar to a global declaration

for the bundle. Contains descriptions of the bundle as well as common data.
6.3.8 common_data

Declaration of data common to a set of letters. The common_data is identified with a unique identifier that may

be referred to with an internal_ref tag somewhere else in the bundle.
6.3.9 contact

Contains the list of possible contact points for either a mailee or addressee. The contact points can be

postal_address, email, fax or any externally defined format that enables delivery.

6.3.10 declaration
Contains meta-information for the encapsulating bundle.
6.3.11 external_ref

External URL reference to a data segment. The attribute type has to specify what kind of data is pointing to.

6.3.12 generation_application

The application that processed this bundle. Generation date and generation application tags are grouped in

tag track_history to enable a list of processing times to be used for tracking.
---------------------- Page: 13 ----------------------
CEN/TS 14014:2006 (E)
6.3.13 generation_date

The date and time of the processing of this bundle. Generation date and generation application tags are

grouped in tag track_history to enable a list of processing times to be used for tracking.

6.3.14 hml
The root level tag defines the document.
6.3.15 internal_ref
Internal reference to a unique key id declared in the common data section.
6.3.16 letter

The smallest message unit. A message is constituted by an instance of a letter. A bundle contains a list of

letters.
6.3.17 letter_data

Contains the data of the letter, either indirectly as internal or external references, or as actual data. Letter data

is an open slot for any external data structure and does not attempt to describe the data itself.

6.3.18 mailee
The mailee section contains the possible contact points of the sender.
6.3.19 processing

Defines a property to follow the data contained in the current encapsulating document fragment and fragments

inside (and after the processing tag), except if the type is redefined in a document sub fragment. This is

similar to an environment variable for the data. Processing holds and transports the properties of the data

contained in the document fragment. These options may or may not be relevant for pre-processing,

processing and post-processing, depending on the HML application.
6.3.20 sender_id
The id used by the HML processor to identify the originator of the file.
6.3.21 track_history

Contains one record of a processing event. A list of track_history records the processing of the bundle.

---------------------- Page: 14 ----------------------
CEN/TS 14014:2006 (E)
Annex A
(normative)
List of elements
A.1 Elements
Element Type Reference
acknowledgement Element See 6.3.2 and B.1.1.
addressee Element See 6.3.3 and B.1.2.
batchname Element See 6.3.4 and B.1.3.
binary_data Element See 6.3.5 and B.1.4.
bundle Element See 0, 6.3.6 and B.1.5.
common Element See 6.3.7 and B.1.6.
common_data Element See 6.3.8 and B.1.7.
contact Element See 6.3.9 and B.1.8.
declaration Element See 6.3.10 and B.1.9.
external_ref Element See 6.3.11 and B.1.10.
generation_application Element See 6.3.12 and B.1.11.
generation_date Element See 6.3.13 and B.1.12.
hml Element See 6.3.14 and B.1.13.
internal_ref Element See 6.3.15 and B.1.14.
letter Element See 0, 6.3.16 and B.1.15.
letter_data Element See 6.3.17 and B.1.16.
mailee Element See 6.3.18 and B.1.17.
processing Element See 6.3.19 and B.1.18.
sender_id Element See 6.3.20 and B.1.19.
track_history Element See 6.3.21 and B.1.20.
---------------------- Page: 15 ----------------------
CEN/TS 14014:2006 (E)
A.2 Complex types
Element Type Reference
acknowledgementType Complex type See B.2.1
addresseeType Complex type See B.2.2
bundleType Complex type See B.2.4
commonType Complex type See B.2.6
contactType Complex type See B.2.7
data_type Complex type See B.2.8
declarationType Complex type See B.2.9
external_refType Complex type See B.2.10
hmlType Complex type See B.2.11
Internal_refType Complex type See B.2.12
letterType Complex type See B.2.13
maileeType Complex type See B.2.14
restricted_dataType Complex type See B.2.16
track_historyType Complex type See B.2.17
---------------------- Page: 16 ----------------------
CEN/TS 14014:2006 (E)
Annex B
(informative)
HML description
B.1 Elements
B.1.1 acknowledgement
diagram
type hml:acknowledgementType
hml:contact hml:internal_ref
children
complexTypes commonType letterType
used by
Name Type Use Annotation
attributes

preference xs:IDREFS optional Preference attribute is specifying what is the order of preferred

delivery channel.
The IDREFS has to be the one defined in the contact.
If none specified then the order in which the channels had
been defined will be used.

documentation Optional tag to provide a contact point for a recipient of bundle acknowledgement information.

annotation

source

Optional tag to provide a contact point for a recipient of bundle acknowledgement

information.


---------------------- Page: 17 ----------------------
CEN/TS 14014:2006 (E)
B.1.2 addressee
diagram
type hml:addresseeType
children hml:contact hml:internal_ref
complexType letterType
used by
Name Type Use Annotation
attributes
Preference attribute is specifying what is the order of preferred
preference xs:IDREFS optional
delivery channel.
The IDREFS has to be the one defined in the contact.
If none specified then the order in which the channels had
been defined will be used.

documentation The addressee section contains the possible contact points of the recipient.

annotation

source

The addressee section contains the possible
contact points of the recipient.


B.1.3 batchname
diagram
type xs:anyURI
complexType declarationType
used by
documentation Unique identifier for the bundle.
annotation
source

Unique identifier for the bundle.


---------------------- Page: 18 ----------------------
CEN/TS 14014:2006 (E)
B.1.4 binary_data
diagram
type hml:binary_dataType
used by complexTypes data_type restricted_dataType
attributes Name Type Use Default Fixed Annotation
type xs:string required

annotation documentation Holds data of any sort, base64 encoded. This can be used for data that is not XML structured.

source

Holds data of any sort, base64 encoded. This can be used for data that is not XML

structured.


B.1.5 bundle
diagram
type hml:bundleType
children hml:common hml:letter
hmlType
complexType
used by
attributes Name Type Use Default Fixed Annotation
bundleid xs:ID optional

annotation documentation Represents a collection of letters and their common properties. An HML document may contain a

number of bundles. A bundle contain at least one letter.
source

Represents a collection of letters and their common properties. An HML document may contain a

number of bundles. A bundle contains a number of letters.


---------------------- Page: 19 ----------------------
CEN/TS 14014:2006 (E)
B.1.6 common
diagram
type hml:commonType

children hml:declaration hml:processing hml:common_data hml:contact hml:mailee hml:acknowledgement

complexType bundleType
used by
---------------------- Page: 20 ----------------------
CEN/TS 14014:2006 (E)

documentation Contains the data and information that is common to all the letters of a bundle. Similar to a global

annotation

declaration for the bundle. Contains descriptions of the bundle as well as common data.


source

Contains the data and information that is common to all the letters of a bundle. Similar to a global

declaration for the bundle. Contains descriptions of the bundle as well as common data.



B.1.7 common_data
diagram
type hml:common_dataType
children hml:binary_data hml:external_ref
complexType commonType
used by
Name Type Use Default Fixed Annotation
attributes
id xs:ID required

documentation Declaration of data common to a set of letters. The common_data is identified with a unique identifier

annotation
that may be referred to with an internal_ref tag somewhere else in the bundle.

source

Declaration of data common to a set of letters. The common_data is identified with a unique identifier

that may be referred to with an internal_ref tag somewhere else in the bundle.



B.1.8 contact
diagram
type hml:contactType
---------------------- Page: 21 ----------------------
CEN/TS 14014:2006 (E)
complexTypes acknowledgementType addresseeType commonType maileeType
used by
Name Type Use Default Fixed Annotation
attributes
id xs:ID

Contains the list of possible contact points for either a mailee or addressee. The contact points can be

documentation
annotation

postal_address, email, fax or any externally defined format that enables delivery.


source

Contains the list of possible contact points for either a mailee or addressee. The contact points c

...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.