Hi Bob, This is super neat, and its a use case that is very useful. I've had to generate all that extra stuff I didnt 'need'.
This will also streamline metedata generation because one will only need to generate and pass metadata for only de/ou/period. But I wonder; what's the difference between orgunitId and orgunit in your example. Also, some elements don't use any categories, but the model references a default categorycombo. How will that look in your proposed schema? Would you branch Jo's code in a way we could use easily test yours as a module? or... Thanks Ime --- On Thu, 9/1/11, Bob Jolliffe <bobjolli...@gmail.com> wrote: The implication of adding all the above will be that whereas the datavalueset above will remain valid (except perhaps shifting to storedBy), the following would also be valid: <dataValueSets orgUnitId="code" dataElementId="internal" <dataValueSet orgUnit="23" period="201004" storedBy="Bob" > <dataValue dataElement="2" value="4" Sex="1" /> <dataValue dataElement="2" value="5" Sex="2"/> <dataValue dataElement="4" value="43" Sex="1" Age="3" /> <dataValue dataElement="5" value="44" Sex="1" Age="3" /> </dataValueSet> </dataValueSets> I am pretty sure I can implement the above without breaking what is currently there. One possible but minor breaking change I would suggest to improving parsing of very large datasets might be to abbreviate some well known element names to dv, de and v for compactness.
_______________________________________________ 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
