[Accessibility conventions are described at the bottom of the page]
*** This is a free preview excerpt of a commercial publication. ***

2. Defining and using controlled vocabularies
[> 3.][< 1.1.10][^^^]
2.0 Controlled value list maintenance and identity
[> 2.0.1][> 3.][< 2.][^^][^^^]
A list of values has an identity in the abstract, regardless of how it is maintained
[[1] - e.g. ISO 3166-1 country codes
 [1] - e.g. UN/ECE 4461 payment means codes
 [1] - e.g. UBL 2.0 document status codes
]
The complete list may be maintained by hand or by a database or by any means
[[1] - the management of the values is important to long-term maintenance
 [1] - some lists may have tens of thousands of entries (e.g. vehicle model codes)
 [1] - a list may be synthesized by an algorithmic process
[[2] - e.g. the 100 ISBN numbers assigned to publisher "978-1-894049"
]]
The concrete expressions of the lists may vary based on purpose or contextual use
[[1] - e.g. complete lists
 [1] - e.g. restricted subset lists
 [1] - each list and list subset expression must necessarily be uniquely identified
[[2] - a subset of a list cannot have the same identity as the complete list otherwise there would be confusion regarding which list is the "true" list
 [2] - identity can be expressed as meta data for the list or list subset
][1] - the concrete expression may take any useful form for the user
[[2] - e.g. simple text
 [2] - e.g. comma-separated values
 [2] - e.g. XML files
 [2] - having a standardized representation of lists would encourage the development of more widely-useful applications
]]
The sender and receiver may have different identities for a list of identical values
[[1] - e.g. the sender specifies an ISO country code
[[2] - the meta data for the list is that of the complete list
][1] - e.g. the receiver only accepts a subset of ISO country codes as valid
[[2] - the meta data for the subset list is necessarily different than that of the complete list
 [2] - for validation purposes the subset list must masquerade as the complete list yet reject specified values outside of the subset list
]]
2.0.1 Controlled value specification
[> 3.][< 2.0][^][^^][^^^]
A controlled value is, in fact, a multi-faceted value
[[1] - the list from which the code value is obtained
[[2] - described by meta data for the list
 [2] - the list identification itself may be multi-faceted
][1] - the key code value itself
[[2] - unique within any given list
][1] - properties (value-level meta data) of the values themselves
[[2] - helpful in understanding the semantics of the key code value
]]
When an information item can be populated with a coded value, it should also be possible to specify the associated value list meta data
[[1] - even very stable lists of values will change over time
[[2] - one may need to specify a chronologically-distinct interpretation of a given value
 [2] - e.g. the list of provinces in Canada changed in 1999 when the Northwest Territories was split into two territories: Nunavut and the Northwest Territories
[[3] - the Canadian postal province and territories indication of the Northwest Territories was and remains "NT" even though the definition of the territory changed
 [3] - if the distinction is important to a trading partner, then provision for making the distinction must be made available
][2] - e.g. the list of country codes changes frequently
[[3] - before 2003 "CS" represented Czechoslovakia and since 2006 "CS" is reserved for Serbia and Montenegro
]][1] - one information item value may be an item selected from one of a number of lists
[[2] - if all of the values are mutually exclusive in separate lists, there is no risk of confusion other than changes over time for any given list as noted above
 [2] - if the values in the lists are not mutually exclusive, meta data is required to disambiguate an ambiguous specified value
]]
The risk is borne by the party encoding the information that the recipient can properly decode the intent expressed by the information
[[1] - list meta data is often optional and is often ignored when coded values are specified
 [1] - the more specific a specification is, the less opportunity for improper understanding of the intended meaning
]

*** This is a free preview excerpt of a commercial publication. ***

This is an accessible version of Crane's commercial training material. The content has been specifically designed to assist screen reader software in viewing the entire textual content. Figures are replaced with text narratives.

Navigation hints are in square brackets:
[Tx.x] and [Fx.x] are textual representations of the applicability icons;
[digit] indicates list depth for nested lists;
[link [URL]] indicates the URL of a hyperlink if different than link;
[EXAMPLE] indicates an example listing of code;
[FIGURE] indicates the presence of a figure replaced by its description;
[>] jumps forward;
[<] jumps backward;
[^] jumps to start of the section;
[^^] jumps to the start of the chapter;
[^^^] jumps to the table of contents.
Suggestions for improvement are welcome: [info@CraneSoftwrights.com]
Book sales: [http://www.CraneSoftwrights.com/links/trn-acc.htm]
Information: [http://www.CraneSoftwrights.com/links/info-acc.htm]
This content is protected by copyright and, as there are no means to protect this accessible version from plagiarism, please do not make any commercial edition available to others.

+//ISBN 1-894049::CSL::Presentation::UBL//DOCUMENT Practical Code List Implementation 2009-02-09 22:30UTC//EN
Practical Code List Implementation
First Edition - 2009-02-09
ISBN 978-1-894049-22-1
Copyright © Crane Softwrights Ltd.