2009/4/23 Saptarshi Purkayastha <[email protected]>: > 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 :-)
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 ;-) 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 > > --- > > 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 <[email protected]> >> >> >> On Thu, Apr 23, 2009 at 2:03 PM, Bob Jolliffe <[email protected]> >> 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 >> >> > > _______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
