On 15 February 2011 14:09, Lars Helge Øverland <larshe...@gmail.com> wrote: > > > On Tue, Feb 15, 2011 at 2:34 PM, Jo Størset <stor...@gmail.com> wrote: >> >> Den 15. feb. 2011 kl. 18.40 skrev Bob Jolliffe: >> >> > Simple validation seems to work ok. I get an "Aw, Snap! ..." when >> > posting twice with the same period but that is probably something you >> > are not catching yet. >> >> Should work now. >> >> > I don't agree with this. >> >> I know :) I don't necessarily agree myself, but it is also a matter of >> what is practically possible.. (And it might make sense to have a simpler >> json-oriented web api vs. a more fullfledged xml format for heavy imp/exp. >> Are you coming to Oslo in March by any chance, then we can fight it out! ) >> > > Can you please explain why it is not practically possible to have dxf as the > root element? > I don't have anything against grouping datavalues in sets to make the format > more compact. But, first, we currently don't have any real requirements or > use-case where we want to persist the "datavalueset". Second we currently > have no support for it in the model. So whats the point of modeling our > exchange format this way?
Well partly because this structure models the way data is produced. In sets. Off a form or off an import. SDMX data for example also arrives in sets. While there is no support in the model it simply means that we can lose information regarding the set. It becomes important where you might want to rollback a set or identify where some particular has come from. Currently this is sort of implicitly keyed but there are benefits in making it explicit. For example you can't currently trace a datavalue back to whether it was entered through a dhis form, whether it arrived from one of Jo's 5000 phone's or whether it was imported from iHRIS (or whatever). You can populate the comment of all the datavalues but that's really expensive. There are also savings to be had on storage by inheriting atttributes like period and orrgunit from a dataset rather replicating in each datavalue. It's not a model change I would propose immediately (I think we have enough zooks to sort out) but surely it is hard to argue that its not the (proverbial) right thing to do. Meanwhile the way Jo has it in his xml looks fine to me. Cheers Bob > Yes we might need it sometime in the future but > then we should implement it when we need it. > I also find it weird that we really need to implement two parsers for this. > More work and more code to maintain. > The uuids will go for a new Identifier property for version 2.2 and make > things less verbose btw. > Lars > >> >> > Your use of DataValueSet here is very welcome - as you know I have >> > been advocating this for a while. Would be nice also to persist it to >> > provide audit (and simplify dtavalue store) but that is maybe too much >> > for now. >> >> Yes, that would have to be the next topic. Let's see if anyone else take >> the bait :) >> >> Jo >> _______________________________________________ >> 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
