Practical Code List Implementation

[Accessibility conventions are described at the bottom of the page]

1. Controlled vocabularies
[> 2.][^^^]
1.0 XML document interchange
[> 1.0.1][> 1.1][> 2.][< 1.][^^][^^^]
An XML document describes a hierarchy of information items
[[1] - XML is only responsible for representation of information and not the meaning of information
[[2] - how information is labeled allows it to be identified, not interpreted
[2] - up to applications to interpret the meaning of the labels and information so-labeled
][1] - each item is labeled using the document's XML vocabulary
[[2] - the item's value is expressed in an attribute's specification or an element's text value
][1] - document constraints describe limitations on the contents of the XML documents
[[2] - what is allowed to be used as item labels and where
[2] - what is allowed to be used as item values and where
[2] - a document isn't XML unless it is well-formed
[[3] - rules govern the proper labeling of the information in the hierarchy
[3] - labels can be comprised of namespace URI strings to be globally unique
[[4] - the metaphor for "labels in a namespace" is "words in a dictionary"
]][2] - different document constraint languages provide different validation features
[[3] - directives of the language engage validation semantics
]]]
Business documents have many information items whose values are controlled
[[1] - code lists have been used for hundreds of years
[[2] - show up in historical documents, business records, passenger manifests, etc.
][1] - codes, identifiers, any information item with a predetermined value set
[[2] - like a label, a code represents the semantic, it doesn't "mean" the semantic
[2] - nothing in the value conveys understanding, only representation
[2] - still up to an application recognizing the code to be pre-programmed to interpret the semantic associated with that code
[2] - sender and receiver need to agree on the understanding of the value
][1] - the information's value is limited to one or more of a set of fixed values
[1] - item values do not impact on the structure of the document
]
Two distinct kinds of "vocabularies" for interchange
[[1] - the XML vocabulary of element and attribute labels
[1] - a controlled vocabulary of code or identifier values
[1] - in document interchange, the vocabularies represent the concepts and information for commonly-understood semantics
[1] - in applications, internal representations of both may be very much richer than the interchange representation
]
1.0.1 Controlled vocabulary semantics
[> 1.1][> 2.][< 1.0][^][^^][^^^]
A controlled vocabulary is the set of agreed-upon values for a concept
[[1] - e.g. the list of country code abbreviations
[[2] - e.g. "CA" for Canada, "US" for United States
][1] - e.g. the list of currency code abbreviations
[[2] - e.g. "CAD" for Canadian dollars, "USD" for United States dollars
][1] - e.g. the list of transaction payment means
[[2] - e.g. "10" for cash, "20" for cheque
][1] - e.g. the list of units of measure
[[2] - e.g. "KGM" for kilogram, "MTQ" for cubic meter
][1] - e.g. identifiers for different kinds of dimensions
[[2] - e.g. representing gross weight and net weight
][1] - e.g. a company's private list of product and service identifiers
[[2] - e.g. catalogue part numbers
]]
Each value in a controlled vocabulary represents a particular semantic
[[1] - for obvious enumerated concepts, no semantic need be published authoritatively
[[2] - e.g. the directions of latitude are either "North" or "South" of the equator
[2] - e.g. currency conversion operators are either "Multiply" or "Divide"
][1] - for public vocabularies, the associated semantic is a published concept
[[2] - managed by a public authority recognized as the trusted custodian of values
[2] - e.g. the International Organization for Standardization (ISO) list of country codes, currency codes, container sizes, etc.
[2] - e.g. the United Nations Economic Commission for Europe (UN/ECE) list of port codes, types of payment means, etc.
[2] - e.g. the Canadian Post Office list of Canadian province and territory abbreviations
][1] - between trading partners, the associated semantic is an agreed-upon concept
[[2] - e.g. the list of identifiers representing product and service offerings of a vendor
[2] - e.g. the document status codes accepted by a particular work flow specification
]]
All parties implicitly agree to interpret the concepts in the same way in their independent applications
[[1] - by constraining the expression of the possible values to an agreed-upon set, both parties set expectations for interchange
[1] - a formal expression of the constraints can form part of a business contract agreeing to limit values used to only the agreed-upon set
[1] - traditional approaches to using W3C schema conflate the document constraints with the value constraints
[[2] - new approaches are needed to layer value constraints on document constraints
][1] - an important caveat: "obvious" values may not be obvious to all
]
A controlled value is necessarily unique in a single given list
[[1] - if a given string value represented more than one concept it would be ambiguous and there would be no way to distinguish which concept was desired
[1] - list meta data for a value distinguishes ambiguous values in combined lists
[[2] - the values may overlap when meta data is used to identify which list's distinct value is being used
][1] - the unique value is analogous to a relational database table key
[[2] - used as a lookup value
][1] - another use of the "words in a dictionary" metaphor
[[2] - the meta data of the list defines which dictionary the words are from
[2] - the meta data may distinguish different versions of the same dictionary
]]
Each controlled value may have many associated values
[[1] - value meta data may be simple strings or compound values
[[2] - compound information can be expressed in rich markup
][1] - analogous to relational database table columns
[1] - display string(s)
[1] - non-normative synonyms
[1] - language translations
[1] - supporting detail and nuance
[1] - meta data
[[2] - derivation method
[2] - source of information
]]
ISO parlance has been in use a long time for code lists
[[1] - "Code" refers to a value's unique key value within its list
[1] - "Name" refers to that value's description with which meaning is intended to be expressed
[1] - for some concepts, far more information needs to be associated with values
]
Controlled vocabularies are used in documents, databases, applications, messages
[[1] - by controlling the representation of a concept, a specified value can unambiguously identify the associated semantic
[[2] - provided all users of the value understand the concept in the same manner
[2] - the burden is on the trusted custodian of the values to maintain the documentation of the list
][1] - abbreviated values (codes) may provide a savings of effort or space when otherwise the expression of the concept is long-winded or wordy
[[2] - the abbreviation is consistent
[2] - mnemonic values are typically biased to a particular language
[[3] - e.g. "USD" mnemonic for "United States Dollars"
[3] - e.g. "ES" mnemonic for "Spain" ("España" is Spanish for "Spain")
][2] - non-mnemonic numeric values are often used as representations of abstract concepts without language bias
[[3] - e.g. "42" non-mnemonic for "Payment to bank account" payment means
][2] - the mnemonic or non-mnemonic abbreviation is typically short
[[3] - e.g. "51" non-mnemonic for "norme 6 97-Telereglement CFONB (French Organisation for Banking Standards) - Option A" payment means
]][1] - commonly used for centuries in messages to keep messages succinct
]
Promotes consistent interpretation of the value
[[1] - all applications can follow the published or agreed-upon semantics
[1] - opportunity for misinterpretation through neglect or accident
[1] - if each trading partner came up with their own abbreviations independently, it would be impossible to know that two different values represent the same concept
[1] - removes language dependencies when abbreviating the same concept in two languages
[[2] - though some codes are mnemonically derived from a native language, the rule governing that prevents the code from being derived differently in another language
][1] - meta data columns can include various translations
[[2] - promotes common interpretation
]]
1.1 Facets of controlled vocabularies
[> 2.][< 1.0.1][^^][^^^]
1.1.1 Codes and identifiers
[> 1.1.2][> 2.][< 1.0.1][^^][^^^]
As a general rule of thumb (but not definitively), a controlled vocabulary information item is typically either a code or an identifier
[[1] - these are very symmetrically-defined constructs that are distinguished by arbitrary decisions of construction and use
[[2] - guidelines and distinctions are not black and white
[2] - whether the values are characteristic or lookup can be twisted one way or the other
][1] - these concepts are not always consistently applied
[[2] - e.g. in UBL some identifiers could easily be codes and vice versa
][1] - a code typically represents a unique concept, group or type using a characteristic value
[[2] - e.g. a currency code for an account value - "GBP" (British pounds)
[2] - e.g. a unit of measure for a measurement - " MTR" (meters)
[2] - e.g. a shipping container's dimensions
[[3] - this is an example of a set of coded values created by the application of a scheme on component parts of the value describing the container's height, width, depth and features
][2] - e.g. a method of transport
[2] - e.g. a document's type
][1] - an identifier typically represents a unique thing or singleton from a group using a lookup value
[[2] - may be synthesized by applying an algorithmic scheme
[[3] - the range of identifier values may, however, be enumerated as members of a list
][2] - e.g. a particular account's identifier - "travel" or "supplies" or "ABC0001"
[2] - e.g. a particular dimension - "gross width" or "net width"
[2] - e.g. a particular aircraft's identifier
[2] - e.g. a particular catalogue item's identifier
]]
Trading partners may wish to constrain either codes or identifiers or any other information item as a controlled vocabulary
[[1] - codes typically taken from a set representing known semantic concepts
[1] - constraining an identifier would be from a fixed list of identifiers
[[2] - e.g. a set of account identifiers
][1] - open-ended identifiers would typically not be constrained
[[2] - used to identify things that are being created
]]
1.1.2 Code list registration authorities
[> 1.1.3][> 2.][< 1.1.1][^][^^][^^^]
The custodians of abstract code lists are typically the authorities with governance
[[1] - users of a list have a level of assurance regarding the maintenance of the sets of values
[1] - stability is implied by the authority's governance of the concepts and expressions of the list members
]
The publishing of the list is different from the definition of the list
[[1] - the authority selects and defines codes in the abstract based on semantics (meaning)
[1] - the list of codes is published hopefully with sufficient information to convey the semantics they represent so that all users interpret the codes as meaning the same concepts
]
The authorities can publish their code lists in many possible formats
[[1] - prose lists and descriptions
[[2] - text files
[2] - word processing files
[2] - web site pages (HTML files)
[2] - algorithmic descriptions (e.g. ISBN checksum)
[2] - value assemblies (e.g. container height, width, depth and feature values)
][1] - W3C schemas with annotations
[1] - Comma Separated Values (CSV) files
[1] - database tables
[1] - colloquial XML expressions
[[2] - using a bespoke document model invented by a community of users
[2] - an XML vocabulary not standardized outside of the community or users
][1] - standardized XML expressions
[[2] - using a published document model created by a committee effort
[2] - openness of process and access to results are important in assessing protection against private interests or encumbrances
]]
Alternative expressions of lists may be made available in the absence of bona fide expressions
[[1] - a stop-gap measure to make up for the authority not having published the information in a useful form
[1] - e.g. UBL has expressed a number of published abstract code lists using XML syntax until such time as the official custodians publish their own artefacts for public use
]
1.1.3 Identifying controlled vocabularies
[> 1.1.4][> 2.][< 1.1.2][^][^^][^^^]
Some controlled vocabularies are already officially maintained
[[1] - custodians are typically international standards organizations
[1] - e.g. currency codes by ISO (ISO 4217)
[1] - e.g. country codes by ISO (ISO 3166-1)
[1] - e.g. payment means codes by UN/ECE (UN/ECE 4461)
]
Projects must establish which codes are applicable to their work
[[1] - community responsibility
[[2] - manage expectations of individuals and trading partners
[2] - guide community in common understanding of concepts and representations
][1] - a subset of codes from established lists
[[2] - don't re-invent the wheel
][1] - new codes for use where an established list is deficient
[[2] - are extensions needed for the community to use?
][1] - new lists of codes where there are no established lists
[[2] - are entire new lists required for a set of community semantics?
]]
Where new codes are needed,
[[1] - what do each of them mean?
[[2] - what meta data might be associated with each?
][1] - how are they coded?
[[2] - mnemonic? numeric? arbitrary?
][1] - which values are unconstrained?
]
List-level meta data identifies the list being used
[[1] - the needed list is an established list
[[2] - the list identification is the official list-level meta data
]]
[Figure 1.1: List-level meta data
The diagram shows three tabled of coded values, each associated with a single location in an XML document.
The first of the three shows a dozen of the "UN/ECE 4461 Payment Means" values while implying the entire list of values is applicable.
The second of the three shows a two-entry table titled "Cash or Certified Cheque", noting that this list is masqueraded as the "UN/ECE 4461 Payment Means" complete list.
The third of the three shows a one-entry table titled "Alternative Payment Means".
]
Value-level meta data qualifies the code with more detail
[[1] - code and name are not always sufficient to identify information
[1] - value-level meta data can be used to distinguish facets of the code
]
[Figure 1.2: Value-level meta data
Excerpts from the "UN/ECE Recommendation 16 LOCODE" table are shown, highlighting six of the many columns of values associated with each row of the table: code, name, country, subdivision, port, and IATA.
]
Instance-level meta data qualifies the use of a code
[[1] - tells an application the list in which the code is found
[1] - clarifies the meaning
]
[Figure 1.3: Instance-level meta data
Three document contexts are shown. The first has a coded value of 25 and no associated instance-level meta data.
The second has a coded value of "10" and the instance level meta data points to the "UN/ECE 44561 Payment Means" list, even though the actual list being pointed to is the "Cash or Certified Cheque" list.
The third also has a coded value of "10" but the instance level meta data points to the "Alternative Payment Means" list.
]
Community responsibility when defining the XML vocabulary
[[1] - which instance-level meta data can the user specify?
[1] - how does the user specify instance-level meta data?
]
Summary of controlled vocabulary meta data
[[1] - list-level meta data
[[2] - distinguishes one list of values from another list of values
[2] - responsibility of the controlled vocabulary custodian
][1] - value-level meta data
[[2] - distinguishes one value from another value within the same list
[2] - responsibility of the controlled vocabulary custodian
][1] - instance-level meta data
[[2] - distinguishes from which list a value is being used
[2] - responsibility of the XML vocabulary designer
[2] - utilized by the XML document writer
]]
1.1.4 Modeling controlled vocabularies
[> 1.1.5][> 2.][< 1.1.3][^][^^][^^^]
The organization of a set of associated values for all key values is tabular
[[1] - one row per semantic concept
[1] - one or more key value columns uniquely identifying the concept
[1] - zero or more meta data value columns defining the concept
]
The maintenance of list information necessarily needs to be tabular
[[1] - such a need distinguishes the available enumeration technologies as to their usefulness
[[2] - i.e. a technology that does not support a tabular arrangement is not as useful as a technology that does support a tabular arrangement of list information
]]
Maintaining an independent expression provides for re-use and change isolation
[[1] - the maintenance of a list of values will likely have a different life cycle than the contexts in which the values are used
[1] - revising an external expression of a controlled vocabulary prevents having to change an expression in which a controlled vocabulary is embedded
]
Human language translations may help as supplemental information
[[1] - may reduce problems interpreting what a value represents
]
1.1.5 Expressing controlled vocabularies
[> 1.1.6][> 2.][< 1.1.4][^][^^][^^^]
Non-standard use of spreadsheets, word processing, comma-separated value (CSV) documents is common
[[1] - each custodial organization may have its own way of expressing the representation values and their associated semantics
[1] - applications incorporating the values into their validation processes would need to accommodate ad hoc means with ad hoc measures
[1] - the expression may not be well defined for maintenance
]
The interchange representation is independent of the internal representation
[[1] - though some applications may choose to use the interchange representation as the internal representation
[1] - lookup strategies should be based on application requirements and be independent of interchange requirements
]
Artefacts for legal contractual agreements may be ambiguous
[[1] - using a standardized representation allows both parties to interpret all lists in the same fashion
[1] - prose is often improperly used when meta data may be less ambiguous
[[2] - especially when human language translation is involved
]]
Standards exist with which one enumerates the defined values of a controlled vocabulary
[[1] - the choice of expression empowers the use of that expression in different circumstances
[1] - some XML designers fervently believe that document values belong in a document schema
[1] - some XML designers fervently believe that document values must never be in a document schema
]
W3C Schema enumerations
[[1] - designed for use only in validation with W3C Schema semantics
[1] - the formalism only captures the key coded values in a standardized structure
[[2] - the associated meta data may be expressed in a non-standardized structure
[2] - only one key can ever be used to distinguish the information in the list
][1] - document-wide scope of re-use
[[2] - e.g. every use of the code list incorporates every code of the code list
[2] - using only a subset of codes requires declaring a separate code list for those contexts where the subset is needed
[[3] - there is a question of what meta data to use for the lists
[3] - the full list's meta data would be inappropriate for a subset list, yet instances might require the use of the meta data for the full list
]][1] - the expressions are intertwined with the expressions of structural constraints
[[2] - to change an enumeration one must "touch" the schema files that participate in structural validation
[2] - risk of inadvertently modifying the structural constraints, or burden of proving that the structural constraints were not inadvertently modified
]]
OASIS Genericode 1.0 (2007)
[[1] - designed for maintenance of the meta data of an enumeration and its members
[1] - the formalism captures all information about values in a standardized structure
[[2] - when there are multiple keys, the actual key needed can be chosen by an application
[2] - specifies standardized list-level meta data
[[3] - all controlled vocabularies can be identifies using the same mechanisms
][2] - specifies mechanisms for arbitrary value-level meta data
[[3] - each controlled vocabulary can satisfy its own requirements for value distinction and definition
]][1] - context-free scope of use
[[2] - the definition of the codes is independent of the specification of where the codes are used
][1] - the external XML-based expression is independent of any particular use
[[2] - useful for validation or user-interface definition or any use
][1] - still a role for schema specification of available instance-level meta data
]
1.1.6 Data entry of controlled vocabularies
[> 1.1.7][> 2.][< 1.1.5][^][^^][^^^]
By formally associating the use of value lists with document contexts, one can direct valid data entry
[[1] - directs a user interface
[[2] - can be written to only allow entry of a value from the associated values
][1] - value-level meta data is helpful
[[2] - could be presented to the user to help them choose the right value to use in the data entry
][1] - instance-level meta data records list-level meta data where needed for disambiguation
[[2] - when one information item can have a value from two lists, and a code is needed that exists with the same value in each list, the list-level meta data distinguishes the code and needs to be recorded as instance-level meta data
]]
1.1.7 Application development supporting controlled vocabularies
[> 1.1.8][> 2.][< 1.1.6][^][^^][^^^]
Controlled vocabularies are declarative while application program code is imperative
[[1] - easier (therefore cheaper?) to change an outboard declared list of allowed values than to change the inboard program logic
[1] - non-programmer resources can be tasked with changing the declared vocabularies
]
An application can blindly support all values in a controlled vocabulary
[[1] - the application can support all possible allowed values and presume that pre-validation has rejected those instances where a supported value is not allowed
[1] - the flexibility is in the filtering of allowed instances by dynamic application of value constraints during validation, without changing the programming in the application
]
The trading partner relationship constrains which values are allowed in a given transmission
[[1] - message filtering ensures only the messages with the allowed values for a given trading partner are passed for processing
]
Reduces application development to support new trading partners
[[1] - no need to change the program for every trading partner or new trading partners
]
Flexible to changing trading partner relationships
[[1] - as a relationship with a partner matures or changes, only the message filtering need change, not the application code
]
1.1.8 Validating controlled vocabularies
[> 1.1.9][> 2.][< 1.1.7][^][^^][^^^]
Having an expression of valid values enables the validation of specified values
[[1] - validation can reject an instance before engaging an application to act on the instance
[1] - off-loads the validation responsibility (and possible error) from applications
[1] - ensures consistent loading of database values
]
Values outside of the allowed set are considered invalid
[[1] - trading partners would not necessarily know what semantic an unexpected value represents
[1] - legal agreements could not be entered into where the parties have arbitrary values possibly representing concepts outside of the agreement
]
Methodologies are published with which one confirms the proper selection of values in an XML information item
[[1] - traditional use of grammar- or type-based document schemas
[[2] - e.g. XML DTD - grammar-based schema language
[2] - e.g. ISO/IEC 19757-2 RELAX-NG - grammar-based schema language
[2] - e.g. W3C Schema - type-based schema language
][1] - alternative schema expressions
[[2] - e.g. ISO/IEC 19757-3 Schematron - assertion-based schema language
]]
Traditional approaches validate values at the same time as validating structure
[[1] - conflates structural validation with value validation
[1] - inflexible to dynamically changing business requirements
[[2] - no need to change the structural validation just because business relationships change
][1] - business agreements impact on values but do not impact on document structures
]
UBL 2.0 separates UBL conformance from code list conformance
[[1] - to which version of UBL schemas do the structures conform?
[[2] - e.g. UBL-Invoice-2.0.xsd for an invoice
][1] - to which code lists do the values conform?
[[2] - e.g. defaultCodeList.xsl for a suite of typical code lists
]]
Layering value constraints on top of structural and lexical constrains
[[1] - can be used for any XML document structure, not only UBL
[1] - can be applied to any information item with an enumerated set of allowed values
[1] - not restricted to only codes or identifiers
[1] - can be built on top of ISO/IEC 19757-3 Schematron
[1] - separates structural/lexical validation from value validation
]
[Figure 1.4: Two-step validation
The diagram is split with a horizontal line indicating runtime process above the line and advance preparation process below the line.
Above the line and at the left is an incoming XML instance depicted as a triangle. This is connected by an arrow to the box at the right labeled "Application Code" under the column "Semantic Interpretation". Two arrows lead down from this horizontal arrow, one under the column "Structure Validation" to a box labeled "W3C Schema", and the other under the column "Value Validation" to a box labeled "XSLT".
Below the line and under the column "Structure Validation" an "XSD" labeled triangle titled "Structure Constraints" and identified with a circled "1" has an arrow leading into the "W3C Schema" box. Below the line and under the column "Value Validation" an "XSLT" labeled triangle titled "Value Constraints" and identified with a circled "2" has an arrow leading into the "XSLT" box.
]
Opportunity to incorporate many kinds of value constraints
[Figure 1.5: Second-pass value-validation artefact creation
The diagram shows triangles and boxes in three different areas.
The area labeled "Definition" shows the "XML" labeled triangle titled "Code List Context Associations" and identified with a circled "3", a set of "GC" labeled triangles titled "External Code List Expressions" and identified with a circled "4", and a setoff "SCH" labeled triangles titled "Business Rules" and identified with a circled "6". Each of these has an arrow directed to a box labeled "Schematron implementation of OASIS context/value association files for validation" in the area labeled "Preparation".
One arrow leaves this box to the "XSLT" labeled triangle titled "Assertion Validation Stylesheet" and identified with a circled "2".
One arrow leaves this box to the "XSLT Process" labeled box in the area labeled "Processing". The other input to this box is a set of "XML" labeled triangles titled "Document Instances Being Validated". The one output from this box is a set of "Report" labeled parallelograms titled "Validation Reports".
]
Context/value associations establish which code lists apply where in the document
[[1] - gives flexibility to specify different codes for the same conceptual value used in different document contexts
]
External value list expressions in genericode
[[1] - the XML documents defining the controlled vocabularies
[1] - includes list-level and value-level meta data
]
Business rules can express co-occurrence and algorithmic constraints
[[1] - more powerful than simple declarative approaches
[1] - use Schematron for arbitrary XPath expressions
]
1.1.9 Semantic representation by fixed values
[> 1.1.10][> 2.][< 1.1.8][^][^^][^^^]
Assigned semantics
[[1] - each unique value represents an associated concept, label or longer value
[1] - community of users agree on the association between specified value and represented value
[1] - a value has two aspects of context in order to have some meaning
[[2] - context of use/location
[[3] - where in the document is the information item being used
][2] - context of definition/meaning
[[3] - from which set of values is the information item value being obtained
][2] - without explicit context a value may be ambiguous or reliant on informal agreement
][1] - especially important for non-mnemonic codes: e.g. "42" vs. "USD"
[[2] - the meaning of some mnemonic codes might be guessed based on context of use, e.g. "USD" for a currency
[2] - non-mnemonic codes typically have no basis for guessing the meaning, e.g. "42" for a payment means
]]
Instance-level meta data disambiguates a code when context is insufficient
[[1] - used for identification of values and definition of values
[1] - list meta data identifies the collection from which the value is taken
[[2] - information about the collection as a whole
[2] - gives context to the specified values
][1] - value meta data helps define the semantics or details of the value itself
[[2] - information about the one particular coded value
]]
Changes in time can affect the interpretation/semantics of values
[[1] - the collection of values evolves creating a new version of an existing code list
[[2] - identified by associated meta data
][1] - the meaning of individual values evolves
[[2] - described by associated meta data or prose
][1] - migrating data from old to new may require simultaneous support of multiple versions of the same code list
[[2] - requires flexibility not typically associated with traditional schema-based approaches to using codes
][1] - unused and retired codes might get re-used later for new semantic concepts
[[2] - e.g. country code "CS" was Czechoslovakia before 2003 and was reserved in 2006 for Serbia and Montenegro
]]
1.1.10 Trading partners and agreements
[> 2.][< 1.1.9][^][^^][^^^]
Trading partners need to agree on the structure and content of interchanged documents
[[1] - so doing provides interoperability between independent systems acting on the information
[1] - using XML isn't a magic bullet
[[2] - it doesn't make our programs better, it makes our interchange of information more reliable
[2] - layers interchange constraints on top of implementation foundations
][1] - structuring the information in a standardized fashion ensures the information is communicated
[[2] - where to find information based on how it is labeled and where it is found hierarchically
][1] - agreeing on the semantics behind values in the communicated information ensures the information is understood
[[2] - what specified information values mean and represent in the abstract
]]
Relationships between trading partners change, while standards do not
[[1] - trading partner requirements can be layered on top of industry standards
[1] - trading partners can also anticipate future changes to standards
]
Published interchange specifications cannot pretend to know every value that trading partners need
[[1] - there is no standardization of many business concepts, just practical and pragmatic use for those concepts of import to trading partners
[1] - therefore that can be no standardization of a set of values representing business concepts that are particular to trading partners
]
Industries can state what the semantics are behind values
[[1] - trading partners can agree on which values to use
]
Codes for some established business practices can be supplemented or subset by trading partners
[[1] - e.g. extending document status codes
[[2] - a typical workflow will have typical status values for the progress of a document
[2] - particular workflow systems used by trading partners may use only some or maybe more document status values for a given document
][1] - e.g. restricting payment means codes
[[2] - payment can only be by certified cheque or credit card
][1] - e.g. restricting and extending transportation status codes
[[2] - the suite of status codes includes a subset of a standard suite in combination with non-standard additional values
]]
Identifiers are especially important as they specify actual business objects and not business concepts
[[1] - e.g. account identifiers
[[2] - every business will probably have a different set of accounts than other businesses
[2] - when engaging in a transaction, a trading partner can publish its accepted list of account identifiers so that a correspondent knows which values can be used
][1] - e.g. measurement identifiers
[[2] - a catalogue item's characteristics need to be identified unambiguously (e.g. "gross weight" is distinct from "net weight")
]]
Additional business rules can be layered on top of value constraints
[[1] - e.g. validity of non-coded data values based on trading partner relationship
[[2] - e.g. a maximum value for an order
][1] - e.g. the nature of a product identified by its identifier may restrict the payment means by which it is paid for
[[2] - e.g. no credit cards for certain products
]]

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.