XML Naming and Design Rulesxml.coverpages.org/ATG2-NamingAndDesignRules200501.pdf2 UN/CEFACT – XML...

XML Naming and Design Rules Draft 1.1, 14 January 2005

NamingAndDesignRules_1.1.doc 14 January 2005

1 Status of this Documents This UN/CEFACT Technical Specification has been developed in accordance with the UN/CEFACT/TRADE/22 Open Development Process (ODP) for Technical Specifications. It has been approved by the United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) Applied Techniques Group (ATG) for implementation verification in accordance with Step 6 of the ODP.

Distribution of this document is unlimited.

The document formatting is based on the Internet Society’s Standard RFC format.

This version:

XML Naming and Design Rules, Version 1.1 of 14 January 2005

Previous version:

NamingAndDesignRules_1.0.doc

Document identifier:

NamingAndDesignRules_1.1.doc

Location:

http://www.disa.org/cefact-groups/atg/downloads/index.cfm


2 UN/CEFACT – XML Naming and Design Rules Project Team Participants

1

2

3 4 5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

We would like to recognise the following for their significant participation to the development of this Technical Specification. Project Team Leader:

Mark Crawford LMI

Editors:

Gunther Stuhec SAP AG

Paula Heilig Worldspan

Margaret Pemberton Diskray

Garret Minakawa Oracle/OAGI

Contributors:

Hisanao Sugamata ECOM-Japan

Frank Lin GCOM

K.K. Suen EAN Hong Kong

Luc Mouchot CNAM-TS

Thomas Bikeev EAN.UCC

Jostein Frømyr EDISYS

Sue Probert SEPIA eb

Alain Dechamps CEN

Michael Dill GEFEG

2.1 Acknowledgements The UN/CEFACT - XML Naming and Design Rules were developed in close coordination with other XML standards efforts. In particular, the OASIS Universal Business Language Technical Committee Naming and Design Rules were instrumental in developing this document. Additionally, contributions were also received from: SWIFT U.S. Department of the Navy U.S. Environmental Protection Agency U.S. Federal CIO Council XML Working Group OpenTravel Alliance Australia Electricity & Gas Industry CIDX EAN/UCC European Transmission System Operators PIDX


3 Table of Contents 38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53 54 55 56

57

58 59

60 61 62 63

64 65 66 67 68 69 70

71

1 STATUS OF THIS DOCUMENTS......................................................................................... 2

2 UN/CEFACT – XML NAMING AND DESIGN RULES PROJECT TEAM PARTICIPANTS. 3

2.1 Acknowledgements .............................................................................................................................3

3 TABLE OF CONTENTS........................................................................................................ 4

4 INTRODUCTION ................................................................................................................... 8

4.1 Scope and Focus..................................................................................................................................8

4.2 Audience ..............................................................................................................................................8

4.3 Structure of this Specification ...........................................................................................................8

4.4 Terminology and Notation .................................................................................................................9

4.5 Related Documents .............................................................................................................................9

4.6 Conformance.......................................................................................................................................9

4.7 Guiding Principles ..............................................................................................................................9

5 GENERAL XML CONSTRUCT........................................................................................... 11

5.1 Overall Schema Structure................................................................................................................11

5.2 Relationship to the CCTS ................................................................................................................11 5.2.1 CCTS ..................................................................................................................................................11 5.2.2 Business Information Entities.............................................................................................................12 5.2.3 The XML Constructs ..........................................................................................................................13

5.3 Naming and Modelling Constraints ................................................................................................15

5.4 Reusability Scheme...........................................................................................................................16 5.4.1 Element Naming Conventions............................................................................................................17

5.5 Modularity Model.............................................................................................................................17 5.5.1 Root Schema.......................................................................................................................................18 5.5.2 Internal Schema ..................................................................................................................................19 5.5.3 External Schema.................................................................................................................................19

5.6 Namespace Scheme...........................................................................................................................22 5.6.1 UN/CEFACT Namespace Scheme .....................................................................................................23 5.6.2 Declaring Namespace .........................................................................................................................23 5.6.3 Namespace Persistence.......................................................................................................................24 5.6.4 Namespace Uniform Resource Identifiers ..........................................................................................24 5.6.5 Namespace Constraint ........................................................................................................................25 5.6.6 UN/CEFACT XSD Schema Namespace Tokens ...............................................................................25

5.7 Schema Location...............................................................................................................................26


5.8 Versioning .........................................................................................................................................26 72 73 74

75

76 77

78 79 80

81 82 83 84

85 86 87

88 89

90

91 92 93 94 95 96 97

98 99

100 101

102 103 104 105 106 107

108

109 110 111 112 113 114 115 116 117

5.8.1 Major Versions ...................................................................................................................................26 5.8.2 Minor Versions ...................................................................................................................................27

6 GENERAL XML SCHEMA LANGUAGE CONVENTIONS................................................. 29

6.1 Schema Construct.............................................................................................................................29 6.1.1 Constraints on Schema Construction..................................................................................................29

6.2 Attribute and Element Declarations ...............................................................................................29 6.2.1 Attributes ............................................................................................................................................29 6.2.2 Elements .............................................................................................................................................30

6.3 Type Definitions................................................................................................................................31 6.3.1 Usage of Types ...................................................................................................................................31 6.3.2 Simple Type Definitions.....................................................................................................................31 6.3.3 Complex Type Definitions .................................................................................................................31

6.4 Use of XSD Extension and Restriction............................................................................................32 6.4.1 Extension ............................................................................................................................................32 6.4.2 Restriction...........................................................................................................................................32

6.5 Annotation.........................................................................................................................................32 6.5.1 Documentation ...................................................................................................................................32

7 XML SCHEMA MODULES.................................................................................................. 36

7.1 Root Schema......................................................................................................................................36 7.1.1 Schema Construct ...............................................................................................................................36 7.1.2 Namespace Scheme ............................................................................................................................36 7.1.3 Imports and Includes ..........................................................................................................................37 7.1.4 Root Element Declaration...................................................................................................................37 7.1.5 Type Definitions .................................................................................................................................38 7.1.6 Annotations.........................................................................................................................................38

7.2 Internal Schema................................................................................................................................39 7.2.1 Schema Construct ...............................................................................................................................39 7.2.2 Namespace Scheme ............................................................................................................................39 7.2.3 Imports and Includes ..........................................................................................................................39

7.3 Reusable Aggregate Business Information Entities.......................................................................39 7.3.1 Schema Construct ...............................................................................................................................39 7.3.2 Namespace Scheme ............................................................................................................................40 7.3.3 Imports and Includes ..........................................................................................................................40 7.3.4 Type Definitions .................................................................................................................................41 7.3.5 Element Declarations..........................................................................................................................43

7.4 Annotation.........................................................................................................................................43

7.5 Core Component Type .....................................................................................................................47 7.5.1 Use of Core Component Type Module...............................................................................................47 7.5.2 Schema Construct ...............................................................................................................................47 7.5.3 Namespace Scheme ............................................................................................................................47 7.5.4 Imports and Includes ..........................................................................................................................47 7.5.5 Type Definitions .................................................................................................................................48 7.5.6 Attribute Declarations.........................................................................................................................48 7.5.7 Extension and Restriction...................................................................................................................49 7.5.8 Annotation ..........................................................................................................................................49


7.6 Unqualified Data Type .....................................................................................................................50 118 119 120 121 122 123 124 125 126

127 128 129 130 131 132 133 134 135

136 137 138 139 140 141 142 143 144 145

146 147 148 149 150 151 152 153 154 155

156

157

158

159

160

161

162

163

7.6.1 Use of Unqualified Data Type Module...............................................................................................50 7.6.2 Schema Construct ...............................................................................................................................50 7.6.3 Namespace Scheme ............................................................................................................................51 7.6.4 Imports and Includes ..........................................................................................................................51 7.6.5 Type Definitions .................................................................................................................................52 7.6.6 Attribute Declarations.........................................................................................................................52 7.6.7 Restriction...........................................................................................................................................55 7.6.8 Annotation ..........................................................................................................................................55

7.7 Qualified Data Type .........................................................................................................................56 7.7.1 Use of Qualified Data Type Module...................................................................................................56 7.7.2 Schema Construct ...............................................................................................................................57 7.7.3 Namespace Scheme ............................................................................................................................57 7.7.4 Imports and Includes ..........................................................................................................................57 7.7.5 Type Definitions .................................................................................................................................58 7.7.6 Attribute and Element Declarations....................................................................................................59 7.7.7 Extension and Restriction...................................................................................................................59 7.7.8 Annotation ..........................................................................................................................................59

7.8 Code Lists ..........................................................................................................................................61 7.8.1 Schema Construct ...............................................................................................................................62 7.8.2 Namespace Name for Code Lists .......................................................................................................62 7.8.3 UN/CEFACT XSD Schema Namespace Token for Code Lists .........................................................64 7.8.4 Schema Location ................................................................................................................................65 7.8.5 Imports and Includes ..........................................................................................................................65 7.8.6 Type Definitions .................................................................................................................................65 7.8.7 Element Declarations..........................................................................................................................66 7.8.8 Extension and Restriction...................................................................................................................66 7.8.9 Annotation ..........................................................................................................................................67

7.9 Identifier List Schema ......................................................................................................................67 7.9.1 Schema Construct ...............................................................................................................................68 7.9.2 Namespace Name for Identifier List Schema ....................................................................................68 7.9.3 UN/CEFACT XSD Schema Namespace Token for Identifier List Schema.......................................70 7.9.4 Schema Location ................................................................................................................................70 7.9.5 Imports and Includes ..........................................................................................................................71 7.9.6 Type Definitions .................................................................................................................................71 7.9.7 Attribute and Element Declarations....................................................................................................72 7.9.8 Extension and Restriction...................................................................................................................72 7.9.9 Annotation ..........................................................................................................................................73

8 XML INSTANCE DOCUMENTS.......................................................................................... 74

8.1 Character Encoding .........................................................................................................................74

8.2 Empty Content..................................................................................................................................74

8.3 xsi:type...............................................................................................................................................74

APPENDIX A. RELATED DOCUMENTS .................................................................................................. 75

APPENDIX B. OVERALL STRUCTURE ................................................................................................... 76

APPENDIX C. ATG APPROVED ACRONYMS AND ABBREVIATIONS................................................. 83

APPENDIX D. CORE COMPONENT SCHEMA MODULE ....................................................................... 84


APPENDIX E. UNQUALIFIED DATA TYPE SCHEMA MODULE ............................................................ 95 164

165

166

167

168

169

APPENDIX F. ANNOTATION TEMPLATES ........................................................................................... 110

APPENDIX G. MAPPING OF CCTS REPRESENTATION TERMS TO CCT AND UDT DATA TYPES 114

APPENDIX H. NAMING & DESIGN RULES LIST .................................................................................. 115

APPENDIX I. GLOSSARY....................................................................................................................... 130

APPENDIX J. QUALIFIED DATA TYPE SCHEMA MODULE................................................................ 134


4 Introduction 170

171 172

173 174 175

176

177 178 179 180

181 182 183 184 185 186

187

188 189 190 191 192

193 194 195 196

197

198 199

200 201

202 203 204 205

206 207

208 209

210

211

212

213

214

This UN/CEFACT – XML Naming and Design Rules Technical Specification describes and specifies the rules and guidelines that will be applied by UN/CEFACT when developing XML schema.

This technical specification provides a way to identify, capture and maximize the re-use of business information expressed as XML schema components to support and enhance information interoperability across multiple business situations.

4.1 Scope and Focus This UN/CEFACT – XML Naming and Design Rules Technical Specification can be employed wherever business information is being shared or exchanged amongst and between enterprises, governmental agencies, and/or other organizations in an open and worldwide environment using XML schema for defining the content of the information exchange.

This technical specification will form the basis for standards development work of technical experts developing XML schema based on information models developed in accordance with the UN/CEFACT Core Components Technical Specification – Part 8 of the ebXML Framework (CCTS). The CCTS specification has subsequently been published as ISO/TS 15000-5 ebCCTS ebXML Electronic Business Extensible Mark-up Language, Part 5: ebCCTS ebXML Core Components Technical Specification, Version 2.01 (2003-11-15).

4.2 Audience The primary audience for this UN/CEFACT – XML Naming and Design Rules Technical Specification are members of the UN/CEFACT Applied Technologies Group who are responsible for development and maintenance of UN/CEFACT XML schema. The intended audience also includes the wider membership of the other UN/CEFACT Groups who will participate in the process of creating and maintaining UN/CEFACT XML schema.

Additional audiences are designers of tools who need to specify the conversion of user input into XML schema representation adhering to the rules defined in this document. Additionally, designers of XML schema outside of the UN/CEFACT Forum community may find the rules contained herein suitable as design rules for their own organization.

4.3 Structure of this Specification The UN/CEFACT XML Naming and Design Rules Technical Specification has been divided into 5 main sections.

Section 4 provides general information about the document itself as well as normative statements in respect to conformance.

Section 5 provides information on the guiding principles applied in developing this specification as well as its dependency and relationship to CCTS. Furthermore, this section describes the approach taken to modularity in order to maximize the re-use of business information expressed as XML schema components and the general naming conventions applied. (Normative)

Section 6 provides the general conventions applied with respect to the use of the XML schema language. (Normative)

Section 7 provides detailed rules applicable to each of the schema modules defined by the modularity approach. (Normative)

Section 8 provides guidelines and rules related to XML instance documents. (Normative)

The document also contains the following Appendices:

Appendix A Related Documents (Informative)

Appendix B Overall Structure (Normative)

Appendix C ATG Approved Acronyms and Abbreviations (Normative)


215

216

217

218

219

220

221

222

223 224 225 226 227

228

229

230 231 232

233

234

235

236

237

238

239

240

241 242

Appendix D Core Component Schema Module (Normative)

Appendix E Unqualified Data Type Schema Module (Normative)

Appendix F Annotation Templates (Informative)

Appendix G Mapping of CCTS Representation Terms to CCT and UDT Data Types (Informative)

Appendix H Naming and Design Rules List (Normative)

Appendix I Glossary (Informative)

Appendix J Qualified Data Type Schema Module (Normative)

4.4 Terminology and Notation The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in Internet Engineering Task Force (IETF) Request For Comments (RFC) 2119.1 Wherever xsd: appears this refers to a construct taken from the W3C XML schema specification. Wherever ccts: appears this refers to a construct taken from the CCTS.

Example – A representation of a definition or a rule. Examples are informative.

[Note] – Explanatory information. Notes are informative.

[Rn] – Identification of a rule that requires conformance. Rules are normative. In order to ensure continuity across versions of the specification, rule numbers that are deleted will not be re-issued, and any new rules will be assigned the next higher number - regardless of location in the text.

Courier – All words appearing in bolded courier font are values, objects or keywords.

When defining rules the following annotations are used:

• [ ] = optional

• < > = Variable

• | = choice

4.5 Related Documents Related documents referenced in this specification are listed in Appendix A.

4.6 Conformance Applications will be considered to be in full conformance with this technical specification if they comply with the content of normative sections, rules and definitions.

[R 1] Conformance shall be determined through adherence to the content of normative sections, 243 rules and definitions. 244

245

246

247 248

249 250 251

252 253

4.7 Guiding Principles The following guiding principles were used as the basis for all design rules contained in this document:

• Relationship to UMM – UN/CEFACT XSD Schema will be based on UMM metamodel adherent Business Process Models.

• Relationship to Information Models – UN/CEFACT XSD Schema will be based on information models developed in accordance with the UN/CEFACT – Core Components Technical Specification.

• Schema Creation– UN/CEFACT XML design rules will support schema creation through handcrafting as well as automatic generation.

1 Key words for use in RFCs to Indicate Requirement Levels - Internet Engineering Task Force, Request For Comments 2119, March 1997, http://www.ietf.org/rfc/rfc2119.txt


http://www.ietf.org/rfc/rfc2119.tx9

254 255 256

257 258

259 260

261 262

263 264

265 266

267 268

269 270

271

272 273

274 275

276 277

278

• ebXML Use – UN/CEFACT XSD Schema and instance documents shall be straightforwardly usable within the ebXML framework and compatible with other frameworks to the maximum extent practicable.

• Interchange and Application Use – UN/CEFACT XSD Schema and instance documents are intended for business-to-business and application-to-application use.

• Tool Use and Support - The design of UN/CEFACT XSD Schema will not make any assumptions about sophisticated tools for creation, management, storage, or presentation being available.

• Legibility - UN/CEFACT XML instance documents should be intuitive and reasonably clear in the context for which they are designed.

• Schema Features - The design of UN/CEFACT XSD Schema should use the most commonly supported features of W3C XSD Schema.

• Technical Specifications – UN/CEFACT XML design rules will be based on Technical Specifications holding the equivalent of W3C recommended status.

• Schema Specification – UN/CEFACT XML design rules will be fully conformant with W3C XML Schema Definition Language.

• Interoperability - The number of ways to express the same information in a UN/CEFACT XSD Schema and UN/CEFACT XML instance document is to be kept as close to one as possible.

• Maintenance – The design of UN/CEFACT XSD Schema must facilitate maintenance.

• Context Sensitivity - The design of UN/CEFACT XSD Schema must ensure that context-sensitive document types aren’t precluded.

• Relationship to Other Namespaces - UN/CEFACT XML design rules will be cautious about making dependencies on other namespaces.

• Legacy formats - UN/CEFACT XML design rules are not responsible for sustaining legacy formats.

• Messages must express semantics fully in schema and not rely on well-formedness.


5 General XML Construct 279

280

281

282

283

284

285

286

287

288

289 290 291 292

This section defines rules related to general XML constructs to include:

• Overall Schema Structure

• Relationship to CCTS

• Naming and Modelling Constraints

• Reusability Scheme

• Modularity Strategy

• Namespace Scheme

• Versioning Scheme

5.1 Overall Schema Structure UN/CEFACT has determined that the World Wide Web Consortium (W3C) XML schema definition (XSD) language is the generally accepted schema language experiencing the broadest adoption. Accordingly, all UN/CEFACT normative schema will be expressed in XSD. All references to XML schema will be as XSD schema or UN/CEFACT XSD Schema.

[R 2] All UN/CEFACT XSD Schema design rules MUST be based on the W3C XML Schema 293 Recommendations: XML Schema Part 1: Structures and XML Schema Part 2: Data Types. 294

295 296 297

The W3C is the recognized source for XML specifications. W3C specifications can hold various status. Only those W3C specifications holding recommendation status are guaranteed by the W3C to be stable specifications.

[R 3] All UN/CEFACT XSD Schema and UN/CEFACT conformant XML instance documents MUST 298 be based on the W3C suite of technical specifications holding recommendation status. 299

300 301

To maintain consistency in lexical form, all UN/CEFACT XSD Schema need to use a standard structure for all content. This standard structure is contained in Appendix B.

[R 4] UN/CEFACT XSD Schema MUST follow the standard structure defined in Appendix B. 302

303

304 305

306

307 308 309 310 311 312

5.2 Relationship to the CCTS All UN/CEFACT business information and business process modelling employ the methodology and model described in CCTS.

5.2.1 CCTS CCTS defines context neutral and context specific information building blocks. Context neutral information components are defined as Core Components (ccts:CoreComponents). Context neutral ccts:CoreComponents are defined in CCTS as “A building block for the creation of a semantically correct and meaningful information exchange package. It contains only the information pieces necessary to describe a specific concept.”2 Figure 5-1 illustrates the various pieces of the overall ccts:CoreComponents metamodel.

2 Core Components Technical Specification, Part 8 of the ebXML Technical Framework Version 2.0 (Second Edition), UN/CEFACT, 15 November 2003


Core ComponentBusiness Term 0..*

Registry ClassUnique Identifier 1..1Dictionary EntryName 1..1Definition 1..1

CC P ropertyProperty Term 1..1Cardinality 1..1

Aggregate Core Component (ACC)Object Class Term 1..1

1..*1..*

Association Core Component (ASCC)

Association CC P roperty

1

0..*

1

0..* 1

1

1

1

S upplementary Component

Content Component

B asic Core Component (B CC)

Core Component Type (CCT)Primary Representation Term 1..1Secondary Representation Term 0..*

1..*1..*

11

Basic CC P roperty

11 11

Supplementary Component Restriction

Content Component Restriction

Data TypeQual ifier Term 0..1

0..* 10..*+basis

11

0..*

1

0..*

0..*0..*

0..*0..*

313 314

315

316 317 318 319 320

Figure 5-1 Core Component Metamodel

5.2.2 Business Information Entities In the CCTS model, context neutral core components are instantiated as context specific components for message assembly and model harmonization. The context specific components are defined as Business Information Entities (ccts:BusinessInformationEntities). See CCTS Section 6.2 for a detailed discussion of the ebXML context mechanism.3 Context specific ccts:BusinessInformationEntities are defined in CCTS as “A piece of business data or a group

3Core Components Technical Specification, Part 8 of the ebXML Technical Framework Version 2.0 (Second Edition), UN/CEFACT, 15 November 2003


of pieces of business data with a unique Business Semantic definition.”4 Figure 5-2 illustrates the various pieces of the overall

321 322 323

ccts:BusinessInformationEntity metamodel and their relationship with the ccts:CoreComponents metamodel.

Registry ClassUnique Identif ier 1..1Dictionary Entry Name 1..1Def inition 1..1

Business Context

Business Information Entity (BIE )Business Term 0..*

1..*

0..*

+context 1..*

0..*

Core Component0..* 10..*

+basis

1

Association BIE Property Association CC Property

Association Core Component (ASCC)

1

1

1

1

Association Business Inf ormation Enti ty (ASBI E)

1

1

1

1

10..*

+basis

10..*

Aggregate Business Inf ormation Entity (ABIE)Qualif ier Term 0..1Cardinality 1..1

1

0..*

1

0..*

Aggregate Core Component (ACC)

Object Class Term 1..1

0..*

1

0..*

1

10..*

+basis

10..*

CC PropertyProperty Term 1..1Cardinality 1 .. 1

1..*1..*

B IE P ropertyQualif ier Term 0..1

1..*1..*

10..*

+basis

10..*

Basic Business Information Entity (BBIE)

Basic BIE Property

1

1

1

1

Basic Core Component (BCC)

10..*

+basis

10..*

Basic CC Property

1

1

1

1

Data TypeQualif ier Term 0..1

0..*

1

0..*

10..*

10..*

1

324 325

326

327 328 329 330 331 332

Figure 5-2 Context Specific Business Information Entity Metamodel

5.2.3 The XML Constructs UN/CEFACT XML design rules will be closely coupled with CCTS. UN/CEFACT XSD Schema will be developed from fully conformant Business Information Entities that are based on fully conformant Core Components. Figure 5-3 shows the relationship between CC’s, BIE’s and XSD artefacts. The grey boxes reflect CCTS constructs (Core Component Types, Data Types, Core Components, Business Information Entities), and the other boxes reflect XSD constructs (xsd:types, xsd:elements, xsd:attributes). The relationships follow the following basic principles:

4 Core Components Technical Specification, Part 8 of the ebXML Technical Framework Version 2.01, UN/CEFACT, 15 November 2003


xsd:complexType

xsd:element

xsd:element

Core Component Type(CCT)

Specifiesrestrictions on

Data Type(DT)

Basic Core Component(BCC)

Aggregate Core Component(ACC)

Association Core Component(ASCC)

Defines a setof values of

As Propertyaggregated

in

Furtherrestricts

Based

Is

BasedOn

xsd:complexType

xsd:complexType or

xsd:simpleType

xsd:(root)element

Data Type(DT)

Basic Business InformationEntity (BBIE)

Aggregate BusinessInformation Entity (ABIE)

Association BusinessInformation Entity (ASBIE)

Defines a setof values of

Message Assembly

Aggregatedin

Qualified andUnqualifiedData Types

AssemblyComponent

Addsextra

information

Aggregatedin

Is Based On

As Propertyaggregated

in

Is

On

Context Neutral Context Specific Syntax Specific

QualifiesThe

ObjectClass

Of

333 334

335 336 337 338

339

340 341 342 343 344

Figure 5-3 Relationship between CCTS and XSD Artefacts in UN/CEFACT XSD Schema

• The message assembly is represented as a xsd:complexType definition and global element declaration in an UN/CEFACT XSD Schema. The global element declaration is based on (is of type) xsd:complexType that represents the document level ABIE. The global element appears in, and is designated as the root element of, UN/CEFACT conformant XML instances.

• An ABIE is defined as a xsd:complexType.

• An ASBIE is declared as a local element within the xsd:complexType representing the associating ABIE. The ASBIE element is in itself based on (is of type) xsd:complexType of the associated ABIE. In this way the content model of the associated ABIE is included in the content model of the associating ABIE.

[Note] 345

Per CCTS, an ABIE can contain other ABIEs in ever higher levels of aggregation. When 346 an ABIE contains another ABIE, this is accomplished through the use of ASBIEs. The 347 ASBIE is the linking mechanism that shows the hierarchical relationship between ABIE 348 constructs. When an ASBIE is used, we refer to the ABIE that contains it as the 349 associating ABIE, and the ABIE that it represents as the associated ABIE. 350

351 352

353 354 355 356 357 358

• A BBIE is declared as a local element within the xsd:complexType representing the parent ABIE. The BBIE is based on a (is of type) qualified or unqualified data type (DT).

• A DT is defined as either a xsd:complexType or xsd:simpleType. DT’s are based on Core Component Type xsd:complexType from the CCT schema module. These data types can be unqualified (no additional restrictions above those imposed by the CCT type) or qualified (additional restrictions above those imposed by the CCT type). XSD built-in data types will be used whenever the facets of the built-in data type are equivalent to the CCT supplementary components for that data type.


[Note] 359

Data Types are not derived from the CCT complex types using xsd:restiction 360 because whereas all CCTs are defined as complex types with attributes representing 361 their supplementary components, in several cases we leverage built-in 362 xsd:simpleType whose facets correspond to the supplementary components. See 363 Section 7.5 for more information. 364

365 366 367 368

369

370 371 372 373 374 375 376

• A CCT is defined as a xsd:complexType. Supplementary components are declared as attributes for the CCT xsd:complexType. CCTs are contained in the Core Component Type Schema Module which is considered the normative XSD expression of CCTS Core Component Types.

5.3 Naming and Modelling Constraints UN/CEFACT XSD Schema are derived from CCTS and UN/CEFACT Modelling Methodology (UMM) process modelling and data analysis. The UN/CEFACT library contains fully conformant CCTS dictionary entry names as well as truncated XML element names developed in conformance with the naming constraint rules specified below. The XML fully qualified XPath ties the information to its standardized semantics as described in the underlying CCTS construct and CCTS Dictionary Entry Name, while the XML element or attribute name is a truncation that reflects the hierarchy inherent in the XML construct. There are differences in the rules for naming of elements, attributes, and types.

[R 5] Each element or attribute XML name MUST have one and only one fully qualified XPath 377 (FQXP). 378

379 380

381

This rule and the other rules on element naming imply that a part of the fully qualified XPath will always represent the CCTS dictionary entry name of the corresponding ABIE, BBIE, ASBIE or DT.

Example 5-1: Fully Qualified XPath Address/Coordinate/Latitude Measure 382

383

384 385 386 387

Organisation/Location/Name

The official language for UN/CEFACT is English. All official XML constructs as published by UN/CEFACT will be in English. XML development work may very well occur in other languages, however official submissions for inclusion in the UN/CEFACT XML library must be in English. Other language translations of UN/CEFACT published XML components are at the discretion of users.

[R 6] Element, attribute and type names MUST be composed of words in the English language, 388 using the primary English spellings provided in the Oxford English Dictionary. 389

390 391 392 393 394

Following the ebXML Architecture Specification and commonly used best practice, Lower Camel Case (LCC) is used for naming attributes and Upper Camel Case (UCC) is used for naming elements and types. Lower Camel Case capitalizes the first character of each word except the first word and compounds the name. Upper Camel Case capitalizes the first character of each word and compounds the name.

[R 7] Lower camel case (LCC) MUST be used for naming attributes. 395

396 Example 5-2: Attribute 397 <xsd:attribute name="unitCode" .../>

[R 8] Upper camel case (UCC) MUST be used for naming elements and types. 398

399 Example 5-3: Element 400

401

<xsd:element name="LanguageCode" ...>

Example 5-4: Type 402 <xsd:complexType name="DespatchAdviceCodeType">

[R 9] Element, attribute and type names MUST be in singular form unless the concept itself is 403 plural. 404

405 Example 5-5: Singular and Plural Concept Form


Allowed - Singular: 406 407

408

<xsd:element name="ItemQuantity" ...>

Not Allowed - Plural: 409 <xsd:element name="GoodsQuantity" ...>

[R 10] Element, attribute and type names MUST be drawn from the following character set: a-z 410 and A-Z. 411

412

413

Example 5-6: Non-Letter Characters

Not Allowed 414

415 416 417

<xsd:element name="LanguageCode8" ...>

The CCTS allows for the use of periods, spaces and other separators in the dictionary entry name. XML best practice is to not include these in an XML tag name. Additionally XML 1.0 specifically prohibits the use of certain reserved characters in XML tag names.

[R 11] XML element, attribute and type names constructed from dictionary entry names MUST NOT 418 419 include periods, spaces, or other separators; or characters not allowed by W3C XML 1.0 for

XML names. 420

421

422

Example 5-7: Spaces in Name

Not Allowed 423 <xsd:element name="Customized_ Language. Code:8" ...>

[R 12] XML element, attribute and type names MUST NOT use acronyms, abbreviations, or other 424 425 426

427 428 429

word truncations, except those included in the UN/CEFACT controlled vocabulary or listed in Appendix C.

[R 13] Acronyms and abbreviations at the beginning of an attribute declaration MUST appear in all lower case. All other acronym and abbreviation usage in an attribute declaration must appear in upper case.

[R 14] Acronyms MUST appear in all upper case for all element declarations and type definitions. 430

431

432

Example 5-8: Acronyms and Abbreviations

Allowed – ID is an approved abbreviation 433

434 435

<xsd:attribute name="currencyID"

Not Allowed – Cd is not an approved abbreviation, if it was an approved abbreviation it must appear in all upper case

436

437

438 439 440 441 442 443 444 445 446 447 448 449 450 451 452

<xsd:simpleType name="temperatureMeasureUnitCdType>

5.4 Reusability Scheme UN/CEFACT is committed to transitioning to an object based approach for its process models and core components implementation efforts as supported in both UMM and CCTS. UN/CEFACT deliberated adopting a type based approach (named types), a type and element based approach, or an element based approach. A type based approach for XML management provides the closest alignment with the process modelling methodology described in UMM. Type information is beginning to be accessible when processing XML instance documents. Post schema-validation infoset (PSVI) capabilities are beginning to emerge that support this approach, such as “data-binding” software that compiles schema into ready-to-use object classes and is capable of manipulating XML data based on their types. The most significant drawback to a type based approach is the risk of developing an inconsistent element vocabulary where elements are declared locally and allowed to be reused without regard to semantic clarity and consistency across types. UN/CEFACT manages this risk by carefully controlling the creation of BBIEs and ASBIEs with fully defined semantic clarity that are only usable within the ABIE in which they appear. This is accomplished through the relationship between BBIEs, ASBIEs and their parent ABIE and the strict controls put in place for harmonization and approval of the semantic constructs prior to their XSD instantiation.


[R 15] All element declarations for BBIEs and ASBIEs MUST be locally declared within the parent 453 ABIE type. 454

455

456 457 458 459 460 461

462

463 464 465 466

467 468 469 470 471 472 473

474 475 476 477 478 479

480 481 482 483

484 485

5.4.1 Element Naming Conventions The fully qualified XPath anchors the use of a construct to a particular location in a business message. The dictionary definition identifies any semantic dependencies that the FQXP has on other elements and attributes within the UN/CEFACT library that are not otherwise enforced or made explicit in its structural definition. The dictionary serves as a traditional data dictionary, and also serves some of the functions of traditional implementation guides. As discussed in Section 5.4 above, the dictionary must be carefully controlled to overcome the limitations in control inherent in a local element approach.

5.5 Modularity Model Modularity in schema design promotes reuse and provides significant management capabilities. Modules can be either unique in their functionality, or represent splitting of larger schema files for performance or manageability enhancement. A modularity model provides an efficient and effective mechanism for importing components as needed rather than dealing with complex, multi-focused schema.

Accordingly UN/CEFACT has defined a number of schema modules to support this approach. Figure 5-4 portrays the CEFACT modularity model. We categorize our modules into message assembly and external schema. The message assembly consists of root schema and internal schema modules that reside in the same namespace as the root schema. The external schema modules consist of a set of reusable schema for ABIEs, unqualified data types, qualified data types, code lists and identifier lists. Each of these schema modules reside in their own namespace. Dependencies exist amongst the various modules as shown in the figure.

The root schema always includes any internal schema residing in its namespace. It also always imports the ABIE reusable schema, unqualified and qualified data type schema modules. It may import root schemas from other namespaces as well as reusable schema from other standards bodies. The internal schema may include other internal schema modules from its own namespace, and may reference – through the root schema – other root schema and their internal schema modules. It may also import the unqualified data type, qualified data type, and reusable ABIE schema modules.

The reusable ABIE schema module always imports the unqualified data type and qualified data type schema modules. The unqualified data type schema imports necessary code list schema modules and may import identifier list schema modules. The qualified data type schema always imports the unqualified data type schema as well as necessary code list and identifier list schema modules.

The core component type schema module is provided as reference documentation and is used as the basis for the unqualified data type schema module.


486 487

488 489 490

Figure 5-4 UN/CEFACT XSD Schema Modularity Scheme

To ensure consistency, and for standardization of namespace tokens as addressed elsewhere in this specification, all schema modules identified above are referred to by their formal name or token value in the table below:

Schema Module Name Token RootSchema rsm CCTS CCT cct UN/CEFACT Reusable Aggregate Business Information Entity

ram

UN/CEFACT Unqualified Data Type udt UN/CEFACT Qualified Data Type qdt Code List clm Identifier List ids

5.5.1 Root Schema 491

492 493 494

UN/CEFACT incorporates a modularity concept that leverages the benefits previously described. In the UN/CEFACT XML repository, there are a number of UN/CEFACT root schema, each of which expresses a separate business function.

[R 16] A root schema MUST be created for each unique business information exchange. 495

496 497 498 499 500

The UN/CEFACT modularity approach enables the reuse of individual root schema without having to import the entire UN/CEFACT root schema library. Additionally, a root schema can import individual modules without having to import all UN/CEFACT XSD schema modules. Each root schema will define its own dependencies. A root schema should not duplicate reusable XML constructs contained in other schema, rather it should reuse existing constructs available elsewhere. Specifically, root schema will


import or include other schema modules to maximize reuse through xsd:include or xsd:import as appropriate.

501 502

[R 17] A root schema MUST NOT replicate reusable constructs available in schema modules 503 capable of being referenced through xsd:include or xsd:import. 504

505 506

Schema modules used by the root schema need to be treated as either internal or external schema modules so correct namespace decisions can be made.

[R 18] UN/CEFACT XSD schema modules MUST either be treated as external schema modules or 507 as internal schema modules of the root schema. 508

509

510 511 512 513

514 515 516 517 518

5.5.2 Internal Schema Not all ABIEs will be suitable for widespread reuse. Some may be limited to a specific business function or information exchange. These ABIEs will be defined as xsd:complexType in an internal schema module rather than in the reusable ABIE module, (See Section 5.5.3.4 below). UN/CEFACT XSD Schema may have zero or more internal modules.

Internal schema modules will reside in the same namespace as their parent root schema. Since the internal schema reside in the same namespace as the root, the root schema uses xsd:include to incorporate these internal modules. The UN/CEFACT XSD schema modularity approach ensures that logical associations exist between root and internal schema modules and that individual modules can be reused to the maximum extent possible.

[R 19] All UN/CEFACT internal schema modules MUST be in the same namespace as their 519 corresponding rsm:RootSchema. 520

521 522 523

UN/CEFACT internal schema modules will necessarily have a semantically meaningful name. Internal schema module names will identify the parent root schema module, the internal schema module function, and the schema module itself.

[R 20] Each UN/CEFACT internal schema module MUST be named 524 <ParentRootSchemaModuleName><InternalSchemaModuleFunction> Schema Module 525

526 Example 5-9: UN/CEFACT internal schema module name TravelReservationRequestFlightInformation Schema Module 527 Where: 528 TravelReservationRequest represents the parent root schema module name 529

530

531

532 533 534 535

536

537

538

539

540

541

542 543

FlightInformation represents the internal schema module function

5.5.3 External Schema To adhere to the principles and rules contained in Section 7, schema modules will be created for reusable components. These schema modules are referred to as external schema modules because they reside in a different namespace from the root schema. Root schema may import one or more of these external schema modules. UN/CEFACT has identified the need for the following external schema modules:

• Core Component Type

• Unqualified Data Type

• Qualified Data Type

• Reusable ABIE

• Code List

• Identifier List

• Other Standards Body ABIE module

[Note] 544


The terms “unqualified data type” and “qualified data type” refer to the ISO 11179 545 concept of qualifiers for name constructs, not to the xml namespace concept of qualified 546 and unqualified 547

548 These external schema modules are reflected in Figure 5-5.

Schema ModuleType

File

Namespace

W3C XML Schema

1

1

1

1 ..*

Root Schema Module

Internal Schema Module

Reusable ABIE Module

Unqualified Data Type Module

Qualified Data Type Module

Identifier List Module

Code List Module

Core Component Type Module

Other Standards Body ABIE Module

549 550

551

552 553 554

Figure 5-5 UN/CEFACT XSD Schema Modules

5.5.3.1 Core Component Type Schema Module A schema module is required to represent the normative form for CCTs from CCTS. This schema module will be used as the normative reference for all CCTS based XML instantiations. This schema will form the basis of the UDT schema module, however it will never be imported directly into any UN schema module.

[R 21] A Core Component Type schema module MUST be created 555

556 557

The Core Component Type schema module will have a standardized name that uniquely differentiates it from other UN/CEFACT XSD schema modules.

[R 22] The cct:CoreComponentType schema module MUST be named "CCTS CCT Schema 558 Module" 559

560

561

562 563 564 565 566 567 568

The current version of the normative UN/CEFACT CCT schema module is contained in Appendix D.

5.5.3.2 Unqualified Data Type Schema Module A schema module is required to represent the normative form data types for each CCT as expressed in the CCTS meta model. These data types are based on the XSD constructs from the CCT schema module but where possible reflect the use of built-in xsd:simpleType rather than their parent CCT xsd:complexType. As such, the unqualified data type schema module does not import the CCT schema module. The unqualified data types are so named because they contain no additional restrictions on their source CCTs other than those defined in CCTS and agreed upon best practices. An unqualified data type is defined for all approved CCTS primary and secondary representation terms.

[R 23] An Unqualified Data Type schema module MUST be created 569

570 571

The unqualified data type schema module will have a standardized name that uniquely differentiates it from other UN/CEFACT XSD schema modules.

[R 24] The udt:UnqualifiedDataType schema module MUST be named "UN/CEFACT 572 Unqualified Data Type Schema Module" 573


574 575

576

577 578 579 580 581

The current version of the normative UN/CEFACT Unqualified Data Type Schema Module is contained in Appendix E.

5.5.3.3 Qualified Data Type Schema Module As data types are reused for different BIEs, restrictions on the data type may be applied. These restricted data types are referred to as qualified data types. These qualified data types will be defined in a separate qualified data type schema module. A qualified data type schema module will import the UN/CEFACT Unqualified Data Type Schema Module. In the future this single qualified data type schema module may be segmented into additional modules if deemed necessary.

[R 25] A Qualified Data Type schema module MUST be created.. 582

583 584

The qualified data type schema module will have a standardized name that uniquely differentiates it from other UN/CEFACT XSD schema modules.

[R 26] The qdt:QualifiedDataType schema module MUST be named "UN/CEFACT Qualified 585 Data Type Schema Module" 586

587 588

589

590 591 592 593 594 595 596

The current version of the normative UN/CEFACT Qualified Data Type Schema Module is contained in Appendix E.

5.5.3.4 Reusable Aggregate Business Information Entity Schema Module A single reusable aggregate business information entity schema module is required. This schema module will contain a type definition for every reusable ABIE in the UN/CEFACT Core Component Library. In the future this single reusable schema module may be segmented into additional modules if deemed necessary. This single reusable schema module may be compressed for run time performance considerations if necessary. Compression means that a run time version of the reusable ABIE schema module would be created that would consist of a subset of the ABIE constructs. This subset would consist only of those ABIEs necessary to support the specific root schema being validated.

[R 27] A Reusable Aggregate Business Information Entity schema module MUST be created 597

598 599

The reusable aggregate business information entity schema module will have a standardized name that uniquely differentiates it from other UN/CEFACT XSD schema modules.

[R 28] The ram:ReusableAggregateBusinessInformationEntity schema module MUST 600 be named "UN/CEFACT Reusable Aggregate Business Information Entity Schema Module" 601

602

603 604 605

5.5.3.5 Code List Schema Modules In cases where a code list is required or used, reusable code list schema modules will be created to minimize the impact of code list changes on root and other reusable schema. Each reusable code list schema module will contain enumeration values for codes and code values.

[R 29] Reusable Code List schema modules MUST be created to convey code list enumerations 606

607 608

Code list schema modules will have a standardized name that uniquely differentiates it from other UN/CEFACT XSD schema modules and external organization generated code list modules.

[R 30] The name of each clm:CodeList schema module MUST be of the form: <Code List 609 610 611 612 613 614 615 616 617

Agency Identifier|Code List Agency Name><Code List Identification Identifier|Code List Name> - Code List Schema Module Where: Code List Agency Identifier = Identifies the agency that maintains the code list Code List Agency Name = Agency that maintains the code list Code List Identification Identifier = Identifies a list of the respective corresponding codes Code List Name = The name of the code list as assigned by the agency that maintains the code list 618

619 Example 5-10: Name of UN/CEFACT Account Type Code Schema Module 64437 - Code List Schema Module 620


where: 621 6 = Code list agency identifier for UN/CEFACT as defined in UN/CEFACT code 622 list 3055 623 4437 = Code list identification identifier for Account Type Code in UN/CEFACT 624

625

626

directory

Example 5-11: Name for a code using agency name and code list name 627

628

629 630 631 632

Security Initiative Document Security Code - Code List Schema Module

5.5.3.6 Identifier List Schema Module In those cases where run time validation is required against a used identifier scheme, a separate identifier list schema module will be created to minimize the impact of identifier list changes on root and other reusable schema. Each reusable identifier list schema module will contain enumeration values for the identifiers.

[R 31] An Identifier List schema module MUST be created to convey enumeration values for each 633 identifier list that requires run time validation . 634

635 636

Identifier list schema modules will have a standardized name that uniquely differentiates it from other UN/CEFACT XSD schema modules or external organization generated schema modules.

[R 32] The name of each ids:IdentifierList schema module MUST be of the form: 637 638 639 640 641 642 643 644 645 646 647

<Identifier Scheme Agency Identifier|Identifier Scheme Agency Name><Identifier Scheme Identifier|Identifier Scheme Name> - Identifier List Schema Module Where: Identifier Scheme Agency Identifier = The identification of the agency that maintains the identification scheme Identifier Scheme Agency Name = Agency that maintains the identifier list Identifier Scheme Identifier = The identification of the identification scheme Identification Scheme Name = Name as assigned by the agency that maintains the identifier list 648

649 Example 5-12: Name of ISO Country Identifier schema module 53166-1 - Identifier List Schema Module 650 where: 651 5 = Code list agency identifier for ISO as defined in UN/CEFACT code 652 list 3055 653 3166-1 = Identifier scheme identifier for Two Alpha Country Identifier in 654

655

656 657

658 659 660 661

ISO

5.5.3.7 Other Standards Body Aggregate Business Information Entity Schema Modules

Other Standards Body ABIE modules are those reusable XML constructs created by standards bodies other than UN/CEFACT and made publicly available. UN/CEFACT will only import other Standards Body ABIE modules when their contents are in strict conformance to the requirements of the CCTS and this specification.

[R 33] Imported schema modules MUST be fully conformant with the UN/CEFACT XML Naming and 662 Design Rules Technical Specification and the Core Components Technical Specification. 663

664

665 666 667 668

5.6 Namespace Scheme As defined in the W3C specification, “XML namespaces provide a simple method for qualifying element and attribute names used in Extensible Markup Language documents by associating them with namespaces identified by URI references.”5 This enables interoperability and consistency in the XML artefacts for the extensive library of reusable types and schema modules. The UN/CEFACT reusability

5 World Wide Web Consortium, Namespaces in XML, 14 January 1999


669 670 671 672 673 674

675

676 677 678 679 680

methodology maximizes the reuse of defined named types and locally declared elements and attributes within those types (See Section 5.4). In addition, the modularity approach of multiple reusable schema modules (See Section 5.5) prescribe just such a method. There exists specific relationships between the various internal and external schema modules identified in Section 5.5 with respect to their namespaces. These relationships are defined in Figure 5-4. Accordingly, a sufficiently robust namespace scheme is essential.

5.6.1 UN/CEFACT Namespace Scheme In establishing a UN/CEFACT approach to namespaces, it is important to recognize that in addition to XML requirements, many other requirements exist for a standardized namespace approach. Accordingly, a master UN/CEFACT namespace scheme must be sufficiently flexible and robust to accommodate both XML and other syntax requirements. Figure 5-6 reflects such an approach and will be used as the basis for determining the namespace structure and rules that follow.

681 682

683

684 685

Figure 5-6: UN/CEFACT Namespace Scheme

5.6.2 Declaring Namespace Best practice dictates that every schema module have its own namespace with the exception that internal schema modules will be in the same namespace as the root schema.

[R 34] Every UN/CEFACT defined or imported schema module MUST have a namespace declared, 686 using the xsd:targetNamespace attribute. 687


5.6.3 Namespace Persistence 688

689 690 691 692 693 694 695 696 697 698 699

Namespaces also provide a means for achieving consistency and harmonization between schema versions. UN/CEFACT has chosen to align namespace versioning with schema versioning and modularity. The UN/CEFACT modularity approach provides for grouping of reusable schemas by a root schema. Many of these schema are intended to be reused across multiple schema. Others are unique to a particular root schema. The root schema and those schema modules that are unique to it are considered a schema set. The contents of a schema set are so interrelated that proper management dictates that both versioning and namespace of all members of the set be in synchronization. Schema sets are therefore assigned to a single, versioned namespace. Other schema modules are also best managed by being assigned to their own unique versioned namespaces. Accordingly, with the exception of internal schema modules, each UN/CEFACT XSD schema module will have its own namespace and each namespace will be versioned.

[R 35] Every version of a defined or imported schema module other than internal schema modules 700 MUST have its own unique namespace. 701

702 703 704

Once a namespace declaration is published, any change would result in an inability to validate instance documents citing the namespace. Accordingly, a change in the construct or contents of the namespace should not be allowed.

[R 36] UN/CEFACT published namespace declarations or contents MUST never be changed. 705

706

707 708 709 710 711 712

5.6.4 Namespace Uniform Resource Identifiers Namespaces must be persistent. Namespaces should be resolvable. Uniform Resource Indicators (URIs) are used for identifying a namespace. Within the URI space, options include Uniform Resource Locators (URLs) and Uniform Resource Names (URNs). URNs have an advantage in that they are persistent. URLs have an advantage in that they are resolvable. After careful consideration, UN/CEFACT has determined that URNs are most appropriate as persistence is of a higher priority, and efforts are underway to make URNs resolvable.

[R 37] UN/CEFACT namespaces MUST be defined as Uniform Resource Names 713

714 715 716 717

718

719

720

721

722

723

724

725

726

727

728

729 730

731 732

733

To ensure consistency, each UN/CEFACT namespace will have the same general structure. This namespace structure will follow the provisions if Internet Engineering Task Force (IETF) Request For Comments (RFC) 2141 – URN Syntax. That specification calls for a standardized URN syntax structure as follows: (phrases enclosed in quotes are REQUIRED):

<URN> ::= "urn:" <NID> ":" <NSS>

where :

<NID> = the Namespace Identifier

<NSS> = the Namespace Specific String.

The leading "urn:" sequence is case-insensitive.

The Namespace ID determines the syntactic interpretation of the Namespace Specific String

Following this pattern, the UN/CEFACT namespace general structure for a namespace name should be:

urn:un:unece:uncefact:<schematype>:<status>:<name>:<version>

Where:

• Namespace Identifier (NID) = un

• Namespace Specific String =

• unece:uncefact:<schematype>:<status>:<name>:<version> with unece and uncefact as fixed value second and third level domains within the NID of un

• schematype = a token identifying the type of schema module: data|process|codelist|identifierlist|documentation

• status = the status of the schema as: draft|standard


734

735

736 737

738 739

740 741

• name = the name of the module (using upper camel case)

• version = <major>.<minor>.[<revision>]

• major = The major version number. Sequentially assigned, first release starting with the number 1.

• minor = The minor version number within a major release. Sequentially assigned, first release starting with the number 0. Not applicable for code list or identifier list schema.

• revision = Sequentially assigned alphanumeric character for each revision of a minor release. Only applicable where status = draft. Not applicable for code list or identifier list schema.

[R 38] The names for namespaces MUST have the following structure while the schema is at draft 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756

status: urn:un:unece:uncefact:<schematype>:draft:<name>:<major>.[<minor>].[<revision] Where: schematype = a token identifying the type of schema module: data|process|codelist|identifierlist|documentation name = the name of the module (using upper camel case) major = the major version number. Sequentially assigned, first release starting with the number 1. minor = the minor version number within a major release. Sequentially assigned, first release starting with the number 0. Not applicable for code list or identifier list schema. revision = sequentially assigned alphanumeric character for each revision of a minor release. Only applicable where status = draft and schema type does not equal code list or identifier list. 757

758 Example 5-13: Namespace Name at Draft Status "urn:un:unece:uncefact:data:draft:UNCEFACTUnqualifiedDataTypeSchemaModule:0.3759 .5" 760

[R 39] The namespace names for schema holding specification status MUST be of the form: 761 762 763 764 765 766 767 768 769 770

urn:un:unece:uncefact:<schematype>:standard:<name>:<major>.[<minor>] Where: schematype = a token identifying the type of schema module: data|process|codelist|identifierlist|documentation name = the name of the module major = the major version number, sequentially assigned, first release starting with the number 1. minor = the minor version number within a major release, sequentially assigned, first release starting with the number 0. Not applicable for code list or identifier list schema. 771

772 Example 5-14: Namespace Name at Specification Status "urn:un:unece:uncefact:data:standard:UNCEFACTUnqualifiedDataTypeSchemaModule:773 1.0" 774

775

776 777 778 779

5.6.5 Namespace Constraint To ensure consistency in declaring namespaces, a namespace should only be declared for an XML construct by the owner of that namespace – unless specifically designed as a generic namespace such as xsi. Accordingly, UN/CEFACT namespaces will only contain XML constructs created and assigned by UN/CEFACT.

[R 40] UN/CEFACT namespaces MUST only contain UN/CEFACT developed schema modules. 780

781

782 783

5.6.6 UN/CEFACT XSD Schema Namespace Tokens A unique token will be defined for each namespace. The exact token for each type of namespace will be defined by the applicable schema module subsection in Section 7.


5.7 Schema Location 784

785 786 787 788 789 790 791

792

Schema locations are required to be in the form of a URI scheme. Schema locations are typically the same as their namespaces. Schema locations are typically defined as URL based URI schemes because of resolvability limitations of URN based URI schemes. However, UN/CEFACT XSD Schema use a URN based URI scheme for namespace declarations because persistence is considered more important than resolvability. In recognition of the need for resolvability of schema location, until such time as URNs become fully resolvable, UN/CEFACT will store schema in locations identified using a URL based URI scheme aligned with the URN based URI scheme used for the namespace declaration as follows:

urn:un:unece:uncefact:<schematype>:<status>:<name>:<version>

[R 41] The general structure for schema location MUST be: 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807

808 809

http://www.unece.org/uncefact/<schematype>/<name>_<major>.<minor>. [<revision>]_[<status>].xsd Where: schematype = a token identifying the type of schema module: data|process|codelist|identifierlist|documentation name = the name of the module (using upper camel case) major = the major version number, sequentially assigned, first release starting with the number 1. minor = the minor version number within a major release, sequentially assigned, first release starting with the number 0. revision = sequentially assigned alphanumeric character for each revision of a minor release. Only applicable where status = draft. status = the status of the schema as: draft|standard

[R 42] Each xsd:schemaLocation attribute declaration MUST contain a persistent and resolvable URL.

[R 43] Each xsd:schemaLocation attribute declaration URL MUST contain an absolute path. 810

811

812 813 814 815

816

817 818 819 820

821

822

823

824

825

826

827

828

829

830

5.8 Versioning A UN/CEFACT namespace URN is divided into three parts. First is the standard UN/CEFACT namespace information. Second is the description of the purpose of the namespace. Third is the version information. The version information will in turn be divided into major (or incompatible) and minor (or compatible) fields. The minor field has an optional revision extension.

5.8.1 Major Versions A major version of a UN/CEFACT XSD schema module constitutes significant and/or non-backwards compatible changes. If any XML instance based on such older major version UN/CEFACT XSD Schema attempts validation against the newer version, it will experience validation errors. A new major version will be produced when significant and/or non-backwards compatible changes occur, i.e.

• Removing or changing values in enumerations

• Changing of element names, type names and attribute names

• Changing the structures so as to break polymorphic processing capabilities

• Deleting or adding mandatory elements or attributes

• Changing cardinality from mandatory to optional

Major version numbers are reflected in the namespace declaration as follows:

urn:un:unece:uncefact:<schematype>:<status>:<name>:<major>.0

Where:

• major = the first release starts with the number 1.

• minor = always 0 for major release numbers.


[R 44] Every schema major version MUST have the URI of: 831 832 urn:un:unece:uncefact:<schematype>:<status>:<name>:<major>.0.[<revis

ion>] 833

834 835 836

Major version numbers should be based on logical progressions to ensure semantic understanding of the approach and guarantee consistency in representation. Non-negative, sequentially assigned incremental integers satisfy this requirement.

[R 45] Every UN/CEFACT XSD Schema and schema module major version number MUST be a 837 sequentially assigned incremental integer greater then zero. 838

839

840 841 842 843 844

845

846

847

5.8.2 Minor Versions Within a major version of an UN/CEFACT XSD schema module there can be a series of minor, or compatible, changes. The minor versioning of an UN/CEFACT XSD schema module determines its compatibility with UN/CEFACT XSD schema modules with preceding and subsequent minor versions within the same major version. The minor versioning scheme thus helps to establish backward and forward compatibility. Minor versions will only be increased when compatible changes occur, i.e

• Adding values to enumerations

• Optional extensions

• Add optional elements

[R 46] Minor versioning MUST be limited to declaring new optional XSD constructs, extending 848 existing XSD constructs and refinements of an optional nature. 849

850

851

852

853

854

Minor version numbers are reflected in the namespace declaration as follows:

urn:un:unece:uncefact:<schematype>:<status>:<name>:<major>.<non-zero integer>.[<revision>]

Where:

• major = the major version number, sequentially assigned, first release starting with the number 1

• minor = always positive integer

[R 47] Every UN/CEFACT XSD Schema minor version MUST have the URI of: 855 856 urn:un:unece:uncefact:cc:schema:<name>:<major>.<non-zero

integer>.[<revision>] 857

858 859 860

861 862 863

Just like major version numbers, minor version numbers should be based on logical progressions to ensure semantic understanding of the approach and guarantee consistency in representation. Non-negative, sequentially assigned incremental integers satisfy this requirement.

Minor version changes are not allowed to break compatibility with previous minor versions. Compatibility includes consistency in naming of the schema constructs. UN/CEFACT minor version changes will not include renaming the XML construct.

[R 48] For UN/CEFACT minor version changes, the name of the schema construct MUST NOT 864 change. 865

866 Semantic compatibility across minor versions is essential.

[R 49] Changes in minor versions MUST NOT break semantic compatibility with prior versions. 867

868 869 870 871 872

For a particular namespace, the parent major version and subsequent minor versions of a major version establish a linearly linked relationship. Since each minor version is assigned its own namespace, for conformance purposes, the fist minor version must incorporate all XML constructs present in the parent major version, and each new minor version needs to incorporate all XML constructs present in the immediately preceding minor version.

[R 50] UN/CEFACT minor version schema MUST incorporate all XML constructs from the 873 immediately preceding major or minor version schema. 874


[Note] 875 There has been much discussion surrounding the issue of namespaces and versioning. 876 ATG solicits input from interested parties on the pro’s and con’s of assigning a unique 877 namespace for each minor version as opposed to assigning a new namespace for only 878 major versions and having all minor versions have the same namespace as its major 879 version. 880


6 General XML Schema Language Conventions 881

882 6.1 Schema Construct [R 51] The xsd:elementFormDefault attribute MUST be declared and its value set to “qualified”. 883

884 885

886 887

[R 52] The xsd:attributeFormDefault attribute MUST be declared and its value set to “unqualified”.

[R 53] The “xsd” prefix MUST be used in all cases when referring to http://www.w3.org/2001/XMLSchema as follows: xmlns:xsd=http://www.w3.org/2001/XMLSchema 888

889 Example 6-1: Element and Attribute Form Default <xsd:schema targetNamespace=" ... see namespace ... 890 xmlns:xsd="http://www.w3.org/2001/XMLSchema" 891

892

893

elementFormDefault="qualified" attributeFormDefault="unqualified">

6.1.1 Constraints on Schema Construction

[R 54] The xsi prefix SHALL be used where appropriate for referencing xsd:schemaLocation and 894 895

896

897

898

899

900

901

902

903

904

xsd:noNamespaceLocation attributes in instance documents.

[R 55] xsd:appInfo MUST NOT be used.

[R 56] xsd:notation MUST NOT be used.

[R 57] xsd:wildcard MUST NOT be used.

[R 58] The xsd:any element MUST NOT be used.

[R 59] The xsd:any attribute MUST NOT be used.

[R 60] Mixed content MUST NOT be used (excluding documentation).

[R 61] xsd:substitutionGroup MUST NOT be used.

[R 62] xsd:ID/IDREF MUST NOT be used.

[R 63] xsd:key/xsd:keyref MUST be used for information association.

[R 64] The absence of a construct or data MUST NOT carry meaning. 905

906

907

908

909 910

6.2 Attribute and Element Declarations

6.2.1 Attributes

6.2.1.1 Usage of Attributes User declared attributes are only used to convey the supplementary components of core component types. However, built-in xsd:attributes will be used as described elsewhere in this document.

[R 65] User declared attributes MUST only be used to convey core component type (CCT) 911 supplementary component information. 912

913 914

The user declared attributes can represent different types of values. Some of the values can be variable information or can be based on code lists or identifier schemes.

[R 66] An attribute of a supplementary component with variable information MUST be based on the 915 appropriate built-in XSD data type. 916


http://www.w3.org/2001/XML

[R 67] An attribute of a supplementary component which represents codes MUST be based on the 917 918

919

xsd:simpleType of the appropriate code list

[R 68] An attribute of a supplementary component which represents identifiers MUST be based on the xsd:simpleType of the appropriate identifier scheme. 920

921

922 923 924 925 926 927

6.2.1.2 Constraints on Attribute Declarations In general, the absence of an element in an XML schema does not have any particular meaning - it may indicate that the information is unknown, or not applicable, or the element may be absent for some other reason. The XML schema specification does however provide a feature, the nillable attribute, whereby an element may be transferred with no content, but still use its attributes and thus carry semantic meaning. In order to respect the principles of the CCTS and to retain semantic clarity the nillability feature of XSD will not be used.

[R 69] The xsd:nillable attribute MUST NOT be used. 928

929

930

931

932

6.2.2 Elements

6.2.2.1 Usage of Elements Elements are declared for document level message assembly, BBIEs, and ASBIEs.

6.2.2.2 Element Declaration

[R 70] All element declarations MUST be local except for a root element that must be declared 933 934 globally.

[R 71] Empty elements MUST NOT be used. 935

936 937 938

The xsd:enumeration element may be used within reusable or internal schema modules if the list of enumerated values is less than 10, are not represented by a token, and are considered by TBG to be static and particular to the business processes.

[R 72] The xsd:type of each leaf element declaration MUST be of the data type of its source 939 940 business information entity (BBIE) or complex type of its source association business

information entity (ASBIE). 941

942 Example 6-2: <xsd:complexType name="AccountType"> 943 <xsd:annotation> 944 ...see annotation... 945 </xsd:annotation> 946 <xsd:sequence> 947 <xsd:element name="ID" type="udt:IdentifierType" 948 minOccurs="0" maxOccurs="unbounded"> 949 <xsd:annotation> 950 ...see annotation... 951 </xsd:annotation> 952 </xsd:element> 953 <xsd:element name="Status" type="ram:StatusType" 954 minOccurs="0" maxOccurs="unbounded"> 955 <xsd:annotation> 956 ...see annotation... 957 </xsd:annotation> 958 </xsd:element> 959 <xsd:element name="Name" type="udt:NameType" 960 minOccurs="0" maxOccurs="unbounded"> 961 <xsd:annotation> 962 ...see annotation... 963 </xsd:annotation> 964 </xsd:element> 965 </xsd:sequence> 966 </xsd:complexType> 967


6.2.2.3 Constraints on Element Declarations 968

[R 73] The xsd:all element MUST NOT be used. 969

970

971

6.3 Type Definitions

6.3.1 Usage of Types

[R 74] All type definitions MUST be named. 972

973 Example 6-3: <xsd:complexType name="AccountType"> 974 <xsd:annotation> 975 ... see annotation ... 976 </xsd:annotation> 977 <xsd:sequence> 978 ... see element declaration ... 979 </xsd:sequence> 980

981 </xsd:complexType>

[R 75] Data type definitions MUST NOT duplicate the functionality of an existing data type 982 definition.. 983

984

985 986

987

6.3.2 Simple Type Definitions Built-in simple types must always be used where they satisfy the business requirements. Where the business requirements cannot be satisfied, user defined complex type definitions will be used.

Example 6-4: Simple Types in Unqualified Data Type Schema Module <xsd:simpleType name="DateTimeType"> 988 <xsd:annotation> 989 … see annotation … 990 </xsd:annotation> 991 <xsd:restriction base="xsd:dateTime"/> 992

993

994

</xsd:simpleType>

Example 6-5: Simple Types in Code Lists Module <xsd:simpleType name="CurrencyCodeContentType"> 995 <xsd:restriction base="xsd:token"> 996 <xsd:enumeration value="ADP"> 997 …see enumeration of code lists … 998 </xsd:enumeration> 999 <xsd:annotation> 1000 … see annotation … 1001 </xsd:annotation> 1002 </xsd:restriction> 1003

1004

1005

1006 1007

1008

</xsd:simpleType>

6.3.3 Complex Type Definitions User defined complex types may be used when built-in simple types do not satisfy the business requirements or when an aggregate business information entity (ABIE) must be defined.

Example 6-6: Complex Type of Object Class “AccountType” <xsd:complexType name="AccountType"> 1009 <xsd:annotation> 1010 ... see annotation ... 1011 </xsd:annotation> 1012 <xsd:sequence> 1013 ... see element declaration ... 1014 </xsd:sequence> 1015 </xsd:complexType> 1016


6.4 Use of XSD Extension and Restriction 1017

1018 1019 1020 1021 1022 1023 1024 1025

1026

The general philosophy is that all UN/CEFACT XSD schema constructs will follow the model defined in Figure 5.1. These schema constructs are based on the concept that the underlying semantic structures of the core components and business information entities are normative forms of standards that developers are not allowed to alter without coordination of appropriate TBG groups (including TBG17 - Harmonization) and ICG. Accordingly, as business requirements dictate, new schema constructs will be created and new types defined and elements declared as appropriate. The concept of derivation through the use of xsd:extension and xsd:restriction will only be used in limited circumstances as described below.

6.4.1 Extension

[R 76] xsd:extension MUST only be used in the cct:CoreComponentType schema module and 1027 1028 the udt:UnqualifiedDataType schema module. When used it MUST only extend a built-

in XSD datatype. 1029

1030

1031 1032 1033 1034

6.4.2 Restriction The CCTS specification employs the concept of semantic restriction in creating specific instantiations of core components. Accordingly, xsd:restriction will be used as appropriate to define types that are derived from the existing types. Where used, the derived types must always be renamed. Simple and complex type restrictions may be used.

[R 77] When xsd:restriction is applied to a xsd:simpleType or xsd:complexType the 1035 derived construct MUST use a different name. 1036

1037 Example 6-7: Restriction of Simple Type <xsd:simpleType name="IndicatorType"> 1038 <xsd:annotation> 1039 ... see annotation ... 1040 </xsd:annotation> 1041 <xsd:restriction base="xsd:boolean"> 1042 <xsd:pattern value="false"/> 1043 <xsd:pattern value="true"/> 1044 </xsd:restriction> 1045 </xsd:simpleType> 1046

1047

1048 1049

6.5 Annotation All UN/CEFACT XSD schema constructs will use xsd:annotation to provide the documentation specified in Section 7 of CCTS.

[R 78] Each UN/CEFACT defined or declared construct MUST use the xsd:annotation element 1050 for required CCTS documentation. 1051

[Note] 1052

In order to conform to this specification, this rule also applies to any construct imported 1053 from other standards bodies. 1054

1055

1056 1057 1058 1059

1060

1061

6.5.1 Documentation The annotation documentation will be used to convey all metadata as specified in the CCTS, i.e., to convey the semantic content carried in the XML construct. The following annotations are required as defined in section 7 in type definitions and element declarations (the representation of each item in XML code is shown in parenthesis):

• Unique Identifier: The unique identifier assigned to the artefact in the library. (UniqueID)

• Category Code: The category to which the artefact belongs. (CategoryCode)


• Dictionary Entry Name: The complete name (not the tag name) of the artefact in the library. (DictionaryEntryName)

1062 1063

1064

1065

1066

1067

1068 1069

1070

1071

1072 1073

1074

1075 1076

1077 1078

1079 1080

1081 1082

1083 1084

1085

1086

1087 1088

1089 1090 1091

1092 1093

1094 1095

1096 1097

1098 1099

1100 1101

1102 1103

1104 1105

• Name: The name of the message assembly. (Name)

• Version: The version of the artefact as assigned by the registry. (VersionID)

• Definition: The semantic meaning of the artefact. (Definition)

• Description: A brief description of the business information exchange. (Description)

• Cardinality: An indication of whether the property represents a not-applicable, optional, mandatory and/or repetitive characteristic of the object. (Cardinality)

• Business Domain: The TBG groups(s) that developed the artefact. (BusinessDomain)

• Object Class Term: The Object Class represented by the artefact. (ObjectClassTermName)

• Object Class Qualifier Term: A term(s) that qualifies the Object Class.. (ObjectClassQualifierTermName)

• Property Term: The Property Term represented by the artefact. (PropertyTermName)

• Property Qualifier Term: A term(s) that qualifies the Property Term. (PropertyQualifierTermName)

• Associated Object Class Term: The Associated Object Class Term represented by the artefact. (AssociatedObjectClassTermName)

• Associated Object Class Qualifier Term: A term(s) that qualifies the Associated Object Class Term. (AssociatedObjectClassQualifierTermName)

• Representation Term: The Representation Term represented by the artefact. (RepresentationTermName)

• Data Type Qualifier Term: A term(s) that qualifies the Data Type Term. (DataTypeQualifierTermName)

• Primitive Type: The primitive data type as assigned to the artefact by CCTS. (PrimitiveType)

• Built In Type: The XSD built-in data type assigned to the artefact. (BuiltInType)

• Business Process Context: A valid value describing the Business Process contexts for which this construct has been designed. Default is “In All Contexts”. (BusinessProcessContext)

• Geopolitical/Region Context: A valid value describing the Geopolitical/Region contexts for which this construct has been designed. Default is “In All Contexts”. (GeopoliticalOrRegionContext)

• Official Constraints Context: A valid value describing the Official Constraints contexts for which this construct has been designed. Default is “None”. (OfficialConstraintContext)

• Product Context: A valid value describing the Product contexts for which this construct has been designed. Default is “In All Contexts”. (ProductContext)

• Industry Context: A valid value describing the Industry contexts for which this construct has been designed. Default is “In All Contexts”. (IndustryContext)

• Business Process Role Context: A valid value describing the Role contexts for which this construct has been designed. Default is “In All Contexts”. (BusinessProcessRoleContext)

• Supporting Role Context: A valid value describing the Supporting Role contexts for which this construct has been designed. Default is “In All Contexts”. (SupportingRoleContext)

• System Capabilities Context: A valid value describing the Systems Capabilities contexts for which this construct has been designed. Default is “In All Contexts”. (SystemCapabilitiesContext)

• Usage Rule: A constraint that describes specific conditions which are applicable to the artefact. (UsageRuleText)


• Business Term: A synonym term under which the artefact is commonly known and used in business. (BusinessTermName)

1106 1107

1108

1109

1110

• Example: A possible value for the artefact. (Example)

Appendix F specifies normative information on the specific annotation required for each of the artefacts.

Example 6-8: Example of annotation <xsd:annotation> 1111 <xsd:documentation xml:lang="en"> 1112 <ccts:UniqueID>UN00000002</ccts:UniqueID> 1113 <ccts:CategoryCode>BBIE</ccts:CategoryCode> 1114 <ccts:DictionaryEntryName>Account. 1115 Identifier</ccts:DictionaryEntryName> 1116 <ccts:Definition>The identification of a specific 1117 account.</ccts:Definition> 1118 <ccts:VersionID>1.0</ccts:VersionID> 1119 <ccts:ObjectClassTermName>Account</ccts:ObjectClassTermName> 1120 <ccts:PropertyTermName>Identifier</ccts:PropertyTermName> 1121 <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> 1122 <ccts:BusinessTermName>Account Number</ccts:BusinessTermName> 1123 </xsd:documentation> 1124

1125

1126 1127 1128

</xsd:annotation>

Each UN/CEFACT construct containing a code should include documentation that will identify the code list(s) that must be minimally supported when the construct is used.


1128

1129

1130

1131

1132

1133

The following table provides a summary view of the annotation data as defined in section 6.

rsm

:Roo

tSch

ema

ABIE

xsd

:com

plex

Type

BBIE

xsd

:ele

men

t

ASBI

E: x

sd:e

lem

ent

cct:C

oreC

ompo

nent

Type

supp

lem

enta

ry c

ompo

nent

udt:U

nqua

lifie

dDat

aTyp

eqd

t:Qua

lifie

dDat

aTyp

e

Unique Identifier UniqueID M M M M M M M MCategory Code CategoryCode M M M M M M M MDictionary Entry Name DictionaryEntryName M M M M M M MName Name MVersion VersionID M M M M M M MDefinition Definition M M M M M M MDescription Description MCardinality Cardinality M MBusiness Domain BusinessDomain M, RObject Class Term ObjectClassTermName M M M M

Object Class Qualifier TermObjectClassQualifierTermName O O O

Property Term PropertyTermName M M M

Property Qualifier Term PropertyQualifierTermName O O

Associated Object Class TermAssociatedObjectClassTermName M

Associated Object Class Qualifier Term

AssociatedObjectClassQualifierTermName O

Representation Term RepresentationTermName M M M M

Data Type Qualifier TermDataTypeQualifierTermName M

Primitive Type PrimitiveType M M M MXSD Built-in data type BuiltInType C M MBusiness Process Context BusinessProcessContext M, R O, R O, R O, R O, R

Geopolitical/Region ContextGeopoliticalOrRegionContext O, R O, R O, R O, R O, R

Official Constraints Context OfficialContraintContext O, R O, R O, R O, R O, RProduct Context ProductContext O, R O, R O, R O, R O, RIndustry Context IndustryContext O, R O, R O, R O, R O, R

Business Process Role ContextBusinessProcessRoleContext O, R O, R O, R O, R O, R

Supporting Role Context SupportingRoleContext O, R O, R O, R O, R O, R

System Capabilities Context SystemCapabilitiesContext O, R O, R O, R O, R O, RUsage Rule UsageRuleText O, R O, R O, R O, R O, R O, R O, RBusiness Term BusinessTermName O, R O, R O, R O, RExample Example O, R O, R O, R O, R O, R O, R O, R

M

Key:

M - mandatory

O - optional

R - repeating

C - conditional


7 XML Schema Modules 1134

1135 1136

1137

1138 1139 1140

1141

1142 1143 1144

1145

This section describes the requirements of the various XML schema modules that will be incorporated within the UN/CEFACT library.

7.1 Root Schema The root schema serves as the container for all other schema content that is required to fulfil a business information exchange. The root schema resides in its own namespace and imports external schema modules as needed. It may also include internal schema modules that reside in its namespace.

7.1.1 Schema Construct Each root schema will be constructed in a standardized format in order to ensure consistency and ease of use. The specific format is shown in the example below and must adhere to the format of the relevant sections as detailed in Appendix B.

Example 7-1: Structure of RootSchema Module <?xml version="1.0" encoding="UTF-8"?> 1146  1147  1148  1149  1159 <xsd:schema 1160 targetNamespace="urn:un:unece:uncefact:data:draft:[MODULENAME]:0.3.6" 1161 ... see namespaces ... 1162 xmlns:xsd="http://www.w3.org/2001/XMLSchema" 1163 elementFormDefault="qualified" attributeFormDefault="unqualified"> 1164  1165  1166  1167 ... see includes ... 1168  1169  1170  1171 ... see imports ... 1172 1173  1174  1175 ... see root element declaraction ... 1176  1177  1178  1179  1180 <xsd:complexType name="[TYPENAME]"> 1181 <xsd:restriction base="xsd:token"> 1182 ... see type definition .... 1183 </xsd:restriction> 1184 </xsd:complexType> 1185 </xsd:schema> 1186

1187

1188 1189

7.1.2 Namespace Scheme All root schemas published by UN/CEFACT will be assigned a unique token by ATG to represent the namespace prefix. This token will be prefixed by ‘rsm’.

[R 79] The root schema module MUST be represented by a unique token. 1190

1191 Example 7-2: Structure of Root Schema Module

xmlns:rsm="urn:un:unece:uncefact:data:draft:UNCEFACTExamplesSchemaModule:0.3.6" 1192

[Note] 1193

Throughout this specification, the token ‘rsm’ is used for the unique root schema token. 1194

1195 7.1.3 Imports and Includes

[R 80] The rsm:RootSchema MUST import the following schema modules: 1196 1197 1198

– ram:ReusableABIE Schema Module – udt:UnqualifiedDataType Schema Module – qdt:QualifiedDataType Schema Module 1199

1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210

The root schema will include all internal schema modules that reside in its namespace. The root schema may import other external schema modules as necessary provided they conform to UN/CEFACT naming and design rules. One root schema (root schema A) may also make use of ABIEs defined as part of another root schema (root schema B) or that root schema’s internal schema module. In other words, reuse type definitions and element declarations defined in another namespace. An example may be that the root schema for an Order Response message (root schema A) makes use of ABIEs defined as part of the schema definition for an Order message (root schema B). If that is the case then such type definitions and element declarations should be imported in to the root schema (root schema A). To achieve this only the root schema (root schema B) in the namespace containing the type definitions and element declarations needed should be imported as this in itself included the subordinate internal schema modules.

Root schema(A)

Internal schema module(A)

Root schema(B)

Internal schema module(B)

Include Include

Import

1211

[R 81] A rsm:RootSchema in one UN/CEFACT namespace that is dependent upon type definitions 1212 1213 1214

1215 1216 1217

1218

or element declaration defined in another namespace MUST import the rsm:RootSchema from that namespace.

[R 82] A rsm:RootSchema in one UN/CEFACT namespace that is dependant upon type definitions or element declarations defined in another namespace MUST NOT import Schema Modules from that namespace other than the rsm:RootSchema.

[R 83] The rsm:RootSchema MUST include any internal schema modules that reside in the root schema namespace. 1219

1220

1221 1222 1223

7.1.4 Root Element Declaration Each UN/CEFACT business message has a single root element that is globally declared in the root schema.. The root element is named according to the business information exchange that it represents and references the message assembly that contains the actual business information.


[R 84] A single global element known as the root element MUST be globally declared in a 1224 1225

1226

rsm:RootSchema.

[R 85] The name of the root element MUST be the name of the Message Assembly with separators and spaces removed. 1227

1228 Example 7-3: Name of Root Element  1229  1230 <xsd:element name="PurchaseOrder" type="rsm:PurchaseOrderType"> 1231 <xsd:annotation> 1232 ... see annotation ... 1233 </xsd:annotation> 1234 </xsd:element> 1235

1236

1237 1238

7.1.5 Type Definitions Root schemas are limited to defining a single xsd:complexType and a declaring a single global element that fully describe the business information exchange.

[R 86] Root schema MUST define a single xsd:complexType that fully describes the business 1239 1240

1241 1242

information exchange.

[R 87] The name of the top-level complex type MUST be the name of the root element with the word “Type” appended.

[R 88] The xsd:complexType of the root element must be the top-level complex type. 1243

1244 Example 7-4: Name of Complex Type Definition  1245  1246 <xsd:element name="PurchaseOrder" type="rsm:PurchaseOrderType"> 1247 <xsd:annotation> 1248 ... see annotation ... 1249 </xsd:annotation> 1250 <xsd:complexType name="PurchaseOrderType"> 1251 <xsd:sequence> 1252 ... 1253 </xsd:sequence> 1254 </xsd:complexType> 1255

1256

1257

</xsd:element>

7.1.6 Annotations

[R 89] For every rsm:RootSchema root element declaration a structured set of annotations MUST 1258 be present in the following pattern: 1259

• UniqueID (mandatory): The identifier that references the Message Assembly instance in a 1260 unique and unambiguous way. 1261

• CategoryCode (mandatory): The category to which the object belongs. In this case the value 1262 will always be RSM. 1263

• Name (mandatory): The name of the Message Assembly 1264

• VersionID (mandatory): An indication of the evolution over time of a Message Assembly. 1265

• Description (mandatory): A brief description of the business information exchange. 1266

• BusinessDomain (mandatory, repetitive): The TBG group(s) that developed this Message 1267 Assembly. 1268

• BusinessProcessContext (mandatory, repetitive): The business process with which this 1269 Message Assembly is associated. 1270

• GeopoliticalorRegionContext (optional, repetitive): The geopolitical/region contexts for this 1271 Message Assembly. 1272

• OfficialConstraintContext (optional, repetitive): The official constraint context for this 1273 Message Assembly. 1274

• ProductContext (optional, repetitive): The product context for this Message Assembly. 1275

• IndustryContext (optional, repetitive): The industry context for this Message Assembly. 1276

• BusinessProcessRoleContext (optional, repetitive): The role context for this Message 1277 Assembly. 1278

• SupportingRoleContext (optional, repetitive): The supporting role context for this Message 1279 Assembly. 1280

• SystemCapabilitiesContext (optional, repetitive): The system capabilities context for this 1281 Message Assembly. 1282

1283

1284 1285 1286 1287

1288

1289 1290 1291

1292

7.2 Internal Schema A UN/CEFACT internal schema module will contain schema constructs representing ABIEs that are specific to a given root schema. Internal schema modules reside in the same namespace as their root schema. These constructs are subject to the same rules as those for reusable ABIEs as provided in sections 7.3.4, 7.3.5, and 7.3.6.

7.2.1 Schema Construct Each internal schema will be constructed in a standardized format in order to ensure consistency and ease of use. Each internal schema format must adhere to the format of the relevant sections as detailed in Appendix B.

7.2.2 Namespace Scheme [R 90] All UN/CEFACT internal schema modules MUST be in the same namespace as their 1293

corresponding rsm:RootSchema. 1294

1295 1296 1297

The UN/CEFACT internal schema modules do not declare a target namespace, but instead reside in the namespace of their parent root schema. All internal schema modules are accessed from the root schema using xsd:include.

[R 91] The internal schema module MUST be represented by the same token as its 1298 rsm:RootSchema. 1299

1300

1301 1302

1303

1304 1305 1306

1307

1308 1309 1310

1311

7.2.3 Imports and Includes The internal schema module may import or include other schema module as necessary to support validation.

7.3 Reusable Aggregate Business Information Entities The UN/CEFACT ABIE schema module is a schema instance that contains all of the reusable ABIEs. This schema module may thus be used (imported into) in conjunction with any of the UN/CEFACT root schema.

7.3.1 Schema Construct The reusable ABIE schema will be constructed in a standardized format in order to ensure consistency and ease of use. The specific format is shown below and must adhere to the format of the relevant sections as detailed in Appendix B.

Example 7-5: Structure of Reusable ABIEs Schema Module <?xml version="1.0" encoding="UTF-8"?> 1312  1313  1314  1315 <!-- 1316

Module of Reusable ABIEs (Aggregate Business Information Entities) 1317 Agency: UN/CEFACT 1318 Version: 0.3 Rev. 6 1319 Last change: 25 June 2004 1320 1321 Copyright (C) UN/CEFACT (2004). All Rights Reserved. 1322 1323 ... see copyright information ... 1324 --> 1325 <xsd:schema 1326 targetNamespace= 1327 ... see namespace declaration ... 1328 xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" 1329 attributeFormDefault="unqualified"> 1330  1331 ... see imports ... 1332  1333  1334 ... see type defintions ... 1335 </xsd:schema> 1336

1337 7.3.2 Namespace Scheme [R 92] The Reusable Aggregate Business Information Entity schema module MUST be represented 1338

by the token “ram”. 1339

1340 Example 7-6: Namespace of Reusable Aggregate Business Information Entity Schema Module "urn:un:unece:uncefact:data:draft:UNCEFACTReusableAggregateBusinessInformationEntitySc1341 hemaModule:0.3.6" 1342

1343 Example 7-7: Schema-Element of Reusable ABIEs Schema Module <xsd:schema 1344 targetNamespace= 1345 "urn:un:unece:uncefact:data:draft:UNCEFACTReusableAggregateBusinessInformationEntitySc1346 hemaModule:0.3.6" 1347 xmlns:ram= 1348 "urn:un:unece:uncefact:data:draft:UNCEFACTReusableAggregateBusinessInformationSchemaMo1349 dule:0.3.6" 1350

1351 7.3.3 Imports and Includes

[R 93] The ram:ReusableAggregateBusinessInformationEntity schema MUST import the 1352 1353 1354

following schema modules: – udt:UnqualifiedDataType Schema Module – qdt:QualifiedDataType Schema Module 1355

1356 Example 7-8: Import of required modules  1357  1358  1359  1360 <xsd:import 1361 namespace= 1362 "urn:un:unece:uncefact:data:draft:UNCEFACTQualifiedDataTypeSchemaModule:0.3.6" 1363 schemaLocation="http://www.unece.org/uncefact/data/ 1364 UNCEFACTQualifiedDataTypeSchemaModule_0.3.6_draft.xsd"/> 1365  1366  1367  1368 <xsd:import 1369 namespace= 1370 "urn:un:unece:uncefact:data:draft:UNCEFACTUnqualifiedDataTypeSchemaModule: 1371 0.3.6" 1372 1373 schemaLocation="http://www.unece.org/uncefact/data/UNCEFACTUnqualifiedDataTypesSchemaM1374 odule_0.3.6_draft.xsd"/> 1375

7.3.4 Type Definitions 1376

[R 94] For every object class (ABIE) identified in the UN/CEFACT syntax-neutral model, a named 1377 1378

1379

xsd:complexType MUST be defined.

[R 95] The name of the ABIE xsd:complexType MUST be the ccts:DictionaryEntryName with the separators removed and with the "Details" suffix replaced with "Type". 1380

1381 1382 1383 1384

For every complex type definition based on an ABIE object class, its xsd:content model will be defined such that it reflects each property of the object class as a local element declaration, with its cardinality and sequencing within the schema XSD content model determined by the details of the source business information entity (ABIE).

[R 96] Every aggregate business information entity (ABIE) xsd:complexType definition 1385 1386 1387

xsd:content model MUST use the xsd:sequence and/or xsd:choice elements with appropriate local element declarations to reflect each property (BBIE or ASBIE) of its class.

[R 97] Recursion of xsd:sequence and/or xsd:choice MUST NOT occur. 1388

1389 1390

1391

No complex type may contain a sequence followed by another sequence or a choice followed by another choice. However, it is permissible to alternate sequence and choice as in example 7.9.

Example 7-9: Sequence within an object class <xsd:complexType name="AccountType" > 1392 <xsd:annotation> 1393 ...see annotation... 1394 </xsd:annotation> 1395 <xsd:sequence> 1396 <xsd:element name="ID" type="udt:IdentifierType" 1397 minOccurs="0" maxOccurs="unbounded"> 1398 <xsd:annotation> 1399 ...see annotation... 1400 </xsd:annotation> 1401 </xsd:element> 1402 <xsd:element name="Status" type="ram:StatusType" 1403 minOccurs="0" maxOccurs="unbounded"> 1404 <xsd:annotation> 1405 ...see annotation... 1406 </xsd:annotation> 1407 </xsd:element> 1408 <xsd:element name="Name" type="udt:NameType" 1409 minOccurs="0" maxOccurs="unbounded"> 1410 <xsd:annotation> 1411 ...see annotation... 1412 </xsd:annotation> 1413 </xsd:element> 1414 ... 1415 </xsd:sequence> 1416 </xsd:complexType> 1417

1418 Example 7-10: Choice <xsd:complexType name="LocationType"> 1419 <xsd:annotation> 1420 ... see annotation ... 1421 </xsd:annotation> 1422 <xsd:choice> 1423 <xsd:element name="GeoCoordinate" type="ram:GeoCoordinateType" 1424 minOccurs="0"> 1425 <xsd:annotation> 1426 ... see annotation ... 1427 </xsd:annotation> 1428 </xsd:element> 1429 <xsd:element name="Address" type="ram:AddressType" 1430 minOccurs="0"> 1431 <xsd:annotation> 1432 ... see annotation ... 1433 </xsd:annotation> 1434 </xsd:element> 1435 <xsd:element name="Location" type="ram:LocationType" 1436 minOccurs="0"> 1437 <xsd:annotation> 1438


... see annotation ... 1439 </xsd:annotation> 1440 </xsd:element> 1441 </xsd:choice> 1442 </xsd:complexType> 1443

1444 Example 7-11: Sequence + Choice within Object Class "PeriodType" <xsd:complexType name="PeriodType"> 1445 ... 1446 <xsd:sequence> 1447 <xsd:element name="DurationDateTime" 1448 type="qdt:DurationDateTimeType" minOccurs="0" 1449 maxOccurs="unbounded"> 1450 ... 1451 </xsd:element> 1452 ... 1453 <xsd:choice> 1454 <xsd:sequence> 1455 <xsd:element name="StartTime" type="udt:TimeType" 1456 minOccurs="0"> 1457 ... 1458 </xsd:element> 1459 <xsd:element name="EndTime" type="udt:TimeType" 1460 minOccurs="0"> 1461 ... 1462 </xsd:element> 1463 </xsd:sequence> 1464 <xsd:sequence> 1465 <xsd:element name="StartDate" type="udt:DateType" 1466 minOccurs="0"> 1467 ... 1468 </xsd:element> 1469 <xsd:element name="EndDate" type="udt:DateType" 1470 minOccurs="0"> 1471 ... 1472 </xsd:element> 1473 </xsd:sequence> 1474 <xsd:sequence> 1475 <xsd:element name="StartDateTime" type="udt:DateTimeType" 1476 minOccurs="0"> 1477 ... 1478 </xsd:element> 1479 <xsd:element name="EndDateTime" type="udt:DateTimeType" 1480 minOccurs="0"> 1481 ... 1482 </xsd:element> 1483 </xsd:sequence> 1484 </xsd:choice> 1485 </xsd:sequence> 1486 </xsd:complexType> 1487

[R 98] The order and cardinality of the elements within an ABIE xsd:complexType MUST be 1488 according to the structure of the ABIE as defined in the model. 1489

1490 Example 7-12: Type definition of an ABIE  1491  1492 <xsd:complexType name="AccountType" > 1493 <xsd:annotation> 1494 ... see annotation ... 1495 </xsd:annotation> 1496 <xsd:sequence> 1497 <xsd:element name="ID" type="udt:IdentifierType" 1498 minOccurs="0" maxOccurs="unbounded"> 1499 <xsd:annotation> 1500 ... see annotation ... 1501 </xsd:annotation> 1502 </xsd:element> 1503 ... see element declaration .... 1504 </xsd:sequence> 1505 </xsd:complexType> 1506

7.3.5 Element Declarations 1507

[R 99] For every attribute of an object class (BBIE) identified in an ABIE, a named xsd:element 1508 1509

1510 1511 1512 1513

1514

1515 1516 1517

1518 1519 1520

1521 1522 1523 1524

1525

MUST be locally declared within the xsd:complexType representing that ABIE.

[R 100] Each BBIE element name declaration MUST be based on the property term and qualifiers and the representation term of the basic business information entity (BBIE). If there are successive duplicate words in the property term and representation terms of the source dictionary entry name, then the duplicate words MUST be removed.

[R 101] If the representation term of a BBIE is ‘text’, it MUST be removed.

[R 102] The BBIE element MUST be based on an appropriate data type that is defined in the UN/CEFACT qdt:QualifiedDataType or udt:UnqualifiedDataType schema modules.

[R 103] For every association (ASBIE) identified in the UN/CEFACT syntax-neutral model, a named xsd:element MUST be locally declared within the xsd:complexType representing the ABIE.

[R 104] Each ASBIE element name declaration MUST be based on the property term and object class of the association business information entity (ASBIE). If there are successive duplicate words in the property term and object class of the associated ABIE, then the duplicate words MUST be removed.

[R 105] The element representing an association business information entity (ASBIE) MUST be of the complex type corresponding to its associated aggregate business information (ABIE). 1526

1527 Example 7-13: Element declaration within an ABIE ... see type defintion ... 1528 <xsd:element name="ID" type="udt:IdentifierType" 1529 minOccurs="0" maxOccurs="unbounded"> 1530 <xsd:annotation> 1531 ... see annotation ... 1532 </xsd:annotation> 1533 </xsd:element> 1534 <xsd:element name="Status" type="ram:StatusType" 1535 minOccurs="0" maxOccurs="unbounded"> 1536 <xsd:annotation> 1537 ... see annotation ... 1538 </xsd:annotation> 1539 </xsd:element> 1540 <xsd:element name="Name" type="udt:NameType" 1541 minOccurs="0" maxOccurs="unbounded"> 1542 <xsd:annotation> 1543 ... see annotation ... 1544 </xsd:annotation> 1545 </xsd:element> 1546 <xsd:element name="CurrencyCode" type="qdt:CurrencyCodeType" 1547 minOccurs="0" maxOccurs="unbounded"> 1548 <xsd:annotation> 1549 ... see annotation ... 1550 </xsd:annotation> 1551 </xsd:element> 1552 ... see type definition ... 1553

1554 7.4 Annotation [R 106] For every ABIE xsd:complexType definition a structured set of annotations MUST be 1555

present in the following pattern: 1556

• UniqueID (mandatory): The identifier that references an ABIE instance in a unique and 1557 unambiguous way. 1558

• CategoryCode (mandatory): The category to which the object belongs. In this case the value 1559 will always be ABIE. 1560


• DictionaryEntryName (mandatory): The official name of an ABIE. 1561

• VersionID (mandatory): An indication of the evolution over time of an ABIE instance. 1562

• Definition (mandatory): The semantic meaning of an ABIE. 1563

• ObjectClassTermName (mandatory): The Object Class Term of the ABIE. 1564

• QualifierTermName (optional): Qualifies the Object Class Term of the ABIE. 1565

• UsageRule (optional, repetitive): A constraint that describes specific conditions that are 1566 applicable to the ABIE. 1567

• BusinessTermName (optional, repetitive): A synonym term under which the ABIE is 1568 commonly known and used in the business. 1569

• BusinessProcessContext (optional, repetitive): The business process with which this ABIE is 1570 associated. 1571

• GeopoliticalorRegionContext (optional, repetitive): The geopolitical/region contexts for this 1572 ABIE. 1573

• OfficialConstraintContext (optional, repetitive): The official constraint context for this ABIE. 1574

• ProductContext (optional, repetitive): The product context for this ABIE. 1575

• IndustryContext (optional, repetitive): The industry context for this ABIE. 1576

• BusinessProcessRoleContext (optional, repetitive): The role context for this ABIE. 1577

• SupportingRoleContext (optional, repetitive): The supporting role context for this ABIE. 1578

• SystemCapabilitiesContext (optional, repetitive): The system capabilities context for this 1579 ABIE. 1580

• Example (optional, repetitive): Example of a possible value of an ABIE. 1581

1582 Example 7-14: Annotation of an ABIE <xsd:complexType name="AccountType" > 1583 <xsd:annotation> 1584 <xsd:documentation xml:lang="en"> 1585 <ccts:UniqueID>UN00000001</ccts:UniqueID> 1586 <ccts:CategoryCode>ABIE</ccts:CategoryCode> 1587 <ccts:DictionaryEntryName>Account. 1588 Details</ccts:DictionaryEntryName> 1589 <ccts:VersionID>1.0</ccts:VersionID> 1590 <ccts:Definition> A business arrangement whereby debits and/or 1591 credits arising from transactions are recorded. This could be with a bank, 1592 i.e. a financial account, or a trading partner offering supplies or services 1593 'on account', i.e. a commercial account</ccts:Definition> 1594 <ccts:ObjectClassTermName>Account</ccts:ObjectClassTermName> 1595 </xsd:documentation> 1596 </xsd:annotation> 1597 ... 1598


[R 107] For every BBIE xsd:element declaration a structured set of annotations MUST be present 1600 in the following pattern: 1601

• UniqueID (mandatory): The identifier that references a BBIE instance in a unique and 1602 unambiguous way. 1603

• CategoryCode (mandatory): The category to which the object belongs. In this case the value 1604 will always be BBIE. 1605

• Dictionary Entry Name (mandatory): The official name of the BBIE. 1606

• VersionID (mandatory): An indication of the evolution over time of a BBIE instance. 1607

• Definition (mandatory): The semantic meaning of the BBIE. 1608


• Cardinality (mandatory): Indication whether the BIE Property represents a not-applicable, 1609 optional, mandatory and/or repetitive characteristic of the ABIE. 1610

• ObjectClassTermName (mandatory): The Object Class Term of the parent ABIE. 1611

• ObjectClassQualifierTermName (optional): Qualifies the Object Class Term of the parent 1612 ABIE. 1613

• PropertyTermName (mandatory): The Property Term of the BBIE. 1614

• PropertyQualifierTermName (optional): Qualifies the Property Term of the BBIE. 1615

• RepresentationTermName (mandatory): The Representation Term of the BBIE. 1616

• UsageRule (optional, repetitive): A constraint that describes specific conditions that are 1617 applicable to the BBIE. 1618

• BusinessProcessContext (optional, repetitive): The business process with which this BBIE is 1619 associated. 1620

• GeopoliticalorRegionContext (optional, repetitive): The geopolitical/region contexts for this 1621 BBIE. 1622

• OfficialConstraintContext (optional, repetitive): The official constraint context for this BBIE. 1623

• ProductContext (optional, repetitive): The product context for this BBIE. 1624

• IndustryContext (optional, repetitive): The industry context for this BBIE. 1625

• BusinessProcessRoleContext (optional, repetitive): The role context for this BBIE. 1626

• SupportingRoleContext (optional, repetitive): The supporting role context for this BBIE. 1627

• SystemCapabilitiesContext (optional, repetitive): The system capabilities context for this 1628 BBIE. 1629

• UsageRule (optional, repetitive): A constraint that describes specific conditions that are 1630 applicable to this BBIE. 1631

• BusinessTermName (optional, repetitive): A synonym term under which the BBIE is 1632 commonly known and used in the business. 1633

• Example (optional, repetitive): Example of a possible value of a BBIE. 1634

1635 Example 7-15: Annotation of a BBIE <xsd:element name="ID" type="udt:IdentifierType" 1636 minOccurs="0" maxOccurs="unbounded"> 1637 <xsd:annotation> 1638 <xsd:documentation xml:lang="en"> 1639 <ccts:UniqueID>UN00000002</ccts:UniqueID> 1640 <ccts:CategoryCode>BBIE</ccts:CategoryCode> 1641 <ccts:DictionaryEntryName>Account. 1642 Identifier</ccts:DictionaryEntryName> 1643 <ccts:VersionID>1.0</ccts:VersionID> 1644 <ccts:Definition>The identification of a specific account. 1645 </ccts:Definition> 1646 </ccts:Cardinality>0..n</ccts:Cardinality> 1647 <ccts:ObjectClassTermName>Account</ccts:ObjectClassTermName> 1648 <ccts:PropertyTermName>Identifier</ccts:PropertyTermName> 1649 <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> 1650 <ccts:BusinessTermName>Account Number</ccts:BusinessTermName> 1651 </xsd:documentation> 1652 </xsd:annotation> 1653

1654 </xsd:element>

[R 108] For every ASBIE xsd:element declaration a structured set of annotations MUST be present 1655 in the following pattern: 1656

• UniqueID (mandatory): The identifier that references an ASBIE instance in a unique and 1657 unambiguous way. 1658


• CategoryCode (mandatory): The category to which the object belongs. In this case the value 1659 will always be ASBIE. 1660

• DictionaryEntryName (mandatory): The official name of the ASBIE. 1661

• VersionID (mandatory): An indication of the evolution over time of the ASBIE instance. 1662

• Definition (mandatory): The semantic meaning of the ASBIE. 1663

• Cardinality (mandatory): Indication whether the ASBIE Property represents a not-applicable, 1664 optional, mandatory and/or repetitive characteristic of the ABIE. 1665

• ObjectClassTermName (mandatory): The Object Class Term of the associating ABIE. 1666

• ObjectClassQualifierTermName (Optional): A term that qualifies the Object Class Term of the 1667 associating ABIE. 1668

• PropertyTermName (mandatory): The Property Term of the ASBIE. 1669

• PropertyQualifierTermName (Optional): A term that qualifies the Property Term of the ASBIE. 1670

• AssociatedObjectClassTermName (mandatory): The Object Class Term of the associated 1671 ABIE. 1672

• AssociatedObjectClassQualifierTermName (optional): Qualifies the Object Class Term of the 1673 associated ABIE. 1674

• BusinessProcessContext (optional, repetitive): The business process with which this ASBIE 1675 is associated. 1676

• GeopoliticalorRegionContext (optional, repetitive): The geopolitical/region contexts for this 1677 ASBIE. 1678

• OfficialConstraintContext (optional, repetitive): The official constraint context for this ASBIE. 1679

• ProductContext (optional, repetitive): The product context for this ASBIE. 1680

• IndustryContext (optional, repetitive): The industry context for this ASBIE. 1681

• BusinessProcessRoleContext (optional, repetitive): The role context for this ASBIE. 1682

• SupportingRoleContext (optional, repetitive): The supporting role context for this ASBIE. 1683

• SystemCapabilitiesContext (optional, repetitive): The system capabilities context for this 1684 ASBIE. 1685

• UsageRule (optional, repetitive): A constraint that describes specific conditions that are 1686 applicable to the ASBIE. 1687

• BusinessTermName (optional, repetitive): A synonym term under which the ASBIE is 1688 commonly known and used in the business. 1689

• Example (optional, repetitive): Example of a possible value of an ASBIE. 1690

1691 Example 7-16: Annotation of an ASBIE <xsd:element name="Status" type="ram:StatusType" 1692 minOccurs="0" maxOccurs="unbounded"> 1693 <xsd:annotation> 1694 <xsd:documentation xml:lang="en"> 1695 <ccts:UniqueID>UN00000003</ccts:UniqueID> 1696 <ccts:CategoryCode>ASCC</ccts:CategoryCode> 1697 <ccts:DictionaryEntryName>Account. 1698 Status</ccts:DictionaryEntryName> 1699 <ccts:VersionID>1.0</ccts:VersionID> 1700 <ccts:Definition>Associated status information related to 1701 account details.</ccts:Definition> 1702 <ccts:Cardinality>0..n</ccts:Cardinality> 1703 <ccts:ObjectClassTermName>Account</ccts:ObjectClassTermName> 1704 <ccts:PropertyTermName>Status</ccts:PropertyTermName> 1705 <ccts:AssociatedObjectClassTermName>Status 1706 </ccts:AssociatedObjectClassTermName> 1707 </xsd:documentation> 1708


</xsd:annotation> 1709 1710

1711

1712

1713 1714 1715 1716

1717

1718 1719 1720

1721

</xsd:element>

7.5 Core Component Type

7.5.1 Use of Core Component Type Module The purpose of the core component type module is to define the core component types on which the unqualified data types are based. This module is only for reference and will not be included/imported in any schema. The normative formatted schema for the Core Component Type module is contained in Appendix D.

7.5.2 Schema Construct The core component type schema module will be constructed in a standardized format in order to ensure consistency and ease of use. The specific format is shown below and must adhere to the format of the relevant sections as detailed in Appendix B.

Example 7-17: Structure of Core Component Type Schema Module <?xml version="1.0" encoding="utf-8"?> 1722  1723  1724  1725  1736 <xsd:schema 1737 targetNamespace= 1738 ... see namespace ... 1739 xmlns:xsd="http://www.w3.org/2001/XMLSchema" 1740 elementFormDefault="qualified" attributeFormDefault="unqualified"> 1741  1742  1743  1744  1745 ... see type definitions ... 1746

1747

1748

</xsd:schema>

7.5.3 Namespace Scheme

[R 109] The core component type (CCT) schema module MUST be represented by the token "cct". 1749

1750 Example 7-18: Namespace of Core Component Type Schema Module 1751

1752

"urn:un:unece:uncefact:documentation:draft:UNCEFACTCCTSCCTSchemaModule:03.6"

Example 7-19: Namespace of Core Component Type Schema Module <xsd:schema 1753 targetNamespace= 1754 "urn:un:unece:uncefact:documentation:draft:UNCEFACTCCTSCCTSchemaModule:0.3.61755 " 1756 xmlns:cct= 1757 "urn:un:unece:uncefact:documentation:draft:UNCEFACTCCTSCCTSchemaModule:0.3.61758 " 1759 xmlns:xsd="http://www.w3.org/2001/XMLSchema" 1760

1761

1762

1763


7.5.4 Imports and Includes The core component types schema module does not import or include any other schema modules.

[R 110] The cct:CoreCoreComponentType schema module MUST NOT include or import any 1764 other schema modules. 1765

1766 7.5.5 Type Definitions

[R 111] Every cct:CoreComponentType MUST be defined as a named xsd:complexType in the 1767 1768

1769 1770 1771

1772 1773

1774 1775 1776 1777

1778

cct:CoreComponentType schema module.

[R 112] The name of each xsd:complexType based on a cct:CoreComponentType MUST be the dictionary entry name of the core component type (CCT), with the separators and spaces removed.

[R 113] Each cct:CoreComponentType xsd:complexType definition MUST contain one xsd:simpleContent element.

[R 114] The cct:CoreComponentType xsd:complexType definition xsd:simpleContent element MUST contain one xsd:extension element. This xsd:extension element must include an XSD based attribute that defines the specific built-in XSD data type required for the CCT content component.

[R 115] Within the cct:CoreComponentType xsd:extension element a xsd:attribute MUST be declared for each supplementary component pertaining to that cct:CoreComponentType. 1779

1780 Example 7-20: Type definition of a CCT  1781  1782  1783  1784 <xsd:complexType name="AmountType"> 1785 <xsd:annotation> 1786 ... see annotation ... 1787 </xsd:annotation> 1788 <xsd:simpleContent> 1789 <xsd:extension base="xsd:decimal"> 1790 <xsd:attribute name="currencyID" type="xsd:token" use="optional" 1791 <xsd:annotation> 1792 ... see annotation ... 1793 </xsd:annotation> 1794 </xsd:attribute> 1795 ... see attribute declaration ... 1796 </xsd:extension> 1797 </xsd:simpleContent> 1798

1799

1800 1801 1802 1803 1804 1805 1806

</xsd:complexType>

7.5.6 Attribute Declarations The current CCTS does not specify the components of the CCT supplementary component dictionary entry name. However, in order to ensure a standard approach to declaring the supplementary components as attributes, ATG has applied the naming concepts from ISO 11179, part 5. Specifically, ATG has defined the dictionary entry name as it is stated in CCTS in terms of object class, property term, and representation term. These components are identified in the annotation documentation for each supplementary component in the CCT schema module.

[R 116] Each cct:CoreComponentType supplementary component xsd:attribute "name" 1807 1808 1809

1810 1811 1812

1813 1814

MUST be the CCTS supplementary component dictionary entry name with the separators and spaces removed.

[R 117] If the object class of the supplementary component dictionary entry name contains the name of the representation term of the parent CCT, the duplicated object class word or words MUST be removed from the supplementary component xsd:attribute name.

[R 118] If the object class of the supplementary component dictionary entry name contains the term ‘identification’, the term ‘identification’ MUST be removed from the supplementary component xsd:attribute name. 1815

[R 119] If the representation term of the supplementary component dictionary entry name is ‘text’, the 1816 1817 1818

1819

representation term MUST be removed from the supplementary component xsd:attribute name.

[R 120] The attribute representing as supplementary component MUST be based on the appropriate built-in XSD data type. 1820

Example 7-22: Supplementary component other than code or identifier 1821 <xsd:complexType name="BinaryObjectType"> 1822 … 1823 <xsd:simpleContent> 1824 <xsd:extension base="xsd:base64Binary"> 1825 <xsd:attribute name="format" type="xsd:string" use="optional"> 1826 … 1827 </xsd:attribute> 1828 … 1829 </xsd:extension> 1830 </xsd:simpleContent> 1831

1832

1833

1834 1835

1836

</xsd:complexType>

7.5.7 Extension and Restriction The core component type schema module is a generic module that will be restricted in qualified and unqualified data type schema modules.

7.5.8 Annotation

[R 121] For every cct:CoreComponentType xsd:complexType definition a structured set of 1837 annotations MUST be present in the following pattern: 1838

• UniqueID (mandatory): The identifier that references the Core Component Type instance in a 1839 unique and unambiguous way. 1840

• CategoryCode (mandatory): The category to which the object belongs. In this case the value 1841 will always be CCT. 1842

• DictionaryEntryName (mandatory): The official name of a Core Component Type. 1843

• VersionID (mandatory): An indication of the evolution over time of a Core Component Type 1844 instance. 1845

• Definition (mandatory): The semantic meaning of a Core Component Type. 1846

• RepresentationTermName (mandatory): The primary representation term of the Core 1847 Component Type. 1848

• PrimitiveType (mandatory): The primitive data type of the Core Component Type. 1849

• UsageRule (optional, repetitive): A constraint that describes specific conditions that are 1850 applicable to the Core Component Type. 1851

• BusinessTermName (optional, repetitive): A synonym term under which the Core Component 1852 Type is commonly known and used in the business. 1853

• Example (optional, repetitive): Example of a possible value of a Core Component Type. 1854

1855 Example 7-21: Annotation of a CCT ... see type definition ... 1856 <xsd:annotation> 1857 <xsd:documentation xml:lang="en"> 1858 <ccts:UniqueID>UNDT000001</ccts:UniqueID> 1859 <ccts:CategoryCode>CCT</ccts:CategoryCode> 1860 <ccts:DictionaryEntryName>Amount. Type</ccts:DictionaryEntryName> 1861 <ccts:VersionID>1.0</ccts:VersionID> 1862 <ccts:Definition>A number of monetary units specified in a currency 1863 where the unit of the currency is explicit or 1864 implied.</ccts:Definition> 1865 <ccts:RepresentationTermName>Amount</ccts:RepresentationTermName> 1866 <ccts:PrimitiveType>decimal</ccts:PrimitiveType> 1867


</xsd:documentation> 1868 </xsd:annotation> 1869

1870 ... see type definition ...

[R 122] For every supplementary component xsd:attribute declaration a structured set of 1871 annotations MUST be present in the following pattern: 1872

• UniqueID (mandatory): The identifier that references a Supplementary Component instance 1873 in a unique and unambiguous way. 1874

• CategoryCode (mandatory): The category to which the object belongs. In this case the value 1875 will always be SC. 1876

• DictionaryEntryName (mandatory): The official name of the Supplementary Component. 1877

• Definition (mandatory): The semantic meaning of the Supplementary Component. 1878

• ObjectClassTermName (mandatory): The Object Class of the Supplementary Component. 1879

• PropertyTermName (mandatory): The Property Term of the Supplementary Component. 1880

• RepresentationTermName (mandatory): The Representation term of the Supplementary 1881 Component. 1882

• PrimitiveType (mandatory): The primitive data type of the Supplementary Component. 1883

• UsageRule (optional, repetitive): A constraint that describes specific conditions that are 1884 applicable to the Supplementary Core Component. 1885

• Example (optional, repetitive): Example of a possible value of a Basic Core Component. 1886

1887 Example 7-22: Annotation of a supplementary component ... see attribute declaration ... 1888 <xsd:annotation> 1889 <xsd:documentation xml:lang="en"> 1890 <ccts:UniqueID>UNDT000001-SC2</ccts:UniqueID> 1891 <ccts:CategoryCode>SC</ccts:CategoryCode> 1892 <ccts:DictionaryEntryName>Amount. Currency. 1893 Identifier</ccts:DictionaryEntryName> 1894 <ccts:Definition>The currency of the amount.</ccts:Definition> 1895 <ccts:ObjectClassTermName>Amount</ccts:ObjectClassTermName> 1896 <ccts:PropertyTermName>Currency</ccts:PropertyTermName> 1897 <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> 1898 <ccts:PrimitiveType>string</ccts:PrimitiveType> 1899 <ccts:UsageRule>Reference UNECE Rec 9, using 3-letter 1900 alphabetic codes.</ccts:UsageRule> 1901 </xsd:documentation> 1902 </xsd:annotation> 1903

1904

1905

1906

1907 1908 1909 1910

1911

1912 1913 1914

1915

... see attribute declaration ...

7.6 Unqualified Data Type

7.6.1 Use of Unqualified Data Type Module The unqualified data type schema module will define data types for all primary and secondary representation terms as specified in the CCTS. All data types will be defined as xsd:complexType or xsd:simpleType and will only reflect restrictions as specified in CCTS and agreed upon industry best practices.

7.6.2 Schema Construct The unqualified data types schema will be constructed in a standardized format in order to ensure consistency and ease of use. The specific format is shown below and must adhere to the format of the relevant sections as detailed in Appendix B.

Example 7-23: Structure of unqualified data type schema module <?xml version="1.0" encoding="utf-8"?> 1916  1917  1918

1919  1930 <xsd:schema targetNamespace= 1931 ... see namespace ... 1932 xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" 1933 attributeFormDefault="unqualified"> 1934  1935  1936 ... see imports ... 1937  1938  1939  1940  1941  1942 <xsd:complexType name="AmountType"> 1943 ... see type definition ... 1944 </xsd:complexType> 1945 ... 1946

1947

1948

</xsd:schema>

7.6.3 Namespace Scheme [R 123] The Unqualified Data Type schema module namespace MUST be represented by the token 1949

"udt". 1950

1951 Example 7-24: Namespace of unqualified data type schema module "urn:un:unece:uncefact:data:draft:UNCEFACTUnqualifiedDataTypeSchemaModule:0.31952 .6" 1953

1954 Example 7-25: Schema-element of unqualified data type schema module <xsd:schema 1955 targetNamespace= 1956 "urn:un:unece:uncefact:data:draft:UNCEFACTUnqualifiedDataTypeSchemaModule:0.1957 3.6" 1958 xmlns:udt= 1959 "urn:un:unece:uncefact:data:draft:UNCEFACTUnqualifiedDataTypeSchemaModule:0.1960 3.6" 1961 xmlns:xsd="http://www.w3.org/2001/XMLSchema" 1962

1963

1964 1965


7.6.4 Imports and Includes The Unqualified Data Type schema will import the required code list and identifier list schema modules.

[R 124] The udt:UnqualifiedDataType schema MUST NOT import any other schema modules 1966 1967 1968

than the following: – ids:IdentifierList schema modules – clm:CodeList schema modules 1969

1970 Example 7-26: Imports  1971  1972  1973  1974 <xsd:import namespace= 1975 "urn:un:unece:uncefact:codelist:draft:6:3403:D.04A" 1976 schemaLocation="http://www.unece.org/uncefact/codelist/63403_D.04A_draft.xsd1977 "/> 1978  1979  1980

<xsd:import namespace= 1981 "urn:un:unece:uncefact:identifierlist:draft:5:3166-1:1977" 1982 schemaLocation="http://www.unece.org/uncefact/identifierlist/53166-1983 1.1997_standard.xsd"/> 1984

1985

1986 1987 1988

7.6.5 Type Definitions Each unqualified data type is represented in the unqualified data type schema module as either a xsd:complexType or a xsd:simpleType. Unqualified data types are defined based on the core component types as defined in the CCTS.

[R 125] A udt:UnqualifiedDataType MUST be defined for each approved primary and 1989 1990 1991

1992 1993

secondary representation terms identified in the CCTS Permissible Representation Terms table.

[R 126] The name of each udt:UnqualifiedDataType MUST be the dictionary entry name of the primary or secondary representation term, with “Type” at the end and the separators and spaces removed. 1994

1995 1996 1997

In accordance with rules and principles in this document, the unqualified data type will be based on XSD built-in data types whenever the XSD built-in data type meets the functionality of the supplementary components for that data type.

[R 127] For every udt:UnqualifiedDataType whose supplementary components map directly to 1998 1999 2000 2001

2002 2003 2004

the properties of a built-in xsd:dataTtpe, the udt:UnqualifiedDataType MUST be defined as a named xsd:simpleType in the udt:UnqualifiedDataType schema module.

[R 128] Every udt:UnqualifiedDataType defined as a xsd:simpleType MUST contain one xsd:restriction element. This xsd:restriction element MUST include an xsd:base attribute that defines the specific built-in XSD data type required for the content component. 2005

2006 2007

When the unqualified data type does not directly map to an xsd:simpleType due to the supplementary components needing to be expressed, it will be defined as an xsd:complexType.

[R 129] For every udt:UnqualfiedDataType whose supplementary components are not 2008 2009 2010 2011

2012 2013

2014 2015 2016

equivalent to the properties of a built-in XSD data type, a udt:UnqualifiedDataType MUST be defined as an xsd:complexType in the udt:UnqualifiedDataType schema module.

[R 130] Every udt:UnqualifiedDataType xsd:complexType definition MUST contain one xsd:simpleContent element.

[R 131] Every udt:UnqualifiedDataType xsd:complexType xsd:simpleContent element MUST contain one xsd:extension element. This xsd:extension element must include an xsd:base attribute that defines the specific built-in XSD datatype required for the content component. 2017

2018

2019 2020 2021 2022 2023

7.6.6 Attribute Declarations Each core component supplementary component will normally be declared as an attribute of the complex type. However, the namespace scheme for code lists and identification scheme lists has been designed to include some of the supplementary components for the CCTs Code. Type and Identifier. Type. Thus, those attributes that are included in the namespace will not be declared as part of the unqualified data type.

[R 132] Within the udt:UnqualifiedDataType xsd:complextype xsd:extension element 2024 2025 an xsd:attribute MUST be declared for each supplementary component pertaining to the

underlying CCT, unless the attribute is contained in the namespace declaration. 2026


2027 2028

2029

2030

2031 2032

2033 2034 2035

The attributes representing supplementary components will be named based on their underlying CCT supplementary component. The user declared attributes can be based on:

• XSD built-in types, if a specific supplementary component represents a variable value

• simpleTypes of a code list, if the specific supplementary component represents a code value

• simpleTypes of an identifier scheme, if the specific supplementary component represents an identifier value.

For some CCTs, the CCTS identifies restrictions in the form of pointing to certain restrictive code or identifier lists. These restrictive lists will be declared in the code list or identifier schema module and the unqualified data type will reference these.

[R 133] Each supplementary component xsd:attribute name MUST be the supplementary 2036 2037

2038 2039 2040

2041 2042 2043

2044 2045

component name with the separators and spaces removed.


[R 135] If the object class of the supplementary component dictionary entry name contains the term ‘identification’, the term ‘identification’ MUST be removed from the supplementary component xsd:attribute name.

[R 136] If the representation term of the supplementary component dictionary entry name is ‘text’, the representation term MUST be removed from the supplementary component xsd:attribute name. 2046

2047 Example 7-27: Type definitions of unqualified data types  2048  2049  2050  2051 <xsd:complexType name="AmountType"> 2052 <xsd:annotation> 2053 ... see annotation ... 2054 </xsd:annotation> 2055 <xsd:simpleContent> 2056 <xsd:extension base="xsd:decimal"> 2057 <xsd:attribute name="currencyID" 2058 type="clm54217:CurrencyCodeContentType" use="required"> 2059 <xsd:annotation> 2060 ... see annotation ... 2061 </xsd:annotation> 2062 </xsd:attribute> 2063 <xsd:attribute name="currencyCodeListVersionID" 2064 type="xsd:normalizedString" use="optional"> 2065 <xsd:annotation> 2066 ... see annotation ... 2067 </xsd:annotation> 2068 </xsd:attribute> 2069 </xsd:extension> 2070 </xsd:simpleContent> 2071 </xsd:complexType> 2072  2073  2074 <xsd:complexType name="BinaryObjectType"> 2075 <xsd:annotation> 2076 ... see annotation ... 2077 </xsd:annotation> 2078 <xsd:simpleContent> 2079 <xsd:extension base="xsd:base64Binary"> 2080 <xsd:attribute name="mimeCode" 2081 2082 type="clmIANAMIMEMediaTypes:BinaryObjectMimeCodeContentType"> 2083 <xsd:annotation> 2084 ... see annotation ... 2085 </xsd:annotation> 2086

</xsd:attribute> 2087 <xsd:attribute name="encodingCode" type="xsd:normalizedString" 2088 use="optional"> 2089 <xsd:annotation> 2090 ... see annotation ... 2091 </xsd:annotation> 2092 </xsd:attribute> 2093 <xsd:attribute name="characterSetCode" type="xsd:normalizedString" 2094 use="optional"> 2095 <xsd:annotation> 2096 ... see annotation ... 2097 </xsd:annotation> 2098 </xsd:attribute> 2099 <xsd:attribute name="uri" type="xsd:anyURI" use="optional"> 2100 <xsd:annotation> 2101 ... see annotation ... 2102 </xsd:annotation> 2103 </xsd:attribute> 2104 <xsd:attribute name="filename" type="xsd:string" use="optional"> 2105 <xsd:annotation> 2106 ... see annotation ... 2107 </xsd:annotation> 2108 </xsd:attribute> 2109 </xsd:extension> 2110 </xsd:simpleContent> 2111

2112

2113 2114 2115

</xsd:complexType>

The user declared attributes are dependent on the type of representation term of the specific supplementary component. See Appendix G for the mapping of the representation terms to the user defined attributes.

[R 137] If the representation term of the relevant supplementary component is a “Code” and 2116 2117 validation is required, then the attribute representing this supplementary component MUST

be based on the defined xsd:simpleType of the appropriate external imported code list. 2118

2119 Example 7-28: Supplementary Component is a Code <xsd:complexType name="MeasureType"> 2120 … 2121 <xsd:simpleContent> 2122 <xsd:extension base="xsd:decimal"> 2123 <xsd:attribute name="unitCode" 2124 type="clm620:MeasureUnitCodeContent" use="optional"> 2125 … 2126 </xsd:attribute> 2127 … 2128 </xsd:extension> 2129 </xsd:simpleContent> 2130


[R 138] If the representation term of the relevant supplementary component is an “Identifier” and 2132 2133 2134

validation is required, then the attribute representing this supplementary component MUST be based on the defined xsd:simpleType of the appropriate external imported identifier scheme. 2135

2136 Example 7-29: Supplementary component is an identifier <xsd:complexType name="AmountType"> 2137 <xsd:annotation> 2138 ... 2139 </xsd:annotation> 2140 <xsd:simpleContent> 2141 <xsd:extension base="xsd:decimal"> 2142 <xsd:attribute name="currencyID" 2143 type="clm54217:CurrencyIdentifierContentType" 2144 use="required"> 2145 ... 2146 </xsd:attribute> 2147 </xsd:extension> 2148 </xsd:simpleContent> 2149 </xsd:complexType> 2150


[R 139] If the representation term of the supplementary component is not “Code” or “Identifier”, then 2151 2152 the attribute representing this supplementary component MUST be based on the appropriate

built-in XSD data type. 2153

2154 Example 7-30: Supplementary component other than code or identifier <xsd:complexType name="BinaryObjectType"> 2155 … 2156 <xsd:simpleContent> 2157 <xsd:extension base="xsd:base64Binary"> 2158 <xsd:attribute name="format" type="xsd:string" use="optional"> 2159 … 2160 </xsd:attribute> 2161 … 2162 </xsd:extension> 2163 </xsd:simpleContent> 2164

2165

2166

2167

2168

</xsd:complexType>

7.6.7 Restriction The unqualified data types can be further restricted in the qualified data type module.

7.6.8 Annotation

[R 140] For every udt:UnqualifiedDataType xsd:complexType or xsd:simpleType 2169 definition a structured set of annotations MUST be present in the following pattern: 2170

• UniqueID (mandatory): The identifier that references an Unqualified Data Type instance in a 2171 unique and unambiguous way. 2172

• CategoryCode (mandatory): The category to which the object belongs. In this case the value 2173 will always be UDT. 2174

• DictionaryEntryName (mandatory): The official name of the Unqualified Data Type. 2175

• VersionID (mandatory): An indication of the evolution over time of the Unqualified Data Type 2176 instance. 2177

• Definition (mandatory): The semantic meaning of the Unqualified Data Type. 2178

• RepresentationTermName (mandatory): The primary or secondary representation term of 2179 the associated Core Component Type. 2180

• PrimitiveType (mandatory): The primitive data type of the Unqualified Data Type. 2181

• BuiltInType (mandatory): The XSD built-in data type of the Unqualified Data Type. 2182

• UsageRule (optional, repetitive): A constraint that describes specific conditions that are 2183 applicable to the Unqualified Data Type. 2184

• Example (optional, repetitive): Example of a possible value of an Unqualified Data Type. 2185

2186 Example 7-31: Annotation of unqualified type definition .. see complex type definition ... 2187 <xsd:annotation> 2188 <xsd:documentation xml:lang="en"> 2189 <ccts:UniqueID>UNDT000001</ccts:UniqueID> 2190 <ccts:CategoryCode>UDT</ccts:CategoryCode> 2191 <ccts:DictionaryEntryName>Amount. Type</ccts:DictionaryEntryName> 2192 <ccts:VersionID>1.0</ccts:VersionID> 2193 <ccts:Definition> A number of monetary units specified in a 2194 currency where the unit of the currency is explicit or 2195 implied.</ccts:Definition> 2196 <ccts:RepresentationTermName>Amount</ccts:RepresentationTermName> 2197 <ccts:PrimitiveType>decimal</ccts:PrimitiveType> 2198 <ccts:BuiltInType>decimal</ccts:BuiltIn 2199 Type> 2200 </xsd:documentation> 2201 </xsd:annotation> 2202 ... see complex type definition ... 2203



• UniqueID (mandatory): The identifier that references a Supplementary Component instance 2206 in a unique and unambiguous way. 2207

• CategoryCode (mandatory): The category to which the object belongs. In this case the value 2208 will always be SC. 2209

• Dictionary Entry Name (mandatory): The official name of the Supplementary Component. 2210

• Definition (mandatory): The semantic meaning of the Supplementary Component. 2211

• ObjectClassTermName (mandatory): The Object Class of the Supplementary Component. 2212

• PropertyTermName (mandatory): The Property Term of the Supplementary Component. 2213

• RepresentationTermName (mandatory): The Representation term of the Supplementary 2214 Component. 2215

• UsageRule (optional, repetitive): A constraint that describes specific conditions that are 2216 applicable to the Supplementary Core Component. 2217

• Example (optional, repetitive): Example of a possible value of a Basic Core Component. 2218

2219 Example 7-32: Annotation of a supplementary component ... see complex type definition ... 2220 <xsd:attribute name="currencyID" type="iso4217:CurrencyCodeContentType" 2221 use="required"> 2222 <xsd:annotation> 2223 <xsd:documentation xml:lang="en"> 2224 <ccts:UniqueID>UNDT000001-SC2</ccts:UniqueID> 2225 <ccts:CategoryCode>SC</ccts:CategoryCode> 2226 <ccts:DictionaryEntryName>Amount. Currency. Identifier 2227 </ccts:DictionaryEntryName> 2228 <ccts:Definition>The currency of the amount.</ccts:Definition> 2229 </ccts:ObjectClassTermName>Amount</ccts:ObjectClassTermName> 2230 <ccts:PropertyTermName>Currency</ccts:PropertyTermName> 2231 <ccts:RepresentationTermName>Identifier</ccts:Representation 2232 TermName> 2233 <ccts:PrimitiveType>decimal</ccts:PrimitiveType> 2234 <ccts:BuiltInType>decimal</ccts:BuiltInType> 2235 <ccts:UsageRule>ReferenceUNECE Rec 9, using 3-letter alphabetic 2236 codes.</ccts:UsageRule> 2237 </xsd:documentation> 2238 </xsd:annotation> 2239 </xsd:attribute> 2240

2241

2242

2243 2244 2245 2246

2247

2248 2249 2250 2251 2252 2253 2254 2255

... see complex type definition ...

7.7 Qualified Data Type Ensuring consistency of qualified data types with the UN/CEFACT modularity and reuse goals requires creating a single schema module that defines all qualified data types. The qualified data type schema module name must follow the UN/CEFACT module naming approach. The qualified data type schema module will be used by the reusable ABIE schema module and all root schema modules.

7.7.1 Use of Qualified Data Type Module The data types defined in the unqualified data type schema module are of type xsd:complexType or xsd:simpleType. These types are intended to be suitable as the xsd:base type for some, but not all BBIEs represented as xsd:elements. As business process modelling reveals the need for specialized data types, new ‘qualified’ types will need to be defined. These new qualified data types must be based on an unqualified data type and must represent a semantic or technical restriction of the unqualified data type. Technical restrictions must be implemented as a xsd:restriction or a new xsd:simpleType if the supplementary components of the qualified data type map directly to the properties of a built-in XSD data type.


7.7.2 Schema Construct 2256

2257 2258 2259

2260

The qualified data type schema will be constructed in a standardized format in order to ensure consistency and ease of use. The specific format is shown below and must adhere to the format of the relevant sections as detailed in Appendix B.

Example 7-33: Structure of qualified data type schema module <?xml version="1.0" encoding="utf-8"?> 2261  2262  2263  2264  2276 <xsd:schema targetNamespace= 2277 ... see namespace ... 2278 xmlns:xsd="http://www.w3.org/2001/XMLSchema" 2279 elementFormDefault="qualified" attributeFormDefault="unqualified"> 2280  2281  2282 ... see imports ... 2283  2284  2285 ... see type definitions ... 2286

2287

2288

</xsd:schema>

7.7.3 Namespace Scheme [R 142] The UN/CEFACT:QualifiedDataType schema module namespace MUST be represented by 2289

the token “qdt”. 2290

2291 Example 7-34: Namespace name "urn:un:unece:uncefact:data:draft:UNCEFACTQualifiedDataTypeSchemaModule:0.3.62292 " 2293

2294 Example 7-35: Schema element <xsd:schema targetNamespace="urn:un:unece:uncefact:data:draft: 2295 UNCEFACTQualifiedDataTypeSchemaModule:0.3.6" 2296 xmlns:udt="urn:un:unece:uncefact:data:draft: 2297 UNCEFACTUnqualifiedDataTypeSchemaModule:0.3.6" 2298 xmlns:qdt="urn:un:unece:uncefact:data:draft: 2299 UNCEFACTQualifiedDataTypeSchemaModule:0.3.6" 2300 xmlns:xsd="http://www.w3.org/2001/XMLSchema" 2301

2302

2303

2304 2305


7.7.4 Imports and Includes Qualified data types will be derived from data types defined in the unqualified data types, code list, and identifier list schema modules.

[R 143] The qdt:QualifiedDataType schema module MUST import the 2306 udt:UnqualifiedDataType schema module 2307

[Note] 2308

If needed, relevant UN/CEFACT and external code list and identifier scheme schema 2309 modules not imported by the udt:UnqualifiedDataType schema module may be 2310 imported. 2311

7.7.5 Type Definitions 2312

[R 144] Where required to change facets of an existing udt:UnqualifiedDataType, a new data 2313 2314

2315 2316

2317 2318 2319

2320 2321 2322 2323 2324 2325 2326

2327 2328 2329 2330 2331 2332 2333

2334 2335 2336

type MUST be defined in the qdt:QualifiedDataType schema module.

[R 145] A qdt:QualifiedDataType MUST be based on an unqualified data type and add some semantic and/or technical restriction to the unqualified data type

[R 146] The name of a qdt:QualifiedDataType MUST be the name of its base udt:UnqualifiedDataType with separators and spaces removed and with its qualifier term added.

[R 147] Every qdt:QualifiedDataType based on a udt:UnqualifiedDataType xsd:complexType whose supplementary components map directly to the properties of a built-in xsd:data type MUST be defined as a xsd:simpleType MUST contain one xsd:restriction element MUST include a xsd:base attribute that defines the specific built-in XSD data type required for the content component.

[R 148] Every qdt:QualifiedDataType based on a udt:UnqualifiedDataType xsd:complexType whose supplementary components do not map directly to the properties of a built-in xsd:data type MUST be defined as a xsd:complexType MUST contain one xsd:simpleContent element MUST contain one xsd:extension element MUST include the udt:UnqualifiedDataType as its xsd:base attribute

[R 149] Every qdt:QualifiedDataType based on a udt:UnqualifiedDataType xsd:simpleType MUST contain one xsd:restriction element MUST include the udt:UnqualifiedDataType as its xsd:base attribute 2337

[Note] 2338

If a non-standard variation of the standard date time built-in data types are required, for 2339 example year month, then a qualified data type of textType needs to be defined, with the 2340 appropriate restriction specified, e.g. as a pattern, to specify the required format. 2341

2342 Example 7-36: Type Definitions  2343  2344  2345  2346  2347  2348 <xsd:simpleType name="DayDateType"> 2349 <xsd:annotation> 2350 ... see annotation ... 2351 </xsd:annotation> 2352 <xsd:restriction base="xsd:gDay"/> 2353 </xsd:simpleType> 2354 ... 2355  2356  2357  2358  2359 <xsd:complexType name="DescriptionTextType"> 2360 <xsd:annotation> 2361 ... see annotation ... 2362 </xsd:annotation> 2363 <xsd:simpleContent> 2364 <xsd:restriction base="udt:TextType"/> 2365 </xsd:simpleContent> 2366 </xsd:complexType> 2367

... 2368  2369  2370  2371  2372 <xsd:simpleType name="UniformResouceIdentifierType"> 2373 <xsd:annotation> 2374 ... see annotation ... 2375 </xsd:annotation> 2376 <xsd:restriction base="xsd:anyURI"/> 2377 </xsd:simpleType> 2378 ... 2379  2380  2381 <xsd:simpleType name="CountryIdentifierType"> 2382 <xsd:annotation> 2383 ... see annotation ... 2384 </xsd:annotation> 2385 <xsd:restriction base="ids53166:CountryCodeContentType"/> 2386 </xsd:simpleType> 2387

2388

2389

2390 2391 2392

2393

...

7.7.6 Attribute and Element Declarations There will be no element declarations in the qualified data type schema module. Attribute names will appear in the qualified data type as defined in the unqualified data type schema module with further restrictions applied as required.

7.7.7 Extension and Restriction

[R 150] The qdt:QualifiedDataType xsd:complexType definition xsd:simpleContent 2394 2395 element MUST only restrict attributes declared in its base type, or MUST only restrict facets

equivalent to allowed supplementary components. 2396

2397 Example 7-37: Qualified Data Type Restricting an Identification Scheme <xsd:complexType name="PartyIdentifierType"> 2398 <xsd:annotation> 2399 ... see annotation ... 2400 </xsd:annotation> 2401 <xsd:simpleContent> 2402 <xsd:restriction base="udt:IdentifierType"> 2403 <xsd:attribute name="schemeName" use="prohibited"/> 2404 <xsd:attribute name="schemeAgencyName" use="prohibited"/> 2405 <xsd:attribute name="schemeVersionID" use="prohibited"/> 2406 <xsd:attribute name="schemeDataURI" use="prohibited"/> 2407 </xsd:restriction> 2408 </xsd:simpleContent> 2409

2410

2411

</xsd:complexType>

7.7.8 Annotation

[R 151] Every qdt:QualifiedDataType definition MUST contain a structured set of annotations in 2412 the following sequence and pattern: 2413

• UniqueID (mandatory): The identifier that references a Qualified Data Type instance in a 2414 unique and unambiguous way. 2415

• CategoryCode (mandatory): The category to which the object belongs. In this case the value 2416 will always be QDT. 2417

• DictionaryEntryName (mandatory): The official name of the Qualified Data Type. 2418

• VersionID (mandatory): An indication of the evolution over time of the Qualified Data Type 2419 instance. 2420

• Definition (mandatory): The semantic meaning of the Qualified Data Type. 2421

• RepresentationTermName (mandatory): The Representation Term of the Qualified Data 2422 Type. 2423

• PrimitiveType (mandatory): The primitive data type of the Qualified Data Type. 2424

• BuiltInType (mandatory): The XSD built-in data type of the Qualified Data Type. 2425

• Data Type Qualifier Term (mandatory): A term that qualifies the Representation Term in 2426 order to differentiate it from its underlying Unqualified Data Type and other Qualified Data 2427 Types. 2428

• BusinessProcessContext (optional, repetitive): The business process context for this 2429 Qualified Data Type is associated. 2430

• GeopoliticalorRegionContext (optional, repetitive): The geopolitical/region contexts for this 2431 Qualified Data Type. 2432

• OfficialConstraintContext (optional, repetitive): The official constraint context for this 2433 Qualified Data Type. 2434

• ProductContext (optional, repetitive): The product context for this Qualified Data Type. 2435

• IndustryContext (optional, repetitive): The industry context for this Qualified Data Type. 2436

• BusinessProcessRoleContext (optional, repetitive): The role context for this Qualified Data 2437 Type. 2438

• SupportingRoleContext (optional, repetitive): The supporting role context for this Qualified 2439 Data Type. 2440

• SystemCapabilitiesContext (optional, repetitive): The system capabilities context for this 2441 Qualified Data Type. 2442

• UsageRule (optional, repetitive): A constraint that describes specific conditions that are 2443 applicable to the Qualified Data Type. 2444

• Example (optional, repetitive): Example of a possible value of a Qualified Data Type. 2445

2446 Example 7-38: Annotation of qualified data types ... see type definition ... 2447 <xsd:annotation> 2448 <xsd:documentation xml:lang="en"> 2449 <ccts:UniqueID/> 2450 <ccts:CategoryCode>QDT</ccts:CategoryCode> 2451 <ccts:DictionaryEntryName>Account_ Type_ Code. 2452 Type</ccts:DictionaryEntryName> 2453 <ccts:VersionID>1.0</ccts:VersionID> 2454 <ccts:Definition>This code represents the type of an account. 2455 </ccts:Definition> 2456 <ccts:RepresentationTermName>Code</ccts:RepresentationTermName> 2457 <ccts:RepresentationTermQualifier>Account</ccts: 2458 RepresentationTermQualifier> 2459 <ccts:RepresentationTermQualifier>Type</ccts: 2460 RepresentationTermQualifier> 2461 <ccts:PrimitiveType>string</ccts:PrimitiveType> 2462 <ccts:BuiltInType>normalizedString</ccts:BuiltInType> 2463 </xsd:documentation> 2464 </xsd:annotation> 2465

2466 ... see type definition ...


• UniqueID (mandatory): The identifier that references a Supplementary Component of a Core 2469 Component Type instance in a unique and unambiguous way. 2470

• CategoryCode (mandatory): The category to which the object belongs. In this case the value 2471 will always be QDT. 2472

• Dictionary Entry Name (mandatory): The official name of a Supplementary Component. 2473


• VersionID (mandatory): An indication of the evolution over time of a Supplementary 2474 Component instance. 2475

• Definition (mandatory): The semantic meaning of a Supplementary Component. 2476

• Cardinality (mandatory): Indication whether the Supplementary Component Property 2477 represents a not-applicable, optional, mandatory and/or repetitive characteristic of the Core 2478 Component Type. 2479

• PropertyTermName (optional): The Property Term of the associated Supplementary 2480 Component. 2481

• RepresentationTermName (optional): The Representation Term of the associated 2482 Suppplementary Component. 2483

• UsageRule (optional, repetitive): A constraint that describes specific conditions that are 2484 applicable to the Supplementary Component. 2485

• BusinessProcessContext (optional, repetitive): The business process with which this 2486 Supplementary Component is associated. 2487

• GeopoliticalorRegionContext (optional, repetitive): The geopolitical/region contexts for this 2488 Supplementary Component. 2489

• OfficialConstraintContext (optional, repetitive): The official constraint context for this 2490 Supplementary Component. 2491

• ProductContext (optional, repetitive): The product context for this Supplementary 2492 Component. 2493

• IndustryContext (optional, repetitive): The industry context for this Supplementary 2494 Component. 2495

• BusinessProcessRoleContext (optional, repetitive): The role context for this Qualified Data 2496 Type. 2497

• SupportingRoleContext (optional, repetitive): The supporting role context for this 2498 Supplementary Component. 2499

• SystemCapabilitiesContext (optional, repetitive): The system capabilities context for this 2500 Supplementary Component. 2501

• Example (optional, repetitive): Example of a possible value of a Supplementary Component. 2502

2503

2504 2505 2506 2507 2508 2509 2510 2511

7.8 Code Lists Codes are an integral component of any business to business information flow as they facilitate the ability of the flow to be machine understandable. In order for the XML instance documents to be fully validated by the parsers, any codes used within the XML document need to be available as part of the schema validation process. Many international, national and sectorial agencies create and maintain code lists relevant to their area. If required to be used within an information flow, these code lists will be stored in their own schema, and are referred to as external code lists. For example, many of the existing code lists that exist in the United Nations Code List (UNCL) will be stored as external code list schema for use within other UN/CEFACT XSD Schema.

[R 153] Each UN/CEFACT maintained code list MUST be defined in its own schema module. 2512

2513 2514

2515 2516 2517

External code lists must be used when they exist in schema module form and when they can be directly imported into a schema module.

UN/CEFACT may design and use an internal code list schema where an existing external code list schema needs to be extended, or where no suitable external code list schema exists. If a code list schema is created, it should be globally scoped and designed for reuse and sharing.

[R 154] Internal code list schema MUST NOT duplicate existing external code list schema when the 2518 existing ones are available to be imported. 2519


7.8.1 Schema Construct 2520

2521 2522 2523

2524

The code list schema module will follow the general pattern for all UN/CEFACT XSD schema modules. Following the generic module information, the body of the schema will consist of code list definitions of the following general form:

Example 7-39: Structure of code lists <?xml version="1.0" encoding="UTF-8"?> 2525  2526  2527  2528  2539 <xsd:schema targetNamespace=" ... see namespace ... 2540 xmlns:xsd="http://www.w3.org/2001/XMLSchema" 2541 elementFormDefault="qualified" attributeFormDefault="unqualified"> 2542  2543  2544 ... see root element declaration ... 2545  2546  2547  2548  2549 ... see type definition ... 2550

2551

2552

2553 2554 2555 2556 2557 2558

2559

2560

2561

2562 2563

2564 2565 2566

</xsd:schema>

7.8.2 Namespace Name for Code Lists The namespace name for code list is somewhat unique in order to convey some of the supplementary component information rather than including them as attributes. Specifically, the UN/CEFACT namespace structure for a namespace name of a code list should be: urn:un:unece:uncefact:codelist:<status>:<Code List Agency Identifier|Code List Agency Name Text>:<Code List Identification Identifier|Code List Name Text>:<Code List Version Identifier>

Where:



• unece:uncefact:codelist:<status> with unece and uncefact as fixed value second and third level domains within the NID of un and the codelist as a fixed schema type.

• Supplementary Component String for unique identifiying of code lists = <Code List. Agency Identifier|Code List. Agency Name. Text>:<Code List. Identification. Identifier|Code List. Name. Text>:<Code List. Version. Identifier>

[R 155] The names for namespaces MUST have the following structure while the schema is at draft 2567 2568 2569 2570 2571 2572 2573 2574 2575 2576

status: urn:un:unece:uncefact:codelist:draft:<Code List Agency Identifier|Code List Agency Name Text>:<Code List Identification. Identifier|Code List Name Text>:<Code List Version. Identifier> Where: codelist = this token identifying the schema as a code list Code List Agency Identifier = identifies the agency that manages a code list. The default

agencies used are those from DE 3055 but roles defined in DE 3055 cannot be used. Code List Agency Name Text = the name of the agency that maintains the code list. Code List Identification Identifier = identifies a list of the respective corresponding codes. listID is only unique within the agency that manages this code list. Code List Name Text = the name of a list of codes. Code List Version Identifier = identifies the version of a code list.

2577 2578 2579 2580 2581 2582 2583

2584 2585

Example 7-40: Namespace name of a code list with an agency and a code list identifier at draft status

"urn:un:unece:uncefact:codelist:draft:6:3403:D.04A" 2586 2587 where 2588 6 = the value for UN/ECE in UN/CEFACT data element 3055 representing 2589 the Code List. Agency. Identifier 2590 3403 = UN/CEFACT data element tag for Name type code representing 2591 the Code List. Identification. Identifier 2592

2593

2594

D.04A = the version of the UN/CEFACT directory

Example 7-41: Namespace name of proprietary code list at draft status "urn:un:unece:uncefact:codelist:draft:Security_Initiative:Document_Security:12595 .2" 2596 2597 where 2598 SecurityInitiative = the code list agency name of a repsonsible agency, which 2599 is not defined in UN/CEFACT data element 3055 2600 representing the Code List. Agency. Identifier 2601 DocumentSecurity = the value for Code List. Name. Text 2602

2603 1.2 = the value for Code List. Version. Identifier

[R 156] The namespace names for schema holding specification status MUST be of the form: 2604 2605 2606 2607 2608 2609 2610 2611 2612 2613 2614 2615 2616 2617

urn:un:unece:uncefact:codelist:standard:<Code List. Agency Identifier|Code List Agency Name Text>:<Code List Identification. Identifier|Code List Name Text>:<Code List Version Identifier> Where: codelist = this token identifying the schema as a code list Code List Agency Identifier = identifies the agency that manages a code list. The default agencies used are those from DE 3055 but roles defined in DE 3055 cannot be used. Code List Agency Name Text = the name of the agency that maintains the code list. Code List Identification Identifier = identifies a list of the respective corresponding codes. listID is only unique within the agency that manages this code list. Code List Name Text = the name of a list of codes. Code List Version Identifier = identifies the version of a code list. 2618

2619 2620

Example 7-42: Namespace name of a code list with an agency and a code list identifier at standard status

"urn:un:unece:uncefact:codelist:standard:6:3403:D.04A" 2621 2622 where 2623 6 = the value for UN/ECE in UN/CEFACT data element 3055 representing 2624 the Code List. Agency. Identifier 2625 3403 = UN/CEFACT data element tag for Name status code representing 2626 the Code List. Identification. Identifier 2627

2628

2629

D.04A = the version of the UN/CEFACT directory

Example 7-43: Namespace name of proprietary code list at standard status "urn:un:unece:uncefact:codelist:standard:Security_Initiative:Document_Securit2630 y:1.2" 2631 2632 where 2633 SecurityInitiative = the code list agency name of a responsible agency, which 2634 is not defined in UN/CEFACT data element 3055 2635 representing the Code List. Agency. Identifier 2636 DocumentSecurity = the value for Code List. Name. Text 2637 1.2 = the value for Code List. Version. Identifier 2638


2639 2640 2641

2642

2643 2644 2645 2646 2647 2648 2649 2650

2651 2652 2653 2654 2655

Versioning for code lists published by external organisations is outside our control. As UN/CEFACT published code lists and identifier list schema the value of the <Code List. Version. Identifier> will follow the same rules as for versioning of other schema modules.

7.8.3 UN/CEFACT XSD Schema Namespace Token for Code Lists A unique token will be defined for each namespace of code lists. The token representing the namespace for code lists should be constructed based on the identifier of the agency maintaining the code list and the identifier of the specific code list as issued by the maintenance agency except where there is no identifier. When there is no identifier, the name for the agency and/or code list should be used instead. This will typically be true when proprietary code lists are used. This method of token construction will provide uniqueness with a reasonably short token. When the code list is used for a qualified data type with a restricted set of valid code values, the qualified data type name is required to be used to distinguish one set of restricted values from another.

The agency maintaining the code list will generally be either identified by the agency code as specified in data element 3055 in the UN/CEFACT Code List directory or the agency name if the agency does not have a code value in 3055. The identifier of the specific code list will generally be the data element tag of the corresponding list in the UN/CEFACT directory. If there is no corresponding data element, then the name of the code list will be used.

[R 157] Each UN/CEFACT maintained code list schema module MUST be represented by a unique 2656 2657 2658 2659 2660 2661 2662

token constructed as follows: clm[Qualified data type name]<Code List Agency Identifier|Code List Agency Name Text><Code List Identification Identifier|Code List Name Text> with any repeated words eliminated. 2663

2664 Example 7-44: Code list token with an agency and a code list identifier The code list token for Name Type. Code is clm63403 2665 where 2666 6 = the value for UN/ECE in UN/CEFACT data element 3055 representing 2667 the Code List. Agency. Identifier 2668 3403 = UN/CEFACT data element tag for Name status code representing 2669

2670

2671

the Code List. Identification. Identifier

Example 7-45: Code list token for a qualified data type with an agency and code list identifiers Code list token for Person_Name Type. Code is clmPersonNameType63403 2672 where 2673 PersonNameType = name of the qualified data type 2674 6 = the value for UN/ECE in UN/CEFACT data element 3055 representing 2675 the Code List. Agency. Identifier 2676 3403 = UN/CEFACT data element tag for Name status code representing 2677

2678

2679

the Code List. Identification. Identifier

Example 7-46: Code list token for a proprietary code list Code list token for a proprietary code list for Document Security is 2680 clmSecurityInitiativeDocumentSecurity 2681 where 2682 SecurityInitiative = the code list agency name of a repsonsible agency, which 2683 is not defined in UN/CEFACT data element 3055 2684 representing the Code List. Agency. Identifier 2685

2686

2687 2688

2689

DocumentSecurity = the value for Code List. Name. Text

Based on the constructs identified in the above examples, a namespace declaration for a code list would appear as shown in Example 7-47.

Example 7-47: Target namespace declaration for a code list <xsd:schema 2690 targetNamespace="urn:un:unece:uncefact:codelist:draft:6:4437:D.04A" 2691 xmlns:clm64437="urn:un:unece:uncefact:codelist:draft:6:4437:D.04A" 2692 xmlns:xsd="http://www.w3.org/2001/XMLSchema" 2693

2694 elementFormDefault="qualified" attributeFormDefault="unqualified">

[Note] 2695


External developers are encouraged to follow the above construct rule when customizing 2696 schema for code lists to ensure that there is no namespace conflict. 2697

2698

2699 2700 2701 2702 2703 2704 2705

2706 2707

7.8.4 Schema Location Schema locations of code lists are typically defined as URL based URI schemes because of resolvability limitations of URN based URI schemes. However, UN/CEFACT XSD Schema of code lists use a URN based URI scheme for namespace declarations because persistence is considered more important than resolvability. In recognition of the need for resolvability of schema location, until such time as URNs become fully resolvable, UN/CEFACT will store schema of code lists in locations identified using a URL based URI scheme aligned with the URN based URI scheme used for the namespace declaration as follows:

urn:un:unece:uncefact:codelist:<status>:<Code List. Agency Identifier|Code List. Agency Name. Text>:<Code List. Identification. Identifier|Code List. Name. Text>:<Code List. Version. Identifier>

[R 158] The structure for schema location of code lists MUST be: 2708 2709 2710 2711 2712 2713 2714 2715 2716 2717 2718 2719 2720 2721 2722 2723

2724 2725

2726

http://www.unece.org/uncefact/codelist/<status>/<Code List. Agency Identifier|Code List Agency Name Text>/<Code List Identification Identifier|Code List Name Text>_<Code List Version Identifier>.xsd Where: schematype = a token identifying the type of schema module: codelist status = the status of the schema as: draft|standard Code List Agency Identifier = identifies the agency that manages a code list. The default agencies used are those from DE 3055 but roles defined in DE 3055 cannot be used. Code List Agency Name Text = the name of the agency that maintains the code list. Code List Identification Identifier = identifies a list of the respective corresponding codes. listID is only unique within the agency that manages this code list. Code List Name Text = the name of a list of codes. Code List Version Identifier = identifies the version of a code list.

[R 159] Each xsd:schemaLocation attribute declaration of a code list MUST contain a persistent and resolvable URL.

[R 160] Each xsd:schemaLocation attribute declaration URL of a code list MUST contain an absolute path. 2727

2728

2729 2730

7.8.5 Imports and Includes UN/CEFACT Code List Schema Modules are standalone schema modules and will not import or include any other schema modules.

[R 161] Code List schema modules MUST not import or include any other schema modules. 2731

2732 7.8.6 Type Definitions

[R 162] Within each code list module one, and only one, named xsd:simpleType MUST be defined 2733 2734

2735

for the content component.

[R 163] The name of the xsd:simpleType MUST be the name of root element based on the value of the code list name text with the word “ContentType” appended. 2736

2737 Example 7-48: Simple type definition of code lists  2738  2739  2740  2741 <xsd:simpleType name="AccountTypeCodeContentType"> 2742 <xsd:restriction base="xsd:token"> 2743 <xsd:enumeration value="2"> 2744

... see enumeration ... 2745 </xsd:enumeration> 2746 </xsd:restriction> 2747

2748 </xsd:simpleType>

[R 164] The xsd:restriction element base attribute value MUST be set to “xsd:token”. 2749

2750 [R 165] Each code in the code list MUST be expressed as an xsd:enumeration, where the xsd:value for the enumeration is the actual code value. 2751

2752 Example 7-49: Enumeration facet of code lists ... see type defintion ... 2753 <xsd:enumeration value="2"> 2754 <xsd:annotation> 2755 ... see annotation 2756 </xsd:annotation> 2757 </xsd:enumeration> 2758 <xsd:enumeration value="15"> 2759 <xsd:annotation> 2760 ... see annotation 2761 </xsd:annotation> 2762 </xsd:enumeration> 2763

2764

2765 2766

...

The purpose of the code list schema module is to define the list of allowable values (enumerations) that can appear within a particular element. Therefore, no other facet restrictions are allowed.

[R 166] Facets other than xsd:enumeration MUST NOT be used in the code list schema module. 2767

2768

2769

7.8.7 Element Declarations Each code list schema module will contain the list of enumerations allowed for a particular element.

[R 167] For each code list a single root element MUST be globally declared. 2770

2771 2772

[R 168] The name of root element MUST be based on the code list name text following the naming rules as defined in section 5.3.

[R 169] The root element MUST be of a type representing the actual list of code values. 2773

2774 Example 7-50: Root element declaration of code lists  2775  2776 <xsd:element name="AccountTypeCode" 2777 type="clm64437:AccountTypeCodeContentType"/> 2778

2779

2780 2781

2782

2783

2784

2785 2786

2787

2788

7.8.8 Extension and Restriction Users of the UN/CEFACT library may identify any subset they wish from a specific identifier list for their own trading community requirements by defining a qualified data type.

Representation of a qualified data type of code lists could be

• a combination of several individual code lists using xsd:union

• a choice between several code lists, using xsd:choice

Both of these can easily be accommodated in this syntax solution as required by the user’s business requirements.

XML declarations for using code lists in qualified data types are shown in the following examples.

Example 7-51: Usage of only one Code List <xsd:simpleType name="TemperatureMeasureUnitCodeType"> 2789 <xsd:annotation> 2790 ... see annotation ... 2791 </xsd:annotation> 2792 <xsd:restriction base="clm66411:UnitCodeContentType"> 2793 <xsd:length value="3"/> 2794

<xsd:enumeration value="BTU"> 2795 <xsd:annotation> 2796 <xsd:documentation source="code" xml:lang="en"> 2797 <ccts:CodeName>British thermal unit</ccts:CodeName> 2798 </xsd:documentation> 2799 </xsd:annotation> 2800 </xsd:enumeration> 2801 <xsd:enumeration value="CEL"> 2802 <xsd:annotation> 2803 <xsd:documentation source="code" xml:lang="en"> 2804 <ccts:CodeName>degree Celsius</ccts:CodeName> 2805 </xsd:documentation> 2806 </xsd:annotation> 2807 </xsd:enumeration> 2808 <xsd:enumeration value="FAH"> 2809 <xsd:annotation> 2810 <xsd:documentation source="code" xml:lang="en"> 2811 <ccts:CodeName>degree Fahrenheit</ccts:CodeName> 2812 </xsd:documentation> 2813 </xsd:annotation> 2814 </xsd:enumeration> 2815 </xsd:restriction> 2816

2817

2818

</xsd:simpleType>

Example 7-52: Usage of alternative Code Lists <xsd:complexType name="PersonPropertyCodeType"> 2819 <xsd:annotation> 2820 ... see annotation ... 2821 </xsd:annotation> 2822 <xsd:choice> 2823 <xsd:element ref="clm63479:MaritalCode"/> 2824 <xsd:element ref="clm63499:GenderCode"/> 2825 </xsd:choice> 2826

2827

2828

</xsd:complexType>

Example 7-53: Combination of Code Lists <xsd:simpleType name="AccountDutyCodeType"> 2829 <xsd:annotation> 2830 ... see annotation ... 2831 </xsd:annotation> 2832 <xsd:union memberTypes="clm64437:AccountTypeCodeContentType 2833 clm65153:DutyTaxFeeTypeCodeContentType"/> 2834

2835

2836

2837 2838

</xsd:simpleType>

7.8.9 Annotation In order to facilitate a clear and unambiguous understanding of the list of allowable codes within an element, annotations will be provided for each enumeration to provide the code name and description.

[R 170] Each xsd:enumeration MUST include an annotation documentation providing the code 2839 name and the code description. 2840

2841 Example 7-54: Annotation of codes <xsd:enumeration value="2"> 2842 <xsd:annotation> 2843 <xsd:documentation xml:lang="en"> 2844 <ccts:CodeName>Budgetary account</ccts:CodeName> 2845 <ccts:CodeDescription>Code identifying a budgetary account. 2846 </ccts:CodeDescription> 2847 </xsd:documentation> 2848 </xsd:annotation> 2849

2850

2851

2852 2853 2854 2855

</xsd:enumeration>...

7.9 Identifier List Schema When required separate schema modules will be defined for identification schemes that have a token, and optionally a description, and that have the same functionality as a code list. In this way, XML instance documents containing these identifiers can be fully validated by the parsers. Other identifier schemes should be defined as a qualified or unqualified data type as appropriate.


2856 2857

2858 2859 2860

External identifier lists must be used when they exist in schema module form and when they can be directly imported into a schema module.

UN/CEFACT may design and use an internal identifier list where an existing external identifier list needs to be extended, or where no suitable external identifier list exists. If an identifier list is created, the lists should be globally scoped and designed for reuse and sharing.

[R 171] Internal identifier lists schema MUST NOT duplicate existing external identifier list schema 2861 2862 when the existing ones are available to be imported.

[R 172] Each UN/CEFACT maintained identifier list MUST be defined in its own schema module. 2863

2864

2865 2866 2867

2868

7.9.1 Schema Construct The identifier list schema module will follow the general pattern for all UN/CEFACT XSD schema modules. Following the generic module information, the body of the schema will consist of identifier list definitions of the following general form:

Example 7-55: Structure of identifier lists <?xml version="1.0" encoding="UTF-8"?> 2869  2870  2871  2872  2883 <xsd:schema targetNamespace=" ... see namespace ... 2884 xmlns:xsd="http://www.w3.org/2001/XMLSchema" 2885 elementFormDefault="qualified" attributeFormDefault="unqualified"> 2886  2887  2888 ... see root element declaration ... 2889  2890  2891  2893  2894 ... see type definition ... 2895

2896

2897

2898 2899 2900 2901 2902 2903 2904

2905

2906

2907

2908 2909

</xsd:schema>

7.9.2 Namespace Name for Identifier List Schema The namespace name for identifier list is somewhat unique in order to convey some of the supplementary component information rather than including them as attributes. Specifically, the UN/CEFACT namespace structure for a namespace name of an identifier list schema should be: urn:un:unece:uncefact:identifierlist:<status>:<Identifier Scheme Agency Identifier|Identifier Scheme Agency Name Text>:< Identifier Scheme Identifier|Identifier Scheme Name Text>:< Identifier Scheme Version. Identifier>

Where:



• unece:uncefact:codelist:<status> with unece and uncefact as fixed value second and third level domains within the NID of un and the code list as a fixed schema type.

2910 2911 2912

• Supplementary Component String for unique identifiying of identifier schemes = <Identifier Scheme Agency Identifier|Identifier Scheme Agency Name Text>:< Identifier Scheme Identifier|Identifier Scheme Name Text>:< Identifier Scheme Version Identifier>

[R 173] The names for namespaces MUST have the following structure while the schema is at draft 2913 2914 2915 2916 2917 2918 2919 2920 2921 2922 2923 2924 2925 2926 2927 2928

status: urn:un:unece:uncefact:identifierlist:draft:<Identifier Scheme. Agency Identifier|Identifier Scheme Agency Name Text>:<Identifier Scheme Identifier|Identifier Scheme Name Text>:<Identifier Scheme Version Identifier> Where: identifierlist = this token identifying the schema as an identifier scheme Identifier Scheme Agency Identifier = the identification of the agency that maintains the identification scheme. Identifier Scheme Agency Name. Text = the name of the agency that maintains the identification list. Identifier Scheme Identifier = the identification of the identification scheme. Identifier Scheme Name. Text = the name of the identification scheme. Identifier Scheme Version. Identifier = the version of the identification scheme. 2929

2930 2931

Example 7-56: Namespace name of an identifier list schema with an agency and an identifier list schema identifier at draft status

"urn:un:unece:uncefact:identifierlist:draft:5:4217:2001" 2932 2933 where 2934 5 = the value for ISO in UN/CEFACT data element 3055 representing 2935 the Code List. Agency. Identifier 2936 4217 = ISO identifier scheme identifier for currency code representing 2937 the Code List. Identification. Identifier 2938

2939 2001 = the version of the ISO currency code list.

[R 174] The namespace names for identifier list schema holding specification status MUST be of the 2940 2941 2942 2943 2944 2945 2946 2947 2948 2949 2950 2951 2952 2953 2954 2955

form: urn:un:unece:uncefact:identifierlist:standard:<Identifier Scheme. Agency Identifier|Identifier Scheme Agency Name Text>:<Identifier Scheme Identifier|Identifier Scheme Name Text>:<Identifier Scheme. Version Identifier> Where: identifierlist = this token identifying the schema as an identifier scheme Identifier Scheme Agency Identifier = the identification of the agency that maintains the identification scheme. Identifier Scheme Agency Name. Text = the name of the agency that maintains the identification scheme. Identifier Scheme Identifier = the identification of the identification scheme. Identifier Scheme Name. Text = the name of the identification scheme. Identifier Scheme Version. Identifier = the version of the identification scheme. 2956

2957 2958

Example 7-57: Namespace of an identifier list schema with an agency and an identifier list schema identifier at standard status

"urn:un:unece:uncefact:identifierlist:standard:5:4217:2001" 2959 2960 where 2961 5 = the value for ISO in UN/CEFACT data element 3055 representing 2962 the Code List. Agency. Identifier 2963 4217 = ISO identifier scheme identifier for currency code representing 2964 the Code List. Identification. Identifier 2965 2001 = the version of the ISO currency code list. 2966


2967 2968 2969

2970 2971

2972 2973 2974 2975 2976 2977

2978 2979 2980

Versioning for identifier list schemas published by external organisations is outside our control. As UN/CEFACT published identifier list schema the value of the <Identifier Scheme. Version. Identifier> will follow the same rules as for versioning of other schema modules.

7.9.3 UN/CEFACT XSD Schema Namespace Token for Identifier List Schema

A unique token will be defined for each namespace of an identifier list schema. The token representing the namespace for identifier lists should be constructed based on the identifier of the agency maintaining the identification list and the identifier of the specific identification list as issued by the maintenance agency. This method of token construction will provide uniqueness with a reasonably short token. When the identifier list is used for a qualified data type with a restricted set of valid identifier values, the qualified data type name is required to be used to distinguish one set of restricted values from another.

The agency maintaining the identification list will be either identified by the agency code as specified in data element 3055 in the UN/CEFACT directory. The identifier of the identification list will be the identifier as allocated by the identification scheme agency.

[R 175] Each UN/CEFACT maintained identifier list schema module MUST be represented by a 2981 2982 2983 2984

unique token constructed as follows: ids[Qualified data type name]<Identification Scheme Agency Identifier><Identification Scheme Identifier> 2985

2986 Example 7-58: Identifier list token Token for the ISO Country Codes would be: ids53166-1 2987 where: 2988 5 = the Identification Scheme Agency Identifier for ISO in codelist 3055 2989 3166-1 = the Identification Scheme Identifier as allocated by ISO. 2990

2991 2992

2993

Based on the constructs identified in Example 4-37, a namespace declaration for an identifier list would appear as shown in Example 4-38.

Example 7-59: Target Namespace declaration for an Identifier list <xsd:schema 2994 targetNamespace="urn:un:unece:uncefact:identifierlist:draft:5:3166-1:1997" 2995 xmlns:ids53166-1="urn:un:unece:uncefact:identifierlist:draft:5:3166-1:1977" 2996 xmlns:xsd="http://www.w3.org/2001/XMLSchema" 2997

2998 elementFormDefault="qualified" attributeFormDefault="unqualified">

[Note] 2999

External developers are encouraged to follow the above construct rule when customizing 3000 schema for identifier lists to ensure that there is no namespace conflict. 3001

3002

3003 3004 3005 3006 3007 3008 3009 3010 3011 3012 3013

7.9.4 Schema Location Schema locations of identifier list schema are typically defined as URL based URI schemes because of resolvability limitations of URN based URI schemes. However, UN/CEFACT XSD Schema of identifier lists use a URN based URI scheme for namespace declarations because persistence is considered more important than resolvability. In recognition of the need for resolvability of schema location, until such time as URNs become fully resolvable, UN/CEFACT will store schema of identifier list in locations identified using a URL based URI scheme aligned with the URN based URI scheme used for the namespace declaration as follows: urn:un:unece:uncefact:identifierlist:<status>:<Identifier Scheme Agency Identifier|Identifier Scheme Agency Name Text>:< Identifier Scheme Identifier|Identifier Scheme Name Text>:< Identifier Scheme Version. Identifier>

[R 176] The structure for schema location of identifier lists MUST be: 3014 3015 3016 3017 3018

http://www.unece.org/uncefact/identifierlist/<status>/<Identifier Scheme Agency Identifier|Identifier Scheme Agency Name Text>/< Identifier Scheme Identifier|Identifier Scheme Name Text>_<


Identifier Scheme Version Identifier>.xsd Where: schematype = a token identifying the type of schema module: identifierlist status = the status of the schema as: draft|standard Identifier Scheme. Agency Identifier = the identification of the agency that maintains the identification scheme. Identifier Scheme. Agency Name. Text = the name of the agency that maintains the identification scheme. Identifier Scheme. Identifier = the identification of the identification scheme. Identifier Scheme. Name. Text = the name of the identification scheme. Identifier Scheme. Version. Identifier = the version of the identification scheme.

3019 3020 3021 3022 3023 3024 3025 3026 3027 3028 3029 3030

3031 3032

3033

[R 177] Each xsd:schemaLocation attribute declaration of an identifier list schema MUST contain a persistent and resolvable URL.

[R 178] Each xsd:schemaLocation attribute declaration URL of an identifier list schema MUST contain an absolute path. 3034

3035

3036 3037

7.9.5 Imports and Includes UN/CEFACT Identifier List Schema Modules are standalone schema modules and will not import or include any other schema modules.

[R 179] Identifier list schema modules MUST NOT import or include any other schema modules. 3038

3039

3040 3041 3042

7.9.6 Type Definitions A restriction has to be declared in order to define the content component (the simple type) as a restriction of the unqualified data type in order to comply with parser requirements. The restriction itself is the list of enumerations.

[R 180] Within each identifier list schema module one, and only one, named xsd:simpleType 3043 3044

3045

MUST be defined for the content component.

[R 181] The name of the xsd:simpleType MUST be the name of root element with the word “ContentType” appended. 3046

3047 Example 7-60: Simple type definition of an identifier list  3048  3049 <xsd:simpleType name="CountryIdentifierContentType"> 3050 <xsd:restriction base="xsd:token"> 3051 <xsd:enumeration value="AU"> 3052 ... see enumeration ... 3053 </xsd:enumeration> 3054 </xsd:restriction> 3055

3056 </xsd:simpleType>

[R 182] The xsd:restriction element base attribute value MUST be set to “xsd:token”. 3057

3058 [R 183] Each identifier in the identifier list MUST be expressed as an xsd:enumeration, where the xsd:value for the enumeration is the actual identifier value. 3059

3060 Example 7-61: Enumeration facet of an identifier list ... see type defintion ... 3061 <xsd:enumeration value="AU"> 3062 <xsd:annotation> 3063 ... see annotation 3064 </xsd:annotation> 3065 </xsd:enumeration> 3066 <xsd:enumeration value="US"> 3067 <xsd:annotation> 3068 ... see annotation 3069 </xsd:annotation> 3070

</xsd:enumeration> 3071 3072

3073 3074

...

The purpose of the identifier list schema module is to define the list of allowable values (enumerations) that can appear within a particular element. Therefore, no other facet restrictions are allowed.

[R 184] Facets other than xsd:enumeration MUST NOT be used in the identifier list schema 3075 module. 3076

3077

3078

7.9.7 Attribute and Element Declarations Each identifier list schema module will contain a list of enumerations allowed for a particular element.

[R 185] For each identifier list a single root element MUST be globally declared. 3079

3080 3081

[R 186] The name of the root element MUST be based on the identification scheme. name. text following the naming rules as defined in section 5.3.

[R 187] The root element MUST be of a type representing the actual list of identifier values. 3082

3083 Example 7-62: Root element declaration of identifier lists  3084  3085 <xsd:element name="CountryIdentifier" 3086 type="ids53166:CountryIdentifierContentType"/> 3087

3088

3089 3090

3091

3092

3093

3094 3095

3096

3097

7.9.8 Extension and Restriction Users of the UN/CEFACT library may identify any subset they wish from a specific identifier list for their own trading community requirements by defining a qualified data type.

Representation of a qualified data type of identifier lists could be

• a combination of several individual identifier lists using xsd:union

• a choice between several identifier lists, using xsd:choice

Both of these can easily be accommodated in this syntax solution as required by the user’s business requirements.

XML declarations for using identifier lists in qualified data types are shown in the following examples.

Example 7-63: Enumeration facet of identifier scheme ... see type definition ... 3098 <xsd:enumeration value="AD"> 3099 <xsd:annotation> 3100 ... see annotation ... 3101 </xsd:annotation> 3102 </xsd:enumeration> 3103 <xsd:enumeration value="AE"> 3104 <xsd:annotation> 3105 ... see annotation ... 3106 </xsd:annotation> 3107 </xsd:enumeration> 3108 <xsd:enumeration value="AF"> 3109 <xsd:annotation> 3110 ... see annotation ... 3111 </xsd:annotation> 3112 </xsd:enumeration> 3113

3114

3115

... see type definition ...

Example 7-64: Usage of only one identifier scheme <xsd:simpleType name="CountryIdentifierType"> 3116 <xsd:annotation> 3117 ... see annotation ... 3118 </xsd:annotation> 3119 <xsd:restriction base="ids53166:CountryIdentifierContentType"/> 3120

3121

3122

</xsd:simpleType>

Example 7-65: Usage of alternative identifier schemes

<xsd:complexType name="GeopoliticalIdentifierType"> 3123 <xsd:annotation> 3124 ... see annotation ... 3125 </xsd:annotation> 3126 <xsd:choice> 3127 <xsd:element ref="ids53166:CountryCode"/> 3128 <xsd:element ref="ids53166-2:RegionCode"/> 3129 </xsd:choice> 3130

3131

3132

3133 3134 3135

</xsd:complexType>

7.9.9 Annotation In order to facilitate a clear and unambiguous understanding of the list of allowable identifiers within an element, annotations will be provided for each enumeration to provide the name, and optionally a description of, the identifier.

[R 188] Each xsd:enumeration MUST include an annotation documentation providing the identifier 3136 name and optionally the description of the identifier. 3137

3138 Example 7-66: Annotation of Identifiers <xsd:enumeration value="AU"> 3139 <xsd:annotation> 3140 <xsd:documentation xml:lang="en"> 3141 <ccd:IdentifierName>Australia</ccd:IdentifierName> 3142 </xsd:documentation> 3143 </xsd:annotation> 3144 </xsd:enumeration> 3145


8 XML Instance Documents 3146

3147 3148 3149 3150 3151 3152

3153

3154 3155 3156 3157

In order to be UN/CEFACT conformant, an instance document must be valid against the relevant UN/CEFACT compliant XML schema. The XML instance documents should be readable and understandable by both humans and applications, and should enable reasonably intuitive interactions. It should represent all truncated tag names as described in section 7. A XPath navigation path should describe the complete semantic understanding by concatenating the nested elements. This navigation path should also reflect the meaning of each dictionary entry name of a BBIE or ASBIE.

8.1 Character Encoding In conformance with ISO/IETF/ITU/UNCEFACT Memorandum of Understanding Management Group (MOUMG) Resolution 01/08 (MOU/MG01n83) as agreed to by UN/CEFACT, all UN/CEFACT XML will be instantiated using UTF. UTF-8 is the preferred encoding, but UTF-16 may be used where necessary to support other languages.

[R 189] All UN/CEFACT XML MUST be instantiated using UTF . UTF-8 should be used as the 3158 preferred encoding. If UTF-8 is not used, UTF-16 MUST be used. 3159

3160

3161 3162

8.2 Empty Content Empty elements do not provide the level of assurance necessary for business information exchanges and as such, will not be used.

[R 190] UN/CEFACT conformant instance documents MUST NOT contain an element devoid of 3163 3164 content.

[R 191] The xsi:nil attribute MUST NOT appear in any conforming instance. 3165

3166

3167 3168

8.3 xsi:type The xsi:type attribute allows for substitution during an instantiation of a xml document. In the same way that substitution groups are not allowed, the xsi:type attribute is not allowed.

[R 192] The xsi:type attribute MUST NOT be used. 3169


Appendix A. Related Documents 3170

3171

3172 3173

3174

3175

3176

3177 3178

3179 3180 3181

3182 3183

3184 3185

3186 3187

3188 3189

The following documents provided significant levels of influence in the development of this document:

• UN/CEFACT Core Components Technical Specification, Part 8 of the ebXML Framework Version 2.01

• ebXML Technical Architecture Specification v1.04

• OASIS/ebXML Registry Information Model v2.0

• ebXML Requirements Specification v1.06

• Information Technology - Metadata registries: Framework for the Specification and Standardization of Data Elements, International Standardization Organization, ISO 11179-1

• Information Technology - Metadata registries: Classification of Concepts for the Identification of Domains, International Standardization Organization, ISO 11179-2

• Information Technology - Metadata registries: Registry Metamodel, International Standardization Organization, ISO 11179-3

• Information Technology - Metadata registries: Rules and Guidelines for the Formulation of Data Definitions, International Standardization Organization, ISO 11179-4

• Information Technology - Metadata registries: Naming and Identification Principles for Data Elements, International Standardization Organization, ISO 11179-5

• Information Technology - Metadata registries: Framework for the Specification and Standardization of Data Elements, International Standardization Organization, ISO 11179-6


Appendix B. Overall Structure 3190

3191 3192

3193

3194

3195

3196

3197

3198

3199

3200

3201

3202

The structure of an UN/CEFACT compliant XML schema must contain one or more of the following sections as relevant. Relevant sections must appear in the order given:

• XML Declaration

• Schema Module Identification and Copyright Information

• Schema Start-Tag

• Includes

• Imports

• Root element

• Type Definitions

B.1 XML Declaration A UTF-8 encoding is adopted throughout all UN/CEFACT XML schema.

Example B-1: XML Declaration <?xml version="1.0" encoding="UTF-8"?> 3203

3204

3205

B.2 Schema Module Identification and Copyright Information Example B-2: Copyright Information

 3206  3207  3208  3235

3236

3237 3238

3239

3240

3241

B.3 Schema Start-Tag The Schema Start-Tag section of an UN/CEFACT compliant XML schema must contain one or more of the below declarations as relevant. Relevant declarations must appear in the order given:

• Version

• Namespaces

• targetNamespace attribute

3242

3243

3244

3245

3246

3247

3248

3249

3250

3251

3252

3253

3254

• xmlns:xsd attribute

• namespace declaration for reusable ABIEs actually used in the schema

• namespace declaration for unqualified data types actually used in the schema

• namespace declaration for qualified data types actually used in the schema

• namespace declaration for code lists actually used in the schema

• namespace declaration for identifier schemes actually used in the schema

• Form Defaults

• elementFormDefault

• attributeFormDefault

• Others

• other schema attributes with schema namespace

• other schema attributes with non-schema namespace

Example B-3: XML Schema Start Tag <xsd:schema 3255 targetNamespace="urn:un:unece:uncefact:data:draft:UNCEFACTExamplesSchemaModule:0.3.6" 3256 xmlns:rsm="urn:un:unece:uncefact:data:draft:UNCEFACTExamplesSchemaModule:0.3.6" 3257 xmlns:xsd="http://www.w3.org/2001/XMLSchema" 3258 xmlns:ram="urn:un:unece:uncefact:data:draft:UNCEFACTReusableAggregateBusinessInformati3259 onEntitySchemaModule:0.3.6" 3260 xmlns:udt="urn:un:unece:uncefact:data:draft:UNCEFACTUnqualifiedDataTypeSchemaModule:0.3261 3.6" 3262 xmlns:qdt="urn:un:unece:uncefact:data:draft:UNCEFACTQualifiedDataTypeSchemaModule:0.3.3263 6" 3264 xmlns:ids53166="urn:un:unece:uncefact:codelist:draft:5:3166-1:1997" 3265 xmlns:ids53166-2="urn:un:unece:uncefact:codelist:draft:5:3166-2:1998" 3266 xmlns:clm65153="urn:un:unece:uncefact:codelist:draft:6:5153:D.01C" 3267 xmlns:clm64405="urn:un:unece:uncefact:codelist:draft:6:4405:D.01C " 3268 xmlns:clm69143="urn:un:unece:uncefact:codelist:draft:6:9143:D.01C " 3269 xmlns:clmPerson_Characteristic_Code63289="urn:un:unece:uncefact:codelist:draft: 3270 6:3289:D.01C" xmlns:clm63479="urn:un:unece:uncefact:codelist:draft:6:3479:D.01C" 3271 xmlns:clm63499="urn:un:unece:uncefact:codelist:draft:6:3499:D.01C" 3272 xmlns:clm1161131="urn:un:unece:uncefact:codelist:draft:11:61131:4031" 3273 xmlns: clm66411="urn:un:unece:uncefact:codelist:draft:6:6411:2001" 3274 xmlns:clm54217="urn:un:unece:uncefact:codelist:draft:5:4217:2001" 3275 xmlns:clm5639="urn:un:unece:uncefact:codelist:draft:5:639:1988" 3276 xmlns:clm64437="urn:un:unece:uncefact:codelist:draft:6:4437:D.01C" 3277 3278 elementFormDefault="qualified" 3279 attributeFormDefault="unqualified"> 3280

3281

3282 3283

3284

3285

B.4 Includes The Include section of an UN/CEFACT compliant XML schema must contain one or more of the below declarations as relevant. Relevant declarations must appear in the order given:

• Inclusion of the internal ABIE schema module if used

Example B-4: Includes  3286  3287  3288  3289  3290 <xsd:include 3291 namespace="urn:un:unece:uncefact:data:draft:UNCEFFACTInternalAggregateBusinessInformat3292 ionEntitySchemaModule:0.3.6" 3293 schemaLocation="http://www.unece.org/uncefact/data/UNCEFACTInternalAggregateBusinessIn3294 formationEntitySchemaModule_0.3.6_draft.xsd"/> 3295

B.5 Imports 3296

3297 3298

3299

3300

3301

3302

3303

3304

The Import section of an UN/CEFACT compliant XML schema must contain one or more of the below declarations as relevant. Relevant declarations must appear in the order given:

• Import of the reusable ABIE schema module if used

• Import of the unqualified data type schema module if used

• Import of the qualified data type schema module if used

• Import of code list schema modules actually used

• Import of identifier list schema modules actually used

Example B-5: Imports  3305  3306  3307  3308  3309 <xsd:import namespace=" 3310 urn:un:unece:uncefact:data:draft:UNCEFACTReusableAggregateBusinessInformationSchemaMod3311 ule:0.3.6" schemaLocation=" http://www.unece.org/uncefact/data/ 3312 UNCEFACTReusableAggregateBusinessInformationEntitySchemaModule_0.3.6_draft.xsd"/> 3313  3314  3315  3316 <xsd:import 3317 namespace="urn:un:unece:uncefact:data:draft:UNCEFACTUnqualifiedDataTypeSchemaModule:0.3318 3.6" schemaLocation=" http://www.unece.org/uncefact/data/ 3319 UNCEFACTUnqualifiedDataTypeSchemaModule_0.3.6_draft.xsd"/> 3320  3321  3322  3323 <xsd:import 3324 namespace="urn:un:unece:uncefact:data:draft:UNCEFACTQualifiedDataTypeSchemaModule:0.3.3325 6" schemaLocation=" http://www.unece.org/uncefact/data/ 3326 UNCEFACTQualifiedDataTypeSchemaModule_0.3.6_draft.xsd"/> 3327  3328  3329  3330 <xsd:import namespace="urn:un:unece:uncefact:codelist:draft:6:4437:D.01C" 3331 schemaLocation="http://www.unece.org/uncefact/codelist/64437_D.01C_draft.xsd"/> 3332 <xsd:import namespace="urn:un:unece:uncefact:codelist:draft:6:6411:2001" 3333 schemaLocation=" http://www.unece.org/uncefact/codelist/66411_2001_draft.xsd"/> 3334 <xsd:import namespace="urn:un:unece:uncefact:codelist:draft:5:4217:2001" 3335 schemaLocation=" http://www.unece.org/uncefact/codelist/54217_2001_draft.xsd"/> 3336 <xsd:import namespace="urn:un:unece:uncefact:codelist:draft:5:639-1:1988" 3337 schemaLocation="http://www.unece.org/uncefact/codelist/5639-1.1988_draft.xsd"/> 3338 <xsd:import namespace="urn:un:unece:uncefact:codelist:draft:11:61131:4031" 3339 schemaLocation="http://www.unece.org/uncefact/codelist/1161131_4031_draft.xsd"/> 3340 <xsd:import namespace="urn:un:unece:uncefact:codelist:draft:6:3499:D.01C" 3341 schemaLocation="http://www.unece.org/uncefact/codelist/63499_D.01C_draft.xsd"/> 3342 <xsd:import namespace="urn:un:unece:uncefact:codelist:draft:6:3479:D.01C" 3343 schemaLocation="http://www.unece.org/uncefact/codelist/63479_D.01C_draft.xsd"/> 3344 <xsd:import namespace="urn:un:unece:uncefact:codelist:draft:6:3289:D.01C" 3345 schemaLocation="http://www.unece.org/uncefact/codelist/63289_D.01C_draft.xsd"/> 3346 <xsd:import namespace="urn:un:unece:uncefact:codelist:draft:6:9143:D.01C" 3347 schemaLocation="http://www.unece.org/uncefact/codelist/69143_D.01C_draft.xsd"/> 3348 <xsd:import namespace="urn:un:unece:uncefact:codelist:draft:6:4405:D.01C" 3349 schemaLocation="http://www.unece.org/uncefact/codelist/64405_D.01C_draft.xsd"/> 3350 <xsd:import namespace="urn:un:unece:uncefact:codelist:draft:6:5153:D.01C" 3351 schemaLocation="http://www.unece.org/uncefact/codelist/65153_D.01C_draft.xsd"/> 3352  3353  3354  3355 <xsd:import namespace="urn:un:unece:uncefact:codelist:draft:5:3166-1:1997" 3356 schemaLocation="http://www.unece.org/uncefact/identiferlist/53166-1_1997_draft.xsd"/> 3357 <xsd:import namespace="urn:un:unece:uncefact:codelist:draft:5:3166-2:1998" 3358 schemaLocation="http://www.unece.org/uncefact/identifierlist/53166-2_1998_draft.xsd"/> 3359

B.6 Root element 3360

3361 3362

3363

The root element's type definition is defined immediately following the definition of the global root element to provide clear visibility of the root element's type, of which this particular schema is all about.

Example B-6:  3364  3365 3366 <xsd:element name="PurchaseOrder" type="exp:PurchaseOrderType"> 3367 <xsd:annotation> 3368 <xsd:documentation> 3369 <ccts:UniqueID>UNM0000001</ccts:UniqueID> 3370 <ccts:CategoryCode>RSM</ccts:CategoryCode> 3371 <ccts:Name>PurchaseOrder</ccts:Name> 3372 <ccts:VersionID>1.0</ccts:VersionID> 3373 <ccts:Description>A document that contains information directly relating to 3374 the economic event of ordering products.</ccts:Description> 3375 <ccts:BusinessDomain>TBG1</ccts:BusinessDomain> 3376 <ccts:BusinessProcessContext>Purchase Order</ccts:BusinessProcessContext> 3377 </xsd:documentation> 3378 </xsd:annotation> 3379 </xsd:element> 3380

3381

3382

3383

3384

B.7 Type Definitions • Definition of types for Basic Business Information Entities in alphabetical order, if applicable.

• Definition of types for Aggregate Business Information Entities in alphabetical order, if applicable.

Example B-7:  3385  3386  3387  3388  3389 <xsd:complexType name="AccountType"> 3390 <xsd:annotation> 3391 <xsd:documentation xml:lang="en"> 3392 <ccts:UniqueID>UN00000001</ccts:UniqueID> 3393 <ccts:CategoryCode>ABIE</ccts:CategoryCode> 3394 <ccts:DictionaryEntryName>Account. Details</ccts:DictionaryEntryName> 3395 <ccts:VersionID>1.0</ccts:VersionID> 3396 <ccts:Definition>A business arrangement whereby debits and/or credits arising 3397 from transactions are recorded. This could be with a bank, i.e. a financial account, 3398 or a trading partner offering supplies or services 'on account', i.e. a commercial 3399 account</ccts:Definition> 3400 <ccts:ObjectClassTermName>Account</ccts:ObjectClassTermName> 3401 </xsd:documentation> 3402 </xsd:annotation> 3403 <xsd:sequence> 3404 <xsd:element name="ID" type="udt:IdentifierType" minOccurs="0" 3405 maxOccurs="unbounded"> 3406 <xsd:annotation> 3407 <xsd:documentation xml:lang="en"> 3408 <ccts:UniqueID>UN00000002</ccts:UniqueID> 3409 <ccts:CategoryCode>BBIE</ccts:CategoryCode> 3410 <ccts:DictionaryEntryName>Account. 3411 Identifier</ccts:DictionaryEntryName> 3412 <ccts:VersionID>1.0</ccts:VersionID> 3413 <ccts:Definition>The identification of a specific 3414 account.</ccts:Definition> 3415 <ccts:Cardinality>0..n</ccts:Cardinality> 3416 <ccts:ObjectClassTermName>Account</ccts:ObjectClassTermName> 3417 <ccts:PropertyTermName>Identifier</ccts:PropertyTermName> 3418 <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> 3419 <ccts:BusinessTermName>Account Number</ccts:BusinessTermName> 3420 </xsd:documentation> 3421 </xsd:annotation> 3422 </xsd:element> 3423 <xsd:element name="Status" type="ram:StatusType" minOccurs="0" 3424 maxOccurs="unbounded"> 3425 <xsd:annotation> 3426 <xsd:documentation xml:lang="en"> 3427

<ccts:UniqueID>UN00000003</ccts:UniqueID> 3428 <ccts:CategoryCode>ASBIE</ccts:CategoryCode> 3429 <ccts:DictionaryEntryName>Account. Status</ccts:DictionaryEntryName> 3430 <ccts:VersionID>1.0</ccts:VersionID> 3431 <ccts:Definition>Status information related to account 3432 details.</ccts:Definition> 3433 <ccts:Cardinality>0..n</ccts:Cardinality> 3434 <ccts:ObjectClassTermName>Account</ccts:ObjectClassTermName> 3435 <ccts:PropertyTermName>Status</ccts:PropertyTermName> 3436 <ccts:RepresentationTermName>Code</ccts:RepresentationTermName> 3437 3438 <ccts:AssociatedObjectClassTermName>Status</ccts:AssociatedObjectClassTermName> 3439 </xsd:documentation> 3440 </xsd:annotation> 3441 </xsd:element> 3442 <xsd:element name="Name" type="udt:NameType" minOccurs="0" 3443 maxOccurs="unbounded"> 3444 <xsd:annotation> 3445 <xsd:documentation xml:lang="en"> 3446 <ccts:UniqueID>UN00000004</ccts:UniqueID> 3447 <ccts:CategoryCode>BBIE</ccts:CategoryCode> 3448 <ccts:DictionaryEntryName>Account. Name. 3449 Text</ccts:DictionaryEntryName> 3450 <ccts:VersionID>1.0</ccts:VersionID> 3451 <ccts:Definition>The text name for a specific account</ccts:Definition> 3452 <ccts:Cardinality>0..n</ccts:Cardinality> 3453 3454 <ccts:ObjectClassTermName>Account</ccts:ObjectClassTermName> 3455 <ccts:PropertyTermName>Name</ccts:PropertyTermName> 3456 <ccts:RepresentationTermName>Text</ccts:RepresentationTermName> 3457 </xsd:documentation> 3458 </xsd:annotation> 3459 </xsd:element> 3460 <xsd:element name="CurrencyCode" type="qdt:CurrencyCodeType" minOccurs="0" 3461 maxOccurs="unbounded"> 3462 <xsd:annotation> 3463 <xsd:documentation xml:lang="en"> 3464 <ccts:UniqueID>UN00000005</ccts:UniqueID> 3465 <ccts:CategoryCode>BBIE</ccts:CategoryCode> 3466 <ccts:DictionaryEntryName>Account. Currency. 3467 Code</ccts:DictionaryEntryName> 3468 <ccts:VersionID>1.0</ccts:VersionID> 3469 <ccts:Definition>A code specifying the currency in which monies are 3470 held within the account.</ccts:Definition> 3471 <ccts:Cardinality>0..n</ccts:Cardinality> 3472 <ccts:ObjectClassTermName>Account</ccts:ObjectClassTermName> 3473 <ccts:PropertyTermName>Currency</ccts:PropertyTermName> 3474 <ccts:RepresentationTermName>Code</ccts:RepresentationTermName> 3475 </xsd:documentation> 3476 </xsd:annotation> 3477 </xsd:element> 3478 <xsd:element name="TypeCode" type="qdt:AccountTypeCodeType" minOccurs="0" 3479 maxOccurs="unbounded"> 3480 <xsd:annotation> 3481 <xsd:documentation xml:lang="en"> 3482 <ccts:UniqueID>UN00000006</ccts:UniqueID> 3483 <ccts:CategoryCode>BBIE</ccts:CategoryCode> 3484 <ccts:DictionaryEntryName>Account. Type. 3485 Code</ccts:DictionaryEntryName> 3486 <ccts:VersionID>1.0</ccts:VersionID> 3487 <ccts:Definition>This provides the ability to indicate what type of 3488 account this is (checking, savings, etc).</ccts:Definition> 3489 <ccts:Cardinality>0..1<ccts:Cardinality> 3490 <ccts:ObjectClassTermName>Account</ccts:ObjectClassTermName> 3491 <ccts:PropertyTermName>Type</ccts:PropertyTermName> 3492 <ccts:RepresentationTermName>Code</ccts:RepresentationTermName> 3493 </xsd:documentation> 3494 </xsd:annotation> 3495 </xsd:element> 3496 <xsd:element name="Country" type="ram:CountryType" minOccurs="0" 3497 maxOccurs="unbounded"> 3498 <xsd:annotation> 3499 <xsd:documentation xml:lang="en"> 3500 <ccts:UniqueID>UN00000007</ccts:UniqueID> 3501 <ccts:CategoryCode>ASBIE</ccts:CategoryCode> 3502 <ccts:DictionaryEntryName>Account. Country</ccts:DictionaryEntryName> 3503


<ccts:VersionID>1.0</ccts:VersionID> 3504 <ccts:Definition>Country information related to account 3505 details.</ccts:Definition> 3506 <ccts:Cardinality>0..n<ccts:Cardinality> 3507 <ccts:ObjectClassTermName>Account</ccts:ObjectClassTermName> 3508 <ccts:PropertyTermName>Country</ccts:PropertyTermName> 3509 3510 <ccts:AssociatedObjectClassTermName>Country</ccts:AssociatedObjectClassTermName> 3511 </xsd:documentation> 3512 </xsd:annotation> 3513 </xsd:element> 3514 <xsd:element name="Person" type="ram:PersonType" minOccurs="0" 3515 maxOccurs="unbounded"> 3516 <xsd:annotation> 3517 <xsd:documentation xml:lang="en"> 3518 <ccts:UniqueID>UN00000008</ccts:UniqueID> 3519 <ccts:CategoryCode>ASBIE</ccts:CategoryCode> 3520 <ccts:DictionaryEntryName>Account. Person</ccts:DictionaryEntryName> 3521 <ccts:VersionID>1.0</ccts:VersionID> 3522 <ccts:Definition>Associated person information related to account 3523 details. This can be used to identify multiple people related to an account, for 3524 instance, the account holder.</ccts:Definition> 3525 <ccts:Cardinality>0..n<ccts:Cardinality> 3526 <ccts:ObjectClassTermName>Account</ccts:ObjectClassTermName> 3527 <ccts:PropertyTermName>Person</ccts:PropertyTermName> 3528 3529 <ccts:AssociatedObjectClassTermName>Person</ccts:AssociatedObjectClassTermName> 3530 </xsd:documentation> 3531 </xsd:annotation> 3532 </xsd:element> 3533 <xsd:element name="Organisation" type="ram:OrganisationType" minOccurs="0" 3534 maxOccurs="unbounded"> 3535 <xsd:annotation> 3536 <xsd:documentation xml:lang="en"> 3537 <ccts:UniqueID>UN00000009</ccts:UniqueID> 3538 <ccts:CategoryCode>ASBIE</ccts:CategoryCode> 3539 <ccts:DictionaryEntryName>Account. 3540 Organisation</ccts:DictionaryEntryName> 3541 <ccts:VersionID>1.0</ccts:VersionID> 3542 <ccts:Definition>The associated organisation information related to 3543 account details. This can be used to identify multiple organisations related to this 3544 account, for instance, the account holder.</ccts:Definition> 3545 <ccts:Cardinality>0..n<ccts:Cardinality> 3546 <ccts:ObjectClassTermName>Account</ccts:ObjectClassTermName> 3547 <ccts:PropertyTermName>Organisation</ccts:PropertyTermName> 3548 3549 <ccts:AssociatedObjectClassTermName>Organisation</ccts:AssociatedObjectClassTermName> 3550 </xsd:documentation> 3551 </xsd:annotation> 3552 </xsd:element> 3553 </xsd:sequence> 3554 </xsd:complexType> 3555

3556 Example B-8: Complete Structure <?xml version="1.0" encoding="UTF-8"?> 3557  3558  3559  3560 <!-- 3561 Module: [MODULENAME] 3562 Agency: UN/CEFACT 3563 Version: [VERSION] 3564 Last change: [DATE OF LAST CHANGE] 3565 3566 Copyright (C) UN/CEFACT (2004). All Rights Reserved. 3567 3568 This document and translations of it may be copied and furnished to others, and 3569 derivative works that comment on or otherwise explain it or assist in its 3570 implementation may be prepared, copied, published and distributed, in whole or in 3571 part, without restriction of any kind, provided that the above copyright notice and 3572 this paragraph are included on all such copies and derivative works. However, this 3573 document itself may not be modified in any way, such as by removing the copyright 3574 notice or references to UN/CEFACT, except as needed for the purpose of developing 3575 UN/CEFACT specifications, in which case the procedures for copyrights defined in the 3576 UN/CEFACT Intellectual Property Rights document must be followed, or as required 3577 to translate it into languages other than English. 3578

3579 The limited permissions granted above are perpetual and will not be revoked by 3580 UN/CEFACT or its successors or assigns. 3581 3582 This document and the information contained herein is provided on an "AS IS" basis and 3583 UN/CEFACT DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 3584 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 3585 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3586 --> 3587 <xsd:schema 3588 targetNamespace="urn:un:unece:uncefact:data:draft:[MODULENAME]:[VERSION" 3589 xmlns:xsd="http://www.w3.org/2001/XMLSchema" 3590 … FURTHER NAMESPACES …. 3591 elementFormDefault="qualified" attributeFormDefault="unqualified"> 3592  3593  3594  3595  3596  3597 <xsd:include namespace="…" schemaLocation="…"/> 3598  3599  3600  3601  3602  3603 <xsd:import namespace="…" schemaLocation="…"/> 3604  3605  3606 3607 <xsd:element name="[ELEMENTNAME]" type="[TOKEN]:[TYPENAME]> 3608  3609  3610  3611  3612  3613 <xsd:complexType name="[TYPENAME]"> 3614 <xsd:restriction base="xsd:token"> 3615 ... see type definition .... 3616 </xsd:restriction> 3617 </xsd:complexType> 3618 </xsd:schema> 3619

Appendix C. ATG Approved Acronyms and Abbreviations 3620

3621 3622

3623 3624

The following constitutes a list of ATG approved acronyms and abbreviations which must be used within tag names when these words are part of the dictionary entry name:

ID – Identifier URI – Uniform Resource Identifier


Appendix D. Core Component Schema Module 3625

<?xml version="1.0" encoding="UTF-8"?> 3626  3627  3628  3629  3659 <xsd:schema targetNamespace="urn:un:unece:uncefact:data:documentation:CoreComponentTypeSchemaModule:1.0" 3660 xmlns:cct="urn:un:unece:uncefact:data:draft:CoreComponentTypeSchemaModule:1.0" 3661 xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> 3662  3663  3664  3665  3666 <xsd:complexType name="AmountType"> 3667 <xsd:annotation> 3668 <xsd:documentation xml:lang="en"> 3669 <ccts:UniqueID>UNDT000001</ccts:UniqueID> 3670 <ccts:CategoryCode>CCT</ccts:CategoryCode> 3671 <ccts:DictionaryEntryName>Amount. Type</ccts:DictionaryEntryName> 3672 <ccts:VersionID>1.0</ccts:VersionID> 3673 <ccts:Definition>A number of monetary units specified in a currency where the unit of the currency is explicit 3674 or implied.</ccts:Definition> 3675 <ccts:RepresentationTermName>Amount</ccts:RepresentationTermName> 3676 <ccts:PrimitiveType>decimal</ccts:PrimitiveType> 3677 </xsd:documentation> 3678 </xsd:annotation> 3679 <xsd:simpleContent> 3680 <xsd:extension base="xsd:decimal"> 3681 <xsd:attribute name="currencyID" type="xsd:normalizedString" use="optional"> 3682 <xsd:annotation> 3683 <xsd:documentation xml:lang="en"> 3684 <ccts:UniqueID>UNDT000001-SC2</ccts:UniqueID> 3685 <ccts:CategoryCode>SC</ccts:CategoryCode> 3686 <ccts:DictionaryEntryName>Amount Currency. Identifier</ccts:DictionaryEntryName> 3687 <ccts:Definition>The currency of the amount.</ccts:Definition> 3688 <ccts:ObjectClass>Amount Currency</ccts:ObjectClass> 3689 <ccts:PropertyTermName>Identification</ccts:PropertyTermName> 3690 <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> 3691

<ccts:PrimitiveType>string</ccts:PrimitiveType> 3692 <ccts:UsageRule>Reference UNECE Rec 9, using 3-letter alphabetic codes.</ccts:UsageRule> 3693 </xsd:documentation> 3694 </xsd:annotation> 3695 </xsd:attribute> 3696 <xsd:attribute name="currencyCodeListVersionID" type="xsd:normalizedString" use="optional"> 3697 <xsd:annotation> 3698 <xsd:documentation xml:lang="en"> 3699 <ccts:UniqueID>UNDT000001-SC3</ccts:UniqueID> 3700 <ccts:CategoryCode>SC</ccts:CategoryCode> 3701 <ccts:DictionaryEntryName>Amount Currency. Code List Version. 3702 Identifier</ccts:DictionaryEntryName> 3703 <ccts:Definition>The VersionID of the UN/ECE Rec9 code list.</ccts:Definition> 3704 <ccts:ObjectClass>Amount Currency</ccts:ObjectClass> 3705 <ccts:PropertyTermName>Code List Version</ccts:PropertyTermName> 3706 <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> 3707 <ccts:PrimitiveType>string</ccts:PrimitiveType> 3708 </xsd:documentation> 3709 </xsd:annotation> 3710 </xsd:attribute> 3711 </xsd:extension> 3712 </xsd:simpleContent> 3713 </xsd:complexType> 3714  3715  3716 <xsd:complexType name="BinaryObjectType"> 3717 <xsd:annotation> 3718 <xsd:documentation xml:lang="en"> 3719 <ccts:UniqueID>UNDT000002</ccts:UniqueID> 3720 <ccts:CategoryCode>CCT</ccts:CategoryCode> 3721 <ccts:DictionaryEntryName>Binary Object. Type</ccts:DictionaryEntryName> 3722 <ccts:VersionID>1.0</ccts:VersionID> 3723 <ccts:Definition>A set of finite-length sequences of binary octets.</ccts:Definition> 3724 <ccts:RepresentationTermName>Binary Object</ccts:RepresentationTermName> 3725 <ccts:PrimitiveType>binary</ccts:PrimitiveType> 3726 </xsd:documentation> 3727 </xsd:annotation> 3728 <xsd:simpleContent> 3729 <xsd:extension base="xsd:base64Binary"> 3730 <xsd:attribute name="format" type="xsd:string" use="optional"> 3731 <xsd:annotation> 3732 <xsd:documentation xml:lang="en"> 3733 <ccts:UniqueID>UNDT000002-SC2</ccts:UniqueID> 3734 <ccts:CategoryCode>SC</ccts:CategoryCode> 3735 <ccts:DictionaryEntryName>Binary Object. Format. Text</ccts:DictionaryEntryName> 3736 <ccts:Definition>The format of the binary content.</ccts:Definition> 3737 <ccts:ObjectClass>Binary Object</ccts:ObjectClass> 3738 <ccts:PropertyTermName>Format</ccts:PropertyTermName> 3739 <ccts:RepresentationTermName>Text</ccts:RepresentationTermName> 3740 <ccts:PrimitiveType>string</ccts:PrimitiveType> 3741 </xsd:documentation> 3742 </xsd:annotation> 3743 </xsd:attribute> 3744 <xsd:attribute name="mimeCode" type="xsd:normalizedString" use="optional"> 3745 <xsd:annotation> 3746 <xsd:documentation xml:lang="en"> 3747 <ccts:UniqueID>UNDT000002-SC3</ccts:UniqueID> 3748 <ccts:CategoryCode>SC</ccts:CategoryCode> 3749 <ccts:DictionaryEntryName>Binary Object. Mime. Code</ccts:DictionaryEntryName> 3750 <ccts:Definition>The mime type of the binary object.</ccts:Definition> 3751 <ccts:ObjectClass>Binary Object</ccts:ObjectClass> 3752 <ccts:PropertyTermName>Mime</ccts:PropertyTermName> 3753 <ccts:RepresentationTermName>Code</ccts:RepresentationTermName> 3754 <ccts:PrimitiveType>string</ccts:PrimitiveType> 3755 </xsd:documentation> 3756 </xsd:annotation> 3757 </xsd:attribute> 3758 <xsd:attribute name="encodingCode" type="xsd:normalizedString" use="optional"> 3759 <xsd:annotation> 3760 <xsd:documentation xml:lang="en"> 3761 <ccts:UniqueID>UNDT000002-SC4</ccts:UniqueID> 3762

<ccts:CategoryCode>SC</ccts:CategoryCode> 3763 <ccts:DictionaryEntryName>Binary Object. Encoding. Code</ccts:DictionaryEntryName> 3764 <ccts:Definition>Specifies the decoding algorithm of the binary object.</ccts:Definition> 3765 <ccts:ObjectClass>Binary Object</ccts:ObjectClass> 3766 <ccts:PropertyTermName>Encoding</ccts:PropertyTermName> 3767 <ccts:RepresentationTermName>Code</ccts:RepresentationTermName> 3768 <ccts:PrimitiveType>string</ccts:PrimitiveType> 3769 </xsd:documentation> 3770 </xsd:annotation> 3771 </xsd:attribute> 3772 <xsd:attribute name="characterSetCode" type="xsd:normalizedString" use="optional"> 3773 <xsd:annotation> 3774 <xsd:documentation xml:lang="en"> 3775 <ccts:UniqueID>UNDT000002-SC5</ccts:UniqueID> 3776 <ccts:CategoryCode>SC</ccts:CategoryCode> 3777 <ccts:DictionaryEntryName>Binary Object. Character Set. Code</ccts:DictionaryEntryName> 3778 <ccts:Definition>The character set of the binary object if the mime type is text.</ccts:Definition> 3779 <ccts:ObjectClass>Binary Object</ccts:ObjectClass> 3780 <ccts:PropertyTermName>Character Set</ccts:PropertyTermName> 3781 <ccts:RepresentationTermName>Code</ccts:RepresentationTermName> 3782 <ccts:PrimitiveType>string</ccts:PrimitiveType> 3783 </xsd:documentation> 3784 </xsd:annotation> 3785 </xsd:attribute> 3786 <xsd:attribute name="uri" type="xsd:anyURI" use="optional"> 3787 <xsd:annotation> 3788 <xsd:documentation xml:lang="en"> 3789 <ccts:UniqueID>UNDT000002-SC6</ccts:UniqueID> 3790 <ccts:CategoryCode>SC</ccts:CategoryCode> 3791 <ccts:DictionaryEntryName>Binary Object. Uniform Resource. 3792 Identifier</ccts:DictionaryEntryName> 3793 <ccts:Definition>The Uniform Resource Identifier that identifies where the binary object is 3794 located.</ccts:Definition> 3795 <ccts:ObjectClass>Binary Object</ccts:ObjectClass> 3796 <ccts:PropertyTermName>Uniform Resource Identifier</ccts:PropertyTermName> 3797 <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> 3798 <ccts:PrimitiveType>string</ccts:PrimitiveType> 3799 </xsd:documentation> 3800 </xsd:annotation> 3801 </xsd:attribute> 3802 <xsd:attribute name="filename" type="xsd:string" use="optional"> 3803 <xsd:annotation> 3804 <xsd:documentation xml:lang="en"> 3805 <ccts:UniqueID>UNDT000002-SC7</ccts:UniqueID> 3806 <ccts:CategoryCode>SC</ccts:CategoryCode> 3807 <ccts:DictionaryEntryName>Binary Object. Filename.Text</ccts:DictionaryEntryName> 3808 <ccts:Definition>The filename of the binary object.</ccts:Definition> 3809 <ccts:ObjectClass>Binary Object</ccts:ObjectClass> 3810 <ccts:PropertyTermName>Filename</ccts:PropertyTermName> 3811 <ccts:RepresentationTermName>Text</ccts:RepresentationTermName> 3812 <ccts:PrimitiveType>string</ccts:PrimitiveType> 3813 </xsd:documentation> 3814 </xsd:annotation> 3815 </xsd:attribute> 3816 </xsd:extension> 3817 </xsd:simpleContent> 3818 </xsd:complexType> 3819  3820  3821 <xsd:complexType name="CodeType"> 3822 <xsd:annotation> 3823 <xsd:documentation xml:lang="en"> 3824 <ccts:UniqueID>UNDT000007</ccts:UniqueID> 3825 <ccts:CategoryCode>CCT</ccts:CategoryCode> 3826 <ccts:DictionaryEntryName>Code. Type</ccts:DictionaryEntryName> 3827 <ccts:VersionID>1.0</ccts:VersionID> 3828 <ccts:Definition>A character string (letters, figures, or symbols) that for brevity and/or languange 3829 independence may be used to represent or replace a definitive value or text of an attribute together with relevant 3830 supplementary information.</ccts:Definition> 3831 <ccts:RepresentationTermName>Code</ccts:RepresentationTermName> 3832 <ccts:PrimitiveType>string</ccts:PrimitiveType> 3833

<ccts:UsageRule>Should not be used if the character string identifies an instance of an object class or an 3834 object in the real world, in which case the Identifier. Type should be used.</ccts:UsageRule> 3835 </xsd:documentation> 3836 </xsd:annotation> 3837 <xsd:simpleContent> 3838 <xsd:extension base="xsd:normalizedString"> 3839 <xsd:attribute name="listID" type="xsd:normalizedString" use="optional"> 3840 <xsd:annotation> 3841 <xsd:documentation xml:lang="en"> 3842 <ccts:UniqueID>UNDT000007-SC2</ccts:UniqueID> 3843 <ccts:CategoryCode>SC</ccts:CategoryCode> 3844 <ccts:DictionaryEntryName>Code List. Identifier</ccts:DictionaryEntryName> 3845 <ccts:Definition>The identification of a list of codes.</ccts:Definition> 3846 <ccts:ObjectClass>Code List</ccts:ObjectClass> 3847 <ccts:PropertyTermName>Identification</ccts:PropertyTermName> 3848 <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> 3849 <ccts:PrimitiveType>string</ccts:PrimitiveType> 3850 </xsd:documentation> 3851 </xsd:annotation> 3852 </xsd:attribute> 3853 <xsd:attribute name="listAgencyID" type="xsd:normalizedString" use="optional"> 3854 <xsd:annotation> 3855 <xsd:documentation xml:lang="en"> 3856 <ccts:UniqueID>UNDT000007-SC3</ccts:UniqueID> 3857 <ccts:CategoryCode>SC</ccts:CategoryCode> 3858 <ccts:DictionaryEntryName>Code List. Agency. Identifier</ccts:DictionaryEntryName> 3859 <ccts:Definition>An agency that maintains one or more lists of codes.</ccts:Definition> 3860 <ccts:ObjectClass>Code List</ccts:ObjectClass> 3861 <ccts:PropertyTermName>Agency</ccts:PropertyTermName> 3862 <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> 3863 <ccts:PrimitiveType>string</ccts:PrimitiveType> 3864 <ccts:UsageRule>Defaults to the UN/EDIFACT data element 3055 code list.</ccts:UsageRule> 3865 </xsd:documentation> 3866 </xsd:annotation> 3867 </xsd:attribute> 3868 <xsd:attribute name="listAgencyName" type="xsd:string" use="optional"> 3869 <xsd:annotation> 3870 <xsd:documentation xml:lang="en"> 3871 <ccts:UniqueID>UNDT000007-SC4</ccts:UniqueID> 3872 <ccts:CategoryCode>SC</ccts:CategoryCode> 3873 <ccts:DictionaryEntryName>Code List. Agency Name. Text</ccts:DictionaryEntryName> 3874 <ccts:Definition>The name of the agency that maintains the list of codes.</ccts:Definition> 3875 <ccts:ObjectClass>Code List</ccts:ObjectClass> 3876 <ccts:PropertyTermName>Agency Name</ccts:PropertyTermName> 3877 <ccts:RepresentationTermName>Text</ccts:RepresentationTermName> 3878 <ccts:PrimitiveType>string</ccts:PrimitiveType> 3879 </xsd:documentation> 3880 </xsd:annotation> 3881 </xsd:attribute> 3882 <xsd:attribute name="listName" type="xsd:string" use="optional"> 3883 <xsd:annotation> 3884 <xsd:documentation xml:lang="en"> 3885 <ccts:UniqueID>UNDT000007-SC5</ccts:UniqueID> 3886 <ccts:CategoryCode>SC</ccts:CategoryCode> 3887 <ccts:DictionaryEntryName>Code List. Name. Text</ccts:DictionaryEntryName> 3888 <ccts:Definition>The name of a list of codes.</ccts:Definition> 3889 <ccts:ObjectClass>Code List</ccts:ObjectClass> 3890 <ccts:PropertyTermName>Name</ccts:PropertyTermName> 3891 <ccts:RepresentationTermName>Text</ccts:RepresentationTermName> 3892 <ccts:PrimitiveType>string</ccts:PrimitiveType> 3893 </xsd:documentation> 3894 </xsd:annotation> 3895 </xsd:attribute> 3896 <xsd:attribute name="listVersionID" type="xsd:normalizedString" use="optional"> 3897 <xsd:annotation> 3898 <xsd:documentation xml:lang="en"> 3899 <ccts:UniqueID>UNDT000007-SC6</ccts:UniqueID> 3900 <ccts:CategoryCode>SC</ccts:CategoryCode> 3901 <ccts:DictionaryEntryName>Code List. Version. Identifier</ccts:DictionaryEntryName> 3902 <ccts:Definition>The version of the list of codes.</ccts:Definition> 3903 <ccts:ObjectClass>Code List</ccts:ObjectClass> 3904


<ccts:PropertyTermName>Version</ccts:PropertyTermName> 3905 <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> 3906 <ccts:PrimitiveType>string</ccts:PrimitiveType> 3907 </xsd:documentation> 3908 </xsd:annotation> 3909 </xsd:attribute> 3910 <xsd:attribute name="name" type="xsd:string" use="optional"> 3911 <xsd:annotation> 3912 <xsd:documentation xml:lang="en"> 3913 <ccts:UniqueID>UNDT000007-SC7</ccts:UniqueID> 3914 <ccts:CategoryCode>SC</ccts:CategoryCode> 3915 <ccts:DictionaryEntryName>Code. Name. Text</ccts:DictionaryEntryName> 3916 <ccts:Definition>The textual equivalent of the code content component.</ccts:Definition> 3917 <ccts:ObjectClass>Code</ccts:ObjectClass> 3918 <ccts:PropertyTermName>Name</ccts:PropertyTermName> 3919 <ccts:RepresentationTermName>Text</ccts:RepresentationTermName> 3920 <ccts:PrimitiveType>string</ccts:PrimitiveType> 3921 </xsd:documentation> 3922 </xsd:annotation> 3923 </xsd:attribute> 3924 <xsd:attribute name="languageID" type="xsd:language" use="optional"> 3925 <xsd:annotation> 3926 <xsd:documentation xml:lang="en"> 3927 <ccts:UniqueID>UNDT000007-SC8</ccts:UniqueID> 3928 <ccts:CategoryCode>SC</ccts:CategoryCode> 3929 <ccts:DictionaryEntryName>Language. Identifier</ccts:DictionaryEntryName> 3930 <ccts:Definition>The identifier of the language used in the code name.</ccts:Definition> 3931 <ccts:ObjectClass>Language</ccts:ObjectClass> 3932 <ccts:PropertyTermName>Identification</ccts:PropertyTermName> 3933 <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> 3934 <ccts:PrimitiveType>string</ccts:PrimitiveType> 3935 </xsd:documentation> 3936 </xsd:annotation> 3937 </xsd:attribute> 3938 <xsd:attribute name="listURI" type="xsd:anyURI" use="optional"> 3939 <xsd:annotation> 3940 <xsd:documentation xml:lang="en"> 3941 <ccts:UniqueID>UNDT000007-SC9</ccts:UniqueID> 3942 <ccts:CategoryCode>SC</ccts:CategoryCode> 3943 <ccts:DictionaryEntryName>Code List. Uniform Resource. 3944 Identifier</ccts:DictionaryEntryName> 3945 <ccts:Definition>The Uniform Resource Identifier that identifies where the code list is 3946 located.</ccts:Definition> 3947 <ccts:ObjectClass>Code List</ccts:ObjectClass> 3948 <ccts:PropertyTermName>Uniform Resource Identifier</ccts:PropertyTermName> 3949 <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> 3950 <ccts:PrimitiveType>string</ccts:PrimitiveType> 3951 </xsd:documentation> 3952 </xsd:annotation> 3953 </xsd:attribute> 3954 <xsd:attribute name="listSchemeURI" type="xsd:anyURI" use="optional"> 3955 <xsd:annotation> 3956 <xsd:documentation xml:lang="en"> 3957 <ccts:UniqueID>UNDT000007-SC10</ccts:UniqueID> 3958 <ccts:CategoryCode>SC</ccts:CategoryCode> 3959 <ccts:DictionaryEntryName>Code List Scheme. Uniform Resource. 3960 Identifier</ccts:DictionaryEntryName> 3961 <ccts:Definition>The Uniform Resource Identifier that identifies where the code list scheme is 3962 located.</ccts:Definition> 3963 <ccts:ObjectClass>Code List Scheme</ccts:ObjectClass> 3964 <ccts:PropertyTermName>Uniform Resource Identifier</ccts:PropertyTermName> 3965 <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> 3966 <ccts:PrimitiveType>string</ccts:PrimitiveType> 3967 </xsd:documentation> 3968 </xsd:annotation> 3969 </xsd:attribute> 3970 </xsd:extension> 3971 </xsd:simpleContent> 3972 </xsd:complexType> 3973  3974  3975

<xsd:complexType name="DateTimeType"> 3976 <xsd:annotation> 3977 <xsd:documentation xml:lang="en"> 3978 <ccts:UniqueID>UNDT000008</ccts:UniqueID> 3979 <ccts:CategoryCode>CCT</ccts:CategoryCode> 3980 <ccts:DictionaryEntryName>Date Time. Type</ccts:DictionaryEntryName> 3981 <ccts:VersionID>1.0</ccts:VersionID> 3982 <ccts:Definition>A particular point in the progression of time together with the relevant supplementary 3983 information.</ccts:Definition> 3984 <ccts:RepresentationTermName>Date Time</ccts:RepresentationTermName> 3985 <ccts:PrimitiveType>string</ccts:PrimitiveType> 3986 <ccts:UsageRule>Can be used for a date and/or time.</ccts:UsageRule> 3987 </xsd:documentation> 3988 </xsd:annotation> 3989 <xsd:simpleContent> 3990 <xsd:extension base="xsd:string"> 3991 <xsd:attribute name="format" type="xsd:string" use="optional"> 3992 <xsd:annotation> 3993 <xsd:documentation xml:lang="en"> 3994 <ccts:UniqueID>UNDT000008-SC1</ccts:UniqueID> 3995 <ccts:CategoryCode>SC</ccts:CategoryCode> 3996 <ccts:DictionaryEntryName>Date Time. Format. Text</ccts:DictionaryEntryName> 3997 <ccts:Definition>The format of the date time content</ccts:Definition> 3998 <ccts:ObjectClass>Date Time</ccts:ObjectClass> 3999 <ccts:PropertyTermName>Format</ccts:PropertyTermName> 4000 <ccts:RepresentationTermName>Text</ccts:RepresentationTermName> 4001 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4002 </xsd:documentation> 4003 </xsd:annotation> 4004 </xsd:attribute> 4005 </xsd:extension> 4006 </xsd:simpleContent> 4007 </xsd:complexType> 4008  4009  4010 <xsd:complexType name="IdentifierType"> 4011 <xsd:annotation> 4012 <xsd:documentation xml:lang="en"> 4013 <ccts:UniqueID>UNDT000011</ccts:UniqueID> 4014 <ccts:CategoryCode>CCT</ccts:CategoryCode> 4015 <ccts:DictionaryEntryName>Identifier. Type</ccts:DictionaryEntryName> 4016 <ccts:VersionID>1.0</ccts:VersionID> 4017 <ccts:Definition>A character string to identify and distinguish uniquely, one instance of an object in an 4018 identification scheme from all other objects in the same scheme together with relevant supplementary 4019 information.</ccts:Definition> 4020 <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> 4021 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4022 </xsd:documentation> 4023 </xsd:annotation> 4024 <xsd:simpleContent> 4025 <xsd:extension base="xsd:normalizedString"> 4026 <xsd:attribute name="schemeID" type="xsd:normalizedString" use="optional"> 4027 <xsd:annotation> 4028 <xsd:documentation xml:lang="en"> 4029 <ccts:UniqueID>UNDT000011-SC2</ccts:UniqueID> 4030 <ccts:CategoryCode>SC</ccts:CategoryCode> 4031 <ccts:DictionaryEntryName>Identification Scheme. Identifier</ccts:DictionaryEntryName> 4032 <ccts:Definition>The identification of the identification scheme.</ccts:Definition> 4033 <ccts:ObjectClass>Identification Scheme</ccts:ObjectClass> 4034 <ccts:PropertyTermName>Identification</ccts:PropertyTermName> 4035 <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> 4036 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4037 </xsd:documentation> 4038 </xsd:annotation> 4039 </xsd:attribute> 4040 <xsd:attribute name="schemeName" type="xsd:string" use="optional"> 4041 <xsd:annotation> 4042 <xsd:documentation xml:lang="en"> 4043 <ccts:UniqueID>UNDT000011-SC3</ccts:UniqueID> 4044 <ccts:CategoryCode>SC</ccts:CategoryCode> 4045 <ccts:DictionaryEntryName>Identification Scheme. Name. Text</ccts:DictionaryEntryName> 4046

<ccts:Definition>The name of the identification scheme.</ccts:Definition> 4047 <ccts:ObjectClass>Identification Scheme</ccts:ObjectClass> 4048 <ccts:PropertyTermName>Name</ccts:PropertyTermName> 4049 <ccts:RepresentationTermName>Text</ccts:RepresentationTermName> 4050 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4051 </xsd:documentation> 4052 </xsd:annotation> 4053 </xsd:attribute> 4054 <xsd:attribute name="schemeAgencyID" type="xsd:normalizedString" use="optional"> 4055 <xsd:annotation> 4056 <xsd:documentation xml:lang="en"> 4057 <ccts:UniqueID>UNDT000011-SC4</ccts:UniqueID> 4058 <ccts:CategoryCode>SC</ccts:CategoryCode> 4059 <ccts:DictionaryEntryName>Identification Scheme Agency. 4060 Identifier</ccts:DictionaryEntryName> 4061 <ccts:Definition>The identification of the agency that maintains the identification 4062 scheme.</ccts:Definition> 4063 <ccts:ObjectClass>Identification Scheme Agency</ccts:ObjectClass> 4064 <ccts:PropertyTermName>Identification</ccts:PropertyTermName> 4065 <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> 4066 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4067 <ccts:UsageRule>Defaults to the UN/EDIFACT data element 3055 code list.</ccts:UsageRule> 4068 </xsd:documentation> 4069 </xsd:annotation> 4070 </xsd:attribute> 4071 <xsd:attribute name="schemeAgencyName" type="xsd:string" use="optional"> 4072 <xsd:annotation> 4073 <xsd:documentation xml:lang="en"> 4074 <ccts:UniqueID>UNDT000011-SC5</ccts:UniqueID> 4075 <ccts:CategoryCode>SC</ccts:CategoryCode> 4076 <ccts:DictionaryEntryName>Identification Scheme Agency. Name. 4077 Text</ccts:DictionaryEntryName> 4078 <ccts:Definition>The name of the agency that maintains the identification 4079 scheme.</ccts:Definition> 4080 <ccts:ObjectClass>Identification Scheme Agency</ccts:ObjectClass> 4081 <ccts:PropertyTermName>Agency Name</ccts:PropertyTermName> 4082 <ccts:RepresentationTermName>Text</ccts:RepresentationTermName> 4083 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4084 </xsd:documentation> 4085 </xsd:annotation> 4086 </xsd:attribute> 4087 <xsd:attribute name="schemeVersionID" type="xsd:normalizedString" use="optional"> 4088 <xsd:annotation> 4089 <xsd:documentation xml:lang="en"> 4090 <ccts:UniqueID>UNDT000011-SC6</ccts:UniqueID> 4091 <ccts:CategoryCode>SC</ccts:CategoryCode> 4092 <ccts:DictionaryEntryName>Identification Scheme. Version. 4093 Identifier</ccts:DictionaryEntryName> 4094 <ccts:Definition>The version of the identification scheme.</ccts:Definition> 4095 <ccts:ObjectClass>Identification Scheme</ccts:ObjectClass> 4096 <ccts:PropertyTermName>Version</ccts:PropertyTermName> 4097 <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> 4098 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4099 </xsd:documentation> 4100 </xsd:annotation> 4101 </xsd:attribute> 4102 <xsd:attribute name="schemeDataURI" type="xsd:anyURI" use="optional"> 4103 <xsd:annotation> 4104 <xsd:documentation xml:lang="en"> 4105 <ccts:UniqueID>UNDT000011-SC7</ccts:UniqueID> 4106 <ccts:CategoryCode>SC</ccts:CategoryCode> 4107 <ccts:DictionaryEntryName>Identification Scheme Data. Uniform Resource. 4108 Identifier</ccts:DictionaryEntryName> 4109 <ccts:Definition>The Uniform Resource Identifier that identifies where the identification scheme 4110 data is located.</ccts:Definition> 4111 <ccts:ObjectClass>Identification Scheme Data</ccts:ObjectClass> 4112 <ccts:PropertyTermName>Uniform Resource Identifier</ccts:PropertyTermName> 4113 <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> 4114 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4115 </xsd:documentation> 4116 </xsd:annotation> 4117


</xsd:attribute> 4118 <xsd:attribute name="schemeURI" type="xsd:anyURI" use="optional"> 4119 <xsd:annotation> 4120 <xsd:documentation xml:lang="en"> 4121 <ccts:UniqueID>UNDT000011-SC8</ccts:UniqueID> 4122 <ccts:CategoryCode>SC</ccts:CategoryCode> 4123 <ccts:DictionaryEntryName>Identification Scheme. Uniform Resource. 4124 Identifier</ccts:DictionaryEntryName> 4125 <ccts:Definition>The Uniform Resource Identifier that identifies where the identification scheme 4126 is located.</ccts:Definition> 4127 <ccts:ObjectClass>Identification Scheme</ccts:ObjectClass> 4128 <ccts:PropertyTermName>Uniform Resource Identifier</ccts:PropertyTermName> 4129 <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> 4130 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4131 </xsd:documentation> 4132 </xsd:annotation> 4133 </xsd:attribute> 4134 </xsd:extension> 4135 </xsd:simpleContent> 4136 </xsd:complexType> 4137  4138  4139 <xsd:complexType name="IndicatorType"> 4140 <xsd:annotation> 4141 <xsd:documentation xml:lang="en"> 4142 <ccts:UniqueID>UNDT000012</ccts:UniqueID> 4143 <ccts:CategoryCode>CCT</ccts:CategoryCode> 4144 <ccts:DictionaryEntryName>Indicator. Type</ccts:DictionaryEntryName> 4145 <ccts:VersionID>1.0</ccts:VersionID> 4146 <ccts:Definition>A list of two mutually exclusive Boolean values that express the only possible states of a 4147 Property.</ccts:Definition> 4148 <ccts:RepresentationTermName>Indicator</ccts:RepresentationTermName> 4149 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4150 </xsd:documentation> 4151 </xsd:annotation> 4152 <xsd:simpleContent> 4153 <xsd:extension base="xsd:string"> 4154 <xsd:attribute name="format" type="xsd:string" use="optional"> 4155 <xsd:annotation> 4156 <xsd:documentation xml:lang="en"> 4157 <ccts:UniqueID>UNDT000012-SC2</ccts:UniqueID> 4158 <ccts:CategoryCode>SC</ccts:CategoryCode> 4159 <ccts:DictionaryEntryName>Indicator. Format. Text</ccts:DictionaryEntryName> 4160 <ccts:Definition>Whether the indicator is numeric, textual or binary.</ccts:Definition> 4161 <ccts:ObjectClass>Indicator</ccts:ObjectClass> 4162 <ccts:PropertyTermName>Format</ccts:PropertyTermName> 4163 <ccts:RepresentationTermName>Text</ccts:RepresentationTermName> 4164 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4165 </xsd:documentation> 4166 </xsd:annotation> 4167 </xsd:attribute> 4168 </xsd:extension> 4169 </xsd:simpleContent> 4170 </xsd:complexType> 4171  4172  4173 <xsd:complexType name="MeasureType"> 4174 <xsd:annotation> 4175 <xsd:documentation xml:lang="en"> 4176 <ccts:UniqueID>UNDT000013</ccts:UniqueID> 4177 <ccts:CategoryCode>CCT</ccts:CategoryCode> 4178 <ccts:DictionaryEntryName>Measure. Type</ccts:DictionaryEntryName> 4179 <ccts:VersionID>1.0</ccts:VersionID> 4180 <ccts:Definition>A numeric value determined by measuring an object along with the specified unit of 4181 measure.</ccts:Definition> 4182 <ccts:RepresentationTermName>Measure</ccts:RepresentationTermName> 4183 <ccts:PrimitiveType>decimal</ccts:PrimitiveType> 4184 </xsd:documentation> 4185 </xsd:annotation> 4186 <xsd:simpleContent> 4187 <xsd:extension base="xsd:decimal"> 4188

<xsd:attribute name="unitCode" type="xsd:normalizedString" use="optional"> 4189 <xsd:annotation> 4190 <xsd:documentation xml:lang="en"> 4191 <ccts:UniqueID>UNDT000013-SC2</ccts:UniqueID> 4192 <ccts:CategoryCode>SC</ccts:CategoryCode> 4193 <ccts:DictionaryEntryName>Measure Unit. Code</ccts:DictionaryEntryName> 4194 <ccts:Definition>The type of unit of measure.</ccts:Definition> 4195 <ccts:ObjectClass>Measure Unit</ccts:ObjectClass> 4196 <ccts:PropertyTermName>Code</ccts:PropertyTermName> 4197 <ccts:RepresentationTermName>Code</ccts:RepresentationTermName> 4198 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4199 <ccts:UsageRule>Reference UNECE Rec. 20 and X12 355</ccts:UsageRule> 4200 </xsd:documentation> 4201 </xsd:annotation> 4202 </xsd:attribute> 4203 <xsd:attribute name="unitCodeListVersionID" type="xsd:normalizedString" use="optional"> 4204 <xsd:annotation> 4205 <xsd:documentation xml:lang="en"> 4206 <ccts:UniqueID>UNDT000013-SC3</ccts:UniqueID> 4207 <ccts:CategoryCode>SC</ccts:CategoryCode> 4208 <ccts:DictionaryEntryName>Measure Unit. Code List Version. 4209 Identifier</ccts:DictionaryEntryName> 4210 <ccts:Definition>The version of the measure unit code list.</ccts:Definition> 4211 <ccts:ObjectClass>Measure Unit</ccts:ObjectClass> 4212 <ccts:PropertyTermName>Code List Version</ccts:PropertyTermName> 4213 <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> 4214 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4215 </xsd:documentation> 4216 </xsd:annotation> 4217 </xsd:attribute> 4218 </xsd:extension> 4219 </xsd:simpleContent> 4220 </xsd:complexType> 4221  4222  4223 <xsd:complexType name="NumericType"> 4224 <xsd:annotation> 4225 <xsd:documentation xml:lang="en"> 4226 <ccts:UniqueID>UNDT000014</ccts:UniqueID> 4227 <ccts:CategoryCode>CCT</ccts:CategoryCode> 4228 <ccts:DictionaryEntryName>Numeric. Type</ccts:DictionaryEntryName> 4229 <ccts:VersionID>1.0</ccts:VersionID> 4230 <ccts:Definition>Numeric information that is assigned or is determined by calculation, counting, or 4231 sequencing. It does not require a unit of quantity or unit of measure.</ccts:Definition> 4232 <ccts:RepresentationTermName>Numeric</ccts:RepresentationTermName> 4233 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4234 </xsd:documentation> 4235 </xsd:annotation> 4236 <xsd:simpleContent> 4237 <xsd:extension base="xsd:decimal"> 4238 <xsd:attribute name="format" type="xsd:string" use="optional"> 4239 <xsd:annotation> 4240 <xsd:documentation xml:lang="en"> 4241 <ccts:UniqueID>UNDT000014-SC2</ccts:UniqueID> 4242 <ccts:CategoryCode>SC</ccts:CategoryCode> 4243 <ccts:DictionaryEntryName>Numeric. Format. Text</ccts:DictionaryEntryName> 4244 <ccts:Definition>Whether the number is an integer, decimal, real number or 4245 percentage.</ccts:Definition> 4246 <ccts:ObjectClass>Numeric</ccts:ObjectClass> 4247 <ccts:PropertyTermName>Format</ccts:PropertyTermName> 4248 <ccts:RepresentationTermName>Text</ccts:RepresentationTermName> 4249 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4250 </xsd:documentation> 4251 </xsd:annotation> 4252 </xsd:attribute> 4253 </xsd:extension> 4254 </xsd:simpleContent> 4255 </xsd:complexType> 4256  4257  4258 <xsd:complexType name="QuantityType"> 4259

<xsd:annotation> 4260 <xsd:documentation xml:lang="en"> 4261 <ccts:UniqueID>UNDT000018</ccts:UniqueID> 4262 <ccts:CategoryCode>CCT</ccts:CategoryCode> 4263 <ccts:DictionaryEntryName>Quantity. Type</ccts:DictionaryEntryName> 4264 <ccts:VersionID>1.0</ccts:VersionID> 4265 <ccts:Definition>A counted number of non-monetary units possibly including fractions.</ccts:Definition> 4266 <ccts:RepresentationTermName>Quantity</ccts:RepresentationTermName> 4267 <ccts:PrimitiveType>decimal</ccts:PrimitiveType> 4268 </xsd:documentation> 4269 </xsd:annotation> 4270 <xsd:simpleContent> 4271 <xsd:extension base="xsd:decimal"> 4272 <xsd:attribute name="unitCode" type="xsd:normalizedString" use="optional"> 4273 <xsd:annotation> 4274 <xsd:documentation xml:lang="en"> 4275 <ccts:UniqueID>UNDT000018-SC2</ccts:UniqueID> 4276 <ccts:CategoryCode>SC</ccts:CategoryCode> 4277 <ccts:DictionaryEntryName>Quantity. Unit. Code</ccts:DictionaryEntryName> 4278 <ccts:Definition>The unit of the quantity</ccts:Definition> 4279 <ccts:ObjectClass>Quantity</ccts:ObjectClass> 4280 <ccts:PropertyTermName>Unit Code</ccts:PropertyTermName> 4281 <ccts:RepresentationTermName>Code</ccts:RepresentationTermName> 4282 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4283 </xsd:documentation> 4284 </xsd:annotation> 4285 </xsd:attribute> 4286 <xsd:attribute name="unitCodeListID" type="xsd:normalizedString" use="optional"> 4287 <xsd:annotation> 4288 <xsd:documentation xml:lang="en"> 4289 <ccts:UniqueID>UNDT000018-SC3</ccts:UniqueID> 4290 <ccts:CategoryCode>SC</ccts:CategoryCode> 4291 <ccts:DictionaryEntryName>Quantity Unit. Code List. Identifier</ccts:DictionaryEntryName> 4292 <ccts:Definition>The quantity unit code list.</ccts:Definition> 4293 <ccts:ObjectClass>Quantity Unit</ccts:ObjectClass> 4294 <ccts:PropertyTermName>Code List</ccts:PropertyTermName> 4295 <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> 4296 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4297 </xsd:documentation> 4298 </xsd:annotation> 4299 </xsd:attribute> 4300 <xsd:attribute name="unitCodeListAgencyID" type="xsd:normalizedString" use="optional"> 4301 <xsd:annotation> 4302 <xsd:documentation xml:lang="en"> 4303 <ccts:UniqueID>UNDT000018-SC4</ccts:UniqueID> 4304 <ccts:CategoryCode>SC</ccts:CategoryCode> 4305 <ccts:DictionaryEntryName>Quantity Unit. Code List Agency. 4306 Identifier</ccts:DictionaryEntryName> 4307 <ccts:Definition>The identification of the agency that maintains the quantity unit code 4308 list</ccts:Definition> 4309 <ccts:ObjectClass>Quantity Unit</ccts:ObjectClass> 4310 <ccts:PropertyTermName>Code List Agency</ccts:PropertyTermName> 4311 <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> 4312 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4313 <ccts:UsageRule>Defaults to the UN/EDIFACT data element 3055 code list.</ccts:UsageRule> 4314 </xsd:documentation> 4315 </xsd:annotation> 4316 </xsd:attribute> 4317 <xsd:attribute name="unitCodeListAgencyName" type="xsd:string" use="optional"> 4318 <xsd:annotation> 4319 <xsd:documentation xml:lang="en"> 4320 <ccts:UniqueID>UNDT000018-SC5</ccts:UniqueID> 4321 <ccts:CategoryCode>SC</ccts:CategoryCode> 4322 <ccts:DictionaryEntryName>Quantity Unit. Code List Agency Name. 4323 Text</ccts:DictionaryEntryName> 4324 <ccts:Definition>The name of the agency which maintains the quantity unit code 4325 list.</ccts:Definition> 4326 <ccts:ObjectClass>Quantity Unit</ccts:ObjectClass> 4327 <ccts:PropertyTermName>Code List Agency Name</ccts:PropertyTermName> 4328 <ccts:RepresentationTermName>Text</ccts:RepresentationTermName> 4329 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4330


</xsd:documentation> 4331 </xsd:annotation> 4332 </xsd:attribute> 4333 </xsd:extension> 4334 </xsd:simpleContent> 4335 </xsd:complexType> 4336  4337  4338 <xsd:complexType name="TextType"> 4339 <xsd:annotation> 4340 <xsd:documentation xml:lang="en"> 4341 <ccts:UniqueID>UNDT000019</ccts:UniqueID> 4342 <ccts:CategoryCode>CCT</ccts:CategoryCode> 4343 <ccts:DictionaryEntryName>Text. Type</ccts:DictionaryEntryName> 4344 <ccts:VersionID>1.0</ccts:VersionID> 4345 <ccts:Definition>A character string (i.e. a finite set of characters) generally in the form of words of a 4346 language.</ccts:Definition> 4347 <ccts:RepresentationTermName>Text</ccts:RepresentationTermName> 4348 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4349 </xsd:documentation> 4350 </xsd:annotation> 4351 <xsd:simpleContent> 4352 <xsd:extension base="xsd:string"> 4353 <xsd:attribute name="languageID" type="xsd:language" use="optional"> 4354 <xsd:annotation> 4355 <xsd:documentation xml:lang="en"> 4356 <ccts:UniqueID>UNDT000019-SC2</ccts:UniqueID> 4357 <ccts:CategoryCode>SC</ccts:CategoryCode> 4358 <ccts:DictionaryEntryName>Language. Identifier</ccts:DictionaryEntryName> 4359 <ccts:Definition>The identifier of the language used in the content component.</ccts:Definition> 4360 <ccts:ObjectClass>Language</ccts:ObjectClass> 4361 <ccts:PropertyTermName>Identification</ccts:PropertyTermName> 4362 <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> 4363 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4364 </xsd:documentation> 4365 </xsd:annotation> 4366 </xsd:attribute> 4367 <xsd:attribute name="languageLocaleID" type="xsd:normalizedString" use="optional"> 4368 <xsd:annotation> 4369 <xsd:documentation xml:lang="en"> 4370 <ccts:UniqueID>UNDT000019-SC3</ccts:UniqueID> 4371 <ccts:CategoryCode>SC</ccts:CategoryCode> 4372 <ccts:DictionaryEntryName> Language. Locale. Identifier</ccts:DictionaryEntryName> 4373 <ccts:Definition>The identification of the locale of the language.</ccts:Definition> 4374 <ccts:ObjectClass>Language</ccts:ObjectClass> 4375 <ccts:PropertyTermName>Locale</ccts:PropertyTermName> 4376 <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> 4377 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4378 </xsd:documentation> 4379 </xsd:annotation> 4380 </xsd:attribute> 4381 </xsd:extension> 4382 </xsd:simpleContent> 4383 </xsd:complexType> 4384 </xsd:schema> 4385

Appendix E. Unqualified Data Type Schema Module 4386

<?xml version="1.0" encoding="UTF-8"?> 4387  4388  4389  4390  4419 <xsd:schema targetNamespace="urn:un:unece:uncefact:data:draft:UnqualifiedDataTypesSchemaModule:1.0" 4420 xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:clm5639="urn:un:unece:uncefact:codelist:draft:5639:1988" 4421 xmlns:clm54217="urn:un:unece:uncefact:codelist:draft:54217:2001" 4422 xmlns:clmIANAMIMEMediaTypes="urn:un:unece:uncefact:codelist:draft:IANAMIMEMediaTypes:2003" 4423 xmlns:clm66411="urn:un:unece:uncefact:codelist:draft:66411:2001" 4424 xmlns:udt="urn:un:unece:uncefact:data:draft:UnqualifiedDataTypesSchemaModule:1.0" elementFormDefault="qualified" 4425 attributeFormDefault="unqualified"> 4426  4427  4428  4429  4430 <xsd:import namespace="urn:un:unece:uncefact:codelist:draft:66411:2001" 4431 schemaLocation="CodeList_UnitCode_UNECE_7_04.xsd"/> 4432 <xsd:import namespace="urn:un:unece:uncefact:codelist:draft:IANAMIMEMediaTypes:2003" 4433 schemaLocation="CodeList_MIMEMediaTypeCode_IANA_7_04.xsd"/> 4434 <xsd:import namespace="urn:un:unece:uncefact:codelist:draft:54217:2001" 4435 schemaLocation="CodeList_CurrencyCode_ISO_7_04.xsd"/> 4436 <xsd:import namespace="urn:un:unece:uncefact:codelist:draft:5639:1988" 4437 schemaLocation="CodeList_LanguageCode_ISO_7_04.xsd"/> 4438  4439  4440  4441  4442 <xsd:complexType name="AmountType"> 4443 <xsd:annotation> 4444 <xsd:documentation xml:lang="en"> 4445 <ccts:UniqueID>UDT000001</ccts:UniqueID> 4446 <ccts:CategoryCode>UDT</ccts:CategoryCode> 4447 <ccts:DictionaryEntryName>Amount. Type</ccts:DictionaryEntryName> 4448 <ccts:VersionID>1.0</ccts:VersionID> 4449 <ccts:Definition>A number of monetary units specified in a currency where the unit of the currency is explicit 4450 or implied.</ccts:Definition> 4451 <ccts:RepresentationTermName>Amount</ccts:RepresentationTermName> 4452

<ccts:PrimitiveType>decimal</ccts:PrimitiveType> 4453 <xsd:BuiltinType>decimal</xsd:BuiltinType> 4454 </xsd:documentation> 4455 </xsd:annotation> 4456 <xsd:simpleContent> 4457 <xsd:extension base="xsd:decimal"> 4458 <xsd:attribute name="currencyID" type="clm54217:CurrencyCodeContentType" use="required"> 4459 <xsd:annotation> 4460 <xsd:documentation xml:lang="en"> 4461 <ccts:UniqueID>UDT000001-SC2</ccts:UniqueID> 4462 <ccts:CategoryCode>SC</ccts:CategoryCode> 4463 <ccts:DictionaryEntryName>Amount Currency. Identifier</ccts:DictionaryEntryName> 4464 <ccts:Definition>The currency of the amount.</ccts:Definition> 4465 <ccts:ObjectClass>Amount Currency</ccts:ObjectClass> 4466 <ccts:PropertyTermName>Identification</ccts:PropertyTermName> 4467 <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> 4468 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4469 <xsd:BuiltinType>normalisedString</xsd:BuiltinType> 4470 </xsd:documentation> 4471 </xsd:annotation> 4472 </xsd:attribute> 4473 </xsd:extension> 4474 </xsd:simpleContent> 4475 </xsd:complexType> 4476  4477  4478 <xsd:complexType name="BinaryObjectType"> 4479 <xsd:annotation> 4480 <xsd:documentation xml:lang="en"> 4481 <ccts:UniqueID>UDT000002</ccts:UniqueID> 4482 <ccts:CategoryCode>UDT</ccts:CategoryCode> 4483 <ccts:DictionaryEntryName>Binary Object. Type</ccts:DictionaryEntryName> 4484 <ccts:VersionID>1.0</ccts:VersionID> 4485 <ccts:Definition>A set of finite-length sequences of binary octets.</ccts:Definition> 4486 <ccts:RepresentationTermName>Binary Object</ccts:RepresentationTermName> 4487 <ccts:PrimitiveType>binary</ccts:PrimitiveType> 4488 <xsd:BuiltinType>base64Binary</xsd:BuiltinType> 4489 </xsd:documentation> 4490 </xsd:annotation> 4491 <xsd:simpleContent> 4492 <xsd:extension base="xsd:base64Binary"> 4493 <xsd:attribute name="format" type="xsd:string" use="optional"> 4494 <xsd:annotation> 4495 <xsd:documentation xml:lang="en"> 4496 <ccts:UniqueID>UDT000002-SC2</ccts:UniqueID> 4497 <ccts:CategoryCode>SC</ccts:CategoryCode> 4498 <ccts:DictionaryEntryName>Binary Object. Format. Text</ccts:DictionaryEntryName> 4499 <ccts:Definition>The format of the binary content.</ccts:Definition> 4500 <ccts:ObjectClass>Binary Object</ccts:ObjectClass> 4501 <ccts:PropertyTermName>Format</ccts:PropertyTermName> 4502 <ccts:RepresentationTermName>Text</ccts:RepresentationTermName> 4503 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4504 <xsd:BuiltinType>string</xsd:BuiltinType> 4505 </xsd:documentation> 4506 </xsd:annotation> 4507 </xsd:attribute> 4508 <xsd:attribute name="mimeCode" type="clmIANAMIMEMediaTypes:BinaryObjectMimeCodeContentType" 4509 use="required"> 4510 <xsd:annotation> 4511 <xsd:documentation xml:lang="en"> 4512 <ccts:UniqueID>UDT000002-SC3</ccts:UniqueID> 4513 <ccts:CategoryCode>SC</ccts:CategoryCode> 4514 <ccts:DictionaryEntryName>Binary Object. Mime. Code</ccts:DictionaryEntryName> 4515 <ccts:Definition>The mime type of the binary object.</ccts:Definition> 4516 <ccts:ObjectClass>Binary Object</ccts:ObjectClass> 4517 <ccts:PropertyTermName>Mime</ccts:PropertyTermName> 4518 <ccts:RepresentationTermName>Code</ccts:RepresentationTermName> 4519 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4520 <xsd:BuiltinType>normalizedString</xsd:BuiltinType> 4521 </xsd:documentation> 4522 </xsd:annotation> 4523

</xsd:attribute> 4524 <xsd:attribute name="encodingCode" type="xsd:normalizedString" use="optional"> 4525 <xsd:annotation> 4526 <xsd:documentation xml:lang="en"> 4527 <ccts:UniqueID>UDT000002-SC4</ccts:UniqueID> 4528 <ccts:CategoryCode>SC</ccts:CategoryCode> 4529 <ccts:DictionaryEntryName>Binary Object. Encoding. Code</ccts:DictionaryEntryName> 4530 <ccts:Definition>Specifies the decoding algorithm of the binary object.</ccts:Definition> 4531 <ccts:ObjectClass>Binary Object</ccts:ObjectClass> 4532 <ccts:PropertyTermName>Encoding</ccts:PropertyTermName> 4533 <ccts:RepresentationTermName>Code</ccts:RepresentationTermName> 4534 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4535 <xsd:BuiltinType>normalizedString</xsd:BuiltinType> 4536 </xsd:documentation> 4537 </xsd:annotation> 4538 </xsd:attribute> 4539 <xsd:attribute name="characterSetCode" type="xsd:normalizedString" use="optional"> 4540 <xsd:annotation> 4541 <xsd:documentation xml:lang="en"> 4542 <ccts:UniqueID>UDT000002-SC5</ccts:UniqueID> 4543 <ccts:CategoryCode>SC</ccts:CategoryCode> 4544 <ccts:DictionaryEntryName>Binary Object. Character Set. Code</ccts:DictionaryEntryName> 4545 <ccts:Definition>The character set of the binary object if the mime type is text.</ccts:Definition> 4546 <ccts:ObjectClass>Binary Object</ccts:ObjectClass> 4547 <ccts:PropertyTermName>Character Set</ccts:PropertyTermName> 4548 <ccts:RepresentationTermName>Code</ccts:RepresentationTermName> 4549 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4550 <xsd:BuiltinType>normalizedString</xsd:BuiltinType> 4551 </xsd:documentation> 4552 </xsd:annotation> 4553 </xsd:attribute> 4554 <xsd:attribute name="uri" type="xsd:anyURI" use="optional"> 4555 <xsd:annotation> 4556 <xsd:documentation xml:lang="en"> 4557 <ccts:UniqueID>UDT000002-SC6</ccts:UniqueID> 4558 <ccts:CategoryCode>SC</ccts:CategoryCode> 4559 <ccts:DictionaryEntryName>Binary Object. Uniform Resource. 4560 Identifier</ccts:DictionaryEntryName> 4561 <ccts:Definition>The Uniform Resource Identifier that identifies where the binary object is 4562 located.</ccts:Definition> 4563 <ccts:ObjectClass>Binary Object</ccts:ObjectClass> 4564 <ccts:PropertyTermName>Uniform Resource Identifier</ccts:PropertyTermName> 4565 <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> 4566 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4567 <xsd:BuiltinType>anyURI</xsd:BuiltinType> 4568 </xsd:documentation> 4569 </xsd:annotation> 4570 </xsd:attribute> 4571 <xsd:attribute name="filename" type="xsd:string" use="optional"> 4572 <xsd:annotation> 4573 <xsd:documentation xml:lang="en"> 4574 <ccts:UniqueID>UDT000002-SC7</ccts:UniqueID> 4575 <ccts:CategoryCode>SC</ccts:CategoryCode> 4576 <ccts:DictionaryEntryName>Binary Object. Filename.Text</ccts:DictionaryEntryName> 4577 <ccts:Definition>The filename of the binary object.</ccts:Definition> 4578 <ccts:ObjectClass>Binary Object</ccts:ObjectClass> 4579 <ccts:PropertyTermName>Filename</ccts:PropertyTermName> 4580 <ccts:RepresentationTermName>Text</ccts:RepresentationTermName> 4581 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4582 <xsd:BuiltinType>string</xsd:BuiltinType> 4583 </xsd:documentation> 4584 </xsd:annotation> 4585 </xsd:attribute> 4586 </xsd:extension> 4587 </xsd:simpleContent> 4588 </xsd:complexType> 4589  4590  4591 <xsd:complexType name="GraphicType"> 4592 <xsd:annotation> 4593 <xsd:documentation xml:lang="en"> 4594

<ccts:UniqueID>UDT000003</ccts:UniqueID> 4595 <ccts:CategoryCode>UDT</ccts:CategoryCode> 4596 <ccts:DictionaryEntryName>Graphic. Type</ccts:DictionaryEntryName> 4597 <ccts:VersionID>1.0</ccts:VersionID> 4598 <ccts:Definition>A diagram, graph, mathematical curves, or similar representation.</ccts:Definition> 4599 <ccts:RepresentationTermName>Graphic</ccts:RepresentationTermName> 4600 <ccts:PrimitiveType>binary</ccts:PrimitiveType> 4601 <xsd:BuiltinType>base64Binary</xsd:BuiltinType> 4602 </xsd:documentation> 4603 </xsd:annotation> 4604 <xsd:simpleContent> 4605 <xsd:extension base="xsd:base64Binary"> 4606 <xsd:attribute name="format" type="xsd:string" use="optional"> 4607 <xsd:annotation> 4608 <xsd:documentation xml:lang="en"> 4609 <ccts:UniqueID>UDT000003-SC2</ccts:UniqueID> 4610 <ccts:CategoryCode>SC</ccts:CategoryCode> 4611 <ccts:DictionaryEntryName>Graphic. Format. Text</ccts:DictionaryEntryName> 4612 <ccts:Definition>The format of the graphic content.</ccts:Definition> 4613 <ccts:ObjectClass>Graphic</ccts:ObjectClass> 4614 <ccts:PropertyTermName>Format</ccts:PropertyTermName> 4615 <ccts:RepresentationTermName>Text</ccts:RepresentationTermName> 4616 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4617 <xsd:BuiltinType>string</xsd:BuiltinType> 4618 </xsd:documentation> 4619 </xsd:annotation> 4620 </xsd:attribute> 4621 <xsd:attribute name="mimeCode" type="clmIANAMIMEMediaTypes:BinaryObjectMimeCodeContentType" 4622 use="required"> 4623 <xsd:annotation> 4624 <xsd:documentation xml:lang="en"> 4625 <ccts:UniqueID>UDT000003-SC3</ccts:UniqueID> 4626 <ccts:CategoryCode>SC</ccts:CategoryCode> 4627 <ccts:DictionaryEntryName>Graphic. Mime. Code</ccts:DictionaryEntryName> 4628 <ccts:Definition>The mime type of the graphic object.</ccts:Definition> 4629 <ccts:ObjectClass>Graphic</ccts:ObjectClass> 4630 <ccts:PropertyTermName>Mime</ccts:PropertyTermName> 4631 <ccts:RepresentationTermName>Code</ccts:RepresentationTermName> 4632 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4633 <xsd:BuiltinType>normalizedString</xsd:BuiltinType> 4634 </xsd:documentation> 4635 </xsd:annotation> 4636 </xsd:attribute> 4637 <xsd:attribute name="encodingCode" type="xsd:normalizedString" use="optional"> 4638 <xsd:annotation> 4639 <xsd:documentation xml:lang="en"> 4640 <ccts:UniqueID>UDT000003-SC4</ccts:UniqueID> 4641 <ccts:CategoryCode>SC</ccts:CategoryCode> 4642 <ccts:DictionaryEntryName>Graphic. Encoding. Code</ccts:DictionaryEntryName> 4643 <ccts:Definition>Specifies the decoding algorithm of the graphic object.</ccts:Definition> 4644 <ccts:ObjectClass>Graphic</ccts:ObjectClass> 4645 <ccts:PropertyTermName>Encoding</ccts:PropertyTermName> 4646 <ccts:RepresentationTermName>Code</ccts:RepresentationTermName> 4647 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4648 <xsd:BuiltinType>normalizedString</xsd:BuiltinType> 4649 </xsd:documentation> 4650 </xsd:annotation> 4651 </xsd:attribute> 4652 <xsd:attribute name="uri" type="xsd:anyURI" use="optional"> 4653 <xsd:annotation> 4654 <xsd:documentation xml:lang="en"> 4655 <ccts:UniqueID>UDT000003-SC6</ccts:UniqueID> 4656 <ccts:CategoryCode>SC</ccts:CategoryCode> 4657 <ccts:DictionaryEntryName>Graphic. Uniform Resource. Identifier</ccts:DictionaryEntryName> 4658 <ccts:Definition>The Uniform Resource Identifier that identifies where the graphic object is 4659 located.</ccts:Definition> 4660 <ccts:ObjectClass>Graphic</ccts:ObjectClass> 4661 <ccts:PropertyTermName>Uniform Resource Identifier</ccts:PropertyTermName> 4662 <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> 4663 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4664 <xsd:BuiltinType>anyURI</xsd:BuiltinType> 4665


</xsd:documentation> 4666 </xsd:annotation> 4667 </xsd:attribute> 4668 <xsd:attribute name="filename" type="xsd:string" use="optional"> 4669 <xsd:annotation> 4670 <xsd:documentation xml:lang="en"> 4671 <ccts:UniqueID>UDT000003-SC7</ccts:UniqueID> 4672 <ccts:CategoryCode>SC</ccts:CategoryCode> 4673 <ccts:DictionaryEntryName>Graphic. Filename.Text</ccts:DictionaryEntryName> 4674 <ccts:Definition>The filename of the graphic object.</ccts:Definition> 4675 <ccts:ObjectClass>Graphic</ccts:ObjectClass> 4676 <ccts:PropertyTermName>Filename</ccts:PropertyTermName> 4677 <ccts:RepresentationTermName>Text</ccts:RepresentationTermName> 4678 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4679 <xsd:BuiltinType>string</xsd:BuiltinType> 4680 </xsd:documentation> 4681 </xsd:annotation> 4682 </xsd:attribute> 4683 </xsd:extension> 4684 </xsd:simpleContent> 4685 </xsd:complexType> 4686  4687  4688 <xsd:complexType name="PictureType"> 4689 <xsd:annotation> 4690 <xsd:documentation xml:lang="en"> 4691 <ccts:UniqueID>UDT000004</ccts:UniqueID> 4692 <ccts:CategoryCode>UDT</ccts:CategoryCode> 4693 <ccts:DictionaryEntryName>Picture. Type</ccts:DictionaryEntryName> 4694 <ccts:VersionID>1.0</ccts:VersionID> 4695 <ccts:Definition>A diagram, graph, mathematical curves, or similar representation.</ccts:Definition> 4696 <ccts:RepresentationTermName>Picture</ccts:RepresentationTermName> 4697 <ccts:PrimitiveType>binary</ccts:PrimitiveType> 4698 <xsd:BuiltinType>base64Binary</xsd:BuiltinType> 4699 </xsd:documentation> 4700 </xsd:annotation> 4701 <xsd:simpleContent> 4702 <xsd:extension base="xsd:base64Binary"> 4703 <xsd:attribute name="format" type="xsd:string" use="optional"> 4704 <xsd:annotation> 4705 <xsd:documentation xml:lang="en"> 4706 <ccts:UniqueID>UDT000004-SC2</ccts:UniqueID> 4707 <ccts:CategoryCode>SC</ccts:CategoryCode> 4708 <ccts:DictionaryEntryName>Picture. Format. Text</ccts:DictionaryEntryName> 4709 <ccts:Definition>The format of the picture content.</ccts:Definition> 4710 <ccts:ObjectClass>Picture</ccts:ObjectClass> 4711 <ccts:PropertyTermName>Format</ccts:PropertyTermName> 4712 <ccts:RepresentationTermName>Text</ccts:RepresentationTermName> 4713 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4714 <xsd:BuiltinType>string</xsd:BuiltinType> 4715 </xsd:documentation> 4716 </xsd:annotation> 4717 </xsd:attribute> 4718 <xsd:attribute name="mimeCode" type="clmIANAMIMEMediaTypes:BinaryObjectMimeCodeContentType" 4719 use="required"> 4720 <xsd:annotation> 4721 <xsd:documentation xml:lang="en"> 4722 <ccts:UniqueID>UDT000004-SC3</ccts:UniqueID> 4723 <ccts:CategoryCode>SC</ccts:CategoryCode> 4724 <ccts:DictionaryEntryName>Picture. Mime. Code</ccts:DictionaryEntryName> 4725 <ccts:Definition>The mime type of the picture object.</ccts:Definition> 4726 <ccts:ObjectClass>Picture</ccts:ObjectClass> 4727 <ccts:PropertyTermName>Mime</ccts:PropertyTermName> 4728 <ccts:RepresentationTermName>Code</ccts:RepresentationTermName> 4729 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4730 <xsd:BuiltinType>normalizedString</xsd:BuiltinType> 4731 </xsd:documentation> 4732 </xsd:annotation> 4733 </xsd:attribute> 4734 <xsd:attribute name="encodingCode" type="xsd:normalizedString" use="optional"> 4735 <xsd:annotation> 4736

<xsd:documentation xml:lang="en"> 4737 <ccts:UniqueID>UDT000004-SC4</ccts:UniqueID> 4738 <ccts:CategoryCode>SC</ccts:CategoryCode> 4739 <ccts:DictionaryEntryName>Picture. Encoding. Code</ccts:DictionaryEntryName> 4740 <ccts:Definition>Specifies the decoding algorithm of the picture object.</ccts:Definition> 4741 <ccts:ObjectClass>Picture</ccts:ObjectClass> 4742 <ccts:PropertyTermName>Encoding</ccts:PropertyTermName> 4743 <ccts:RepresentationTermName>Code</ccts:RepresentationTermName> 4744 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4745 <xsd:BuiltinType>normalizedString</xsd:BuiltinType> 4746 </xsd:documentation> 4747 </xsd:annotation> 4748 </xsd:attribute> 4749 <xsd:attribute name="uri" type="xsd:anyURI" use="optional"> 4750 <xsd:annotation> 4751 <xsd:documentation xml:lang="en"> 4752 <ccts:UniqueID>UDT000004-SC6</ccts:UniqueID> 4753 <ccts:CategoryCode>SC</ccts:CategoryCode> 4754 <ccts:DictionaryEntryName>Picture. Uniform Resource. Identifier</ccts:DictionaryEntryName> 4755 <ccts:Definition>The Uniform Resource Identifier that identifies where the picture object is 4756 located.</ccts:Definition> 4757 <ccts:ObjectClass>Picture</ccts:ObjectClass> 4758 <ccts:PropertyTermName>Uniform Resource Identifier</ccts:PropertyTermName> 4759 <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> 4760 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4761 <xsd:BuiltinType>anyURI</xsd:BuiltinType> 4762 </xsd:documentation> 4763 </xsd:annotation> 4764 </xsd:attribute> 4765 <xsd:attribute name="filename" type="xsd:string" use="optional"> 4766 <xsd:annotation> 4767 <xsd:documentation xml:lang="en"> 4768 <ccts:UniqueID>UDT000004-SC7</ccts:UniqueID> 4769 <ccts:CategoryCode>SC</ccts:CategoryCode> 4770 <ccts:DictionaryEntryName>Picture. Filename.Text</ccts:DictionaryEntryName> 4771 <ccts:Definition>The filename of the picture object.</ccts:Definition> 4772 <ccts:ObjectClass>Picture</ccts:ObjectClass> 4773 <ccts:PropertyTermName>Filename</ccts:PropertyTermName> 4774 <ccts:RepresentationTermName>Text</ccts:RepresentationTermName> 4775 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4776 <xsd:BuiltinType>string</xsd:BuiltinType> 4777 </xsd:documentation> 4778 </xsd:annotation> 4779 </xsd:attribute> 4780 </xsd:extension> 4781 </xsd:simpleContent> 4782 </xsd:complexType> 4783  4784  4785 <xsd:complexType name="SoundType"> 4786 <xsd:annotation> 4787 <xsd:documentation xml:lang="en"> 4788 <ccts:UniqueID>UDT000005</ccts:UniqueID> 4789 <ccts:CategoryCode>UDT</ccts:CategoryCode> 4790 <ccts:DictionaryEntryName>Sound. Type</ccts:DictionaryEntryName> 4791 <ccts:VersionID>1.0</ccts:VersionID> 4792 <ccts:Definition>A diagram, graph, mathematical curves, or similar representation.</ccts:Definition> 4793 <ccts:RepresentationTermName>Sound</ccts:RepresentationTermName> 4794 <ccts:PrimitiveType>binary</ccts:PrimitiveType> 4795 <xsd:BuiltinType>base64Binary</xsd:BuiltinType> 4796 </xsd:documentation> 4797 </xsd:annotation> 4798 <xsd:simpleContent> 4799 <xsd:extension base="xsd:base64Binary"> 4800 <xsd:attribute name="format" type="xsd:string" use="optional"> 4801 <xsd:annotation> 4802 <xsd:documentation xml:lang="en"> 4803 <ccts:UniqueID>UDT000005-SC2</ccts:UniqueID> 4804 <ccts:CategoryCode>SC</ccts:CategoryCode> 4805 <ccts:DictionaryEntryName>Sound. Format. Text</ccts:DictionaryEntryName> 4806 <ccts:Definition>The format of the sound content.</ccts:Definition> 4807

<ccts:ObjectClass>Sound</ccts:ObjectClass> 4808 <ccts:PropertyTermName>Format</ccts:PropertyTermName> 4809 <ccts:RepresentationTermName>Text</ccts:RepresentationTermName> 4810 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4811 <xsd:BuiltinType>string</xsd:BuiltinType> 4812 </xsd:documentation> 4813 </xsd:annotation> 4814 </xsd:attribute> 4815 <xsd:attribute name="mimeCode" type="clmIANAMIMEMediaTypes:BinaryObjectMimeCodeContentType" 4816 use="required"> 4817 <xsd:annotation> 4818 <xsd:documentation xml:lang="en"> 4819 <ccts:UniqueID>UDT000005-SC3</ccts:UniqueID> 4820 <ccts:CategoryCode>SC</ccts:CategoryCode> 4821 <ccts:DictionaryEntryName>Sound. Mime. Code</ccts:DictionaryEntryName> 4822 <ccts:Definition>The mime type of the sound object.</ccts:Definition> 4823 <ccts:ObjectClass>Sound</ccts:ObjectClass> 4824 <ccts:PropertyTermName>Mime</ccts:PropertyTermName> 4825 <ccts:RepresentationTermName>Code</ccts:RepresentationTermName> 4826 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4827 <xsd:BuiltinType>normalizedString</xsd:BuiltinType> 4828 </xsd:documentation> 4829 </xsd:annotation> 4830 </xsd:attribute> 4831 <xsd:attribute name="encodingCode" type="xsd:normalizedString" use="optional"> 4832 <xsd:annotation> 4833 <xsd:documentation xml:lang="en"> 4834 <ccts:UniqueID>UDT000005-SC4</ccts:UniqueID> 4835 <ccts:CategoryCode>SC</ccts:CategoryCode> 4836 <ccts:DictionaryEntryName>Sound. Encoding. Code</ccts:DictionaryEntryName> 4837 <ccts:Definition>Specifies the decoding algorithm of the sound object.</ccts:Definition> 4838 <ccts:ObjectClass>Sound</ccts:ObjectClass> 4839 <ccts:PropertyTermName>Encoding</ccts:PropertyTermName> 4840 <ccts:RepresentationTermName>Code</ccts:RepresentationTermName> 4841 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4842 <xsd:BuiltinType>normalizedString</xsd:BuiltinType> 4843 </xsd:documentation> 4844 </xsd:annotation> 4845 </xsd:attribute> 4846 <xsd:attribute name="uri" type="xsd:anyURI" use="optional"> 4847 <xsd:annotation> 4848 <xsd:documentation xml:lang="en"> 4849 <ccts:UniqueID>UDT000005-SC6</ccts:UniqueID> 4850 <ccts:CategoryCode>SC</ccts:CategoryCode> 4851 <ccts:DictionaryEntryName>Sound. Uniform Resource. Identifier</ccts:DictionaryEntryName> 4852 <ccts:Definition>The Uniform Resource Identifier that identifies where the sound object is 4853 located.</ccts:Definition> 4854 <ccts:ObjectClass>Sound</ccts:ObjectClass> 4855 <ccts:PropertyTermName>Uniform Resource Identifier</ccts:PropertyTermName> 4856 <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> 4857 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4858 <xsd:BuiltinType>anyURI</xsd:BuiltinType> 4859 </xsd:documentation> 4860 </xsd:annotation> 4861 </xsd:attribute> 4862 <xsd:attribute name="filename" type="xsd:string" use="optional"> 4863 <xsd:annotation> 4864 <xsd:documentation xml:lang="en"> 4865 <ccts:UniqueID>UDT000005-SC7</ccts:UniqueID> 4866 <ccts:CategoryCode>SC</ccts:CategoryCode> 4867 <ccts:DictionaryEntryName>Sound. Filename.Text</ccts:DictionaryEntryName> 4868 <ccts:Definition>The filename of the sound object.</ccts:Definition> 4869 <ccts:ObjectClass>Sound</ccts:ObjectClass> 4870 <ccts:PropertyTermName>Filename</ccts:PropertyTermName> 4871 <ccts:RepresentationTermName>Text</ccts:RepresentationTermName> 4872 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4873 <xsd:BuiltinType>string</xsd:BuiltinType> 4874 </xsd:documentation> 4875 </xsd:annotation> 4876 </xsd:attribute> 4877 </xsd:extension> 4878


</xsd:simpleContent> 4879 </xsd:complexType> 4880  4881  4882 <xsd:complexType name="VideoType"> 4883 <xsd:annotation> 4884 <xsd:documentation xml:lang="en"> 4885 <ccts:UniqueID>UDT000006</ccts:UniqueID> 4886 <ccts:CategoryCode>UDT</ccts:CategoryCode> 4887 <ccts:DictionaryEntryName>Video. Type</ccts:DictionaryEntryName> 4888 <ccts:VersionID>1.0</ccts:VersionID> 4889 <ccts:Definition>A diagram, graph, mathematical curves, or similar representation.</ccts:Definition> 4890 <ccts:RepresentationTermName>Graphic</ccts:RepresentationTermName> 4891 <ccts:PrimitiveType>binary</ccts:PrimitiveType> 4892 <xsd:BuiltinType>bas64Binary</xsd:BuiltinType> 4893 </xsd:documentation> 4894 </xsd:annotation> 4895 <xsd:simpleContent> 4896 <xsd:extension base="xsd:base64Binary"> 4897 <xsd:attribute name="format" type="xsd:string" use="optional"> 4898 <xsd:annotation> 4899 <xsd:documentation xml:lang="en"> 4900 <ccts:UniqueID>UDT000006-SC2</ccts:UniqueID> 4901 <ccts:CategoryCode>SC</ccts:CategoryCode> 4902 <ccts:DictionaryEntryName>Video. Format. Text</ccts:DictionaryEntryName> 4903 <ccts:Definition>The format of the video content.</ccts:Definition> 4904 <ccts:ObjectClass>Video</ccts:ObjectClass> 4905 <ccts:PropertyTermName>Format</ccts:PropertyTermName> 4906 <ccts:RepresentationTermName>Text</ccts:RepresentationTermName> 4907 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4908 <xsd:BuiltinType>string</xsd:BuiltinType> 4909 </xsd:documentation> 4910 </xsd:annotation> 4911 </xsd:attribute> 4912 <xsd:attribute name="mimeCode" type="clmIANAMIMEMediaTypes:BinaryObjectMimeCodeContentType" 4913 use="required"> 4914 <xsd:annotation> 4915 <xsd:documentation xml:lang="en"> 4916 <ccts:UniqueID>UDT000006-SC3</ccts:UniqueID> 4917 <ccts:CategoryCode>SC</ccts:CategoryCode> 4918 <ccts:DictionaryEntryName>Video. Mime. Code</ccts:DictionaryEntryName> 4919 <ccts:Definition>The mime type of the video object.</ccts:Definition> 4920 <ccts:ObjectClass>Video</ccts:ObjectClass> 4921 <ccts:PropertyTermName>Mime</ccts:PropertyTermName> 4922 <ccts:RepresentationTermName>Code</ccts:RepresentationTermName> 4923 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4924 <xsd:BuiltinType>normalizedString</xsd:BuiltinType> 4925 </xsd:documentation> 4926 </xsd:annotation> 4927 </xsd:attribute> 4928 <xsd:attribute name="encodingCode" type="xsd:normalizedString" use="optional"> 4929 <xsd:annotation> 4930 <xsd:documentation xml:lang="en"> 4931 <ccts:UniqueID>UDT000006-SC4</ccts:UniqueID> 4932 <ccts:CategoryCode>SC</ccts:CategoryCode> 4933 <ccts:DictionaryEntryName>Video. Encoding. Code</ccts:DictionaryEntryName> 4934 <ccts:Definition>Specifies the decoding algorithm of the video object.</ccts:Definition> 4935 <ccts:ObjectClass>Video</ccts:ObjectClass> 4936 <ccts:PropertyTermName>Encoding</ccts:PropertyTermName> 4937 <ccts:RepresentationTermName>Code</ccts:RepresentationTermName> 4938 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4939 <xsd:BuiltinType>normalizedString</xsd:BuiltinType> 4940 </xsd:documentation> 4941 </xsd:annotation> 4942 </xsd:attribute> 4943 <xsd:attribute name="uri" type="xsd:anyURI" use="optional"> 4944 <xsd:annotation> 4945 <xsd:documentation xml:lang="en"> 4946 <ccts:UniqueID>UDT000006-SC6</ccts:UniqueID> 4947 <ccts:CategoryCode>SC</ccts:CategoryCode> 4948 <ccts:DictionaryEntryName>Video. Uniform Resource. Identifier</ccts:DictionaryEntryName> 4949

<ccts:Definition>The Uniform Resource Identifier that identifies where the video object is 4950 located.</ccts:Definition> 4951 <ccts:ObjectClass>Video</ccts:ObjectClass> 4952 <ccts:PropertyTermName>Uniform Resource Identifier</ccts:PropertyTermName> 4953 <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> 4954 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4955 <xsd:BuiltinType>anyURI</xsd:BuiltinType> 4956 </xsd:documentation> 4957 </xsd:annotation> 4958 </xsd:attribute> 4959 <xsd:attribute name="filename" type="xsd:string" use="optional"> 4960 <xsd:annotation> 4961 <xsd:documentation xml:lang="en"> 4962 <ccts:UniqueID>UDT000006-SC7</ccts:UniqueID> 4963 <ccts:CategoryCode>SC</ccts:CategoryCode> 4964 <ccts:DictionaryEntryName>Video. Filename.Text</ccts:DictionaryEntryName> 4965 <ccts:Definition>The filename of the video object.</ccts:Definition> 4966 <ccts:ObjectClass>Video</ccts:ObjectClass> 4967 <ccts:PropertyTermName>Filename</ccts:PropertyTermName> 4968 <ccts:RepresentationTermName>Text</ccts:RepresentationTermName> 4969 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4970 <xsd:BuiltinType>string</xsd:BuiltinType> 4971 </xsd:documentation> 4972 </xsd:annotation> 4973 </xsd:attribute> 4974 </xsd:extension> 4975 </xsd:simpleContent> 4976 </xsd:complexType> 4977  4978  4979 <xsd:complexType name="CodeType"> 4980 <xsd:annotation> 4981 <xsd:documentation xml:lang="en"> 4982 <ccts:UniqueID>UDT000007</ccts:UniqueID> 4983 <ccts:CategoryCode>UDT</ccts:CategoryCode> 4984 <ccts:DictionaryEntryName>Code. Type</ccts:DictionaryEntryName> 4985 <ccts:VersionID>1.0</ccts:VersionID> 4986 <ccts:Definition>A character string (letters, figures, or symbols) that for brevity and/or languange 4987 independence may be used to represent or replace a definitive value or text of an attribute together with relevant 4988 supplementary information.</ccts:Definition> 4989 <ccts:RepresentationTermName>Code</ccts:RepresentationTermName> 4990 <ccts:PrimitiveType>string</ccts:PrimitiveType> 4991 <xsd:BuiltinType>normalizedString</xsd:BuiltinType> 4992 <ccts:UsageRule>Other supplementary components in the CCT are captured as part of the token and name 4993 for the schema module containing the code list and thus, are not declared as attributes. </ccts:UsageRule> 4994 </xsd:documentation> 4995 </xsd:annotation> 4996 <xsd:simpleContent> 4997 <xsd:extension base="xsd:normalizedString"> 4998 <xsd:attribute name="listVersionID" type="xsd:normalizedString" use="optional"> 4999 <xsd:annotation> 5000 <xsd:documentation xml:lang="en"> 5001 <ccts:UniqueID>UNDT000007-SC6</ccts:UniqueID> 5002 <ccts:CategoryCode>SC</ccts:CategoryCode> 5003 <ccts:DictionaryEntryName>Code List. Identifier</ccts:DictionaryEntryName> 5004 <ccts:Definition>The identification of a list of codes.</ccts:Definition> 5005 <ccts:ObjectClass>Code List</ccts:ObjectClass> 5006 <ccts:PropertyTermName>Identification</ccts:PropertyTermName> 5007 <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> 5008 <ccts:PrimitiveType>string</ccts:PrimitiveType> 5009 <xsd:BuiltinType>string</xsd:BuiltinType> 5010 </xsd:documentation> 5011 </xsd:annotation> 5012 </xsd:attribute> 5013 <xsd:attribute name="name" type="xsd:string" use="optional"> 5014 <xsd:annotation> 5015 <xsd:documentation xml:lang="en"> 5016 <ccts:UniqueID>UDT000007-SC7</ccts:UniqueID> 5017 <ccts:CategoryCode>SC</ccts:CategoryCode> 5018 <ccts:DictionaryEntryName>Code. Name. Text</ccts:DictionaryEntryName> 5019 <ccts:Definition>The textual equivalent of the code content component.</ccts:Definition> 5020

<ccts:ObjectClass>Code</ccts:ObjectClass> 5021 <ccts:PropertyTermName>Name</ccts:PropertyTermName> 5022 <ccts:RepresentationTermName>Text</ccts:RepresentationTermName> 5023 <ccts:PrimitiveType>string</ccts:PrimitiveType> 5024 <xsd:BuiltinType>string</xsd:BuiltinType> 5025 </xsd:documentation> 5026 </xsd:annotation> 5027 </xsd:attribute> 5028 <xsd:attribute name="languageID" type="xsd:language" use="optional"> 5029 <xsd:annotation> 5030 <xsd:documentation xml:lang="en"> 5031 <ccts:UniqueID>UDT000007-SC8</ccts:UniqueID> 5032 <ccts:CategoryCode>SC</ccts:CategoryCode> 5033 <ccts:DictionaryEntryName>Language. Identifier</ccts:DictionaryEntryName> 5034 <ccts:Definition>The identifier of the language used in the code name.</ccts:Definition> 5035 <ccts:ObjectClass>Language</ccts:ObjectClass> 5036 <ccts:PropertyTermName>Identification</ccts:PropertyTermName> 5037 <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> 5038 <ccts:PrimitiveType>string</ccts:PrimitiveType> 5039 <xsd:BuiltinType>language</xsd:BuiltinType> 5040 </xsd:documentation> 5041 </xsd:annotation> 5042 </xsd:attribute> 5043 <xsd:attribute name="listURI" type="xsd:anyURI" use="optional"> 5044 <xsd:annotation> 5045 <xsd:documentation xml:lang="en"> 5046 <ccts:UniqueID>UDT000007-SC9</ccts:UniqueID> 5047 <ccts:CategoryCode>SC</ccts:CategoryCode> 5048 <ccts:DictionaryEntryName>Code List. Uniform Resource. 5049 Identifier</ccts:DictionaryEntryName> 5050 <ccts:Definition>The Uniform Resource Identifier that identifies where the code list is 5051 located.</ccts:Definition> 5052 <ccts:ObjectClass>Code List</ccts:ObjectClass> 5053 <ccts:PropertyTermName>Uniform Resource Identifier</ccts:PropertyTermName> 5054 <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> 5055 <ccts:PrimitiveType>string</ccts:PrimitiveType> 5056 <xsd:BuiltinType>anyURI</xsd:BuiltinType> 5057 </xsd:documentation> 5058 </xsd:annotation> 5059 </xsd:attribute> 5060 <xsd:attribute name="listSchemeURI" type="xsd:anyURI" use="optional"> 5061 <xsd:annotation> 5062 <xsd:documentation xml:lang="en"> 5063 <ccts:UniqueID>UDT000007-SC9</ccts:UniqueID> 5064 <ccts:CategoryCode>SC</ccts:CategoryCode> 5065 <ccts:DictionaryEntryName>Code List Scheme. Uniform Resource. 5066 Identifier</ccts:DictionaryEntryName> 5067 <ccts:Definition>The Uniform Resource Identifier that identifies where the code list scheme is 5068 located.</ccts:Definition> 5069 <ccts:ObjectClass>Code List Scheme</ccts:ObjectClass> 5070 <ccts:PropertyTermName>Uniform Resource Identifier</ccts:PropertyTermName> 5071 <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> 5072 <ccts:PrimitiveType>string</ccts:PrimitiveType> 5073 <xsd:BuiltinType>anyURI</xsd:BuiltinType> 5074 </xsd:documentation> 5075 </xsd:annotation> 5076 </xsd:attribute> 5077 </xsd:extension> 5078 </xsd:simpleContent> 5079 </xsd:complexType> 5080  5081  5082 <xsd:simpleType name="DateTimeType"> 5083 <xsd:annotation> 5084 <xsd:documentation xml:lang="en"> 5085 <ccts:UniqueID>UDT000008</ccts:UniqueID> 5086 <ccts:CategoryCode>UDT</ccts:CategoryCode> 5087 <ccts:DictionaryEntryName>Date Time. Type</ccts:DictionaryEntryName> 5088 <ccts:VersionID>1.0</ccts:VersionID> 5089 <ccts:Definition>A particular point in the progression of time together with the relevant supplementary 5090 information.</ccts:Definition> 5091

<ccts:RepresentationTermName>Date Time</ccts:RepresentationTermName> 5092 <ccts:PrimitiveType>string</ccts:PrimitiveType> 5093 <xsd:BuiltinType>dateTime</xsd:BuiltinType> 5094 <ccts:UsageRule>Can be used for a date and/or time.</ccts:UsageRule> 5095 </xsd:documentation> 5096 </xsd:annotation> 5097 <xsd:restriction base="xsd:dateTime"/> 5098 </xsd:simpleType> 5099  5100  5101 <xsd:simpleType name="DateType"> 5102 <xsd:annotation> 5103 <xsd:documentation xml:lang="en"> 5104 <ccts:UniqueID>UDT000009</ccts:UniqueID> 5105 <ccts:CategoryCode>UDT</ccts:CategoryCode> 5106 <ccts:DictionaryEntryName>Date. Type</ccts:DictionaryEntryName> 5107 <ccts:VersionID>1.0</ccts:VersionID> 5108 <ccts:Definition>One calendar day according the Gregorian calendar.</ccts:Definition> 5109 <ccts:RepresentationTermName>Date</ccts:RepresentationTermName> 5110 <ccts:PrimitiveType>string</ccts:PrimitiveType> 5111 <xsd:BuiltinType>date</xsd:BuiltinType> 5112 </xsd:documentation> 5113 </xsd:annotation> 5114 <xsd:restriction base="xsd:date"/> 5115 </xsd:simpleType> 5116  5117  5118 <xsd:simpleType name="TimeType"> 5119 <xsd:annotation> 5120 <xsd:documentation xml:lang="en"> 5121 <ccts:UniqueID>UDT0000010</ccts:UniqueID> 5122 <ccts:CategoryCode>UDT</ccts:CategoryCode> 5123 <ccts:DictionaryEntryName>Time. Type</ccts:DictionaryEntryName> 5124 <ccts:VersionID>1.0</ccts:VersionID> 5125 <ccts:Definition>The instance of time that occurs every day.</ccts:Definition> 5126 <ccts:RepresentationTermName>Time</ccts:RepresentationTermName> 5127 <ccts:PrimitiveType>string</ccts:PrimitiveType> 5128 <xsd:BuiltinType>time</xsd:BuiltinType> 5129 </xsd:documentation> 5130 </xsd:annotation> 5131 <xsd:restriction base="xsd:time"/> 5132 </xsd:simpleType> 5133  5134  5135 <xsd:complexType name="IdentifierType"> 5136 <xsd:annotation> 5137 <xsd:documentation xml:lang="en"> 5138 <ccts:UniqueID>UDT0000011</ccts:UniqueID> 5139 <ccts:CategoryCode>UDT</ccts:CategoryCode> 5140 <ccts:DictionaryEntryName>Identifier. Type</ccts:DictionaryEntryName> 5141 <ccts:VersionID>1.0</ccts:VersionID> 5142 <ccts:Definition>A character string to identify and distinguish uniquely, one instance of an object in an 5143 identification scheme from all other objects in the same scheme together with relevant supplementary 5144 information.</ccts:Definition> 5145 <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> 5146 <ccts:PrimitiveType>string</ccts:PrimitiveType> 5147 <xsd:BuiltinType>normalizedString</xsd:BuiltinType> 5148 <ccts:UsageRule>Other supplementary components in the CCT are captured as part of the token and name 5149 for the schema module containing the identifer list and thus, are not declared as attributes. </ccts:UsageRule> 5150 </xsd:documentation> 5151 </xsd:annotation> 5152 <xsd:simpleContent> 5153 <xsd:extension base="xsd:normalizedString"> 5154 <xsd:attribute name="schemeVersionID" type="xsd:normalizedString" use="optional"> 5155 <xsd:annotation> 5156 <xsd:documentation xml:lang="en"> 5157 <ccts:UniqueID>UNDT000011-SC6</ccts:UniqueID> 5158 <ccts:CategoryCode>SC</ccts:CategoryCode> 5159 <ccts:DictionaryEntryName>Identification Scheme. Version. 5160 Identifier</ccts:DictionaryEntryName> 5161 <ccts:Definition>The version of the identification scheme.</ccts:Definition> 5162

<ccts:ObjectClass>Identification Scheme</ccts:ObjectClass> 5163 <ccts:PropertyTermName>Version</ccts:PropertyTermName> 5164 <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> 5165 <ccts:PrimitiveType>string</ccts:PrimitiveType> 5166 <xsd:BuiltinType>normalizedString</xsd:BuiltinType> 5167 </xsd:documentation> 5168 </xsd:annotation> 5169 </xsd:attribute> 5170 <xsd:attribute name="schemeDataURI" type="xsd:anyURI" use="optional"> 5171 <xsd:annotation> 5172 <xsd:documentation xml:lang="en"> 5173 <ccts:UniqueID>UDT0000011-SC7</ccts:UniqueID> 5174 <ccts:CategoryCode>SC</ccts:CategoryCode> 5175 <ccts:DictionaryEntryName>Identification Scheme Data. Uniform Resource. 5176 Identifier</ccts:DictionaryEntryName> 5177 <ccts:Definition>The Uniform Resource Identifier that identifies where the identification scheme 5178 data is located.</ccts:Definition> 5179 <ccts:ObjectClass>Identification Scheme Data</ccts:ObjectClass> 5180 <ccts:PropertyTermName>Uniform Resource Identifier</ccts:PropertyTermName> 5181 <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> 5182 <ccts:PrimitiveType>string</ccts:PrimitiveType> 5183 <xsd:BuiltinType>anyURI</xsd:BuiltinType> 5184 </xsd:documentation> 5185 </xsd:annotation> 5186 </xsd:attribute> 5187 <xsd:attribute name="schemeURI" type="xsd:anyURI" use="optional"> 5188 <xsd:annotation> 5189 <xsd:documentation xml:lang="en"> 5190 <ccts:UniqueID>UDT0000011-SC8</ccts:UniqueID> 5191 <ccts:CategoryCode>SC</ccts:CategoryCode> 5192 <ccts:DictionaryEntryName>Identification Scheme. Uniform Resource. 5193 Identifier</ccts:DictionaryEntryName> 5194 <ccts:Definition>The Uniform Resource Identifier that identifies where the identification scheme 5195 is located.</ccts:Definition> 5196 <ccts:ObjectClass>Identification Scheme</ccts:ObjectClass> 5197 <ccts:PropertyTermName>Uniform Resource Identifier</ccts:PropertyTermName> 5198 <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> 5199 <ccts:PrimitiveType>string</ccts:PrimitiveType> 5200 <xsd:BuiltinType>anyURI</xsd:BuiltinType> 5201 </xsd:documentation> 5202 </xsd:annotation> 5203 </xsd:attribute> 5204 </xsd:extension> 5205 </xsd:simpleContent> 5206 </xsd:complexType> 5207  5208  5209 <xsd:simpleType name="IndicatorType"> 5210 <xsd:annotation> 5211 <xsd:documentation xml:lang="en"> 5212 <ccts:UniqueID>UDT0000012</ccts:UniqueID> 5213 <ccts:CategoryCode>UDT</ccts:CategoryCode> 5214 <ccts:DictionaryEntryName>Indicator. Type</ccts:DictionaryEntryName> 5215 <ccts:VersionID>1.0</ccts:VersionID> 5216 <ccts:Definition>A list of two mutually exclusive Boolean values that express the only possible states of a 5217 property.</ccts:Definition> 5218 <ccts:RepresentationTermName>Indicator</ccts:RepresentationTermName> 5219 <ccts:PrimitiveType>string</ccts:PrimitiveType> 5220 <xsd:BuiltinType>boolean</xsd:BuiltinType> 5221 </xsd:documentation> 5222 </xsd:annotation> 5223 <xsd:restriction base="xsd:boolean"> 5224 <xsd:pattern value="false"/> 5225 <xsd:pattern value="true"/> 5226 </xsd:restriction> 5227 </xsd:simpleType> 5228  5229  5230 <xsd:complexType name="MeasureType"> 5231 <xsd:annotation> 5232 <xsd:documentation xml:lang="en"> 5233

<ccts:UniqueID>UDT0000013</ccts:UniqueID> 5234 <ccts:CategoryCode>UDT</ccts:CategoryCode> 5235 <ccts:DictionaryEntryName>Measure. Type</ccts:DictionaryEntryName> 5236 <ccts:VersionID>1.0</ccts:VersionID> 5237 <ccts:Definition>A numeric value determined by measuring an object along with the specified unit of 5238 measure.</ccts:Definition> 5239 <ccts:RepresentationTermName>Measure</ccts:RepresentationTermName> 5240 <ccts:PropertyTermName>Type</ccts:PropertyTermName> 5241 <ccts:PrimitiveType>decimal</ccts:PrimitiveType> 5242 <xsd:BuiltinType>decimal</xsd:BuiltinType> 5243 </xsd:documentation> 5244 </xsd:annotation> 5245 <xsd:simpleContent> 5246 <xsd:extension base="xsd:decimal"> 5247 <xsd:attribute name="unitCode" type="clm66411:UnitCodeContentType" use="required"> 5248 <xsd:annotation> 5249 <xsd:documentation xml:lang="en"> 5250 <ccts:UniqueID>UDT0000013-SC2</ccts:UniqueID> 5251 <ccts:CategoryCode>SC</ccts:CategoryCode> 5252 <ccts:DictionaryEntryName>Measure Unit. Code</ccts:DictionaryEntryName> 5253 <ccts:Definition>The type of unit of measure.</ccts:Definition> 5254 <ccts:ObjectClass>Measure Unit</ccts:ObjectClass> 5255 <ccts:PropertyTermName>Code</ccts:PropertyTermName> 5256 <ccts:RepresentationTermName>Code</ccts:RepresentationTermName> 5257 <ccts:PrimitiveType>string</ccts:PrimitiveType> 5258 <xsd:BuiltinType>normalizedString</xsd:BuiltinType> 5259 <ccts:UsageRule>Reference UN/ECE Rec 20 and X12 355.</ccts:UsageRule> 5260 </xsd:documentation> 5261 </xsd:annotation> 5262 </xsd:attribute> 5263 </xsd:extension> 5264 </xsd:simpleContent> 5265 </xsd:complexType> 5266  5267  5268 <xsd:simpleType name="NumericType"> 5269 <xsd:annotation> 5270 <xsd:documentation xml:lang="en"> 5271 <ccts:UniqueID>UDT0000014</ccts:UniqueID> 5272 <ccts:CategoryCode>UDT</ccts:CategoryCode> 5273 <ccts:DictionaryEntryName>Numeric. Type</ccts:DictionaryEntryName> 5274 <ccts:VersionID>1.0</ccts:VersionID> 5275 <ccts:Definition>Numeric information that is assigned or is determined by calculation, counting, or 5276 sequencing. It does not require a unit of quantity or unit of measure.</ccts:Definition> 5277 <ccts:RepresentationTermName>Numeric</ccts:RepresentationTermName> 5278 <ccts:PrimitiveType>string</ccts:PrimitiveType> 5279 <xsd:BuiltinType>decimal</xsd:BuiltinType> 5280 </xsd:documentation> 5281 </xsd:annotation> 5282 <xsd:restriction base="xsd:decimal"/> 5283 </xsd:simpleType> 5284  5285  5286 <xsd:simpleType name="ValueType"> 5287 <xsd:annotation> 5288 <xsd:documentation xml:lang="en"> 5289 <ccts:UniqueID>UDT0000015</ccts:UniqueID> 5290 <ccts:CategoryCode>UDT</ccts:CategoryCode> 5291 <ccts:VersionID>1.0</ccts:VersionID> 5292 <ccts:DictionaryEntryName>Value. Type</ccts:DictionaryEntryName> 5293 <ccts:Definition>Numeric information that is assigned or is determined by calculation, counting, or 5294 sequencing. It does not require a unit of quantity or unit of measure.</ccts:Definition> 5295 <ccts:RepresentationTermName>Value</ccts:RepresentationTermName> 5296 <ccts:PrimitiveType>string</ccts:PrimitiveType> 5297 <xsd:BuiltinType>decimal</xsd:BuiltinType> 5298 </xsd:documentation> 5299 </xsd:annotation> 5300 <xsd:restriction base="xsd:decimal"/> 5301 </xsd:simpleType> 5302  5303  5304

<xsd:simpleType name="PercentType"> 5305 <xsd:annotation> 5306 <xsd:documentation xml:lang="en"> 5307 <ccts:UniqueID>UDT0000016</ccts:UniqueID> 5308 <ccts:CategoryCode>UDT</ccts:CategoryCode> 5309 <ccts:VersionID>1.0</ccts:VersionID> 5310 <ccts:DictionaryEntryName>Percent. Type</ccts:DictionaryEntryName> 5311 <ccts:Definition>Numeric information that is assigned or is determined by calculation, counting, or 5312 sequencing. It does not require a unit of quantity or unit of measure.</ccts:Definition> 5313 <ccts:RepresentationTermName>Percent</ccts:RepresentationTermName> 5314 <ccts:PrimitiveType>string</ccts:PrimitiveType> 5315 <xsd:BuiltinType>decimal</xsd:BuiltinType> 5316 </xsd:documentation> 5317 </xsd:annotation> 5318 <xsd:restriction base="xsd:decimal"/> 5319 </xsd:simpleType> 5320  5321  5322 <xsd:simpleType name="RateType"> 5323 <xsd:annotation> 5324 <xsd:documentation xml:lang="en"> 5325 <ccts:UniqueID>UDT0000017</ccts:UniqueID> 5326 <ccts:CategoryCode>UDT</ccts:CategoryCode> 5327 <ccts:VersionID>1.0</ccts:VersionID> 5328 <ccts:DictionaryEntryName>Rate. Type</ccts:DictionaryEntryName> 5329 <ccts:Definition>Numeric information that is assigned or is determined by calculation, counting, or 5330 sequencing. It does not require a unit of quantity or unit of measuret.</ccts:Definition> 5331 <ccts:RepresentationTermName>Rate</ccts:RepresentationTermName> 5332 <ccts:PrimitiveType>string</ccts:PrimitiveType> 5333 <xsd:BuiltinType>decimal</xsd:BuiltinType> 5334 </xsd:documentation> 5335 </xsd:annotation> 5336 <xsd:restriction base="xsd:decimal"/> 5337 </xsd:simpleType> 5338  5339  5340 <xsd:complexType name="QuantityType"> 5341 <xsd:annotation> 5342 <xsd:documentation xml:lang="en"> 5343 <ccts:UniqueID>UDT0000018</ccts:UniqueID> 5344 <ccts:CategoryCode>UDT</ccts:CategoryCode> 5345 <ccts:DictionaryEntryName>Quantity. Type</ccts:DictionaryEntryName> 5346 <ccts:VersionID>1.0</ccts:VersionID> 5347 <ccts:Definition>A counted number of non-monetary units possibly including fractions.</ccts:Definition> 5348 <ccts:RepresentationTermName>Quantity</ccts:RepresentationTermName> 5349 <ccts:PrimitiveType>decimal</ccts:PrimitiveType> 5350 <xsd:BuiltinType>decimal</xsd:BuiltinType> 5351 </xsd:documentation> 5352 </xsd:annotation> 5353 <xsd:simpleContent> 5354 <xsd:extension base="xsd:decimal"> 5355 <xsd:attribute name="unitCode" type="clm66411:UnitCodeContentType" use="optional"> 5356 <xsd:annotation> 5357 <xsd:documentation xml:lang="en"> 5358 <ccts:UniqueID>UDT0000018-SC2</ccts:UniqueID> 5359 <ccts:CategoryCode>SC</ccts:CategoryCode> 5360 <ccts:DictionaryEntryName>Quantity. Unit. Code</ccts:DictionaryEntryName> 5361 <ccts:Definition>The unit of the quantity</ccts:Definition> 5362 <ccts:ObjectClass>Quantity</ccts:ObjectClass> 5363 <ccts:PropertyTermName>Unit Code</ccts:PropertyTermName> 5364 <ccts:RepresentationTermName>Code</ccts:RepresentationTermName> 5365 <ccts:PrimitiveType>string</ccts:PrimitiveType> 5366 <xsd:BuiltinType>normalizedString</xsd:BuiltinType> 5367 </xsd:documentation> 5368 </xsd:annotation> 5369 </xsd:attribute> 5370 </xsd:extension> 5371 </xsd:simpleContent> 5372 </xsd:complexType> 5373  5374  5375

<xsd:complexType name="TextType"> 5376 <xsd:annotation> 5377 <xsd:documentation xml:lang="en"> 5378 <ccts:UniqueID>UDT0000019</ccts:UniqueID> 5379 <ccts:CategoryCode>UDT</ccts:CategoryCode> 5380 <ccts:DictionaryEntryName>Text. Type</ccts:DictionaryEntryName> 5381 <ccts:VersionID>1.0</ccts:VersionID> 5382 <ccts:Definition>A character string (i.e. a finite set of characters) generally in the form of words of a 5383 language.</ccts:Definition> 5384 <ccts:RepresentationTermName>Text</ccts:RepresentationTermName> 5385 <ccts:PrimitiveType>string</ccts:PrimitiveType> 5386 <xsd:BuiltinType>string</xsd:BuiltinType> 5387 </xsd:documentation> 5388 </xsd:annotation> 5389 <xsd:simpleContent> 5390 <xsd:extension base="xsd:string"> 5391 <xsd:attribute name="languageID" type="xsd:language" use="optional"> 5392 <xsd:annotation> 5393 <xsd:documentation xml:lang="en"> 5394 <ccts:UniqueID>UDT0000019-SC2</ccts:UniqueID> 5395 <ccts:CategoryCode>SC</ccts:CategoryCode> 5396 <ccts:DictionaryEntryName>Language. Identifier</ccts:DictionaryEntryName> 5397 <ccts:Definition>The identifier of the language used in the content component.</ccts:Definition> 5398 <ccts:ObjectClass>Language</ccts:ObjectClass> 5399 <ccts:PropertyTermName>Identification</ccts:PropertyTermName> 5400 <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> 5401 <ccts:PrimitiveType>string</ccts:PrimitiveType> 5402 <xsd:BuiltinType>language</xsd:BuiltinType> 5403 </xsd:documentation> 5404 </xsd:annotation> 5405 </xsd:attribute> 5406 </xsd:extension> 5407 </xsd:simpleContent> 5408 </xsd:complexType> 5409  5410  5411 <xsd:complexType name="NameType"> 5412 <xsd:annotation> 5413 <xsd:documentation xml:lang="en"> 5414 <ccts:UniqueID>UDT0000020</ccts:UniqueID> 5415 <ccts:CategoryCode>UDT</ccts:CategoryCode> 5416 <ccts:DictionaryEntryName>Name. Type</ccts:DictionaryEntryName> 5417 <ccts:VersionID>1.0</ccts:VersionID> 5418 <ccts:Definition>A character string that consititues the distinctive designation of a person, place, thing or 5419 concept.</ccts:Definition> 5420 <ccts:RepresentationTermName>Name</ccts:RepresentationTermName> 5421 <ccts:PrimitiveType>string</ccts:PrimitiveType> 5422 <xsd:BuiltinType>string</xsd:BuiltinType> 5423 </xsd:documentation> 5424 </xsd:annotation> 5425 <xsd:simpleContent> 5426 <xsd:extension base="xsd:string"> 5427 <xsd:attribute name="languageID" type="xsd:language" use="optional"> 5428 <xsd:annotation> 5429 <xsd:documentation xml:lang="en"> 5430 <ccts:UniqueID>UDT0000020-SC2</ccts:UniqueID> 5431 <ccts:CategoryCode>SC</ccts:CategoryCode> 5432 <ccts:DictionaryEntryName>Language. Identifier</ccts:DictionaryEntryName> 5433 <ccts:Definition>The identifier of the language used in the content component.</ccts:Definition> 5434 <ccts:ObjectClass>Language</ccts:ObjectClass> 5435 <ccts:PropertyTermName>Identification</ccts:PropertyTermName> 5436 <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> 5437 <ccts:PrimitiveType>string</ccts:PrimitiveType> 5438 <xsd:BuiltinType>language</xsd:BuiltinType> 5439 </xsd:documentation> 5440 </xsd:annotation> 5441 </xsd:attribute> 5442 </xsd:extension> 5443 </xsd:simpleContent> 5444 </xsd:complexType> 5445 </xsd:schema> 5446

Appendix F. Annotation Templates 5447

5448 5449 5450 5451 5452 5453 5454 5455 5456 5457 5458 5459 5460 5461 5462 5463 5464 5465 5466 5467 5468 5469 5470 5471 5472 5473 5474 5475 5476 5477 5478 5479 5480 5481 5482 5483 5484 5485 5486 5487 5488 5489 5490 5491 5492 5493 5494 5495 5496 5497 5498 5499 5500 5501 5502 5503

The following templates define the annotation for each of the schema modules.  <xsd:annotation> <xsd:documentation xml:lang="en"> <ccts:UniqueID></ccts:UniqueID> <ccts:CategoryCode>RSM</ccts:CategoryCode> <ccts:Name></ccts:Name> <ccts:VersionID></ccts:VersionID> <ccts:Description></ccts:Description> <ccts:BusinessDomain></ccts:BusinessDomain> <ccts:BusinessProcessContext></ccts:BusinessProcessContext> <ccts:GeopoliticalOrRegionContext></ccts:GeopoliticalOrRegionContext> <ccts:OfficialConstraintContext></ccts:OfficialConstraintContext> <ccts:ProductContext></ccts:ProductContext> <ccts:IndustryContext></ccts:IndustryContext> <ccts:BusinessProcessRoleContext></ccts:BusinessProcessRoleContext> <ccts:SupportingRoleContext></ccts:SupportingRoleContext> <ccts:SystemCapabilitiesContext></ccts:SystemCapabilitiesContext> </xsd:documentation> </xsd:annotation>  <xsd:annotation> <xsd:documentation xml:lang="en"> <ccts:UniqueID></ccts:UniqueID> <ccts:CategoryCode>ABIE</ccts:CategoryCode> <ccts:DictionaryEntryName></ccts:DictionaryEntryName> <ccts:VersionID></ccts:VersionID> <ccts:Definition></ccts:Definition> <ccts:ObjectClassTermName></ccts:ObjectClassTermName> <ccts:ObjectClassQualifierTermName></ccts:ObjectClassQualifierTermName> <ccts:BusinessProcessContext></ccts:BusinessProcessContext> <ccts:GeopoliticalOrRegionContext></ccts:GeopoliticalOrRegionContext> <ccts:OfficialConstraintContext></ccts:OfficialConstraintContext> <ccts:ProductContext></ccts:ProductContext> <ccts:IndustryContext></ccts:IndustryContext> <ccts:BusinessProcessRoleContext></ccts:BusinessProcessRoleContext> <ccts:SupportingRoleContext></ccts:SupportingRoleContext> <ccts:SystemCapabilitiesContext></ccts:SystemCapabilitiesContext> <ccts:UsageRule></ccts:UsageRule> <ccts:BusinessTermName></ccts:BusinessTermName> <ccts:Example></ccts:Example> </xsd:documentation> </xsd:annotation>  <xsd:annotation> <xsd:documentation xml:lang="en"> <ccts:UniqueID></ccts:UniqueID> <ccts:CategoryCode>ABIE</ccts:CategoryCode> <ccts:DictionaryEntryName></ccts:DictionaryEntryName> <ccts:VersionID></ccts:VersionID> <ccts:Definition></ccts:Definition> <ccts:Cardinality></ccts: Cardinality> <ccts:ObjectClassTermName></ccts:ObjectClassTermName> <ccts:ObjectClassQualifierTermName></ccts:ObjectClassQualifierTermName>

5504 5505 5506 5507 5508 5509 5510 5511 5512 5513 5514 5515 5516 5517 5518 5519 5520 5521 5522 5523 5524 5525 5526 5527 5528 5529 5530 5531 5532 5533 5534 5535 5536 5537 5538 5539 5540 5541 5542 5543 5544 5545 5546 5547 5548 5549 5550 5551 5552 5553 5554 5555 5556 5557 5558 5559 5560 5561 5562 5563

<ccts:PropertyTermName></ccts:PropertyTermName> <ccts:PropertyQualifierTermName></ccts:PropertyQualifierTermName> <ccts:RepresentationTermName></ccts:RepresentationTermName <ccts:BusinessProcessContext></ccts:BusinessProcessContext> <ccts:GeopoliticalOrRegionContext></ccts:GeopoliticalOrRegionContext> <ccts:OfficialConstraintContext></ccts:OfficialConstraintContext> <ccts:ProductContext></ccts:ProductContext> <ccts:IndustryContext></ccts:IndustryContext> <ccts:BusinessProcessRoleContext></ccts:BusinessProcessRoleContext> <ccts:SupportingRoleContext></ccts:SupportingRoleContext> <ccts:SystemCapabilitiesContext></ccts:SystemCapabilitiesContext> <ccts:UsageRule></ccts:UsageRule> <ccts:BusinessTermName></ccts:BusinessTermName> <ccts:Example></ccts:Example> </xsd:documentation> </xsd:annotation>  <xsd:annotation> <xsd:documentation xml:lang="en"> <ccts:UniqueID></ccts:UniqueID> <ccts:CategoryCode>ABIE</ccts:CategoryCode> <ccts:DictionaryEntryName></ccts:DictionaryEntryName> <ccts:VersionID></ccts:VersionID> <ccts:Definition></ccts:Definition> <ccts:Cardinality></ccts: Cardinality> <ccts:ObjectClassTermName></ccts:ObjectClassTermName> <ccts:ObjectClassQualifierTermName></ccts:ObjectClassQualifierTermName> <ccts:PropertyTermName></ccts:PropertyTermName> <ccts:PropertyQualifierTermName></ccts:PropertyQualifierTermName> <ccts:AssociatedObjectClassTermName></ccts:AssociatedObjectClassTermName> <ccts: AssociatedObjectClassQualifierTermName></ccts: AssociatedObjectClassQualifierTermName> <ccts:BusinessProcessContext></ccts:BusinessProcessContext> <ccts:GeopoliticalOrRegionContext></ccts:GeopoliticalOrRegionContext> <ccts:OfficialConstraintContext></ccts:OfficialConstraintContext> <ccts:ProductContext></ccts:ProductContext> <ccts:IndustryContext></ccts:IndustryContext> <ccts:BusinessProcessRoleContext></ccts:BusinessProcessRoleContext> <ccts:SupportingRoleContext></ccts:SupportingRoleContext> <ccts:SystemCapabilitiesContext></ccts:SystemCapabilitiesContext> <ccts:UsageRule></ccts:UsageRule> <ccts:BusinessTermName></ccts:BusinessTermName> <ccts:Example></ccts:Example> </xsd:documentation>

</xsd:annotation>  <xsd:annotation> <xsd:documentation xml:lang="en"> <ccts:UniqueID></ccts:UniqueID> <ccts:CategoryCode>QDT</ccts:CategoryCode> <ccts:DictionaryEntryName></ccts:DictionaryEntryName> <ccts:VersionID></ccts:VersionID> <ccts:Definition></ccts:Definition> <ccts:RepresentationTermName></ccts:RepresentationTermName> <ccts:DataTypeQualifierTermName></ccts:DataTypeQualifierTermName> <ccts:PrimitiveType></ccts:PrimitiveType> <xsd:BuiltInType></xsd: BuiltInType> <ccts:BusinessProcessContext></ccts:BusinessProcessContext>

5564 5565 5566 5567 5568 5569 5570 5571 5572 5573 5574 5575 5576 5577 5578 5579 5580 5581 5582 5583 5584 5585 5586 5587 5588 5589 5590 5591 5592 5593 5594 5595 5596 5597 5598 5599 5600 5601 5602 5603 5604 5605 5606 5607 5608 5609 5610 5611 5612 5613 5614 5615 5616 5617 5618 5619 5620 5621 5622 5623

<ccts:GeopoliticalOrRegionContext></ccts:GeopoliticalOrRegionContext> <ccts:OfficialConstraintContext></ccts:OfficialConstraintContext> <ccts:ProductContext></ccts:ProductContext> <ccts:IndustryContext></ccts:IndustryContext> <ccts:BusinessProcessRoleContext></ccts:BusinessProcessRoleContext> <ccts:SupportingRoleContext></ccts:SupportingRoleContext> <ccts:SystemCapabilitiesContext></ccts:SystemCapabilitiesContext> <ccts:UsageRule></ccts:UsageRule> <ccts:BusinessTermName></ccts:BusinessTermName> <ccts:Example></ccts:Example> </xsd:documentation> </xsd:annotation>  <xsd:annotation> <xsd:documentation xml:lang="en"> <ccts:UniqueID></ccts:UniqueID> <ccts:CategoryCode>CCT</ccts:CategoryCode> <ccts:DictionaryEntryName></ccts:DictionaryEntryName> <ccts:VersionID></ccts:VersionID> <ccts:Definition></ccts:Definition> <ccts:RepresentationTermName></ccts:RepresentationTermName> <ccts:PrimitiveType></ccts:PrimitiveType> <xsd:BuiltInType></xsd:BuiltInType> <ccts:UsageRule></ccts:UsageRule> <ccts:BusinessTermName></ccts:BusinessTermName> <ccts:Example></ccts:Example> </xsd:documentation> </xsd:annotation>  <xsd:annotation> <xsd:documentation xml:lang="en"> <ccts:UniqueID></ccts:UniqueID> <ccts:CategoryCode>SC</ccts:CategoryCode> <ccts:DictionaryEntryName></ccts:DictionaryEntryName> <ccts:Definition></ccts:Definition> <ccts:ObjectClassTermNam></ccts: ObjectClassTermName> <ccts:PropertyTermName></ccts:PropertyTermName> <ccts:RepresentationTermName></ccts:RepresentationTermName> <ccts:ObjectClassTermeName></ccts:ObjectClassTermeName> <ccts:PrimitiveType></ccts:PrimitiveType> <xsd:BuiltInType></xsd:BuiltInType> <ccts:UsageRule></ccts:UsageRule> <ccts:Example></ccts:Example> </xsd:documentation> </xsd:annotation>  <xsd:annotation> <xsd:documentation xml:lang="en"> <ccts:UniqueID></ccts:UniqueID> <ccts:CategoryCode>CCT</ccts:CategoryCode> <ccts:DictionaryEntryName></ccts:DictionaryEntryName> <ccts:VersionID></ccts:VersionID> <ccts:Definition></ccts:Definition> <ccts:RepresentationTermName></ccts:RepresentationTermName> <ccts:PrimitiveType></ccts:PrimitiveType> <ccts:UsageRule></ccts:UsageRule> <ccts:BusinessTermName></ccts:BusinessTermName>

5624 5625 5626 5627 5628 5629 5630 5631 5632 5633 5634 5635 5636 5637 5638 5639 5640 5641 5642 5643 5644 5645 5646 5647 5648 5649 5650 5651

<ccts:Example></ccts:Example> </xsd:documentation> </xsd:annotation>  <xsd:annotation> <xsd:documentation xml:lang="en"> <ccts:UniqueID></ccts:UniqueID> <ccts:CategoryCode>SC</ccts:CategoryCode> <ccts:DictionaryEntryName></ccts:DictionaryEntryName> <ccts:Definition></ccts:Definition> <ccts:ObjectClassTermNam></ccts: ObjectClassTermName> <ccts:PropertyTermName></ccts:PropertyTermName> <ccts:RepresentationTermName></ccts:RepresentationTermName> <ccts:ObjectClassTermeName></ccts:ObjectClassTermeName> <ccts:PrimitiveType></ccts:PrimitiveType> <ccts:UsageRule></ccts:UsageRule> <ccts:Example></ccts:Example> </xsd:documentation> </xsd:annotation>  <xsd:annotation> <xsd:documentation xml:lang="en"> <ccts:CodeName></ccts:CodeName> <ccts:CodeDescription></ccts:CodeDescription> </xsd:documentation> </xsd:annotation>

Appendix G. Mapping of CCTS Representation Terms to CCT and UDT Data Types

5652

5653

5654 5655

The following table represents the mapping between the representation terms as defined in CCTS and their equivalent data types as declared in the CCT schema module and the UDT schema module. Representation Term Data Type for CCT Data Type for UDT

Amount xsd:decimal xsd:decimal Binary Object xsd:base64Binary xsd:base64Binary Graphic xsd:base64Binary Sound xsd:base64Binary Video xsd:base64Binary Code xsd:normalizedString xsd:normalizedString Date Time xsd:string xsd:dateTime Date xsd:date Time xsd:time Identifier xsd:normalizedString xsd:normalizedString Indicator xsd:string xsd:boolean Measure xsd:decimal xsd:decimal Value xsd:decimal Percent xsd:decimal Rate xsd:decimal Numeric xsd:string xsd:decimal Quantity xsd:decimal xsd:decimal Text xsd:string xsd:string Name xsd:string

5656


Appendix H. Naming & Design Rules List 5657

5658 5659

5660 5661

5662 5663 5664

5665

5666 5667

5668 5669

5670

5671

5672 5673

5674 5675

5676 5677 5678

5679 5680 5681

5682 5683 5684

5685

5686 5687

5688

5689 5690

5691 5692

5693 5694

5695 5696

5697

5698 5699

5700

[R 1] Conformance shall be determined through adherence to the content of normative sections, rules and definitions.

[R 2] All UN/CEFACT XSD Schema design rules MUST be based on the W3C XML Schema Recommendations: XML Schema Part 1: Structures and XML Schema Part 2: Data Types.

[R 3] All UN/CEFACT XSD Schema and UN/CEFACT conformant XML instance documents MUST be based on the W3C suite of technical specifications holding recommendation status.

[R 4] UN/CEFACT XSD Schema MUST follow the standard structure defined in Appendix B. [R 5] Each element or attribute XML name MUST have one and only one fully qualified XPath

(FQXP). [R 6] Element, attribute and type names MUST be composed of words in the English language,

using the primary English spellings provided in the Oxford English Dictionary. [R 7] Lower camel case (LCC) MUST be used for naming attributes. [R 8] Upper camel case (UCC) MUST be used for naming elements and types. [R 9] Element, attribute and type names MUST be in singular form unless the concept itself is

plural. [R 10] Element, attribute and type names MUST be drawn from the following character set: a-z

and A-Z. [R 11] XML element, attribute and type names constructed from dictionary entry names MUST

NOT include periods, spaces, or other separators; or characters not allowed by W3C XML 1.0 for XML names.

[R 12] XML element, attribute and type names MUST NOT use acronyms, abbreviations, or other word truncations, except those included in the UN/CEFACT controlled vocabulary or listed in Appendix C.

[R 13] Acronyms and abbreviations at the beginning of an attribute declaration MUST appear in all lower case. All other acronym and abbreviation usage in an attribute declaration must appear in upper case.

[R 14] Acronyms MUST appear in all upper case for all element declarations and type definitions. [R 15] All element declarations for BBIEs and ASBIEs MUST be locally declared within the parent

ABIE type. [R 16] A root schema MUST be created for each unique business information exchange. [R 17] A root schema MUST NOT replicate reusable constructs available in schema modules

capable of being referenced through xsd:include or xsd:import. [R 18] UN/CEFACT XSD schema modules MUST either be treated as external schema modules

or as internal schema modules of the root schema. [R 19] All UN/CEFACT internal schema modules MUST be in the same namespace as their

corresponding rsm:RootSchema. [R 20] Each UN/CEFACT internal schema module MUST be named

<ParentRootSchemaModuleName><InternalSchemaModuleFunction>SchemaModule [R 21] A Core Component Type schema module MUST be created [R 22] The cct:CoreComponentType schema module MUST be named "CCTS CCT Schema

Module" [R 23] An Unqualified Data Type schema module MUST be created


[R 24] The udt:UnqualifiedDataType schema module MUST be named "UN/CEFACT Unqualified Data Type Schema Module"

5701 5702

5703

5704 5705

5706

5707 5708

5709

5710 5711 5712 5713 5714 5715 5716

5717 5718

5719 5720 5721 5722 5723 5724 5725 5726

5727 5728 5729

5730 5731

5732 5733

5734

5735

5736 5737 5738 5739 5740 5741 5742 5743 5744 5745 5746

5747 5748 5749 5750 5751 5752

[R 25] A Qualified Data Type schema module MUST be created.. [R 26] The qdt:QualifiedDataType schema module MUST be named "UN/CEFACT Qualified

Data Type Schema Module" [R 27] A Reusable Aggregate Business Information Entity schema module MUST be created [R 28] The ram:ReusableAggregateBusinessInformationEntity schema module MUST

be named "UN/CEFACT Reusable Aggregate Business Information Entity Schema Module" [R 29] Reusable Code List schema modules MUST be created to convey code list enumerations [R 30] The name of each clm:CodeList schema module MUST be of the form: <Code List

Agency Identifier|Code List Agency Name><Code List Identification Identifier|Code List Name> - Code List Schema Module Where: Code List Agency Identifier = Identifies the agency that maintains the code list Code List Agency Name = Agency that maintains the code list Code List Identification Identifier = Identifies a list of the respective corresponding codes Code List Name = The name of the code list as assigned by the agency that maintains the code list

[R 31] An Identifier List schema module MUST be created to convey enumeration values for each identifier list that requires run time validation .

[R 32] The name of each ids:IdentifierList schema module MUST be of the form: <Identifier Scheme Agency Identifier|Identifier Scheme Agency Name><Identifier Scheme Identifier|Identifier Scheme Name> - Identifier List Schema Module Where: Identifier Scheme Agency Identifier = The identification of the agency that maintains the identification scheme Identifier Scheme Agency Name = Agency that maintains the identifier list Identifier Scheme Identifier = The identification of the identification scheme Identification Scheme Name = Name as assigned by the agency that maintains the identifier list

[R 33] Imported schema modules MUST be fully conformant with the UN/CEFACT XML Naming and Design Rules Technical Specification and the Core Components Technical Specification.

[R 34] Every UN/CEFACT defined or imported schema module MUST have a namespace declared, using the xsd:targetNamespace attribute.

[R 35] Every version of a defined or imported schema module other than internal schema modules MUST have its own unique namespace.

[R 36] UN/CEFACT published namespace declarations or contents MUST never be changed. [R 37] UN/CEFACT namespaces MUST be defined as Uniform Resource Names [R 38] The names for namespaces MUST have the following structure while the schema is at draft

status: urn:un:unece:uncefact:<schematype>:draft:<name>:<major>.[<minor>].[<revision] Where: schematype = a token identifying the type of schema module: data|process|codelist|identifierlist|documentation name = the name of the module (using upper camel case) major = the major version number. Sequentially assigned, first release starting with the number 1. minor = the minor version number within a major release. Sequentially assigned, first release starting with the number 0. Not applicable for code list or identifier list schema. revision = sequentially assigned alphanumeric character for each revision of a minor release. Only applicable where status = draft and schema type does not equal code list or identifier list.

[R 39] The namespace names for schema holding specification status MUST be of the form: urn:un:unece:uncefact:<schematype>:standard:<name>:<major>.[<minor>] Where: schematype = a token identifying the type of schema module: data|process|codelist|identifierlist|documentation name = the name of the module major = the major version number, sequentially assigned, first release starting with the number 1. minor = the minor version number within a major release,


sequentially assigned, first release starting with the number 0. Not applicable for code list or identifier list schema.

5753 5754

5755

5756 5757 5758 5759 5760 5761 5762 5763 5764 5765

5766 5767

5768

5769 5770 5771

5772 5773

5774 5775

5776 5777 5778

5779 5780

5781

5782 5783

5784 5785

5786 5787

5788 5789 5790

5791 5792

5793

5794

5795

5796

5797

5798

5799

[R 40] UN/CEFACT namespaces MUST only contain UN/CEFACT developed schema modules. [R 41] The general structure for schema location MUST be:

http://www.unece.org/uncefact/<schematype>/<name>_<major>.<minor>. [<revision>]_[<status>].xsd Where: schematype = a token identifying the type of schema module: data|process|codelist|identifierlist|documentation name = the name of the module (using upper camel case) major = the major version number, sequentially assigned, first release starting with the number 1. minor = the minor version number within a major release, sequentially assigned, first release starting with the number 0. revision = sequentially assigned alphanumeric character for each revision of a minor release. Only applicable where status = draft. status = the status of the schema as: draft|standard

[R 42] Each xsd:schemaLocation attribute declaration MUST contain a persistent and resolvable URL.

[R 43] Each xsd:schemaLocation attribute declaration URL MUST contain an absolute path. [R 44] Every schema major version MUST have the URI of:

urn:un:unece:uncefact:<schematype>:<status>:<name>:<major>.0.[<revision>]

[R 45] Every UN/CEFACT XSD Schema and schema module major version number MUST be a sequentially assigned incremental integer greater then zero.

[R 46] Minor versioning MUST be limited to declaring new optional XSD constructs, extending existing XSD constructs and refinements of an optional nature.

[R 47] Every UN/CEFACT XSD Schema minor version MUST have the URI of: urn:un:unece:uncefact:cc:schema:<name>:<major>.<non-zero integer>.[<revision>]

[R 48] For UN/CEFACT minor version changes, the name of the schema construct MUST NOT change.

[R 49] Changes in minor versions MUST NOT break semantic compatibility with prior versions. [R 50] UN/CEFACT minor version schema MUST incorporate all XML constructs from the

immediately preceding major or minor version schema. [R 51] The xsd:elementFormDefault attribute MUST be declared and its value set to

“qualified”. [R 52] The xsd:attributeFormDefault attribute MUST be declared and its value set to

“unqualified”. [R 53] The “xsd” prefix MUST be used in all cases when referring to

http://www.w3.org/2001/XMLSchema as follows: xmlns:xsd=http://www.w3.org/2001/XMLSchema

[R 54] The xsi prefix SHALL be used where appropriate for referencing xsd:schemaLocation and xsd:noNamespaceLocation attributes in instance documents.

[R 55] xsd:appInfo MUST NOT be used. [R 56] xsd:notation MUST NOT be used. [R 57] xsd:wildcard MUST NOT be used. [R 58] The xsd:any element MUST NOT be used. [R 59] The xsd:any attribute MUST NOT be used. [R 60] Mixed content MUST NOT be used (excluding documentation). [R 61] xsd:substitutionGroup MUST NOT be used.


[R 62] xsd:ID/IDREF MUST NOT be used. 5800

5801

5802

5803 5804

5805 5806

5807 5808

5809 5810

5811

5812 5813

5814

5815 5816 5817

5818

5819

5820 5821

5822 5823 5824

5825 5826

5827 5828

5829

5830 5831 5832

5833 5834 5835

5836 5837 5838

5839 5840

5841 5842

5843 5844

[R 63] xsd:key/xsd:keyref MUST be used for information association. [R 64] The absence of a construct or data MUST NOT carry meaning. [R 65] User declared attributes MUST only be used to convey core component type (CCT)

supplementary component information. [R 66] An attribute of a supplementary component with variable information MUST be based on

the appropriate built-in XSD data type. [R 67] An attribute of a supplementary component which represents codes MUST be based on the

xsd:simpleType of the appropriate code list [R 68] An attribute of a supplementary component which represents identifiers MUST be based on

the xsd:simpleType of the appropriate identifier scheme. [R 69] The xsd:nillable attribute MUST NOT be used. [R 70] All element declarations MUST be local except for a root element that must be declared

globally. [R 71] Empty elements MUST NOT be used. [R 72] The xsd:type of each leaf element declaration MUST be of the data type of its source

business information entity (BBIE) or complex type of its source association business information entity (ASBIE).

[R 73] The xsd:all element MUST NOT be used. [R 74] All type definitions MUST be named. [R 75] Data type definitions MUST NOT duplicate the functionality of an existing data type

definition.. [R 76] xsd:extension MUST only be used in the cct:CoreComponentType schema module and

the udt:UnqualifiedDataType schema module. When used it MUST only extend a built-in XSD datatype.

[R 77] When xsd:restriction is applied to a xsd:simpleType or xsd:complexType the derived construct MUST use a different name.

[R 78] Each UN/CEFACT defined or declared construct MUST use the xsd:annotation element for required CCTS documentation.

[R 79] The root schema module MUST be represented by a unique token. [R 80] The rsm:RootSchema MUST import the following schema modules: –

ram:ReusableABIE Schema Module – udt:UnqualifiedDataType Schema Module – qdt:QualifiedDataType Schema Module

[R 81] A rsm:RootSchema in one UN/CEFACT namespace that is dependent upon type definitions or element declaration defined in another namespace MUST import the rsm:RootSchema from that namespace.

[R 82] A rsm:RootSchema in one UN/CEFACT namespace that is dependant upon type definitions or element declarations defined in another namespace MUST NOT import Schema Modules from that namespace other than the rsm:RootSchema.

[R 83] The rsm:RootSchema MUST include any internal schema modules that reside in the root schema namespace.

[R 84] A single global element known as the root element MUST be globally declared in a rsm:RootSchema.

[R 85] The name of the root element MUST be the name of the Message Assembly with separators and spaces removed.


[R 86] Root schema MUST define a single xsd:complexType that fully describes the business information exchange.

5845 5846

5847 5848

5849

5850 5851 5852 5853 5854 5855 5856 5857 5858 5859 5860 5861 5862 5863 5864 5865 5866 5867 5868 5869 5870 5871 5872 5873 5874

5875 5876

5877 5878

5879 5880

5881 5882 5883

5884 5885

5886 5887

5888 5889 5890

5891

5892 5893

5894 5895

[R 87] The name of the top-level complex type MUST be the name of the root element with the

word “Type” appended. [R 88] The xsd:complexType of the root element must be the top-level complex type. [R 89] For every rsm:RootSchema root element declaration a structured set of annotations

MUST be present in the following pattern: • UniqueID (mandatory): The identifier that references the Message Assembly instance in

a unique and unambiguous way. • CategoryCode (mandatory): The category to which the object belongs. In this case the

value will always be RSM. • Name (mandatory): The name of the Message Assembly • VersionID (mandatory): An indication of the evolution over time of a Message Assembly. • Description (mandatory): A brief description of the business information exchange. • BusinessDomain (mandatory, repetitive): The TBG group(s) that developed this

Message Assembly. • BusinessProcessContext (mandatory, repetitive): The business process with which this

Message Assembly is associated. • GeopoliticalorRegionContext (optional, repetitive): The geopolitical/region contexts for

this Message Assembly. • OfficialConstraintContext (optional, repetitive): The official constraint context for this

Message Assembly. • ProductContext (optional, repetitive): The product context for this Message Assembly. • IndustryContext (optional, repetitive): The industry context for this Message Assembly. • BusinessProcessRoleContext (optional, repetitive): The role context for this Message

Assembly. • SupportingRoleContext (optional, repetitive): The supporting role context for this

Message Assembly. • SystemCapabilitiesContext (optional, repetitive): The system capabilities context for this

Message Assembly. [R 90] All UN/CEFACT internal schema modules MUST be in the same namespace as their

corresponding rsm:RootSchema. [R 91] The internal schema module MUST be represented by the same token as its

rsm:RootSchema. [R 92] The Reusable Aggregate Business Information Entity schema module MUST be

represented by the token “ram”. [R 93] The ram:ReusableAggregateBusinessInformationEntity schema MUST import

the following schema modules: – udt:UnqualifiedDataType Schema Module – qdt:QualifiedDataType Schema Module

[R 94] For every object class (ABIE) identified in the UN/CEFACT syntax-neutral model, a named xsd:complexType MUST be defined.

[R 95] The name of the ABIE xsd:complexType MUST be the ccts:DictionaryEntryName with the separators removed and with the "Details" suffix replaced with "Type".

[R 96] Every aggregate business information entity (ABIE) xsd:complexType definition xsd:content model MUST use the xsd:sequence and/or xsd:choice elements with appropriate local element declarations to reflect each property (BBIE or ASBIE) of its class.

[R 97] Recursion of xsd:sequence and/or xsd:choice MUST NOT occur. [R 98] The order and cardinality of the elements within an ABIE xsd:complexType MUST be

according to the structure of the ABIE as defined in the model. [R 99] For every attribute of an object class (BBIE) identified in an ABIE, a named xsd:element

MUST be locally declared within the xsd:complexType representing that ABIE.


[R 100] Each BBIE element name declaration MUST be based on the property term and qualifiers and the representation term of the basic business information entity (BBIE). If there are successive duplicate words in the property term and representation terms of the source dictionary entry name, then the duplicate words MUST be removed.

5896 5897 5898 5899

5900

5901 5902 5903

5904 5905 5906

5907 5908 5909 5910

5911 5912

5913 5914 5915 5916 5917 5918 5919 5920 5921 5922 5923 5924 5925 5926 5927 5928 5929 5930 5931 5932 5933 5934 5935 5936 5937 5938 5939 5940

5941 5942 5943 5944 5945 5946 5947 5948 5949

[R 101] If the representation term of a BBIE is ‘text’, it MUST be removed. [R 102] The BBIE element MUST be based on an appropriate data type that is defined in the

UN/CEFACT qdt:QualifiedDataType or udt:UnqualifiedDataType schema modules.

[R 103] For every association (ASBIE) identified in the UN/CEFACT syntax-neutral model, a named xsd:element MUST be locally declared within the xsd:complexType representing the ABIE.

[R 104] Each ASBIE element name declaration MUST be based on the property term and object class of the association business information entity (ASBIE). If there are successive duplicate words in the property term and object class of the associated ABIE, then the duplicate words MUST be removed.

[R 105] The element representing an association business information entity (ASBIE) MUST be of the complex type corresponding to its associated aggregate business information (ABIE).

[R 106] For every ABIE xsd:complexType definition a structured set of annotations MUST be present in the following pattern: • UniqueID (mandatory): The identifier that references an ABIE instance in a unique and

unambiguous way. • CategoryCode (mandatory): The category to which the object belongs. In this case the

value will always be ABIE. • DictionaryEntryName (mandatory): The official name of an ABIE. • VersionID (mandatory): An indication of the evolution over time of an ABIE instance. • Definition (mandatory): The semantic meaning of an ABIE. • ObjectClassTermName (mandatory): The Object Class Term of the ABIE. • QualifierTermName (optional): Qualifies the Object Class Term of the ABIE. • UsageRule (optional, repetitive): A constraint that describes specific conditions that are

applicable to the ABIE. • BusinessTermName (optional, repetitive): A synonym term under which the ABIE is

commonly known and used in the business. • BusinessProcessContext (optional, repetitive): The business process with which this

ABIE is associated. • GeopoliticalorRegionContext (optional, repetitive): The geopolitical/region contexts for

this ABIE. • OfficialConstraintContext (optional, repetitive): The official constraint context for this

ABIE. • ProductContext (optional, repetitive): The product context for this ABIE. • IndustryContext (optional, repetitive): The industry context for this ABIE. • BusinessProcessRoleContext (optional, repetitive): The role context for this ABIE. • SupportingRoleContext (optional, repetitive): The supporting role context for this ABIE. • SystemCapabilitiesContext (optional, repetitive): The system capabilities context for this

ABIE. • Example (optional, repetitive): Example of a possible value of an ABIE.

[R 107] For every BBIE xsd:element declaration a structured set of annotations MUST be present in the following pattern: • UniqueID (mandatory): The identifier that references a BBIE instance in a unique and


value will always be BBIE. • Dictionary Entry Name (mandatory): The official name of the BBIE. • VersionID (mandatory): An indication of the evolution over time of a BBIE instance. • Definition (mandatory): The semantic meaning of the BBIE.


• Cardinality (mandatory): Indication whether the BIE Property represents a not-applicable, optional, mandatory and/or repetitive characteristic of the ABIE.

5950 5951 5952 5953 5954 5955 5956 5957 5958 5959 5960 5961 5962 5963 5964 5965 5966 5967 5968 5969 5970 5971 5972 5973 5974 5975 5976

5977 5978 5979 5980 5981 5982 5983 5984 5985 5986 5987 5988 5989 5990 5991 5992 5993 5994 5995 5996 5997 5998 5999 6000 6001 6002 6003 6004 6005 6006

• ObjectClassTermName (mandatory): The Object Class Term of the parent ABIE. • ObjectClassQualifierTermName (optional): Qualifies the Object Class Term of the parent

ABIE. • PropertyTermName (mandatory): The Property Term of the BBIE. • PropertyQualifierTermName (optional): Qualifies the Property Term of the BBIE. • RepresentationTermName (mandatory): The Representation Term of the BBIE. • UsageRule (optional, repetitive): A constraint that describes specific conditions that are

applicable to the BBIE. • BusinessProcessContext (optional, repetitive): The business process with which this

BBIE is associated. • GeopoliticalorRegionContext (optional, repetitive): The geopolitical/region contexts for

this BBIE. • OfficialConstraintContext (optional, repetitive): The official constraint context for this

BBIE. • ProductContext (optional, repetitive): The product context for this BBIE. • IndustryContext (optional, repetitive): The industry context for this BBIE. • BusinessProcessRoleContext (optional, repetitive): The role context for this BBIE. • SupportingRoleContext (optional, repetitive): The supporting role context for this BBIE. • SystemCapabilitiesContext (optional, repetitive): The system capabilities context for this

BBIE. • UsageRule (optional, repetitive): A constraint that describes specific conditions that are

applicable to this BBIE. • BusinessTermName (optional, repetitive): A synonym term under which the BBIE is

commonly known and used in the business. • Example (optional, repetitive): Example of a possible value of a BBIE.

[R 108] For every ASBIE xsd:element declaration a structured set of annotations MUST be present in the following pattern: • UniqueID (mandatory): The identifier that references an ASBIE instance in a unique and


value will always be ASBIE. • DictionaryEntryName (mandatory): The official name of the ASBIE. • VersionID (mandatory): An indication of the evolution over time of the ASBIE instance. • Definition (mandatory): The semantic meaning of the ASBIE. • Cardinality (mandatory): Indication whether the ASBIE Property represents a not-

applicable, optional, mandatory and/or repetitive characteristic of the ABIE. • ObjectClassTermName (mandatory): The Object Class Term of the associating ABIE. • ObjectClassQualifierTermName (Optional): A term that qualifies the Object Class Term of

the associating ABIE. • PropertyTermName (mandatory): The Property Term of the ASBIE. • PropertyQualifierTermName (Optional): A term that qualifies the Property Term of the

ASBIE. • AssociatedObjectClassTermName (mandatory): The Object Class Term of the

associated ABIE. • AssociatedObjectClassQualifierTermName (optional): Qualifies the Object Class Term of

the associated ABIE. • BusinessProcessContext (optional, repetitive): The business process with which this

ASBIE is associated. • GeopoliticalorRegionContext (optional, repetitive): The geopolitical/region contexts for

this ASBIE. • OfficialConstraintContext (optional, repetitive): The official constraint context for this

ASBIE. • ProductContext (optional, repetitive): The product context for this ASBIE. • IndustryContext (optional, repetitive): The industry context for this ASBIE. • BusinessProcessRoleContext (optional, repetitive): The role context for this ASBIE.


• SupportingRoleContext (optional, repetitive): The supporting role context for this ASBIE. 6007 6008 6009 6010 6011 6012 6013 6014

6015

6016 6017

6018 6019

6020 6021 6022

6023 6024

6025 6026 6027 6028

6029 6030 6031

6032 6033 6034

6035 6036 6037

6038 6039 6040

6041 6042 6043

6044 6045

6046 6047 6048 6049 6050 6051 6052 6053 6054 6055 6056 6057

• SystemCapabilitiesContext (optional, repetitive): The system capabilities context for this ASBIE.

• UsageRule (optional, repetitive): A constraint that describes specific conditions that are applicable to the ASBIE.

• BusinessTermName (optional, repetitive): A synonym term under which the ASBIE is commonly known and used in the business.

• Example (optional, repetitive): Example of a possible value of an ASBIE. [R 109] The core component type (CCT) schema module MUST be represented by the token "cct". [R 110] The cct:CoreCoreComponentType schema module MUST NOT include or import any

other schema modules. [R 111] Every cct:CoreComponentType MUST be defined as a named xsd:complexType in

the cct:CoreComponentType schema module. [R 112] The name of each xsd:complexType based on a cct:CoreComponentType MUST be

the dictionary entry name of the core component type (CCT), with the separators and spaces removed.

[R 113] Each cct:CoreComponentType xsd:complexType definition MUST contain one xsd:simpleContent element.

[R 114] The cct:CoreComponentType xsd:complexType definition xsd:simpleContent element MUST contain one xsd:extension element. This xsd:extension element must include an XSD based attribute that defines the specific built-in XSD data type required for the CCT content component.

[R 115] Within the cct:CoreComponentType xsd:extension element a xsd:attribute MUST be declared for each supplementary component pertaining to that cct:CoreComponentType.

[R 116] Each cct:CoreComponentType supplementary component xsd:attribute "name" MUST be the CCTS supplementary component dictionary entry name with the separators and spaces removed.



[R 119] If the representation term of the supplementary component dictionary entry name is ‘text’, the representation term MUST be removed from the supplementary component xsd:attribute name.

[R 120] The attribute representing as supplementary component MUST be based on the appropriate built-in XSD data type.

[R 121] For every cct:CoreComponentType xsd:complexType definition a structured set of annotations MUST be present in the following pattern: • UniqueID (mandatory): The identifier that references the Core Component Type instance

in a unique and unambiguous way. • CategoryCode (mandatory): The category to which the object belongs. In this case the

value will always be CCT. • DictionaryEntryName (mandatory): The official name of a Core Component Type. • VersionID (mandatory): An indication of the evolution over time of a Core Component

Type instance. • Definition (mandatory): The semantic meaning of a Core Component Type. • RepresentationTermName (mandatory): The primary representation term of the Core

Component Type.


• PrimitiveType (mandatory): The primitive data type of the Core Component Type. 6058 6059 6060 6061 6062 6063

6064 6065 6066 6067 6068 6069 6070 6071 6072 6073 6074 6075 6076 6077 6078 6079 6080

6081 6082

6083 6084 6085

6086 6087 6088

6089 6090 6091

6092 6093 6094 6095

6096 6097 6098 6099

6100 6101 6102 6103

6104 6105

6106 6107 6108 6109

• UsageRule (optional, repetitive): A constraint that describes specific conditions that are applicable to the Core Component Type.

• BusinessTermName (optional, repetitive): A synonym term under which the Core Component Type is commonly known and used in the business.

• Example (optional, repetitive): Example of a possible value of a Core Component Type. [R 122] For every supplementary component xsd:attribute declaration a structured set of

annotations MUST be present in the following pattern: • UniqueID (mandatory): The identifier that references a Supplementary Component

instance in a unique and unambiguous way. • CategoryCode (mandatory): The category to which the object belongs. In this case the

value will always be SC. • DictionaryEntryName (mandatory): The official name of the Supplementary Component. • Definition (mandatory): The semantic meaning of the Supplementary Component. • ObjectClassTermName (mandatory): The Object Class of the Supplementary

Component. • PropertyTermName (mandatory): The Property Term of the Supplementary Component. • RepresentationTermName (mandatory): The Representation term of the Supplementary

Component. • PrimitiveType (mandatory): The primitive data type of the Supplementary Component. • UsageRule (optional, repetitive): A constraint that describes specific conditions that are

applicable to the Supplementary Core Component. • Example (optional, repetitive): Example of a possible value of a Basic Core Component.

[R 123] The Unqualified Data Type schema module namespace MUST be represented by the token "udt".

[R 124] The udt:UnqualifiedDataType schema MUST NOT import any other schema modules than the following: – ids:IdentifierList schema modules – clm:CodeList schema modules

[R 125] A udt:UnqualifiedDataType MUST be defined for each approved primary and secondary representation terms identified in the CCTS Permissible Representation Terms table.

[R 126] The name of each udt:UnqualifiedDataType MUST be the dictionary entry name of the primary or secondary representation term, with “Type” at the end and the separators and spaces removed.

[R 127] For every udt:UnqualifiedDataType whose supplementary components map directly to the properties of a built-in xsd:dataTtpe, the udt:UnqualifiedDataType MUST be defined as a named xsd:simpleType in the udt:UnqualifiedDataType schema module.

[R 128] Every udt:UnqualifiedDataType defined as a xsd:simpleType MUST contain one xsd:restriction element. This xsd:restriction element MUST include an xsd:base attribute that defines the specific built-in XSD data type required for the content component.

[R 129] For every udt:UnqualfiedDataType whose supplementary components are not equivalent to the properties of a built-in XSD data type, a udt:UnqualifiedDataType MUST be defined as an xsd:complexType in the udt:UnqualifiedDataType schema module.

[R 130] Every udt:UnqualifiedDataType xsd:complexType definition MUST contain one xsd:simpleContent element.

[R 131] Every udt:UnqualifiedDataType xsd:complexType xsd:simpleContent element MUST contain one xsd:extension element. This xsd:extension element must include an xsd:base attribute that defines the specific built-in XSD datatype required for the content component.


[R 132] Within the udt:UnqualifiedDataType xsd:complextype xsd:extension element an xsd:attribute MUST be declared for each supplementary component pertaining to the underlying CCT, unless the attribute is contained in the namespace declaration.

6110 6111 6112

6113 6114

6115 6116 6117

6118 6119 6120

6121 6122 6123

6124 6125 6126

6127 6128 6129 6130

6131 6132 6133

6134 6135 6136 6137 6138 6139 6140 6141 6142 6143 6144 6145 6146 6147 6148 6149 6150

6151 6152 6153 6154 6155 6156 6157 6158 6159 6160 6161 6162 6163

[R 133] Each supplementary component xsd:attribute name MUST be the supplementary

component name with the separators and spaces removed. [R 134] If the object class of the supplementary component dictionary entry name contains the

name of the representation term of the parent CCT, the duplicated object class word or words MUST be removed from the supplementary component xsd:attribute name.


[R 136] If the representation term of the supplementary component dictionary entry name is ‘text’, the representation term MUST be removed from the supplementary component xsd:attribute name.

[R 137] If the representation term of the relevant supplementary component is a “Code” and validation is required, then the attribute representing this supplementary component MUST be based on the defined xsd:simpleType of the appropriate external imported code list.

[R 138] If the representation term of the relevant supplementary component is an “Identifier” and validation is required, then the attribute representing this supplementary component MUST be based on the defined xsd:simpleType of the appropriate external imported identifier scheme.

[R 139] If the representation term of the supplementary component is not “Code” or “Identifier”, then the attribute representing this supplementary component MUST be based on the appropriate built-in XSD data type.

[R 140] For every udt:UnqualifiedDataType xsd:complexType or xsd:simpleType definition a structured set of annotations MUST be present in the following pattern: • UniqueID (mandatory): The identifier that references an Unqualified Data Type instance

in a unique and unambiguous way. • CategoryCode (mandatory): The category to which the object belongs. In this case the

value will always be UDT. • DictionaryEntryName (mandatory): The official name of the Unqualified Data Type. • VersionID (mandatory): An indication of the evolution over time of the Unqualified Data

Type instance. • Definition (mandatory): The semantic meaning of the Unqualified Data Type. • RepresentationTermName (mandatory): The primary or secondary representation term

of the associated Core Component Type. • PrimitiveType (mandatory): The primitive data type of the Unqualified Data Type. • BuiltInType (mandatory): The XSD built-in data type of the Unqualified Data Type. • UsageRule (optional, repetitive): A constraint that describes specific conditions that are

applicable to the Unqualified Data Type. • Example (optional, repetitive): Example of a possible value of an Unqualified Data Type.

[R 141] For every supplementary component xsd:attribute declaration a structured set of annotations MUST be present in the following pattern: • UniqueID (mandatory): The identifier that references a Supplementary Component

instance in a unique and unambiguous way. • CategoryCode (mandatory): The category to which the object belongs. In this case the

value will always be SC. • Dictionary Entry Name (mandatory): The official name of the Supplementary Component. • Definition (mandatory): The semantic meaning of the Supplementary Component. • ObjectClassTermName (mandatory): The Object Class of the Supplementary

Component. • PropertyTermName (mandatory): The Property Term of the Supplementary Component. • RepresentationTermName (mandatory): The Representation term of the Supplementary

Component.


• UsageRule (optional, repetitive): A constraint that describes specific conditions that are applicable to the Supplementary Core Component.

6164 6165 6166

6167 6168

6169 6170

6171 6172

6173 6174

6175 6176 6177

6178 6179 6180 6181 6182

6183 6184 6185 6186 6187

6188 6189 6190

6191 6192 6193

6194 6195 6196 6197 6198 6199 6200 6201 6202 6203 6204 6205 6206 6207 6208 6209 6210 6211 6212 6213 6214

• Example (optional, repetitive): Example of a possible value of a Basic Core Component.

[R 142] The UN/CEFACT:QualifiedDataType schema module namespace MUST be represented by the token “qdt”.

[R 143] The qdt:QualifiedDataType schema module MUST import the udt:UnqualifiedDataType schema module

[R 144] Where required to change facets of an existing udt:UnqualifiedDataType, a new data type MUST be defined in the qdt:QualifiedDataType schema module.

[R 145] A qdt:QualifiedDataType MUST be based on an unqualified data type and add some semantic and/or technical restriction to the unqualified data type

[R 146] The name of a qdt:QualifiedDataType MUST be the name of its base udt:UnqualifiedDataType with separators and spaces removed and with its qualifier term added.

[R 147] Every qdt:QualifiedDataType based on a udt:UnqualifiedDataType xsd:complexType whose supplementary components map directly to the properties of a built-in xsd:data type MUST be defined as a xsd:simpleType MUST contain one xsd:restriction element MUST include a xsd:base attribute that defines the specific built-in XSD data type required for the content component.

[R 148] Every qdt:QualifiedDataType based on a udt:UnqualifiedDataType xsd:complexType whose supplementary components do not map directly to the properties of a built-in xsd:data type MUST be defined as a xsd:complexType MUST contain one xsd:simpleContent element MUST contain one xsd:extension element MUST include the udt:UnqualifiedDataType as its xsd:base attribute

[R 149] Every qdt:QualifiedDataType based on a udt:UnqualifiedDataType xsd:simpleType MUST contain one xsd:restriction element MUST include the udt:UnqualifiedDataType as its xsd:base attribute

[R 150] The qdt:QualifiedDataType xsd:complexType definition xsd:simpleContent element MUST only restrict attributes declared in its base type, or MUST only restrict facets equivalent to allowed supplementary components.

[R 151] Every qdt:QualifiedDataType definition MUST contain a structured set of annotations in the following sequence and pattern: • UniqueID (mandatory): The identifier that references a Qualified Data Type instance in a

unique and unambiguous way. • CategoryCode (mandatory): The category to which the object belongs. In this case the

value will always be QDT. • DictionaryEntryName (mandatory): The official name of the Qualified Data Type. • VersionID (mandatory): An indication of the evolution over time of the Qualified Data

Type instance. • Definition (mandatory): The semantic meaning of the Qualified Data Type. • RepresentationTermName (mandatory): The Representation Term of the Qualified Data

Type. • PrimitiveType (mandatory): The primitive data type of the Qualified Data Type. • BuiltInType (mandatory): The XSD built-in data type of the Qualified Data Type. • Data Type Qualifier Term (mandatory): A term that qualifies the Representation Term in

order to differentiate it from its underlying Unqualified Data Type and other Qualified Data Types.

• BusinessProcessContext (optional, repetitive): The business process context for this Qualified Data Type is associated.

• GeopoliticalorRegionContext (optional, repetitive): The geopolitical/region contexts for this Qualified Data Type.


• OfficialConstraintContext (optional, repetitive): The official constraint context for this Qualified Data Type.

6215 6216 6217 6218 6219 6220 6221 6222 6223 6224 6225 6226 6227

6228 6229 6230 6231 6232 6233 6234 6235 6236 6237 6238 6239 6240 6241 6242 6243 6244 6245 6246 6247 6248 6249 6250 6251 6252 6253 6254 6255 6256 6257 6258 6259 6260 6261 6262 6263 6264

6265

6266 6267

6268 6269 6270

• ProductContext (optional, repetitive): The product context for this Qualified Data Type. • IndustryContext (optional, repetitive): The industry context for this Qualified Data Type. • BusinessProcessRoleContext (optional, repetitive): The role context for this Qualified

Data Type. • SupportingRoleContext (optional, repetitive): The supporting role context for this

Qualified Data Type. • SystemCapabilitiesContext (optional, repetitive): The system capabilities context for this

Qualified Data Type. • UsageRule (optional, repetitive): A constraint that describes specific conditions that are

applicable to the Qualified Data Type. • Example (optional, repetitive): Example of a possible value of a Qualified Data Type.

[R 152] For every supplementary component xsd:attribute declaration a structured set of annotations MUST be present in the following pattern: • UniqueID (mandatory): The identifier that references a Supplementary Component of a

Core Component Type instance in a unique and unambiguous way. • CategoryCode (mandatory): The category to which the object belongs. In this case the

value will always be QDT. • Dictionary Entry Name (mandatory): The official name of a Supplementary Component. • VersionID (mandatory): An indication of the evolution over time of a Supplementary

Component instance. • Definition (mandatory): The semantic meaning of a Supplementary Component. • Cardinality (mandatory): Indication whether the Supplementary Component Property

represents a not-applicable, optional, mandatory and/or repetitive characteristic of the Core Component Type.

• PropertyTermName (optional): The Property Term of the associated Supplementary Component.

• RepresentationTermName (optional): The Representation Term of the associated Suppplementary Component.

• UsageRule (optional, repetitive): A constraint that describes specific conditions that are applicable to the Supplementary Component.

• BusinessProcessContext (optional, repetitive): The business process with which this Supplementary Component is associated.

• GeopoliticalorRegionContext (optional, repetitive): The geopolitical/region contexts for this Supplementary Component.

• OfficialConstraintContext (optional, repetitive): The official constraint context for this Supplementary Component.

• ProductContext (optional, repetitive): The product context for this Supplementary Component.

• IndustryContext (optional, repetitive): The industry context for this Supplementary Component.

• BusinessProcessRoleContext (optional, repetitive): The role context for this Qualified Data Type.

• SupportingRoleContext (optional, repetitive): The supporting role context for this Supplementary Component.

• SystemCapabilitiesContext (optional, repetitive): The system capabilities context for this Supplementary Component.

• Example (optional, repetitive): Example of a possible value of a Supplementary Component.

[R 153] Each UN/CEFACT maintained code list MUST be defined in its own schema module. [R 154] Internal code list schema MUST NOT duplicate existing external code list schema when the

existing ones are available to be imported. [R 155] The names for namespaces MUST have the following structure while the schema is at draft

status: urn:un:unece:uncefact:codelist:draft:<Code List Agency Identifier|Code List Agency Name Text>:<Code List Identification.


Identifier|Code List Name Text>:<Code List Version. Identifier> Where: codelist = this token identifying the schema as a code list Code List Agency Identifier = identifies the agency that manages a code list. The default agencies used are those from DE 3055 but roles defined in DE 3055 cannot be used. Code List Agency Name Text = the name of the agency that maintains the code list. Code List Identification Identifier = identifies a list of the respective corresponding codes. listID is only unique within the agency that manages this code list. Code List Name Text = the name of a list of codes. Code List Version Identifier = identifies the version of a code list.

6271 6272 6273 6274 6275 6276 6277 6278

6279 6280 6281 6282 6283 6284 6285 6286 6287 6288 6289

6290 6291 6292 6293 6294

6295 6296 6297 6298 6299 6300 6301 6302 6303 6304 6305 6306

6307 6308

6309 6310

6311

6312 6313

6314 6315

6316

6317 6318

6319 6320

6321

[R 156] The namespace names for schema holding specification status MUST be of the form:

urn:un:unece:uncefact:codelist:standard:<Code List. Agency Identifier|Code List Agency Name Text>:<Code List Identification. Identifier|Code List Name Text>:<Code List Version Identifier> Where: codelist = this token identifying the schema as a code list Code List Agency Identifier = identifies the agency that manages a code list. The default agencies used are those from DE 3055 but roles defined in DE 3055 cannot be used. Code List Agency Name Text = the name of the agency that maintains the code list. Code List Identification Identifier = identifies a list of the respective corresponding codes. listID is only unique within the agency that manages this code list. Code List Name Text = the name of a list of codes. Code List Version Identifier = identifies the version of a code list.

[R 157] Each UN/CEFACT maintained code list schema module MUST be represented by a unique token constructed as follows: clm[Qualified data type name]<Code List Agency Identifier|Code List Agency Name Text><Code List Identification Identifier|Code List Name Text> with any repeated words eliminated.

[R 158] The structure for schema location of code lists MUST be: http://www.unece.org/uncefact/codelist/<status>/<Code List. Agency Identifier|Code List Agency Name Text>/<Code List Identification Identifier|Code List Name Text>_<Code List Version Identifier>.xsd Where: schematype = a token identifying the type of schema module: codelist status = the status of the schema as: draft|standard Code List Agency Identifier = identifies the agency that manages a code list. The default agencies used are those from DE 3055 but roles defined in DE 3055 cannot be used. Code List Agency Name Text = the name of the agency that maintains the code list. Code List Identification Identifier = identifies a list of the respective corresponding codes. listID is only unique within the agency that manages this code list. Code List Name Text = the name of a list of codes. Code List Version Identifier = identifies the version of a code list.

[R 159] Each xsd:schemaLocation attribute declaration of a code list MUST contain a persistent and resolvable URL.

[R 160] Each xsd:schemaLocation attribute declaration URL of a code list MUST contain an absolute path.

[R 161] Code List schema modules MUST not import or include any other schema modules. [R 162] Within each code list module one, and only one, named xsd:simpleType MUST be

defined for the content component. [R 163] The name of the xsd:simpleType MUST be the name of root element based on the

value of the code list name text with the word “ContentType” appended. [R 164] The xsd:restriction element base attribute value MUST be set to “xsd:token”. [R 165] Each code in the code list MUST be expressed as an xsd:enumeration, where the

xsd:value for the enumeration is the actual code value. [R 166] Facets other than xsd:enumeration MUST NOT be used in the code list schema

module. [R 167] For each code list a single root element MUST be globally declared.


[R 168] The name of root element MUST be based on the code list name text following the naming rules as defined in section 5.3.

6322 6323

6324

6325 6326

6327 6328

6329

6330 6331 6332 6333 6334 6335 6336 6337 6338 6339 6340

6341 6342 6343 6344 6345 6346 6347 6348 6349 6350 6351

6352 6353 6354 6355

6356 6357 6358 6359 6360 6361 6362 6363 6364 6365 6366 6367

6368 6369

6370 6371

6372

6373 6374

[R 169] The root element MUST be of a type representing the actual list of code values. [R 170] Each xsd:enumeration MUST include an annotation documentation providing the code

name and the code description. [R 171] Internal identifier lists schema MUST NOT duplicate existing external identifier list schema

when the existing ones are available to be imported. [R 172] Each UN/CEFACT maintained identifier list MUST be defined in its own schema module. [R 173] The names for namespaces MUST have the following structure while the schema is at draft

status: urn:un:unece:uncefact:identifierlist:draft:<Identifier Scheme. Agency Identifier|Identifier Scheme Agency Name Text>:<Identifier Scheme Identifier|Identifier Scheme Name Text>:<Identifier Scheme Version Identifier> Where: identifierlist = this token identifying the schema as an identifier scheme Identifier Scheme Agency Identifier = the identification of the agency that maintains the identification scheme. Identifier Scheme Agency Name. Text = the name of the agency that maintains the identification list. Identifier Scheme Identifier = the identification of the identification scheme. Identifier Scheme Name. Text = the name of the identification scheme. Identifier Scheme Version. Identifier = the version of the identification scheme.

[R 174] The namespace names for identifier list schema holding specification status MUST be of the form: urn:un:unece:uncefact:identifierlist:standard:<Identifier Scheme. Agency Identifier|Identifier Scheme Agency Name Text>:<Identifier Scheme Identifier|Identifier Scheme Name Text>:<Identifier Scheme. Version Identifier> Where: identifierlist = this token identifying the schema as an identifier scheme Identifier Scheme Agency Identifier = the identification of the agency that maintains the identification scheme. Identifier Scheme Agency Name. Text = the name of the agency that maintains the identification scheme. Identifier Scheme Identifier = the identification of the identification scheme. Identifier Scheme Name. Text = the name of the identification scheme. Identifier Scheme Version. Identifier = the version of the identification scheme.

[R 175] Each UN/CEFACT maintained identifier list schema module MUST be represented by a unique token constructed as follows: ids[Qualified data type name]<Identification Scheme Agency Identifier><Identification Scheme Identifier>

[R 176] The structure for schema location of identifier lists MUST be: http://www.unece.org/uncefact/identifierlist/<status>/<Identifier Scheme Agency Identifier|Identifier Scheme Agency Name Text>/< Identifier Scheme Identifier|Identifier Scheme Name Text>_< Identifier Scheme Version Identifier>.xsd Where: schematype = a token identifying the type of schema module: identifierlist status = the status of the schema as: draft|standard Identifier Scheme. Agency Identifier = the identification of the agency that maintains the identification scheme. Identifier Scheme. Agency Name. Text = the name of the agency that maintains the identification scheme. Identifier Scheme. Identifier = the identification of the identification scheme. Identifier Scheme. Name. Text = the name of the identification scheme. Identifier Scheme. Version. Identifier = the version of the identification scheme.

[R 177] Each xsd:schemaLocation attribute declaration of an identifier list schema MUST contain a persistent and resolvable URL.

[R 178] Each xsd:schemaLocation attribute declaration URL of an identifier list schema MUST contain an absolute path.

[R 179] Identifier list schema modules MUST NOT import or include any other schema modules. [R 180] Within each identifier list schema module one, and only one, named xsd:simpleType

MUST be defined for the content component.


[R 181] The name of the xsd:simpleType MUST be the name of root element with the word “ContentType” appended.

6375 6376

6377

6378 6379

6380 6381

6382

6383 6384

6385

6386 6387

6388 6389

6390 6391

6392

6393

6394

[R 182] The xsd:restriction element base attribute value MUST be set to “xsd:token”. [R 183] Each identifier in the identifier list MUST be expressed as an xsd:enumeration, where the

xsd:value for the enumeration is the actual identifier value. [R 184] Facets other than xsd:enumeration MUST NOT be used in the identifier list schema

module. [R 185] For each identifier list a single root element MUST be globally declared. [R 186] The name of the root element MUST be based on the identification scheme.

name. text following the naming rules as defined in section 5.3. [R 187] The root element MUST be of a type representing the actual list of identifier values. [R 188] Each xsd:enumeration MUST include an annotation documentation providing the

identifier name and optionally the description of the identifier. [R 189] All UN/CEFACT XML MUST be instantiated using UTF . UTF-8 should be used as the

preferred encoding. If UTF-8 is not used, UTF-16 MUST be used. [R 190] UN/CEFACT conformant instance documents MUST NOT contain an element devoid of

content. [R 191] The xsi:nil attribute MUST NOT appear in any conforming instance. [R 192] The xsi:type attribute MUST NOT be used.


Appendix I. Glossary 6395

6396 6397 6398

6399 6400 6401 6402

6403 6404 6405

6406 6407 6408 6409 6410 6411

6412 6413 6414

6415 6416 6417 6418

6419 6420

6421 6422

6423 6424 6425 6426 6427

6428 6429

6430 6431 6432 6433 6434

6435 6436

6437 6438

6439 6440 6441 6442

6443 6444

Aggregate Business Information Entity (ABIE) – A collection of related pieces of business information that together convey a distinct business meaning in a specific Business Context. Expressed in modelling terms, it is the representation of an Object Class, in a specific Business Context.

Aggregate Core Component - (ACC) – A collection of related pieces of business information that together convey a distinct business meaning, independent of any specific Business Context. Expressed in modelling terms, it is the representation of an Object Class, independent of any specific Business Context.

Assembly Rules - Assembly Rules group sets of unrefined Business Information Entities into larger structures. Assembly Rules are more fully defined and explained in the Assembly Rules Supplemental Document.

Association Business Information Entity (ASBIE) - A Business Information Entity that represents a complex business characteristic of a specific Object Class in a specific Business Context. It has a unique Business Semantic definition. An Association Business Information Entity represents an Association Business Information Entity Property and is therefore associated to an Aggregate Business Information Entity, which describes its structure. An Association Business Information Entity is derived from an Association Core Component.

Association Business Information Entity Property - A Business Information Entity Property for which the permissible values are expressed as a complex structure, represented by an Aggregate Business Information Entity.

Association Core Component (ASCC) - A Core Component which constitutes a complex business characteristic of a specific Aggregate Core Component that represents an Object Class. It has a unique Business Semantic definition. An Association Core Component represents an Association Core Component Property and is associated to an Aggregate Core Component, which describes its structure.

Association Core Component Property – A Core Component Property for which the permissible values are expressed as a complex structure, represented by an Aggregate Core Component.

Attribute – A named value or relationship that exists for some or all instances of some entity and is directly associated with that instance.

Basic Business Information Entity (BBIE) – A Business Information Entity that represents a singular business characteristic of a specific Object Class in a specific Business Context. It has a unique Business Semantic definition. A Basic Business Information Entity represents a Basic Business Information Entity Property and is therefore linked to a Data Type, which describes it values. A Basic Business Information Entity is derived from a Basic Core Component.

Basic Business Information Entity Property – A Business Information Entity Property for which the permissible values are expressed by simple values, represented by a Data Type.

Basic Core Component (BCC) – A Core Component which constitutes a singular business characteristic of a specific Aggregate Core Component that represents a Object Class. It has a unique Business Semantic definition. A Basic Core Component represents a Basic Core Component Property and is therefore of a Data Type, which defines its set of values. Basic Core Components function as the properties of Aggregate Core Components.

Basic Core Component (CC) Property – A Core Component Property for which the permissible values are expressed by simple values, represented by a Data Type.

Business Context – The formal description of a specific business circumstance as identified by the values of a set of Context Categories, allowing different business circumstances to be uniquely distinguished.

Business Information Entity (BIE) – A piece of business data or a group of pieces of business data with a unique Business Semantic definition. A Business Information Entity can be a Basic Business Information Entity (BBIE), an Association Business Information Entity (ASBIE), or an Aggregate Business Information Entity (ABIE).

Business Information Entity (BIE) Property – A business characteristic belonging to the Object Class in its specific Business Context that is represented by an Aggregate Business Information Entity.


Business Libraries – A collection of approved process models specific to a line of business (e.g., shipping, insurance).

6445 6446

6447 6448

6449 6450

6451 6452

6453

6454 6455 6456

6457

6458 6459

6460

6461

6462

6463

6464 6465 6466

6467 6468

6469 6470

6471 6472

6473 6474

6475 6476

6477 6478 6479

6480 6481 6482

6483 6484 6485

6486 6487

6488 6489 6490 6491

Business Process – The Business Process as described using the UN/CEFACT Catalogue of Common Business Processes.

Business Process Context – The Business Process name(s) as described using the UN/CEFACT Catalogue of Common Business Processes as extended by the user.

Business Process Role Context – The actors conducting a particular Business Process, as identified in the UN/CEFACT Catalogue of Common Business Processes.

Business Semantic(s) – A precise meaning of words from a business perspective.

Business Term – This is a synonym under which the Core Component or Business Information Entity is commonly known and used in the business. A Core Component or Business Information Entity may have several Business Terms or synonyms.

Cardinality – An indication whether a characteristic is optional, mandatory and/or repetitive.

Catalogue of Business Information Entities – This represents the approved set of Business Information Entities from which to choose when applying the Core Component discovery process

Catalogue of Core Components – see Core Component Catalogue.

CCL – see Core Component Library.

Child Core Component – A Core Component used as part of a larger aggregate construct.

Classification Scheme – This is an officially supported scheme to describe a given Context Category.

Constraint Language – A formal expression of actions occurring in specific Contexts to assemble, structurally refine, and semantically qualify Core Components. The result of applying the Constraint Language to a set of Core Components in a specific Context is a set of Business Information Entities.

Content Component – Defines the Primitive Type used to express the content of a Core Component Type.

Content Component Restrictions – The formal definition of a format restriction that applies to the possible values of a Content Component.

Context – Defines the circumstances in which a Business Process may be used. This is specified by a set of Context Categories known as Business Context.

Context Category – A group of one or more related values used to express a characteristic of a business circumstance.

Context Rules Construct – The overall expression of a single set of rules used to apply Context to Core Components.

Controlled Vocabulary – A supplemental vocabulary used to uniquely define potentially ambiguous words or Business Terms. This ensures that every word within any of the Core Component names and definitions is used consistently, unambiguously and accurately.

Core Component (CC) – A building block for the creation of a semantically correct and meaningful information exchange package. It contains only the information pieces necessary to describe a specific concept.

Core Component Catalogue – The temporary collection of all metadata about each Core Component discovered during the development and initial testing of this Core Component Technical Specification, pending the establishment of a permanent Registry/repository.

Core Component Dictionary – An extract from the Core Component Catalogue that provides a ready reference of the Core Component through its Dictionary Entry Name, component parts, and definition.

Core Component Library – The Core Component Library is the part of the registry/repository in which Core Components shall be stored as Registry Classes. The Core Component Library will contain all the Core Component Types, Basic Core Components, Aggregate Core Components, Basic Business Information Entities and Aggregate Business Information Entities.


Core Component Property – A business characteristic belonging to the Object Class represented by an Aggregate Core Component.

6492 6493

6494 6495 6496 6497

6498 6499 6500

6501 6502

6503 6504

6505 6506

6507 6508

6509

6510 6511

6512 6513

6514 6515 6516

6517 6518

6519 6520

6521 6522 6523

6524 6525

6526 6527 6528

6529

6530 6531 6532

6533 6534 6535

6536 6537

6538 6539

Core Component Type (CCT) – A Core Component, which consists of one and only one Content Component, that carries the actual content plus one or more Supplementary Components giving an essential extra definition to the Content Component. Core Component Types do not have Business Semantics.

Data Type – Defines the set of valid values that can be used for a particular Basic Core Component Property or Basic Business Information Entity Property. It is defined by specifying restrictions on the Core Component Type that forms the basis of the Data Type.

Definition – This is the unique semantic meaning of a Core Component, Business Information Entity, Business Context or Data Type.

Dictionary Entry Name – This is the unique official name of a Core Component, Business Information Entity, Business Context or Data Type in the dictionary.

Geopolitical Context – Geographic factors that influence Business Semantics (e.g., the structure of an address).

Industry Classification Context – Semantic influences related to the industry or industries of the trading partners (e.g., product identification schemes used in different industries).

Information Entity – A reusable semantic building block for the exchange of business-related information.

Lower-Camel-Case (LCC) – a style that capitalizes the first character of each word except the first word and compounds the name.

Naming Convention – The set of rules that together comprise how the Dictionary entry Name for Core Components and Business Information Entities are constructed.

Object Class – The logical data grouping (in a logical data model) to which a data element belongs (ISO11179). The Object Class is the part of a Core Component’s Dictionary Entry Name that represents an activity or object in a specific Context.

Object Class Term – A component of the name of a Core Component or Business Information Entity which represents the Object Class to which it belongs.

Official Constraints Context – Legal and governmental influences on semantics (e.g. hazardous materials information required by law when shipping goods).

Order – In the Constraint Language, the Property on the ContextRules Construct that applies a sequence to the application of a set of rules. Two Rule constructs cannot have the same value for the Property Order.

Primitive Type – Used for the representation of a value. Possible values are String, Decimal, Integer, Boolean, Date and Binary.

Product Classification Context – Factors influencing semantics that are the result of the goods or services being exchanged, handled, or paid for, etc. (e.g. the buying of consulting services as opposed to materials)

Property – A peculiarity common to all members of an Object Class.

Property Term – A semantically meaningful name for the characteristic of the Object Class that is represented by the Core Component Property. It shall serve as basis for the Dictionary Entry Name of the Basic and Association Core Components that represents this Core Component Property.

Qualifier Term – A word or group of words that help define and differentiate an item (e.g. a Business Information Entity or a Data Type) from its associated items (e.g. from a Core Component, a Core Compont Type, another Business Information Entity or another Data Type).

Registry Class – The formal definition of all the information necessary to be recorded in the Registry about a Core Component, a Business Information Entity, a Data Type or a Business Context.

Representation Term – The type of valid values for a Basic Core Component or Business Information Entity.


Supplementary Component – Gives additional meaning to the Content Component in the Core Component Type.

6540 6541

6542 6543

6544 6545

6546

6547 6548

6549 6550 6551

6552 6553

6554 6555

6556

6557 6558 6559 6560 6561

6562 6563

6564 6565 6566 6567

6568

6569

Supplementary Component Restrictions – The formal definition of a format restriction that applies to the possible values of a Supplementary Component.

Supporting Role Context – Semantic influences related to non-partner roles (e.g., data required by a third-party shipper in an order response going from seller to buyer.)

Syntax Binding – The process of expressing a Business Information Entity in a specific syntax.

System Capabilities Context – This Context category exists to capture the limitations of systems (e.g. an existing back office can only support an address in a certain form).

UMM Information Entity – A UMM Information Entity realizes structured business information that is exchanged by partner roles performing activities in a business transaction. Information entities include or reference other information entities through associations.”

Unique Identifier – The identifier that references a Registry Class instance in a universally unique and unambiguous way.

Upper-Camel-Case (UCC) – a style that capitalizes the first character of each word and compounds the name.

Usage Rules – Usage Rules describe how and/or when to use the Registry Class.

User Community – A User Community is a group of practitioners, with a publicised contact address, who may define Context profiles relevant to their area of business. Users within the community do not create, define or manage their individual Context needs but conform to the community’s standard. Such a community should liase closely with other communities and with general standards-making bodies to avoid overlapping work. A community may be as small as two consenting organisations.

Version – An indication of the evolution over time of an instance of a Core Component, Data Type, Business Context, or Business Information Entity.

XML schema – A generic term used to identify the family of grammar based XML document structure validation languages to include the more formal W3C XML Schema Technical Specification, Document Type Definition, Schematron, Regular Language Description for XML (RELAX), and the OASIS RELAX NG.


Appendix J. Qualified Data Type Schema Module 6570

<?xml version="1.0" encoding="UTF-8"?> 6571  6572  6573  6574  6603 <xsd:schema targetNamespace="urn:un:unece:uncefact:data:draft:QualifiedDataTypesSchemaModule:1:0" 6604 xmlns:udt="urn:un:unece:uncefact:data:draft:UnqualifiedDataTypesSchemaModule:1.0" 6605 xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> 6606  6607 <xsd:import namespace="urn:un:unece:uncefact:data:draft:UnqualifiedDataTypesSchemaModule:1.0" 6608 schemaLocation="UnqualifiedDataTypes.xsd"/> 6609  6610  6611  6612  6613 <xsd:simpleType name="HexBinaryObjectType"> 6614 <xsd:annotation> 6615 <xsd:documentation xml:lang="en"> 6616 <ccts:UniqueID>QDT000001</ccts:UniqueID> 6617 <ccts:CategoryCode>QDT</ccts:CategoryCode> 6618 <ccts:DictionaryEntryName>Hex_ Binary Object. Type</ccts:DictionaryEntryName> 6619 <ccts:VersionID>1.0</ccts:VersionID> 6620 <ccts:DefinitionText>hexBinary represents arbitrary hex-encoded binary data. The ·value space· of 6621 hexBinary is the set of finite-length sequences of binary octets.</ccts:DefinitionText> 6622 <ccts:RepresentationTermName>Binary Object</ccts:RepresentationTermName> 6623 <ccts:QualifierTerm>Hex</ccts:QualifierTerm> 6624 <ccts:PrimitiveType>binary</ccts:PrimitiveType> 6625 <xsd:BuiltInType>hexBinary</xsd:BuiltInType> 6626 </xsd:documentation> 6627 </xsd:annotation> 6628 <xsd:restriction base="xsd:hexBinary"/> 6629 </xsd:simpleType> 6630 <xsd:simpleType name="YearDateType"> 6631 <xsd:annotation> 6632 <xsd:documentation xml:lang="en"> 6633 <ccts:UniqueID>QDT000002</ccts:UniqueID> 6634 <ccts:CategoryCode>QDT</ccts:CategoryCode> 6635 <ccts:DictionaryEntryName>Year_ Date. Type</ccts:DictionaryEntryName> 6636

<ccts:VersionID>1.0</ccts:VersionID> 6637 <ccts:DefinitionText>gYear represents a gregorian calendar year. The ·value space· of gYear is the set of 6638 Gregorian calendar years as defined in § 5.2.1 of [ISO 8601]. Specifically, it is a set of one-year long, non-periodic instances 6639 e.g. lexical 1999 to represent the whole year 1999, independent of how many months and days this year 6640 has.</ccts:DefinitionText> 6641 <ccts:RepresentationTermName>Date</ccts:RepresentationTermName> 6642 <ccts:QualifierTerm>Year</ccts:QualifierTerm> 6643 <ccts:PrimitiveType>string</ccts:PrimitiveType> 6644 <xsd:BuiltInType>gYear</xsd:BuiltInType> 6645 </xsd:documentation> 6646 </xsd:annotation> 6647 <xsd:restriction base="xsd:gYear"/> 6648 </xsd:simpleType> 6649 <xsd:simpleType name="YearMonthDateType"> 6650 <xsd:annotation> 6651 <xsd:documentation xml:lang="en"> 6652 <ccts:UniqueID>QDT000003</ccts:UniqueID> 6653 <ccts:CategoryCode>QDT</ccts:CategoryCode> 6654 <ccts:DictionaryEntryName>Year Month_ Date. Type</ccts:DictionaryEntryName> 6655 <ccts:VersionID>1.0</ccts:VersionID> 6656 <ccts:DefinitionText>gYearMonth represents a specific gregorian month in a specific gregorian year. The 6657 ·value space·of gYearMonth is the set of Gregorian calendar months as defined in § 5.2.1 of [ISO 8601]. Specifically, it is a 6658 set of one-month long, non-periodic instances e.g. 1999-10 to represent the whole month of 1999-10, independent of how 6659 many days this month has.</ccts:DefinitionText> 6660 <ccts:RepresentationTermName>Date</ccts:RepresentationTermName> 6661 <ccts:QualifierTerm>Year Month</ccts:QualifierTerm> 6662 <ccts:PrimitiveType>string</ccts:PrimitiveType> 6663 <xsd:BuiltInType>gYearMonth</xsd:BuiltInType> 6664 </xsd:documentation> 6665 </xsd:annotation> 6666 <xsd:restriction base="xsd:gYearMonth"/> 6667 </xsd:simpleType> 6668 <xsd:simpleType name="FloatNumericType"> 6669 <xsd:annotation> 6670 <xsd:documentation xml:lang="en"> 6671 <ccts:UniqueID>QDT000004</ccts:UniqueID> 6672 <ccts:CategoryCode>QDT</ccts:CategoryCode> 6673 <ccts:DictionaryEntryName>Float_ Numeric. Type</ccts:DictionaryEntryName> 6674 <ccts:VersionID>1.0</ccts:VersionID> 6675 <ccts:DefinitionText>float corresponds to the IEEE single-precision 32-bit floating point type [IEEE 754-6676 1985]. The basic·value space· of float consists of the values m × 2^e, where m is an integer whose absolute value is less 6677 than 2^24, and e is an integer between -149 and 104, inclusive. In addition to the basic ·value space· described above, the 6678 ·value space· of float also contains the following special values: positive and negative zero, positive and negative infinity and 6679 not-a-number. The ·order-relation· on float is: x less than y iff y - x is positive. Positive zero is greater than negative zero. 6680 Not-a-number equals itself and is greater than all float values including positive infinity.</ccts:DefinitionText> 6681 <ccts:RepresentationTermName>Numeric</ccts:RepresentationTermName> 6682 <ccts:QualifierTerm>Float</ccts:QualifierTerm> 6683 <ccts:PrimitiveType>decimal</ccts:PrimitiveType> 6684 <xsd:BuiltInType>float</xsd:BuiltInType> 6685 </xsd:documentation> 6686 </xsd:annotation> 6687 <xsd:restriction base="xsd:float"/> 6688 </xsd:simpleType> 6689 <xsd:simpleType name="DoubleNumericType"> 6690 <xsd:annotation> 6691 <xsd:documentation xml:lang="en"> 6692 <ccts:UniqueID>QDT000005</ccts:UniqueID> 6693 <ccts:CategoryCode>QDT</ccts:CategoryCode> 6694 <ccts:DictionaryEntryName>Double_ Numeric. Type</ccts:DictionaryEntryName> 6695 <ccts:VersionID>1.0</ccts:VersionID> 6696 <ccts:DefinitionText>The double datatype corresponds to IEEE double-precision 64-bit floating point type 6697 [IEEE 754-1985]. The basic ·value space· of double consists of the values m × 2^e, where m is an integer whose absolute 6698 value is less than 2^53, and e is an integer between -1075 and 970, inclusive. In addition to the basic ·value space· 6699 described above, the ·value space· of double also contains the following special values: positive and negative zero, positive 6700 and negative infinity and not-a-number. The ·order-relation· on double is: x less than y iff y - x is positive. Positive zero is 6701 greater than negative zero. Not-a-number equals itself and is greater than all double values including positive 6702 infinity.</ccts:DefinitionText> 6703 <ccts:RepresentationTermName>Numeric</ccts:RepresentationTermName> 6704 <ccts:QualifierTerm>Double</ccts:QualifierTerm> 6705 <ccts:PrimitiveType>decimal</ccts:PrimitiveType> 6706 <xsd:BuiltInType>double</xsd:BuiltInType> 6707


</xsd:documentation> 6708 </xsd:annotation> 6709 <xsd:restriction base="xsd:double"/> 6710 </xsd:simpleType> 6711 <xsd:simpleType name="IntegerNumericType"> 6712 <xsd:annotation> 6713 <xsd:documentation xml:lang="en"> 6714 <ccts:UniqueID>QDT000006</ccts:UniqueID> 6715 <ccts:CategoryCode>QDT</ccts:CategoryCode> 6716 <ccts:DictionaryEntryName>Integer_ Numeric. Type</ccts:DictionaryEntryName> 6717 <ccts:VersionID>1.0</ccts:VersionID> 6718 <ccts:DefinitionText>integer is ·derived· from decimal by fixing the value of ·fractionDigits· to be 0. This 6719 results in the standard mathematical concept of the integer numbers. The ·value space· of integer is the infinite set {...,-2,-6720 1,0,1,2,...}. The ·base type· of integer is decimal.</ccts:DefinitionText> 6721 <ccts:RepresentationTermName>Numeric</ccts:RepresentationTermName> 6722 <ccts:QualifierTerm>Integer</ccts:QualifierTerm> 6723 <ccts:PrimitiveType>decimal</ccts:PrimitiveType> 6724 <xsd:BuiltInType>integer</xsd:BuiltInType> 6725 </xsd:documentation> 6726 </xsd:annotation> 6727 <xsd:restriction base="xsd:integer"/> 6728 </xsd:simpleType> 6729 <xsd:simpleType name="PositiveIntegerNumericType"> 6730 <xsd:annotation> 6731 <xsd:documentation xml:lang="en"> 6732 <ccts:UniqueID>QDT000007</ccts:UniqueID> 6733 <ccts:CategoryCode>QDT</ccts:CategoryCode> 6734 <ccts:DictionaryEntryName>Positive Integer_ Numeric. Type</ccts:DictionaryEntryName> 6735 <ccts:VersionID>1.0</ccts:VersionID> 6736 <ccts:DefinitionText>positiveInteger is ·derived· from nonNegativeInteger by setting the value of 6737 ·minInclusive· to be 1. This results in the standard mathematical concept of the positive integer numbers. The ·value space· 6738 of positiveInteger is the infinite set {1,2,...}. The ·base type· of positiveInteger is nonNegativeInteger.</ccts:DefinitionText> 6739 <ccts:RepresentationTermName>Numeric</ccts:RepresentationTermName> 6740 <ccts:QualifierTerm>Positive Integer</ccts:QualifierTerm> 6741 <ccts:PrimitiveType>decimal</ccts:PrimitiveType> 6742 <xsd:BuiltInType>positiveInteger</xsd:BuiltInType> 6743 </xsd:documentation> 6744 </xsd:annotation> 6745 <xsd:restriction base="xsd:positiveInteger"/> 6746 </xsd:simpleType> 6747 <xsd:simpleType name="NegativeIntegerNumericType"> 6748 <xsd:annotation> 6749 <xsd:documentation xml:lang="en"> 6750 <ccts:UniqueID>QDT000008</ccts:UniqueID> 6751 <ccts:CategoryCode>QDT</ccts:CategoryCode> 6752 <ccts:DictionaryEntryName>Negative Integer_ Numeric. Type</ccts:DictionaryEntryName> 6753 <ccts:VersionID>1.0</ccts:VersionID> 6754 <ccts:DefinitionText>negativeInteger is ·derived· from nonPositiveInteger by setting the value of 6755 ·maxInclusive· to be -1. This results in the standard mathematical concept of the negative integers. The ·value space· of 6756 negativeInteger is the infinite set {...,-2,-1}. The ·base type· of negativeInteger is nonPositiveInteger.</ccts:DefinitionText> 6757 <ccts:RepresentationTermName>Numeric</ccts:RepresentationTermName> 6758 <ccts:QualifierTerm>Negative Integer</ccts:QualifierTerm> 6759 <ccts:PrimitiveType>decimal</ccts:PrimitiveType> 6760 <xsd:BuiltInType>negativeInteger</xsd:BuiltInType> 6761 </xsd:documentation> 6762 </xsd:annotation> 6763 <xsd:restriction base="xsd:negativeInteger"/> 6764 </xsd:simpleType> 6765 <xsd:simpleType name="NonPositiveIntegerNumericType"> 6766 <xsd:annotation> 6767 <xsd:documentation xml:lang="en"> 6768 <ccts:UniqueID>QDT000009</ccts:UniqueID> 6769 <ccts:CategoryCode>QDT</ccts:CategoryCode> 6770 <ccts:DictionaryEntryName>Non Positive Integer_ Numeric. Type</ccts:DictionaryEntryName> 6771 <ccts:VersionID>1.0</ccts:VersionID> 6772 <ccts:DefinitionText>nonPositiveInteger is ·derived· from integer by setting the value of ·maxInclusive· to be 6773 0. This results in the standard mathematical concept of the non-positive integers. The ·value space· of nonPositiveInteger is 6774 the infinite set {...,-2,-1,0}. The ·base type· of nonPositiveInteger is integer.</ccts:DefinitionText> 6775 <ccts:RepresentationTermName>Numeric</ccts:RepresentationTermName> 6776 <ccts:QualifierTerm>Non Positive Integer</ccts:QualifierTerm> 6777 <ccts:PrimitiveType>decimal</ccts:PrimitiveType> 6778


<xsd:BuiltInType>nonPositiveInteger</xsd:BuiltInType> 6779 </xsd:documentation> 6780 </xsd:annotation> 6781 <xsd:restriction base="xsd:nonPositiveInteger"/> 6782 </xsd:simpleType> 6783 <xsd:simpleType name="NonNegativeIntegerNumericType"> 6784 <xsd:annotation> 6785 <xsd:documentation xml:lang="en"> 6786 <ccts:UniqueID>QDT000010</ccts:UniqueID> 6787 <ccts:CategoryCode>QDT</ccts:CategoryCode> 6788 <ccts:DictionaryEntryName>Non Negative Integer_ Numeric. Type</ccts:DictionaryEntryName> 6789 <ccts:VersionID>1.0</ccts:VersionID> 6790 <ccts:DefinitionText>nonNegativeInteger is ·derived· from integer by setting the value of ·minInclusive· to be 6791 0. This results in the standard mathematical concept of the non-negative integers. The ·value space· of nonNegativeInteger 6792 is the infinite set {0,1,2,...}. The ·base type· of nonNegativeInteger is integer.</ccts:DefinitionText> 6793 <ccts:RepresentationTermName>Numeric</ccts:RepresentationTermName> 6794 <ccts:QualifierTerm>Non Negative Integer</ccts:QualifierTerm> 6795 <ccts:PrimitiveType>decimal</ccts:PrimitiveType> 6796 <xsd:BuiltInType>nonNegativeInteger</xsd:BuiltInType> 6797 </xsd:documentation> 6798 </xsd:annotation> 6799 <xsd:restriction base="xsd:nonNegativeInteger"/> 6800 </xsd:simpleType> 6801 <xsd:simpleType name="DurationMeasureType"> 6802 <xsd:annotation> 6803 <xsd:documentation xml:lang="en"> 6804 <ccts:UniqueID>QDT000011</ccts:UniqueID> 6805 <ccts:CategoryCode>QDT</ccts:CategoryCode> 6806 <ccts:DictionaryEntryName>Duration_ Measure. Type</ccts:DictionaryEntryName> 6807 <ccts:VersionID>1.0</ccts:VersionID> 6808 <ccts:DefinitionText>duration represents a duration of time. The ·value space· of duration is a six-6809 dimensional space where the coordinates designate the Gregorian year, month, day, hour, minute, and second components 6810 defined in § 5.5.3.2 of [ISO 8601], respectively. These components are ordered in their significance by their order of 6811 appearance i.e. as year, month, day, hour, minute, and second.</ccts:DefinitionText> 6812 <ccts:RepresentationTermName>Measure</ccts:RepresentationTermName> 6813 <ccts:QualifierTerm>Duration</ccts:QualifierTerm> 6814 <ccts:PrimitiveType/> 6815 <xsd:BuiltInType>duration</xsd:BuiltInType> 6816 </xsd:documentation> 6817 </xsd:annotation> 6818 <xsd:restriction base="xsd:duration"/> 6819 </xsd:simpleType> 6820 <xsd:simpleType name="StringType"> 6821 <xsd:annotation> 6822 <xsd:documentation xml:lang="en"> 6823 <ccts:UniqueID>QDT000012</ccts:UniqueID> 6824 <ccts:CategoryCode>QDT</ccts:CategoryCode> 6825 <ccts:DictionaryEntryName>String_ Text. Type</ccts:DictionaryEntryName> 6826 <ccts:VersionID>1.0</ccts:VersionID> 6827 <ccts:DefinitionText>The string datatype represents character strings in XML. The ·value space· of string is 6828 the set of finite-length sequences of characters (as defined in [XML 1.0 (Second Edition)]) that ·match· the Char production 6829 from [XML 1.0 (Second Edition)]. A character is an atomic unit of communication; it is not further specified except to note 6830 that every character has a corresponding Universal Character Set code point, which is an integer.</ccts:DefinitionText> 6831 <ccts:RepresentationTermName>Text</ccts:RepresentationTermName> 6832 <ccts:QualifierTerm>String</ccts:QualifierTerm> 6833 <ccts:PrimitiveType>string</ccts:PrimitiveType> 6834 <xsd:BuiltInType>string</xsd:BuiltInType> 6835 </xsd:documentation> 6836 </xsd:annotation> 6837 <xsd:restriction base="xsd:string"/> 6838 </xsd:simpleType> 6839 <xsd:simpleType name="NormalizedStringType"> 6840 <xsd:annotation> 6841 <xsd:documentation xml:lang="en"> 6842 <ccts:UniqueID>QDT000013</ccts:UniqueID> 6843 <ccts:CategoryCode>QDT</ccts:CategoryCode> 6844 <ccts:DictionaryEntryName>Normalized String_ Text. Type</ccts:DictionaryEntryName> 6845 <ccts:VersionID>1.0</ccts:VersionID> 6846 <ccts:DefinitionText>normalizedString represents white space normalized strings. The ·value space· of 6847 normalizedString is the set of strings that do not contain the carriage return (#xD), line feed (#xA) nor tab (#x9) characters. 6848


The ·lexical space· of normalizedString is the set of strings that do not contain the carriage return (#xD) nor tab (#x9) 6849 characters. The ·base type· of normalizedString is string.</ccts:DefinitionText> 6850 <ccts:RepresentationTermName>Text</ccts:RepresentationTermName> 6851 <ccts:QualifierTerm>Normalized String</ccts:QualifierTerm> 6852 <ccts:PrimitiveType>string</ccts:PrimitiveType> 6853 <xsd:BuiltInType>normalizedString</xsd:BuiltInType> 6854 </xsd:documentation> 6855 </xsd:annotation> 6856 <xsd:restriction base="xsd:normalizedString"/> 6857 </xsd:simpleType> 6858 <xsd:simpleType name="TokenType"> 6859 <xsd:annotation> 6860 <xsd:documentation xml:lang="en"> 6861 <ccts:UniqueID>QDT000014</ccts:UniqueID> 6862 <ccts:CategoryCode>QDT</ccts:CategoryCode> 6863 <ccts:DictionaryEntryName>Token_ Text. Type</ccts:DictionaryEntryName> 6864 <ccts:VersionID>1.0</ccts:VersionID> 6865 <ccts:DefinitionText>token represents tokenized strings. The ·value space· of token is the set of strings that 6866 do not contain the line feed (#xA) nor tab (#x9) characters, that have no leading or trailing spaces (#x20) and that have no 6867 internal sequences of two or more spaces. The ·lexical space· of token is the set of strings that do not contain the line feed 6868 (#xA) nor tab (#x9) characters, that have no leading or trailing spaces (#x20) and that have no internal sequences of two or 6869 more spaces. The ·base type· of token is normalizedString.</ccts:DefinitionText> 6870 <ccts:RepresentationTermName>Text</ccts:RepresentationTermName> 6871 <ccts:QualifierTerm>Token</ccts:QualifierTerm> 6872 <ccts:PrimitiveType>string</ccts:PrimitiveType> 6873 <xsd:BuiltInType>token</xsd:BuiltInType> 6874 </xsd:documentation> 6875 </xsd:annotation> 6876 <xsd:restriction base="xsd:token"/> 6877 </xsd:simpleType> 6878 <xsd:simpleType name="URIType"> 6879 <xsd:annotation> 6880 <xsd:documentation xml:lang="en"> 6881 <ccts:UniqueID>QDT000015</ccts:UniqueID> 6882 <ccts:CategoryCode>QDT</ccts:CategoryCode> 6883 <ccts:DictionaryEntryName>URI_ Identifier. Type</ccts:DictionaryEntryName> 6884 <ccts:VersionID>1.0</ccts:VersionID> 6885 <ccts:DefinitionText>anyURI represents a Uniform Resource Identifier Reference (URI). An anyURI value 6886 can be absolute or relative, and may have an optional fragment identifier (i.e., it may be a URI Reference). This type should 6887 be used to specify the intention that the value fulfills the role of a URI as defined by [RFC 2396], as amended by [RFC 6888 2732].</ccts:DefinitionText> 6889 <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> 6890 <ccts:QualifierTerm>URI</ccts:QualifierTerm> 6891 <ccts:PrimitiveType>string</ccts:PrimitiveType> 6892 <xsd:BuiltInType>anyURI</xsd:BuiltInType> 6893 </xsd:documentation> 6894 </xsd:annotation> 6895 <xsd:restriction base="xsd:anyURI"/> 6896 </xsd:simpleType> 6897 <xsd:simpleType name="LanguageCodeType"> 6898 <xsd:annotation> 6899 <xsd:documentation xml:lang="en"> 6900 <ccts:UniqueID>QDT000016</ccts:UniqueID> 6901 <ccts:CategoryCode>QDT</ccts:CategoryCode> 6902 <ccts:DictionaryEntryName>Language_ Code. Type</ccts:DictionaryEntryName> 6903 <ccts:VersionID>1.0</ccts:VersionID> 6904 <ccts:DefinitionText>language represents natural language identifiers as defined by [RFC 1766]. The ·value 6905 space· of language is the set of all strings that are valid language identifiers as defined in the language identification section 6906 of [XML 1.0 (Second Edition)]. The ·lexical space· of language is the set of all strings that are valid language identifiers as 6907 defined in the language identification section of [XML 1.0 (Second Edition)]. The ·base type· of language is 6908 token.</ccts:DefinitionText> 6909 <ccts:RepresentationTermName>Code</ccts:RepresentationTermName> 6910 <ccts:QualifierTerm>Language</ccts:QualifierTerm> 6911 <ccts:PrimitiveType>string</ccts:PrimitiveType> 6912 <xsd:BuiltInType>language</xsd:BuiltInType> 6913 </xsd:documentation> 6914 </xsd:annotation> 6915 <xsd:restriction base="xsd:language"/> 6916 </xsd:simpleType> 6917  6918  6919

6920 <xsd:simpleType name="MonthDateType"> 6921 <xsd:annotation> 6922 <xsd:documentation xml:lang="en"> 6923 <ccts:UniqueID>QDT000017</ccts:UniqueID> 6924 <ccts:CategoryCode>QDT</ccts:CategoryCode> 6925 <ccts:DictionaryEntryName>Month_ Date. Type</ccts:DictionaryEntryName> 6926 <ccts:VersionID>1.0</ccts:VersionID> 6927 <ccts:DefinitionText/> 6928 <ccts:RepresentationTermName>Date</ccts:RepresentationTermName> 6929 <ccts:QualifierTerm>Month</ccts:QualifierTerm> 6930 <ccts:PrimitiveType>string</ccts:PrimitiveType> 6931 <xsd:BuiltInType>token</xsd:BuiltInType> 6932 </xsd:documentation> 6933 </xsd:annotation> 6934 <xsd:restriction base="xsd:token"> 6935 <xsd:enumeration value="01"/> 6936 <xsd:enumeration value="02"/> 6937 <xsd:enumeration value="03"/> 6938 <xsd:enumeration value="04"/> 6939 <xsd:enumeration value="05"/> 6940 <xsd:enumeration value="06"/> 6941 <xsd:enumeration value="07"/> 6942 <xsd:enumeration value="08"/> 6943 <xsd:enumeration value="09"/> 6944 <xsd:enumeration value="10"/> 6945 <xsd:enumeration value="11"/> 6946 <xsd:enumeration value="12"/> 6947 </xsd:restriction> 6948 </xsd:simpleType> 6949 <xsd:simpleType name="DayDateType"> 6950 <xsd:annotation> 6951 <xsd:documentation xml:lang="en"> 6952 <ccts:UniqueID>QDT0000018</ccts:UniqueID> 6953 <ccts:CategoryCode>QDT</ccts:CategoryCode> 6954 <ccts:DictionaryEntryName>Day_ Date. Type</ccts:DictionaryEntryName> 6955 <ccts:VersionID>1.0</ccts:VersionID> 6956 <ccts:DefinitionText/> 6957 <ccts:RepresentationTermName>Date</ccts:RepresentationTermName> 6958 <ccts:QualifierTerm>Day</ccts:QualifierTerm> 6959 <ccts:PrimitiveType>string</ccts:PrimitiveType> 6960 <xsd:BuiltInType>token</xsd:BuiltInType> 6961 </xsd:documentation> 6962 </xsd:annotation> 6963 <xsd:restriction base="xsd:token"> 6964 <xsd:enumeration value="01"/> 6965 <xsd:enumeration value="02"/> 6966 <xsd:enumeration value="03"/> 6967 <xsd:enumeration value="04"/> 6968 <xsd:enumeration value="05"/> 6969 <xsd:enumeration value="06"/> 6970 <xsd:enumeration value="07"/> 6971 <xsd:enumeration value="08"/> 6972 <xsd:enumeration value="09"/> 6973 <xsd:enumeration value="10"/> 6974 <xsd:enumeration value="11"/> 6975 <xsd:enumeration value="12"/> 6976 <xsd:enumeration value="13"/> 6977 <xsd:enumeration value="14"/> 6978 <xsd:enumeration value="15"/> 6979 <xsd:enumeration value="16"/> 6980 <xsd:enumeration value="17"/> 6981 <xsd:enumeration value="18"/> 6982 <xsd:enumeration value="19"/> 6983 <xsd:enumeration value="20"/> 6984 <xsd:enumeration value="21"/> 6985 <xsd:enumeration value="22"/> 6986 <xsd:enumeration value="23"/> 6987 <xsd:enumeration value="24"/> 6988 <xsd:enumeration value="25"/> 6989 <xsd:enumeration value="26"/> 6990

<xsd:enumeration value="27"/> 6991 <xsd:enumeration value="28"/> 6992 <xsd:enumeration value="29"/> 6993 <xsd:enumeration value="30"/> 6994 <xsd:enumeration value="31"/> 6995 </xsd:restriction> 6996 </xsd:simpleType> 6997 <xsd:simpleType name="MonthDayDateType"> 6998 <xsd:annotation> 6999 <xsd:documentation xml:lang="en"> 7000 <ccts:UniqueID>QDT000019</ccts:UniqueID> 7001 <ccts:CategoryCode>QDT</ccts:CategoryCode> 7002 <ccts:DictionaryEntryName>Month Day_ Date. Type</ccts:DictionaryEntryName> 7003 <ccts:VersionID>1.0</ccts:VersionID> 7004 <ccts:DefinitionText/> 7005 <ccts:RepresentationTermName>Date</ccts:RepresentationTermName> 7006 <ccts:QualifierTerm>Month Day</ccts:QualifierTerm> 7007 <ccts:PrimitiveType>string</ccts:PrimitiveType> 7008 <xsd:BuiltInType>token</xsd:BuiltInType> 7009 </xsd:documentation> 7010 </xsd:annotation> 7011 <xsd:restriction base="xsd:token"> 7012 <xsd:pattern value="/d/d-/d/d"/> 7013 </xsd:restriction> 7014 </xsd:simpleType> 7015

7016 7017

7018

</xsd:schema>


Copyright Statement

Copyright © UN/CEFACT 2005. All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to UN/CEFACT except as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by UN/CEFACT or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and UN/CEFACT DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


XML Naming and Design Rulesxml.coverpages.org/ATG2-NamingAndDesignRules200501.pdf2 UN/CEFACT – XML...

Documents

Transcript of XML Naming and Design Rulesxml.coverpages.org/ATG2-NamingAndDesignRules200501.pdf2 UN/CEFACT – XML...