dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

2011/9/19 Lars Helge Øverland <larshelge@xxxxxxxxx>:
> Hi Bob,
>
> thanks for the well-written document, I think it is very sensible and
> clearly describes the direction where we want to move. Agree fully on
> the points on separation of meta- and data, idscheme, and period
> representation.
>
> My only comment is about the representation of dimensions by
> "exploding" our category model onto optional attributes. This is good
> when dealing with third-party systems but do represent an overhead
> when communicating between dhis systems (including mobile).

Good question.  My sense is that the categoryoption combo is an
internal representation of dimensionality within dhis which should not
*necessarily* be exposed to 3rd parties.  I think this also can and
does include mobile use cases.  In fact Jo has been been on my case to
implement the dimensions particularly with a mobile use case in mind.

Having said that, there is also nothing which prevents an
application-specific datavalueset from using a catoptcombo attribute,
and we can certainly support that internally.  The web-api currently
does this for example.

I'm currently thinking about how best to export the structural
metadata (codelists and the like) required to compose datavalue
messages.  I need to have a bit of discussion about how the data
dictionary is envisaged, but it seems that one should be able to
browse the datadictionary and export relevant codelists from that.
And/or pull them from web-api.  It could well be that it makes sense
to export a dimensionset codelist along the lines of (shooting from
the hip):

<dxf:dimensionsets>
   <dxf:dimensionset id="345" SEX="M" AGE="under5" />
   <dxf:dimensionset id="346" SEX="F" AGE="under5" />
   <dxf:dimensionset id="347" SEX="M" AGE="5andOver" />
   <dxf:dimensionset id="348" SEX="F" AGE="5andOver" />
</dxf:dimensionset>

Which might allow an abbreviated form of datavalue along the lines of:

<dxf:dataValue datelement="45" orgunit="42" "period="201001/P2M"
dimensionset="345" value="56" />

(Note the funny period - that's Jan/Feb 2010).  I think this explicit
approach would be more grokkable by external systems (including our
own tightly coupled ones) than transmitting the entire lattice of
categoryoptioncombo links,, and would be quite familiar with xslt
programmers familair with the attributeset construct in xslt .

Of course the downside being that is yet another codelist to transmit
and perhaps something else to model on the other side.  That seems to
be the eternal compromise.  What you gain on the swings you lose on
the roundabouts :-)

>I thought
> SDMX-HD was our format for communicating with third-party sources - if
> dxf becomes "third-party friendly" then where does that leave SDMX?

That could well turn out to be an interesting question given the
rumblings within WHO :-)

But having a close mapping from (the useful parts of) sdmx to dxf is
very convenient, and in the process makes our dxf representation of
datavalues more sensible I think.

Bob

>
> Lars
>