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: [crl-dev] Codelists with expired values

Hi all,

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.

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.

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.

Regards, Linda

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