Re: [clr-dev] [crl-dev] Codelists with expired values

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

At 2008-12-11 11:05 +0100, Linda van den Brink wrote:
>I'm helping a customer (the dutch cadastre) implement Genericode for
>their information exchange with partners. I have an interesting issue
>I would like your opinions on:
>
>They have codelists that have values that are no longer valid, i.e.
>they are expired. (actually, in the source db in which the codelists
>are maintained, they have a validity start date and end date). But
>this does not mean the code can never be used again. A simple example
>is a list of nations. An element that holds the nation in which a
>person currently resides, would not allow one of the expired nations
>as a value. But as a nation of birth, it would be ok to have one of
>the expired nations. This isn't the only example, it also occurs e.g.
>when legislation about parcel rights changes.
>
>I'm thinking they can deal with this in two ways. One, you split all
>the codelists in two: one with the current values, and one with the
>expired values. In the CVA you decide per element whether it uses only
>the current values list or both lists.

That was my gut feel, and the answer I considered after reading your 
requirement and before continuing on.

>The other way is to extend Genericode to have meta information per
>value (expired yes/no) and to extend CVA as well, so that you can
>indicate if the codelists's expired values are allowed or not for a
>particular element.

Certainly viable, but until this happens the tools are agnostic to 
the meta data.  Of course expiration is a widely-understood concept, 
but who is to say one particular interpretation of expiration should 
be the one implemented by the tools?

And, having decided on building in to tools one particular 
interpretation, how flexible would the tools be to support different 
interpretations.

>The customer prefers the second way, but of course this means we have
>to extend the standard tools (to generate validation schematron/xslt)
>as well.
>
>I'm interested in any arguments for or against the two options, or
>additional ways of dealing with this.

On reflection, I still like the idea of having the union of an 
expired list and an active list because then one gets to dream up any 
and many reasons for expiration and both express the distinction and 
support the distinction with off-the-shelf implementations.

It would be difficult to convincingly argue one way or the other from 
an abstraction perspective because each abstraction is legitimate:

  (1) - when a code changes from active to expired it is "leaving" one
        list and "joining" another list and so each list is different
        than its predecessor, thus having new list-level meta data; and

  (2) - the code never really changes from being whatever it was to what
        it is now, only its applicability has changed not its meaning,
        so it should always stay in the same list and its applicability
        is merely part of its meta data.

I think even considerations of maintenance (source code control of 
the list files themselves) could go either way.  Nothing convincing.

One compelling argument might be that once you change one of the 
tools in your arsenal to support new custom semantics in value-level 
meta data, you end up having to migrate that support to other gc/CVA 
tools you may end up using:  what if your users came to you asking 
for you to now support data entry forms for the fields you are 
currently validating with a gc/CVA++ implementation you've 
customized?  Now you are burdened with having to migrate the 
semantics of value-level meta data into what might be off-the-shelf 
gc/CVA support for forms data entry.  But what if you don't have 
control over that application?  Had you stuck with unmodified gc/CVA 
for validation, then your entire information management structure 
would instantly support gc/CVA for data entry from any vendor without 
any changes.

So even with more consideration I think the deciding factor for me is 
leave the tools agnostic of the semantics of the value-level meta 
data and leave the management of those semantics to a management 
layer and not a deployment layer.  Once you get the foot in the door 
with custom semantics, you now have a maintenance headache.

Of course since expiration is a popular concept, a genericode 1.1 or 
2.0 might very well build in these concepts as standardized 
semantics, and then one could be assured that new implementations 
would support the same concept as existing implementations.

But until expiry is built in, I suggest you manage this by 
out-of-band means than in the syntax.

But that is just my opinion ... I'm interested to hear with other 
members of the list think.

Thanks for asking, Linda!

. . . . . . . . . . . . Ken

p.s. for any readers in Europe or Australia, I'm planning hands-on 
code list gc/CVA training in Q1 2009 in Brussels and Sydney


--
Upcoming XSLT/XSL-FO, UBL and code list hands-on training classes:
:  Sydney, AU 2009-01/02; Brussels, BE 2009-03; Prague, CZ 2009-03
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
Video sample lesson:    http://www.youtube.com/watch?v=PrNjJCh7Ppg
Video course overview:  http://www.youtube.com/watch?v=VTiodiij6gE
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/c/
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/c/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal