revision-diff.txt (956 Bytes)
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 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
···
2009/10/20 noreply@launchpad.net
revno: 892
committer: Lars Helge Oeverland larshelge@gmail.com
branch nick: trunk
timestamp: Tue 2009-10-20 16:36:09 +0200
message:
Temporarily fixed compilation error in importexport. A problem is that we now cannot uniquely identify a category option by its name. We need to include the associated category in its DXF identifier.
modified:
dhis-2/dhis-services/dhis-service-importexport/src/main/java/org/hisp/dhis/importexport/converter/AbstractDataElementCategoryOptionConverter.java
–
lp:dhis2
https://code.launchpad.net/~dhis2-devs-core/dhis2/trunk
Your team DHIS 2 developers is subscribed to branch lp:dhis2.
To unsubscribe from this branch go to https://code.launchpad.net/~dhis2-devs-core/dhis2/trunk/+edit-subscription.
=== modified file ‘dhis-2/dhis-services/dhis-service-importexport/src/main/java/org/hisp/dhis/importexport/converter/AbstractDataElementCategoryOptionConverter.java’
— dhis-2/dhis-services/dhis-service-importexport/src/main/java/org/hisp/dhis/importexport/converter/AbstractDataElementCategoryOptionConverter.java 2009-10-18 22:44:41 +0000
+++ dhis-2/dhis-services/dhis-service-importexport/src/main/java/org/hisp/dhis/importexport/converter/AbstractDataElementCategoryOptionConverter.java 2009-10-20 14:36:09 +0000
@@ -55,7 +55,7 @@
protected DataElementCategoryOption getMatching( DataElementCategoryOption object ) {
return categoryService.getDataElementCategoryOptionByName( object.getName() );
return null; //TODO Fix categoryService.getDataElementCategoryOptionByName( object.getName() );}
protected boolean isIdentical( DataElementCategoryOption object, DataElementCategoryOption existing )
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp
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
···
On Tue, Oct 20, 2009 at 6:09 PM, Bob Jolliffe bobjolliffe@gmail.com 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 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 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 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
···
2009/10/21 Lars Helge Øverland larshelge@gmail.com
On Tue, Oct 20, 2009 at 6:09 PM, Bob Jolliffe bobjolliffe@gmail.com wrote:
Lars
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp
–
Cheers,
Knut Staring