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 <knu...@gmail.com> wrote: > On Sat, Nov 27, 2010 at 4:25 PM, Ola Hodne Titlestad <ol...@ifi.uio.no> wrote: >> On 27 November 2010 16:13, Knut Staring <knu...@gmail.com> wrote: >>> >>> On Sat, Nov 27, 2010 at 3:59 PM, Jo Størset <stor...@gmail.com> 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@lists.launchpad.net > Unsubscribe : https://launchpad.net/~dhis2-devs > More help : https://help.launchpad.net/ListHelp > _______________________________________________ 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