RE: [clr-dev] Code list versioning

[Konstantin Hypponen <Konstantin.Hypponen@uku.fi>]

Thanks for the quick answer, Linda!

Do you have any special methodology for CVA file versioning? Taking your example with the country list, if a new version of the list becomes available, do you automatically update the current CVA files in a centralized manner?

Apparently, you have made a decision that codes can never change: new codes can be added, and old ones removed (or marked as invalid), but code value changes are not allowed. Are there more flexible solutions available, which would allow code changes?

Best regards,
Konstantin

> -----Original Message-----
> From: Linda van den Brink [mailto:brinkwoman@gmail.com]
> Sent: Thursday, March 05, 2009 12:59 PM
> To: clr-dev@lists.oasis-open.org
> 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
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: clr-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: clr-dev-help@lists.oasis-open.org