dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

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.

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.

I suspect that should be our major design effort moving forward.

Bob

On 27 November 2010 15:44, Knut Staring <knutst@xxxxxxxxx> wrote:
> On Sat, Nov 27, 2010 at 4:25 PM, Ola Hodne Titlestad <olati@xxxxxxxxxx> wrote:
>> On 27 November 2010 16:13, Knut Staring <knutst@xxxxxxxxx> wrote:
>>>
>>> On Sat, Nov 27, 2010 at 3:59 PM, Jo Størset <storset@xxxxxxxxx> wrote:
>>> >
>>> > Den 27. nov. 2010 kl. 19.17 skrev Romain-Rolland TOHOURI:
>>> >
>>> >> Hi Ola,
>>> >> there is also Google gear technology that is based on javascrip and
>>> >> allows to create an offline version of a web application that is sync
>>> >> automatically with the server version when Internet connexion is available.
>>> >> There is also some tools to convert java gear javascript code...
>>> >> Hope this can help,
>>> >
>>> > Actually Gears was deprecated in favour of html5 some time ago...
>>>
>>> It is interesting to look at HTML5 for offline storage and synching,
>>> however, it seems to be still early days and need for standardization.
>>> This article spells out the current status (as of half a year ago) and
>>> mentions options like serializing JSON with PersistJS:
>>> http://rethink.unspace.ca/2010/5/10/the-state-of-html5-local-data-storage
>>>
>>>  XSLTforms is another solution in this space:
>>> http://www.agencexml.com/xsltforms
>>>
> On this topic, SitePen is creating all the  XML goodies like Xpath etc for JSON:
>
> Persevere and Pintura provide offline, local storage, server-synching,
> RESTful, JSON database solution with JSONPath/JSONQuery support,
> avoiding to manually comb through stuff. JSONSchema gives an Object
> model of your data.
>
> http://www.persvr.org/Page/Persevere
> http://www.sitepen.com/blog/2010/01/25/getting-started-with-pintura/
>
> Knut
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs
> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help   : https://help.launchpad.net/ListHelp
>