dhis2-devs team mailing list archive

[Knut Staring <knutst@xxxxxxxxx>]

2009/10/21 Lars Helge Øverland <larshelge@xxxxxxxxx>

>
>
> On Tue, Oct 20, 2009 at 6:09 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx>wrote:
>
>> Hi Lars
>>
>> I haven't had a chance to give this too much foreground thought yet but it
>> does occur to me that we can simplify here a little bit.  Given that
>> categoryoptions are no longer free standing, ie they must always be within
>> the context of a category, we can do away with the categoryoption convertor
>> altogether and just have the categoryconvertor.
>>
>> Given that I see from the category api that we have
>> private List<DataElementCategoryOption> categoryOptions
>>
>> The category convertor should be responsible for cascade converting all
>> its categoryoptions.
>>
>>
>> So for dxf it makes sense to miror the structure in xml eg:
>>
>> <dxfv2:category name="Gender" code="CL:GENDER" uid="6565655">
>>    <dxf:categoryoption name="Male" code='1' uid="77867676" />
>>    <dxf:categoryoption name="Female" code='2' uid="77867676" />
>>    <dxf:categoryoption name="Unknown" code='3' uid="77867676" />
>> </dxfv2:caregory>
>>
>> The dxfv2:category parser would perform the multiple steps of
>> (i) create a new category object on processing start category element
>> (ii) create new categoryoption for each categoryoption element encountered
>> before reaching the category end element.
>> (iii) assign the categoryoptions to the category and persist
>> category+options
>>
>> This will also make it quite straightforward for converting to SDMX.
>>
>> In fact a very real alternative (given the way our categories now work) is
>> to simply adopt the sdmx native format for this:
>>
>> eg:
>>
>> <structure:CodeList id="CL_GENDER" agencyID="SDMX-HD" version="1.0"
>> isFinal="true" urn="urn:sdmx:org.sdmx.infomodel.codelist=SDMX-HD:CL_GENDER">
>>       <structure:Name xml:lang="en">Gender</structure:Name>
>>       <structure:Description xml:lang="en">Gender.</structure:Description>
>>       <structure:Code value="1"
>> urn="urn:sdmx:org.sdmx.infomodel.codelist.Code=SDMX-HD:CL_GENDER[1.0].1">
>>         <structure:Description xml:lang="en">Male</structure:Description>
>>       </structure:Code>
>>       <structure:Code value="2"
>> urn="urn:sdmx:org.sdmx.infomodel.codelist.Code=SDMX-HD:CL_GENDER[1.0].2">
>>         <structure:Description
>> xml:lang="en">Female</structure:Description>
>>       </structure:Code>
>>       <structure:Code value="3"
>> urn="urn:sdmx:org.sdmx.infomodel.codelist.Code=SDMX-HD:CL_GENDER[1.0].3">
>>         <structure:Description
>> xml:lang="en">Transgender</structure:Description>
>>       </structure:Code>
>>       <structure:Code value="_NA"
>> urn="urn:sdmx:org.sdmx.infomodel.codelist.Code=SDMX-HD:CL_GENDER[1.0]._NA">
>>         <structure:Description xml:lang="en">Not
>> Applicable</structure:Description>
>>       </structure:Code>
>>       <structure:Code value="_ALL"
>> urn="urn:sdmx:org.sdmx.infomodel.codelist.Code=SDMX-HD:CL_GENDER[1.0]._ALL">
>>         <structure:Description xml:lang="en">All</structure:Description>
>>       </structure:Code>
>>       <structure:Code value="_UNK"
>> urn="urn:sdmx:org.sdmx.infomodel.codelist.Code=SDMX-HD:CL_GENDER[1.0]._UNK">
>>         <structure:Description
>> xml:lang="en">Unknown</structure:Description>
>>       </structure:Code>
>>     </structure:CodeList>
>>
>> <dxfv2:category name="Gender" Codelist="CL_GENDER" />
>>
>> Then we could support SDMX codelists directly within dxf.   I can live
>> with either approach.  Anything to get away from storing
>> categoryoptioncategory associations in XML.
>>
>> Cheers
>> Bob
>>
>
> Hi Bob,
>
> yes agree with this. What concerns me is backwards compatibility for the
> current DXF format. Ie. we cannot force countries to upgrade all district
> installations if they want to upgrade the national installation. Since
> CategoryOptions now have no single unique property this could be a problem.
>
> One solution would be to maintain the uniqueness constraint on the name
> property in a transition period. Not sure.
>
>
Backwards compatibility may be really important - but to know how important
it is, it would perhaps be good to try and elicit information from the
different countries now on whether they are actually using the (old)
mulitidimensional setup. It may be easier to assist those (few?) countries
in making the transition than putting effort into the backwards
compatibility.

Would be great to hear from people on this list on what the situation is in
the countries they know and work with.

Knut


> Lars
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
Cheers,
Knut Staring