dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

2009/4/23 Saptarshi Purkayastha <sunbiz@xxxxxxxxx>:
> Since this discussion moved from roadmap to import-export and then
> interchange formats... lemme add something to chew for on import-export.
>
> Why aren't we using a diff-based import-export?? Suppose I already have an
> exported file and the new export file only should contain the new values, we
> can generate only the changed values in the export process. Definitely
> reduces time/ file size for places where import-export will be used
> monthly/weekly.

Thinking out loud:  the problem with a diff is that you need to have
something to diff against.  So the program would have to be able to
read the exported file you already have in order to un-select these
values from the set in order to export.  On the other hand it would be
quite trivial (and maybe in the end quicker) to have a dxf-diff
process which can generate the difference between two exported files.
Still its an interesting thought ...

> Has anyone thought of object serialization?? Where we could serialize
> objects and move it to new places... A radical and stupid way, but may be
> useful for GIS import-export, where the dxf format may fall short on
> representing sharable geographic information. Disease surveillance on the
> CBHS may be one candidate...

Can of worms here - the respective merits of native serializing
(presumably) vs serializing to XML.  Personally I would always go for
the latter.

I am not up to speed on exactly what shareable geographic information
we might want to share, but it makes sense to use an open geographical
markup language to do it (like GML) rather than trying to reinvent the
wheel in dxf.  Spurious example:

<dxf xmlns:dx="www.hisp.info/dxf" xmlns:gml="http://www.opengis.net/gml/3.2 >

<dx:DataValue DateElement=... Value="32" >
   <dx:Location>
      <gml:Point>
       <gml:coordinates>100,200</gml:coordinates>
    </gml:Point>
   </dx:Location>
</dx:DataValue>

Thats not a good example.  Real life might be more interesting ... but
there is no good reason why we couldn't quite easily get geographic
information into dxf.  The beauty of namespaces.

Cheers
Bob

>
> ---
> Regards,
> Saptarshi PURKAYASTHA
> Director R & D, HISP India
> Health Information Systems Programme
>
> My Tech Blog:  http://sunnytalkstech.blogspot.com
> You Live by CHOICE, Not by CHANCE
>
>
> 2009/4/24 Bob Jolliffe <bobjolliffe@xxxxxxxxx>
>>
>> 2009/4/23 Lars Helge Øverland <larshelge@xxxxxxxxx>:
>> >
>> >>
>> >> 6 complicates the current import strategy where objects get imported
>> >> "on
>> >> the fly" without temporary storage, maybe we can put this on hold.
>> >
>> > Actually this holds for 5 as well...
>> >
>>
>> I'll have to look at this more closely - though I know you will have a
>> better idea of what is going on.  In principle it shouldn't really
>> matter.  All that's happening in 5 is that we import a <Period> object
>> (on the fly, in its entirety or what have you).  Then we just use the
>> inherited periodID attribute as we import all the contained
>> dataValues.  I am not seeing how this would be fundamentally
>> different.  Could be I'm just tired and in need of a beer ...
>>
>> Cheers
>> Bob
>
>