dhis2-devs team mailing list archive

[Lars Helge Øverland <larshelge@xxxxxxxxx>]

On Sat, Nov 27, 2010 at 6:03 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:

> Currently it is possible to feed any type of xml based data into dhis
> via import/export module.  Currently configured is dxf import and
> sdmx-hd in 2.0.5 but others can be implemented on the fly.  But there
> are still 3 areas to be addressed to make this process "better":
>
> (i)  authentication - currently cookies/html form based which is
> awkward.  Watching what Jo is doing with basic auth with interest.
> The basic auth approach is probably going to be the simplest workable
> solution here and we will leverage on what the mobile folk are doing
> here.
>
> (ii) management of identifiers/metadata.  You can't have reliable
> off-site 3rd party client software producing datavaluesets without a
> robust exchange of metadata identifiers and codelists.  My feeling on
> this, which has grown over the past year and a half, is in fact to
> stabilize the integer identifiers within a country context.  So within
> a domain of say Kenya or Tanzania or Sierra Leone, the dataelement
> "New malaria cases" should have a fixed identitier (say 42, the
> meaning of life).  I think the main implication of this is might be
> either to do away completely with auto generated ids as primary key or
> to also persist an authoritative id - you shouldn't be able to create
> a new identifiable object (dataelement, indicator, category or what
> have you) without *assigning* it an id.  And to do that you must
> assume some sort of authority over that metadata element - ie
> ownership.  In an environment where you might want to create
> dataelements from lower down the hierarchy then you either also have
> to have an "authority" identifier, or we need to partition the range -
> eg 0-1000 are WHO SDMX-HD identifiers, 1000-2000 are national
> identifiers and identifiers 10000 and higher are locally assigned.
> There are a few ways this could work but we need to solve it and
> stabilize somehow.
>
> (iii) related to above, when data is imported it should be possible
> for it to indicate the namespace of its metadata codes - rather than
> oblige the import of metadata with data.
>

Agree with all of this. Its planned for and will be addressed in 2.0.7.


>
> With such stability, offline data entry is simply a matter of creating
> custom xml datavalueset authoring clients which can post to a http(s)
> url.  These can be html5, xforms, ooxml, odf, custom mobile, pyqt  or
> what ever.  The format can always be transformed.  Throwing around
> different "technology" suggestions for offline clients is a fairly
> pointless exercise.  We know there are many possibilities.  But none
> of them work without stabilizing the metadata identifiers.
>

Yes. I think there is a slight difference between offline data entry (where
data is entered into one of the containers you mention and sent manually)
and what Ola means with "semi-online" data entry. In the latter the user
will open the data entry screen as usual. Then, we want to be protected from
network downtime by letting the user continue to enter data into a local
storage, and when the network is back up the local data can be flushed and
submitted to the online server. The web storage functionality in HTML 5
provides a suitable lightweight key-value storage mechanism and an API for
determining online/offline status in this regard. We would in any case wait
for this to mature before implementing anything based on it.

http://dev.w3.org/html5/webstorage/