XML Naming and Design Rules Draft 1.1, 14 January 2005
NamingAndDesignRules_1.1.doc Page 1 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
NamingAndDesignRules_1.1.doc Page 2 14 January 2005
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
NamingAndDesignRules_1.1.doc Page 3 14 January 2005
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
NamingAndDesignRules_1.1.doc Page 4 14 January 2005
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
NamingAndDesignRules_1.1.doc Page 5 14 January 2005
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
NamingAndDesignRules_1.1.doc Page 6 14 January 2005
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
NamingAndDesignRules_1.1.doc Page 7 14 January 2005
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)
NamingAndDesignRules_1.1.doc Page 8 14 January 2005
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
NamingAndDesignRules_1.1.doc Page 9 14 January 2005
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.
NamingAndDesignRules_1.1.doc Page 10 14 January 2005
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
NamingAndDesignRules_1.1.doc Page 11 14 January 2005
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
NamingAndDesignRules_1.1.doc Page 12 14 January 2005
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
NamingAndDesignRules_1.1.doc Page 13 14 January 2005
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.
NamingAndDesignRules_1.1.doc Page 14 14 January 2005
[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
NamingAndDesignRules_1.1.doc Page 15 14 January 2005
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.
NamingAndDesignRules_1.1.doc Page 16 14 January 2005
[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.
NamingAndDesignRules_1.1.doc Page 17 14 January 2005
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
NamingAndDesignRules_1.1.doc Page 18 14 January 2005
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
NamingAndDesignRules_1.1.doc Page 19 14 January 2005
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
NamingAndDesignRules_1.1.doc Page 20 14 January 2005
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
NamingAndDesignRules_1.1.doc Page 21 14 January 2005
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
NamingAndDesignRules_1.1.doc Page 22 14 January 2005
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
NamingAndDesignRules_1.1.doc Page 23 14 January 2005
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
NamingAndDesignRules_1.1.doc Page 24 14 January 2005
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.
NamingAndDesignRules_1.1.doc Page 25 14 January 2005
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.
NamingAndDesignRules_1.1.doc Page 26 14 January 2005
[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
NamingAndDesignRules_1.1.doc Page 27 14 January 2005
[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
NamingAndDesignRules_1.1.doc Page 28 14 January 2005
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
NamingAndDesignRules_1.1.doc Page 29 14 January 2005
[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
NamingAndDesignRules_1.1.doc Page 30 14 January 2005
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
NamingAndDesignRules_1.1.doc Page 31 14 January 2005
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)
NamingAndDesignRules_1.1.doc Page 32 14 January 2005
• 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)
NamingAndDesignRules_1.1.doc Page 33 14 January 2005
• 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.
NamingAndDesignRules_1.1.doc Page 34 14 January 2005
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
NamingAndDesignRules_1.1.doc Page 35 14 January 2005
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 <!-- ===== [MODULENAME] Schema Module; [VERSION] ===== --> 1148 <!-- ====================================================================== --> 1149 <!-- 1150 Module of [MODULENAME] 1151 Agency: UN/CEFACT 1152 Version: 0.3 Rev. 6 1153 Last change: 25 June 2004 1154 1155 Copyright (C) UN/CEFACT (2004). All Rights Reserved. 1156 1157 ... see copyright information ... 1158 --> 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 <!-- ===== Includes ===== --> 1165 <!-- =================================================================== --> 1166 <!-- ===== Include of [MODULENAME] ===== --> 1167 ... see includes ... 1168 <!-- ===== Imports ===== --> 1169 <!-- =================================================================== --> 1170 <!-- ===== Import of [MODULENAME] ===== --> 1171 ... see imports ... 1172 1173 <!-- ===== Root Element ===== --> 1174 <!-- =================================================================== --> 1175 ... see root element declaraction ... 1176 <!-- ===== Type Definitions ===== --> 1177 <!-- =================================================================== --> 1178 <!-- ===== Type Definition: [TYPE] ===== --> 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
NamingAndDesignRules_1.1.doc Page 36 14 January 2005
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.
NamingAndDesignRules_1.1.doc Page 37 14 January 2005
[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 <!-- ===== 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 <!-- ===== Root Element ===== --> 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
NamingAndDesignRules_1.1.doc Page 38 14 January 2005
• 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 <!-- ===== RAM Reusable ABIEs Schema Module ===== --> 1314 <!-- ====================================================================== --> 1315 <!-- 1316
NamingAndDesignRules_1.1.doc Page 39 14 January 2005
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 <!-- ===== Imports ===== --> 1331 ... see imports ... 1332 <!-- ===== Type Definitions ===== --> 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 <!-- ===== Imports ===== --> 1357 <!-- =================================================================== --> 1358 <!-- ===== Import of Qualified Data Type Schema Module (QDT) ===== --> 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 <!-- ===== Import of Unqualified Data Type Schema Module (UDT) ===== --> 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
NamingAndDesignRules_1.1.doc Page 40 14 January 2005
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
NamingAndDesignRules_1.1.doc Page 41 14 January 2005
... 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 <!-- ===== Type Definitions ===== --> 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
NamingAndDesignRules_1.1.doc Page 42 14 January 2005
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
NamingAndDesignRules_1.1.doc Page 43 14 January 2005
• 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
1599 </xsd:complexType>
[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
NamingAndDesignRules_1.1.doc Page 44 14 January 2005
• 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
NamingAndDesignRules_1.1.doc Page 45 14 January 2005
• 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
NamingAndDesignRules_1.1.doc Page 46 14 January 2005
</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 <!-- ===== CCTS Core Component Types Schema Module ===== --> 1724 <!-- ==================================================================== --> 1725 <!-- 1726 Module of Core Component Types 1727 Agency: UN/CEFACT 1728 Version: 0.3 Rev. 6 1729 Last change: 25 June 2004 1730 1731 Copyright (C) UN/CEFACT (2004). All Rights Reserved. 1732 1733 ... see copyright information ... 1734 1735 --> 1736 <xsd:schema 1737 targetNamespace= 1738 ... see namespace ... 1739 xmlns:xsd="http://www.w3.org/2001/XMLSchema" 1740 elementFormDefault="qualified" attributeFormDefault="unqualified"> 1741 <!-- ===== Type Definitions ===== --> 1742 <!-- =================================================================== --> 1743 <!-- ===== CCT: AmountType ===== --> 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
elementFormDefault="qualified" attributeFormDefault="unqualified">
7.5.4 Imports and Includes The core component types schema module does not import or include any other schema modules.
NamingAndDesignRules_1.1.doc Page 47 14 January 2005
[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 <!-- ===== Type Definitions ===== --> 1781 <!-- =================================================================== --> 1782 <!-- ===== CCT: AmountType ===== --> 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
NamingAndDesignRules_1.1.doc Page 48 14 January 2005
[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
NamingAndDesignRules_1.1.doc Page 49 14 January 2005
</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 <!-- ===== UDT Unqualified Data Type Schema Module ===== --> 1918
NamingAndDesignRules_1.1.doc Page 50 14 January 2005
<!-- ==================================================================== --> 1919 <!-- 1920 Module of Unqualified Data Types 1921 Agency: UN/CEFACT 1922 Version: 0.3 Rev.6 1923 Last change: 25 June 2004 1924 1925 Copyright (C) UN/CEFACT (2004). All Rights Reserved. 1926 1927 ... see copyright information ... 1928 1929 --> 1930 <xsd:schema targetNamespace= 1931 ... see namespace ... 1932 xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" 1933 attributeFormDefault="unqualified"> 1934 <!-- ===== Imports ===== --> 1935 <!-- =================================================================== --> 1936 ... see imports ... 1937 <!-- =================================================================== --> 1938 <!-- ===== Type Definitions ===== --> 1939 <!-- =================================================================== --> 1940 <!-- ===== Primary RT: Amount. Type ===== --> 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
elementFormDefault="qualified" attributeFormDefault="unqualified">
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 <!-- ===== Imports ===== --> 1971 <!-- =================================================================== --> 1972 <!-- ===== Imports of Code Lists ===== --> 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 <!-- ===== Imports of Identifier Lists ===== --> 1979 <!-- =================================================================== --> 1980
NamingAndDesignRules_1.1.doc Page 51 14 January 2005
<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
NamingAndDesignRules_1.1.doc Page 52 14 January 2005
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 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 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 <!-- ===== Type Definitions ===== --> 2048 <!-- =================================================================== --> 2049 <!-- ===== Primary RT: Amount. Type ===== --> 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 <!-- ===== Primary RT: Binary Object. Type ===== --> 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
NamingAndDesignRules_1.1.doc Page 53 14 January 2005
</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
2131 </xsd:complexType>
[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
NamingAndDesignRules_1.1.doc Page 54 14 January 2005
[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
NamingAndDesignRules_1.1.doc Page 55 14 January 2005
[R 141] For every supplementary component xsd:attribute declaration a structured set of 2204 annotations MUST be present in the following pattern: 2205
• 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.
NamingAndDesignRules_1.1.doc Page 56 14 January 2005
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 <!-- ===== QDT Qualified Data Type Schema Module ===== --> 2263 <!-- ==================================================================== --> 2264 <!-- 2265 Module of Qualified Data Types 2266 Agency: UN/CEFACT 2267 Version: 0.3 Rev. 6 2268 Last change: 25 June 2004 2269 2270 2271 Copyright (C) UN/CEFACT (2004). All Rights Reserved. 2272 2273 ... see copyright information ... 2274 2275 --> 2276 <xsd:schema targetNamespace= 2277 ... see namespace ... 2278 xmlns:xsd="http://www.w3.org/2001/XMLSchema" 2279 elementFormDefault="qualified" attributeFormDefault="unqualified"> 2280 <!-- ===== Imports ===== --> 2281 <!-- =================================================================== --> 2282 ... see imports ... 2283 <!-- ===== Type Definitions ===== --> 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
elementFormDefault="qualified" attributeFormDefault="unqualified">
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
NamingAndDesignRules_1.1.doc Page 57 14 January 2005
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 <!-- ===== Type Definitions ===== --> 2343 <!-- =================================================================== --> 2344 <!-- ===== Qualified Data Type based on DateTime Type ===== --> 2345 <!-- =================================================================== --> 2346 <!-- ===== Qualified DT: Day_ Date. Type ===== --> 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 <!-- ===== Qualified Data Type based on Text. Type ===== --> 2356 <!-- =================================================================== --> 2357 <!-- ===== Qualified DT: Description_ Text. Type ===== --> 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
NamingAndDesignRules_1.1.doc Page 58 14 January 2005
... 2368 <!-- ===== Qualified Data Type based on Identifier. Type ===== --> 2369 <!-- =================================================================== --> 2370 <!-- ===== Qualified DT: Uniform Resource_ Identifier. Type ===== --> 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 <!-- ===== Qualified DT: Country_ Identifier. Type ===== --> 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
NamingAndDesignRules_1.1.doc Page 59 14 January 2005
• 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 ...
[R 152] For every supplementary component xsd:attribute declaration a structured set of 2467 annotations MUST be present in the following pattern: 2468
• 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
NamingAndDesignRules_1.1.doc Page 60 14 January 2005
• 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
NamingAndDesignRules_1.1.doc Page 61 14 January 2005
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 <!-- ===== Code List: Account Type Code ; UNECE ===== --> 2527 <!-- ==================================================================== --> 2528 <!-- 2529 Codelist of Account Type Code 2530 Agency: UNECE 2531 Version: D.01C 2532 Last change: 25 June 2004 2533 2534 Copyright (C) UN/CEFACT (2004). All Rights Reserved. 2535 2536 ... see copyright information ... 2537 2538 --> 2539 <xsd:schema targetNamespace=" ... see namespace ... 2540 xmlns:xsd="http://www.w3.org/2001/XMLSchema" 2541 elementFormDefault="qualified" attributeFormDefault="unqualified"> 2542 <!-- ===== Root Element ===== --> 2543 <!-- =================================================================== --> 2544 ... see root element declaration ... 2545 <!-- ===== Type Definitions ===== --> 2546 <!-- =================================================================== --> 2547 <!-- ===== Code List Type Definition: Account Type Code ===== --> 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:
• Namespace Identifier (NID) = un
• Namespace Specific String =
• 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
NamingAndDesignRules_1.1.doc Page 62 14 January 2005
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
NamingAndDesignRules_1.1.doc Page 63 14 January 2005
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
NamingAndDesignRules_1.1.doc Page 64 14 January 2005
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 <!-- ===== Type Definitions ===== --> 2738 <!-- =================================================================== --> 2739 <!-- ===== Code List Type Definition: Account Type Code ===== --> 2740 <!-- =================================================================== --> 2741 <xsd:simpleType name="AccountTypeCodeContentType"> 2742 <xsd:restriction base="xsd:token"> 2743 <xsd:enumeration value="2"> 2744
NamingAndDesignRules_1.1.doc Page 65 14 January 2005
... 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 <!-- ===== Root Element ===== --> 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
NamingAndDesignRules_1.1.doc Page 66 14 January 2005
<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.
NamingAndDesignRules_1.1.doc Page 67 14 January 2005
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 <!-- ===== ISO Country Identifier – Identifier List Schema Module ===== --> 2871 <!-- ==================================================================== --> 2872 <!-- 2873 Identifier of Country Identifier 2874 Agency: ISO 2875 Version: 2 2876 Last change: 25 June 2004 2877 2878 Copyright (C) UN/CEFACT (2004). All Rights Reserved. 2879 2880 ... see copyright information ... 2881 2882 --> 2883 <xsd:schema targetNamespace=" ... see namespace ... 2884 xmlns:xsd="http://www.w3.org/2001/XMLSchema" 2885 elementFormDefault="qualified" attributeFormDefault="unqualified"> 2886 <!-- ===== Root Element ===== --> 2887 <!-- =================================================================== --> 2888 ... see root element declaration ... 2889 <!-- ===== Type Definitions ===== --> 2890 <!-- =================================================================== --> 2891 <!-- ===== Identifier List Type Definition: Country Identifier 2892 ===== --> 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:
• Namespace Identifier (NID) = un
• Namespace Specific String =
• 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.
NamingAndDesignRules_1.1.doc Page 68 14 January 2005
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
NamingAndDesignRules_1.1.doc Page 69 14 January 2005
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>_<
NamingAndDesignRules_1.1.doc Page 70 14 January 2005
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 <!-- ===== Type Definitions ===== --> 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
NamingAndDesignRules_1.1.doc Page 71 14 January 2005
</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 <!-- ===== Root Element ===== --> 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
NamingAndDesignRules_1.1.doc Page 72 14 January 2005
<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
NamingAndDesignRules_1.1.doc Page 73 14 January 2005
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
NamingAndDesignRules_1.1.doc Page 74 14 January 2005
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
NamingAndDesignRules_1.1.doc Page 75 14 January 2005
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 <!-- ===== Examples Schema Module; 0.3 Rev.6 ===== --> 3207 <!-- ================================================================== --> 3208 <!-- 3209 Module: Example 3210 Agency: UN/CEFACT 3211 Version: 0.3 Rev. 6 3212 Last change: 25 June 2004 3213 3214 Copyright (C) UN/CEFACT (2004). All Rights Reserved. 3215 3216 This document and translations of it may be copied and furnished to others, and 3217 derivative works that comment on or otherwise explain it or assist in its 3218 implementation may be prepared, copied, published and distributed, in whole or in 3219 part, without restriction of any kind, provided that the above copyright notice and 3220 this paragraph are included on all such copies and derivative works. However, this 3221 document itself may not be modified in any way, such as by removing the copyright 3222 notice or references to UN/CEFACT, except as needed for the purpose of developing 3223 UN/CEFACT specifications, in which case the procedures for copyrights defined in the 3224 UN/CEFACT Intellectual Property Rights document must be followed, or as required to 3225 translate it into languages other than English. 3226 3227 The limited permissions granted above are perpetual and will not be revoked by 3228 UN/CEFACT or its successors or assigns. 3229 3230 This document and the information contained herein is provided on an "AS IS" basis and 3231 UN/CEFACT DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 3232 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 3233 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3234 --> 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
NamingAndDesignRules_1.1.doc Page 76 14 January 2005
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 <!-- ===== Include ===== --> 3287 <!-- ================================================================== --> 3288 <!-- ===== Inclusion of internal ABIE ===== --> 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
NamingAndDesignRules_1.1.doc Page 77 14 January 2005
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 <!-- ===== Imports ===== --> 3306 <!-- ================================================================== --> 3307 <!-- ===== Import of reusable UN/CEFACTAggregate Business Information Entity == --> 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 <!-- ===== Import of Unqualified Data Type ===== --> 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 <!-- ===== Import of Qualified Data Type ===== --> 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 <!-- ===== Import of Code lists ===== --> 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 <!-- ===== Import of Identifier Schemes ===== --> 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
NamingAndDesignRules_1.1.doc Page 78 14 January 2005
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 <!-- ===== Root element ===== --> 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 <!-- ===== Type Definitions ===== --> 3386 <!-- ================================================================== --> 3387 <!-- ===== Type Definitions: Account type ===== --> 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
NamingAndDesignRules_1.1.doc Page 79 14 January 2005
<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
NamingAndDesignRules_1.1.doc Page 80 14 January 2005
<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 <!-- ===== [MODULENAME] Schema Module; [VERSION] ===== --> 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
NamingAndDesignRules_1.1.doc Page 81 14 January 2005
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 <!-- ===== Include ===== --> 3594 <!-- ================================================================== --> 3595 <!-- ===== Inclusion of [TYPE OF MODULE] ===== --> 3596 <!-- ================================================================== --> 3597 <xsd:include namespace="…" schemaLocation="…"/> 3598 <!-- ================================================================== --> 3599 <!-- ===== Imports ===== --> 3600 <!-- ================================================================== --> 3601 <!-- ===== Import of [TYPE OF MODULE] ===== --> 3602 <!-- ================================================================== --> 3603 <xsd:import namespace="…" schemaLocation="…"/> 3604 <!-- ================================================================== --> 3605 <!-- ===== Root element ===== --> 3606 <!-- ================================================================== -->3607 <xsd:element name="[ELEMENTNAME]" type="[TOKEN]:[TYPENAME]> 3608 <!-- ================================================================== --> 3609 <!-- ===== Type Definitions ===== --> 3610 <!-- ================================================================== --> 3611 <!-- ===== Type Definitions: [TYPE] ===== --> 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
NamingAndDesignRules_1.1.doc Page 82 14 January 2005
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
NamingAndDesignRules_1.1.doc Page 83 14 January 2005
Appendix D. Core Component Schema Module 3625
<?xml version="1.0" encoding="UTF-8"?> 3626 <!-- ====================================================================== --> 3627 <!-- ===== CCTS Core Component Types Schema Module ===== --> 3628 <!-- ====================================================================== --> 3629 <!-- 3630 Module of Core Component Types, 3631 Agency: UN/CEFACT 3632 VersionID: 1.1 3633 Last change: 14 January2005 3634 3635
3636 3637
Copyright (C) UN/CEFACT (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, 3638 and derivative works that comment on or otherwise explain it or assist 3639 in its implementation may be prepared, copied, published and distributed, 3640 in whole or in part, without restriction of any kind, provided that the 3641 above copyright notice and this paragraph are included on all such copies 3642 and derivative works. However, this document itself may not be modified in 3643 any way, such as by removing the copyright notice or references to 3644 UN/CEFACT, except as needed for the purpose of developing UN/CEFACT 3645 specifications, in which case the procedures for copyrights defined in the 3646 UN/CEFACT Intellectual Property Rights document must be followed, or as 3647
3648 3649
required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked 3650
3651 3652 3653
by UN/CEFACT or its successors or assigns. This document and the information contained herein is provided on an "AS IS" 3654 basis and UN/CEFACT DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3655 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 3656 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 3657 FITNESS FOR A PARTICULAR PURPOSE. 3658 --> 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 <!-- ===== Type Definitions ===== --> 3663 <!-- =================================================================== --> 3664 <!-- ===== CCT: AmountType ===== --> 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
NamingAndDesignRules_1.1.doc Page 84 14 January 2005
<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 <!-- ===== CCT: BinaryObjectType ===== --> 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
NamingAndDesignRules_1.1.doc Page 85 14 January 2005
<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 <!-- ===== CCT: CodeType ===== --> 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
NamingAndDesignRules_1.1.doc Page 86 14 January 2005
<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
NamingAndDesignRules_1.1.doc Page 87 14 January 2005
<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 <!-- ===== CCT: DateTimeType ===== --> 3974 <!-- =================================================================== --> 3975
NamingAndDesignRules_1.1.doc Page 88 14 January 2005
<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 <!-- ===== CCT: IdentifierType ===== --> 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
NamingAndDesignRules_1.1.doc Page 89 14 January 2005
<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
NamingAndDesignRules_1.1.doc Page 90 14 January 2005
</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 <!-- ===== CCT: IndicatorType ===== --> 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 <!-- ===== CCT: MeasureType ===== --> 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
NamingAndDesignRules_1.1.doc Page 91 14 January 2005
<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 <!-- ===== CCT: NumericType ===== --> 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 <!-- ===== CCT: QuantityType ===== --> 4257 <!-- =================================================================== --> 4258 <xsd:complexType name="QuantityType"> 4259
NamingAndDesignRules_1.1.doc Page 92 14 January 2005
<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
NamingAndDesignRules_1.1.doc Page 93 14 January 2005
</xsd:documentation> 4331 </xsd:annotation> 4332 </xsd:attribute> 4333 </xsd:extension> 4334 </xsd:simpleContent> 4335 </xsd:complexType> 4336 <!-- ===== CCT: TextType ===== --> 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
NamingAndDesignRules_1.1.doc Page 94 14 January 2005
Appendix E. Unqualified Data Type Schema Module 4386
<?xml version="1.0" encoding="UTF-8"?> 4387 <!-- ====================================================================== --> 4388 <!-- ===== UDT Unqualified Data Types Schema Module ===== --> 4389 <!-- ====================================================================== --> 4390 <!-- 4391 Module of Unqualified Data Types, 4392 Agency: UN/CEFACT, 4393 Version: 1.1 4394 Last change: 14 January 2005 4395 4396
4397 4398
Copyright (C) UN/CEFACT (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, 4399 and derivative works that comment on or otherwise explain it or assist 4400 in its implementation may be prepared, copied, published and distributed, 4401 in whole or in part, without restriction of any kind, provided that the 4402 above copyright notice and this paragraph are included on all such copies 4403 and derivative works. However, this document itself may not be modified in 4404 any way, such as by removing the copyright notice or references to 4405 UN/CEFACT, except as needed for the purpose of developing UN/CEFACT 4406 specifications, in which case the procedures for copyrights defined in the 4407 UN/CEFACT Intellectual Property Rights document must be followed, or as 4408
4409 4410
required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked 4411
4412 4413
by UN/CEFACT or its successors or assigns. This document and the information contained herein is provided on an "AS IS" 4414 basis and UN/CEFACT DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 4415 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 4416 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 4417 FITNESS FOR A PARTICULAR PURPOSE. 4418 --> 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 <!-- ===== Imports ===== --> 4427 <!-- =================================================================== --> 4428 <!-- ===== Imports of Code Lists ===== --> 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 <!-- ===== Type Definitions ===== --> 4439 <!-- =================================================================== --> 4440 <!-- ===== Primary RT: Amount. Type ===== --> 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
NamingAndDesignRules_1.1.doc Page 95 14 January 2005
<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 <!-- ===== Primary RT: Binary Object. Type ===== --> 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
NamingAndDesignRules_1.1.doc Page 96 14 January 2005
</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 <!-- ===== Secondary RT: Graphic. Type ===== --> 4590 <!-- =================================================================== --> 4591 <xsd:complexType name="GraphicType"> 4592 <xsd:annotation> 4593 <xsd:documentation xml:lang="en"> 4594
NamingAndDesignRules_1.1.doc Page 97 14 January 2005
<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
NamingAndDesignRules_1.1.doc Page 98 14 January 2005
</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 <!-- ===== Secondary RT: Picture. Type ===== --> 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
NamingAndDesignRules_1.1.doc Page 99 14 January 2005
<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 <!-- ===== Secondary RT: Sound. Type ===== --> 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
NamingAndDesignRules_1.1.doc Page 100 14 January 2005
<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
NamingAndDesignRules_1.1.doc Page 101 14 January 2005
</xsd:simpleContent> 4879 </xsd:complexType> 4880 <!-- ===== Secondary RT: Video. Type ===== --> 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
NamingAndDesignRules_1.1.doc Page 102 14 January 2005
<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 <!-- ===== Primary RT: Code. Type ===== --> 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
NamingAndDesignRules_1.1.doc Page 103 14 January 2005
<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 <!-- ===== Primary RT: Date Time. Type ===== --> 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
NamingAndDesignRules_1.1.doc Page 104 14 January 2005
<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 <!-- ===== Secondary RT: Date. Type ===== --> 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 <!-- ===== Secondary RT: Time. Type ===== --> 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 <!-- ===== Primary RT: Identifier. Type ===== --> 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
NamingAndDesignRules_1.1.doc Page 105 14 January 2005
<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 <!-- ===== Primary RT: Indicator. Type ===== --> 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 <!-- ===== Primary RT: Measure. Type ===== --> 5229 <!-- =================================================================== --> 5230 <xsd:complexType name="MeasureType"> 5231 <xsd:annotation> 5232 <xsd:documentation xml:lang="en"> 5233
NamingAndDesignRules_1.1.doc Page 106 14 January 2005
<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 <!-- ===== Primary RT: Numeric. Type ===== --> 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 <!-- ===== Secondary RT: Value. Type ===== --> 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 <!-- ===== Secondary RT: Percent. Type ===== --> 5303 <!-- =================================================================== --> 5304
NamingAndDesignRules_1.1.doc Page 107 14 January 2005
<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 <!-- ===== Secondary RT: Rate. Type ===== --> 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 <!-- ===== Primary RT: Quantity. Type ===== --> 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 <!-- ===== Primary RT: Text.Type ===== --> 5374 <!-- =================================================================== --> 5375
NamingAndDesignRules_1.1.doc Page 108 14 January 2005
<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 <!-- ===== Secondary RT: Name. Type ===== --> 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
NamingAndDesignRules_1.1.doc Page 109 14 January 2005
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. <!-- Root Schema Documentation --> <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> <!-- ABIE Documentation --> <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> <!-- BBIE Documentation --> <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>
NamingAndDesignRules_1.1.doc Page 110 14 January 2005
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> <!-- ASBIE Documentation --> <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> <!-- Qualified Data Types Documentation --> <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>
NamingAndDesignRules_1.1.doc Page 111 14 January 2005
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> <!-- Unqualified Data Type Documentation--> <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> <!-- Unqualified Data Type Supplementary Component Documentation--> <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> <!-- Core Component Type Documentation --> <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>
NamingAndDesignRules_1.1.doc Page 112 14 January 2005
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> <!-- Core Component Type Supplementary Component Documentation--> <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> <!-- Code List / Identification Schema Documentation--> <xsd:annotation> <xsd:documentation xml:lang="en"> <ccts:CodeName></ccts:CodeName> <ccts:CodeDescription></ccts:CodeDescription> </xsd:documentation> </xsd:annotation>
NamingAndDesignRules_1.1.doc Page 113 14 January 2005
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
NamingAndDesignRules_1.1.doc Page 114 14 January 2005
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
NamingAndDesignRules_1.1.doc Page 115 14 January 2005
[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,
NamingAndDesignRules_1.1.doc Page 116 14 January 2005
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.
NamingAndDesignRules_1.1.doc Page 117 14 January 2005
[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.
NamingAndDesignRules_1.1.doc Page 118 14 January 2005
[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.
NamingAndDesignRules_1.1.doc Page 119 14 January 2005
[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
unambiguous way. • CategoryCode (mandatory): The category to which the object belongs. In this case the
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.
NamingAndDesignRules_1.1.doc Page 120 14 January 2005
• 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
unambiguous way. • CategoryCode (mandatory): The category to which the object belongs. In this case the
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.
NamingAndDesignRules_1.1.doc Page 121 14 January 2005
• 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 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.
[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.
NamingAndDesignRules_1.1.doc Page 122 14 January 2005
• 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.
NamingAndDesignRules_1.1.doc Page 123 14 January 2005
[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 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.
[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.
NamingAndDesignRules_1.1.doc Page 124 14 January 2005
• 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.
NamingAndDesignRules_1.1.doc Page 125 14 January 2005
• 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.
NamingAndDesignRules_1.1.doc Page 126 14 January 2005
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.
NamingAndDesignRules_1.1.doc Page 127 14 January 2005
[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.
NamingAndDesignRules_1.1.doc Page 128 14 January 2005
[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.
NamingAndDesignRules_1.1.doc Page 129 14 January 2005
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.
NamingAndDesignRules_1.1.doc Page 130 14 January 2005
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.
NamingAndDesignRules_1.1.doc Page 131 14 January 2005
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.
NamingAndDesignRules_1.1.doc Page 132 14 January 2005
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.
NamingAndDesignRules_1.1.doc Page 133 14 January 2005
Appendix J. Qualified Data Type Schema Module 6570
<?xml version="1.0" encoding="UTF-8"?> 6571 <!-- ====================================================================== --> 6572 <!-- ===== QDT Unqualified Data Types Schema Module ===== --> 6573 <!-- ====================================================================== --> 6574 <!-- 6575 Module of Qualified Data Types, 6576 Agency: UN/CEFACT, 6577 Version: 1.2 6578 Last change: 14 January 2005 6579 6580
6581 6582
Copyright (C) UN/CEFACT (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, 6583 and derivative works that comment on or otherwise explain it or assist 6584 in its implementation may be prepared, copied, published and distributed, 6585 in whole or in part, without restriction of any kind, provided that the 6586 above copyright notice and this paragraph are included on all such copies 6587 and derivative works. However, this document itself may not be modified in 6588 any way, such as by removing the copyright notice or references to 6589 UN/CEFACT, except as needed for the purpose of developing UN/CEFACT 6590 specifications, in which case the procedures for copyrights defined in the 6591 UN/CEFACT Intellectual Property Rights document must be followed, or as 6592
6593 6594
required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked 6595
6596 6597
by UN/CEFACT or its successors or assigns. This document and the information contained herein is provided on an "AS IS" 6598 basis and UN/CEFACT DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 6599 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 6600 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 6601 FITNESS FOR A PARTICULAR PURPOSE. 6602 --> 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 <!-- ===== Imports ===== --> 6607 <xsd:import namespace="urn:un:unece:uncefact:data:draft:UnqualifiedDataTypesSchemaModule:1.0" 6608 schemaLocation="UnqualifiedDataTypes.xsd"/> 6609 <!-- ===== Type Definitions ===== --> 6610 <!-- =================================================================== --> 6611 <!-- ===== QDTs Based On Built-In XML Schema Types ===== --> 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
NamingAndDesignRules_1.1.doc Page 134 14 January 2005
<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
NamingAndDesignRules_1.1.doc Page 135 14 January 2005
</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
NamingAndDesignRules_1.1.doc Page 136 14 January 2005
<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
NamingAndDesignRules_1.1.doc Page 137 14 January 2005
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 <!-- ===== User-Defined Qualified Data Types ===== --> 6919
NamingAndDesignRules_1.1.doc Page 138 14 January 2005
<!-- =================================================================== --> 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
NamingAndDesignRules_1.1.doc Page 139 14 January 2005
<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>
NamingAndDesignRules_1.1.doc Page 140 14 January 2005
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.
NamingAndDesignRules_1.1.doc Page 141 14 January 2005