[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [clr-dev] [crl-dev] Codelists with expired values
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]