On Tue, Feb 15, 2011 at 4:13 PM, Bob Jolliffe <bobjolli...@gmail.com> wrote:
> On 15 February 2011 14:37, Lars Helge Øverland <larshe...@gmail.com> > wrote: > > > > > > On Tue, Feb 15, 2011 at 3:26 PM, Bob Jolliffe <bobjolli...@gmail.com> > wrote: > >> > >> 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. > > > > Yes thats fine, but my point is that we don't support it in the model... > So > > I still don't understand why we should require senders to provide this > info > > as it currently simply will be ignored. > > Well for a set of 100 datavalues you must either require them to > provide the attributes in Jo's datavalueset once or a 100 times :-) > So it makes sense to use it. Even if we don't model and store the > datavalueset object itself. > Yes agree with that and I don't have anything against grouping values for the benefit of making it compact. I am more concerned about having two different formats and parsers. We can discuss later. > > > > >> > >> There are also savings to be had on storage by inheriting atttributes > >> like period and orrgunit from a dataset rather replicating in each > >> datavalue. > > > > That would require that we normalize and decompose into datavalueset > > (dataset,period,orgunit) and datavalue(dataelement, categorycomboid). And > > that would effectively change the whole system and not happen anytime > > soon... > > Agree. Mind you I suspect this would might prove to be a smaller > change to the whole system than the concept business which will be > more disruptive. The benefit of the encapsulation which we have in > the datavalue api is that period, source, storedBy etc are all > private so how the likes of getPeriod() works is easily reimplemented > and so much of the change would be transparent. > > Anyway ... back to work :-) > > Cheers > Bob > > > > >> > >> 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
