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: Re: [clr-dev] Code list versioning


In the Netherlands we have the same story with municipalities that are
being merged. We also have some other code lists that can change due
to e.g. changing laws.

We decided to minimize versioning as much as possible. There is always
1 code list that is valid at a given time. If a code list is changed,
the old version is no longer valid.

In code lists like the one listing the municipalities, each value has
an indication whether it is still valid or not. From the source code
list (they are maintained in a DB) two variants are generated: one
with all the values, including the invalid ones, and one with only the
currently valid values.

A good example of when this is necessary, is in the country list. For
the country of field in the context of where a person was born, it is
allowed to have as value a country that no longer exists. But for the
country in the context of current address, it is only allowed to have
a currently valid country. The first field is associated with the full
list of countries, the second field with the only-current list of
countries.

On Thu, Mar 5, 2009 at 11:43 AM, Konstantin Hypponen
<Konstantin.Hypponen@uku.fi> wrote:
> Hi all,
>
> I work in a project in which we develop document schemata for the social care domain in Finland. I've been checking different ways of handling code lists, and the Genericode/CVA approach seems to be the most flexible.
>
> However, we have a problem similar to the one outlined by Linda van den Brink in one of the previous messages. Namely, we have to implement flexible code list versioning. The reason is that our code lists can change rather often. Municipality codes in Finland are a good example for this, as there is a trend for municipalities to merge, and there are many of them. New codes are added, old ones removed, and some can even change, theoretically.
>
> We store all documents in the XML format in a database. Older documents use older versions of code lists, newly created ones use new versions. Old documents are never changed, so there is no need to validate them, but the interpretation of old code values should be possible. Therefore, information about code versions used in each document is needed.
>
> One solution would be to store a CVA file together with each document, as it lists all the code list versions used in the document. Another solution is to use the listSchemeURI attributes in every element. I am more inclined to the second solution.
>
> However, for the validation of newly created documents CVA files have to be updated every time a new version of a code list appears. This should be done automatically. Perhaps the easiest way is to create a CVA file hierarchy which corresponds to the XML Schema hierarchy. CVA files for each document type would <include> CVAs for core components, other base types, etc.
>
> Has anyone been using CVA hierarchies and flexible code list versioning in their projects?
>
> Best regards,
> --
> Konstantin Hyppönen, coordinator
> Department of Computer Science
> University of Kuopio
> P.O. Box 1627, 70211 Kuopio
> Tel. +358 44 3746911, +358 40 355 2208
> Fax +358 17 16 2595
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: clr-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: clr-dev-help@lists.oasis-open.org
>
>


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