OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

clr-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [clr-dev] Code List Lessons Learned / Problems Encountered

Hi Kenneth,


As an independent consultant to the New Zealand Ministry of Education (MoE), I have been following and implementing Genericode since its early draft releases (known as OASIS UMCLVV at the time).


MoE is successfully deploying Genericode, Context Value Association and ISO Schematron to validate values in internal and external messages.


Before Genericode (and Context Value Association), we faced the following issues:

-          Embedding code lists in schemas as XSD enumerations proved impractical, because every code value change forced a schema version change not only of the code list schema, but all importing schemas also. The overhead of a change was not justifiable.

-          Leaving the code lists out of the schema would have meant that code values are validated inside the applications (either hard coded, or database controlled.) This was not acceptable because synchronising the validation in all the various applications that exchange data is not feasible.

-          Neither of the above approaches could accommodate code list metadata, code list subsets and supersets, or code list transitions (temporarily accepting the old and new version of a code list before decommissioning the old version.)

-          A master code list ‘on paper’ was implemented separately at least twice if not more, once for XML exchanges, once for GUI front-end validation, with all the challenges to keep them in synch. While that is still an issue where we are not in control of an application, we can now at least use Genericode for the front-end applications we do control.)

-          The uncoordinated management of code lists (lack of unambiguous meta data identification of, lack of unambiguous documentation, lack of consistent code value validation, lack of centralised code list authoring) must have had a negative impact on data quality when exchanging data

-          Operational issues: If the receiving application detected an invalid code value, it would return the message with an error to the sender. But if the sender was not validating equivalently, the sending application could at times not detect anything wrong with the message, making manual intervention a necessity.


For more information on the deployment of Genericode/Value Validation, see

-          page 11 of the MoE case study http://www.minedu.govt.nz/~/media/MinEdu/Files/EducationSectors/PrimarySecondary/Initiatives/ModelDrivenSemanticInteroperability.pdf (Note: printed in June 2007, and hence referring to UMCLVV)

-          http://d-m-s.co.nz/serv_xmlval.htm


Is this the kind of experiences you were looking for?




Juerg Tschumperlin

Data Management Solutions

Wellington, New Zealand




From: Sall, Kenneth [mailto:SallK@saic-dc.com]
Sent: Tuesday, 8 December 2009 8:18 a.m.
To: clr-dev@lists.oasis-open.org
Subject: [clr-dev] Code List Lessons Learned / Problems Encountered


Hello, all,


I’m participating in a NIEM-related code list tiger team. I’ve reviewed the CLR requirements from 2007 and the Genericode 1.0 specification that addresses the Version 1 requirements.


Our tiger team would be very interested in collecting any information (metrics, use cases, anecdotal comments, or simply opinions) of problems encountered and lessons learned in working with code lists that led to any of the CLR requirements. This is partially addressed in Section 2 of the spec (“What is a Code List?”) and in a presentation by Tony Coates. We are especially interested in systemic problems – a la root cause analysis.


Examples of the kind of problems we are interested in capturing (independent of Genericode):

n System A added an “unknown” code XYZ to a local copy of a standard code list without realizing that code was already in use.

n Code 123 appears in 2 related code lists, A and B, but the meaning is different each list, so metadata is needed to clarify the full context.


Thanks in advance for your insights and experiences.


Kenneth B.Sall

Data Architect / Sr. XML Data Analyst

202-261-9045 (office)

410-952-2076 (cell)




This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law or may constitute as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, notify us immediately by telephone and (i) destroy this message if a facsimile or (ii) delete this message immediately if this is an electronic communication. Thank you.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]