Den 19. sep. 2011 kl. 12.21 skrev Bob Jolliffe: > 2011/9/19 Lars Helge Øverland <larshe...@gmail.com>: >> 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.
Do note, though, that the use case for now is mostly about sending data value sets by way of a server. If we were to make an external api with direct mobile access in mind, it would seem the openrosa api would be the way to do that (judging by the existing set of clients out there). > <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> This is what we do currently with the "inhouse" mobile clients, although with the uglier not-attribute format (don't trust the attribute naming). Note also that we have the concept of "greying" of certain catoptcombos for specific data sets, and to support that (haven't implemented it for mobile, but should..) these combos really are specific for each data set. > (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 . If we can enforce safe attribute names and there is an easy enough way to link this extendable attribute set through jaxb, I'd use this notation over the generic one. I think we should try to be consistent, though, and I guess we need to decide now if this xml-naming-constraint is something we want to enforce. Morten's attributes have the same issue... >> 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. I kind of end up with the same question, sometimes. Sdmx-hd doesn't specify any web api model, though, and we need to think through these representation problems anyway. So let's see where it leads us. For now I can't really see any obvious reason a generalized dxf couldn't give us what we need, both in terms of being "third-party friendly", map easily to sdmx and be efficient for internal use. Though where to draw the line between generalizing and keeping our specific domain logic can be tricky. Jo _______________________________________________ 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
