Roadmap issues

Support - Assistance technique
1

All of the points should be done for the next version of the DHIS2 release.
They all are quite simple to implement and definitely serve the purpose of
using XML as an interchange format. We have had discussions on this during
the workshop in Delhi in the hotel rooms and lobbies I think.

9.) A point Bob missed out: those namespaces (and the schema) could be web
links where one can follow that link on a webpage explaining the format. The
XSLT are also very imp step in the process because that can mean a lot of
direct database code can be avoided and anyone may want to use these to get
reports, excels, and whatever they are called for with those awesome XML
engines available today :slight_smile:

There are a few options regarding namespace identification, mostly
coming down to URN or URL based URI's. (urrrr soup). In the end its
not that critical but I generally favour the URL based approach. As
promised I'll try and objectively lay out the arguments when we get to
it.

10.) We should use orgUnit, orgUnitId... for similar things that can be
obviously shortened in name.

Not so sure we want to go too far down this road. XML should always
be readable. Although OOXML has broken new ground with tags like
<w:r> etc.

11.) We can use an encrypted = <bool> flag in the manifest. We may just want
to encrypt credit card numbers/patient records for an accounting
system/name-based system based on DHIS :wink:

There are lots of encryption options to consider. But definitely take
advantage of the fact we have a manifest and a zip container to work
in.

Cheers
Bob

···

2009/4/23 Saptarshi Purkayastha <sunbiz@gmail.com>:

---

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/23 Lars Helge Øverland <larshelge@gmail.com>

On Thu, Apr 23, 2009 at 2:03 PM, Bob Jolliffe <bobjolliffe@gmail.com> >> wrote:

Thanks Lars for the update.

I have just updated the whiteboard on the dxf blueprint here:
https://blueprints.launchpad.net/dhis2/+spec/dxf-format

I'd be interested in your comments. I know you've put a lot of work
into the import-export stuff so I'm sensitive about making
suggestions, but I do believe that some of the benefits of revamping
some of this are quite substantial. Tell me what you think.

I am very happy for suggestions on how to improve things:)

I think your points are quite valid (and I see that the current solutions
is not optimal).

1, 2, 7 are nice improvements that won't break backwards compatibility.
Feel free to modify things right away.

3, 4, 5 are improvements that would require only small modifications to
the import code and would obviously make things faster. My only concern is
backwards compatibility. If we introduce this for a specific release and
inform the users we might get away with it. We could also maintain code that
uses the (new) version attribute to achieve backwards compatibility for a
while. Bharath, Saptarshi, any comments here?

6 complicates the current import strategy where objects get imported "on
the fly" without temporary storage, maybe we can put this on hold.

8 I don't have too much experience with, but I like the concept and if it
can be done I'm excited to follow the development here.

Also, the potential for dxf as an open standard sounds promising.

cheers

Lars