1、DD CEN/TS15873:2009ICS 03.240; 35.240.60NO COPYING WITHOUT BSI PERMISSION EXCEPT AS PERMITTED BY COPYRIGHT LAWDRAFT FOR DEVELOPMENTPostal Services OpenStandard Interface Address Data FileFormat for OCR/VCSDictionary GenerationLicensed Copy: Wang Bin, ISO/EXCHANGE CHINA STANDARDS, 15/04/2010 03:34, U
2、ncontrolled Copy, (c) BSIThis Draft for Developmentwas published under theauthority of the StandardsPolicy and StrategyCommittee on 31 January2010 BSI 2010ISBN 978 0 580 64241 8Amendments/corrigenda issued since publicationDate CommentsDD CEN/TS 15873:2009National forewordThis Draft for Development
3、is the UK implementation of CEN/TS15873:2009.This publication is not to be regarded as a British Standard.It is being issued in the Draft for Development series of publications andis of a provisional nature. It should be applied on this provisional basis,so that information and experience of its pra
4、ctical application can beobtained.Comments arising from the use of this Draft for Development arerequested so that UK experience can be reported to the internationalorganization responsible for its conversion to an international standard.A review of this publication will be initiated not later than
5、3 years afterits publication by the international organization so that a decision can betaken on its status. Notification of the start of the review period will bemade in an announcement in the appropriate issue of Update Standards.According to the replies received by the end of the review period,th
6、e responsible BSI Committee will decide whether to support theconversion into an international Standard, to extend the life of theTechnical Specification or to withdraw it. Comments should be sent tothe Secretary of the responsible BSI Technical Committee at BritishStandards House, 389 Chiswick High
7、 Road, London W4 4AL.The UK participation in its preparation was entrusted to TechnicalCommittee SVS/4, Postal services.A list of organizations represented on this committee can be obtained onrequest to its secretary.This publication does not purport to include all the necessary provisionsof a contr
8、act. Users are responsible for its correct application.Compliance with a British Standard cannot confer immunityfrom legal obligations.Licensed Copy: Wang Bin, ISO/EXCHANGE CHINA STANDARDS, 15/04/2010 03:34, Uncontrolled Copy, (c) BSIDD CEN/TS 15873:2009TECHNICAL SPECIFICATIONSPCIFICATION TECHNIQUET
9、ECHNISCHE SPEZIFIKATIONCEN/TS 15873March 2009ICS 03.240; 35.240.60English VersionPostal Services - Open Standard Interface - Address Data FileFormat for OCR/VCS Dictionary GenerationServices postaux - Interface de standard ouvert - Format defichiers de donnes dadresses pour la gnration dudictionnair
10、e OCR/VCSPostalische Dienstleistungen - Offene Normschnittstelle -Adressdateiformat fr die Generierung von Wrterbchernin OCR/Videocodier-SystemenThis Technical Specification (CEN/TS) was approved by CEN on 1 March 2009 for provisional application.The period of validity of this CEN/TS is limited init
11、ially to three years. After two years the members of CEN will be requested to submit theircomments, 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
12、 CEN/TS availablepromptly 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
13、 Austria, Belgium, Bulgaria, 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 CO
14、MMITTEE FOR STANDARDIZATIONCOMIT EUROPEN DE NORMALISATIONEUROPISCHES KOMITEE FR NORMUNGManagement Centre: Avenue Marnix 17, B-1000 Brussels 2009 CEN All rights of exploitation in any form and by any means reservedworldwide for CEN national Members.Ref. No. CEN/TS 15873:2009: ELicensed Copy: Wang Bin
15、, ISO/EXCHANGE CHINA STANDARDS, 15/04/2010 03:34, Uncontrolled Copy, (c) BSIDD CEN/TS 15873:2009CEN/TS 15873:2009 (E) 2 Contents Page Foreword 31 Introduction 42 Scope and purpose52.1 Scope 52.2 Purpose .53 Related Standards .73.1 UPU S42 74 Symbols and Abbreviations .75 XML Schema adressTree 85.1 ,
16、 and 95.2 Address Tree in , and .95.3 Attributes for , and 115.4 String parts in , and . 115.5 Ranges in , and 125.6 Aliases in , and . 135.7 other XML files 145.8 Linking addresses via 155.9 Project specific part of the XML schema . 166 XML Schema addressDeltaTree 186.1 Joining deltas via and file
17、names 196.2 Update actions , and . 197 Miscellaneous . 21Annex A 22A.1 General XML Schema part . 22A.2 Example for a project specific XML Schema part . 24A.3 Initial addressTree Example 25A.4 Update addressDeltaTree Example. 26A.5 Updated addressTree Example . 27Licensed Copy: Wang Bin, ISO/EXCHANGE
18、 CHINA STANDARDS, 15/04/2010 03:34, Uncontrolled Copy, (c) BSIDD CEN/TS 15873:2009CEN/TS 15873:2009 (E) 3 Foreword This document (CEN/TS 15873:2009) has been prepared by Technical Committee CEN/TC 331 “Postal Services”, the secretariat of which is held by NEN. Attention is drawn to the possibility t
19、hat some of the elements of this document may be the subject of patent rights. CEN and/or CENELEC shall not be held responsible for identifying any or all such patent rights. According to the CEN/CENELEC Internal Regulations, the national standards organizations of the following countries are bound
20、to announce this Technical Specification: Austria, Belgium, Bulgaria, 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,
21、 Switzerland and the United Kingdom. NOTE This document has been prepared by experts from CEN/TC 331 and UPU, in the framework of the Memorandum of Understanding between UPU and CEN. Licensed Copy: Wang Bin, ISO/EXCHANGE CHINA STANDARDS, 15/04/2010 03:34, Uncontrolled Copy, (c) BSIDD CEN/TS 15873:20
22、09CEN/TS 15873:2009 (E) 4 1 Introduction In initial meetings of CEN/TC331/WG3 interfaces which will benefit from standardization have been identified and agreed on. Candidates for Open Interface standardization are: interface between the image handler and automatic address readers or video coding pl
23、aces; interface from machine control to Barcode Printers; interface from machine control to Barcode Reader / Verifier; interface between scanner, image handler and machine control; file format of Sort Plan; MIS Interface (Statistics); file format of Address data files. The new intended standard deal
24、s with the file format of Address Data Files. OCR results and video coder inputs have to be verified against the “real” existing addresses in order to reach high recognition rates combined with low error rates. For that purpose postal operators provide postal address directories to the OCR/VCS suppl
25、iers. Usually different postal operators use different file formats for these (source) directories. In typical postal automation systems these files will be processed by directory generation software which creates application specific loadable data. This data usually referred to as “operational dire
26、ctory” is heavily compressed and contains access tables tailored for the specific reading software. Usually different OCR/VCS suppliers use different operational directory formats. This standard shall define a common Address Data File format for postal address directories to be provided from the pos
27、tal operators to the OCR/VCS suppliers. This Address Data File format shall be designed to hold all information necessary to support address reading and video coding software including data required for special recognition tasks e.g. forwarding applications. Licensed Copy: Wang Bin, ISO/EXCHANGE CHI
28、NA STANDARDS, 15/04/2010 03:34, Uncontrolled Copy, (c) BSIDD CEN/TS 15873:2009CEN/TS 15873:2009 (E) 5 2 Scope and purpose 2.1 Scope This document defines a file format for the generation of postal address directories. It is designed to hold all information necessary to support address reading softwa
29、re including data required for forwarding applications. In typical postal automation systems these files will be processed by directory generation software which creates application specific loadable data. This data usually referred to as operational directory is heavily compressed and contains acce
30、ss tables tailored for the specific reading software. Not in the scope of this document are topics external to file like compression, checksums, the interface for transmission to the supplier, modification permissions, error handling on inconsistent data and undo in updates. 2.2 Purpose The format h
31、as been designed with the following requirements in mind: must be able to hold the following data: addresses composed of address components (including aliases and range-data); person and organization names; address codes typically used as sort codes; links between addresses e.g. for use in forwardin
32、g; should not restrict character encoding; easily customizable for specific applications; should allow complete as well as incremental updates, i.e. change-only data; it must be possible to split data in multiple files for better handling. The ideas behind this format are as follows: The format is b
33、ased on XML. The basic XML structure is general. Project(the term project is used throughout this document to describe a specific application such as address data for a specific country or postal organization) specifics are coded as attributes. This should make it easier to build project independent
34、 parsers and tools. Address data can be structured hierarchically. An address component appearing in a lot of addresses shall be written once as parent node in all addresses it is used in the XML address tree. Beyond the pure address data, there are general as well as optional project specific attri
35、butes on the level of address components and string parts. In favour of faster parser execution and smaller file sizes the names of XML elements appearing very often are short strings. Licensed Copy: Wang Bin, ISO/EXCHANGE CHINA STANDARDS, 15/04/2010 03:34, Uncontrolled Copy, (c) BSIDD CEN/TS 15873:
36、2009CEN/TS 15873:2009 (E) 6 Semantics are defined only in a basic manner and have to be completed in the project specific tailoring process. E.g. a street without numbers in the data may be interpreted as a street which has no numbers, or where all numbers are valid. Due to this users must be aware
37、that the interoperability of this Technical Specification may be limited to be applied to the specific project. Licensed Copy: Wang Bin, ISO/EXCHANGE CHINA STANDARDS, 15/04/2010 03:34, Uncontrolled Copy, (c) BSIDD CEN/TS 15873:2009CEN/TS 15873:2009 (E) 7 3 Related Standards 3.1 UPU S42 1) UPU S42 is
38、 beginning with version -5 a two part standard. Part a contains concepts and the theoretical language description. Part b contains practical examples from different countries and may be supplemented with new examples in some future. 2) UPU S42a defines components an address is composed of as well as
39、 postal entities which can be “described” using these address components. The standard goes into great detail in defining a globally usable set of specific address components such as “postcode”, “door”, . 3) UPU S42b describes how to write an address given its constituting address components. It use
40、s templates to describe the order, line-breaks, etc. The templates are country specific (US, Brazil, England, .) and also uses an country specific subset of the globally defined types. 4) UPU S42 address components are assumed to have a type and a string. They do not have additional attributes and d
41、o not have aliases. 5) UPU S42 does not define a format for an individual address = address-component collection and does not define a format for an address directory = set of addresses. 6) UPU S42 has no concept of sort codes or forwarding information. UPU S42 will not conflict with the format defi
42、ned in this document as it targets at a completely different application and type of information described. The only thing in common with address data are the address-component definitions themselves. These could be used in customizing the ADF for a specific project. UPU S42s excellent glossary shou
43、ld be reused where applicable. 4 Symbols and Abbreviations XML eXtended Markup Language ADF Address Data File Licensed Copy: Wang Bin, ISO/EXCHANGE CHINA STANDARDS, 15/04/2010 03:34, Uncontrolled Copy, (c) BSIDD CEN/TS 15873:2009CEN/TS 15873:2009 (E) 8 5 XML Schema adressTree The syntax is described
44、 as an XML schema, divided into a general and a project specific part. The general part of the XML Schema defines the basic structures. It uses some types and attribute groups to be defined in the project specific part. Basically the structure spans a tree of address components represented by XML el
45、ements . The general part of the schema is listed in section A.1A.1. The project specific part is explained in section 5.9. This document contains also another XML Schema addressDeltaTree explained in chapter 6. The following Figure 1 shows the general structure of the XML schema. Since the project
46、specific part does not change the general structure the diagram is independent from any project specifics. Figure 1 General data structure of the XML schema Licensed Copy: Wang Bin, ISO/EXCHANGE CHINA STANDARDS, 15/04/2010 03:34, Uncontrolled Copy, (c) BSIDD CEN/TS 15873:2009CEN/TS 15873:2009 (E) 9
47、5.1 , and Below the XML root element is one and one section. The stores a string and optionally a list of global aliases. Aliases are described in section 5.6. A version string of the data contained in the file is stored in the element. 5.2 Address Tree in , and Addresses are stored in an address tr
48、ee corresponding to the XML elements , and . is the root node of this tree, address components stored in are the nodes and may be additional leafs. Explanation on the element follows in section 5.8. One complete address corresponds to one leafs root path. Each nodes root path identifies a partial ad
49、dress. Other XML elements and attributes carry additional information for the address tree node. allows to split data into multiple files. One address component in XML element holds a type mentioned in attribute tp and a string in child elements or and . Attribute tp and other optional attributes for are described in section 5.3. Other optional child elements are described in the following sections. In this context one address component holds just a name with
