[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? Regards Juerg Tschumperlin Data Management Solutions Wellington, New Zealand From: Sall, Kenneth [mailto:SallK@saic-dc.com] 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]