dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

2010/11/28 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/

OK.  True.  I was still thinking in terms of the xforms scenario at
top of thread.

>
>