[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [clr-dev] Code List Lessons Learned / Problems Encountered
|
Yes, Juerg, that’s exactly the type
of experience I was seeking. Thank you so much! Ken Sall 202-261-9045 (work) 410-952-2076 (cell) From: DMS Lists
[mailto:lists@d-m-s.co.nz] 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 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. 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]