dhis2-devs team mailing list archive

[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.

Lars