dhis2-devs team mailing list archive

[Lars Helge Øverland <larshelge@xxxxxxxxx>]

On Tue, Feb 15, 2011 at 3:26 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:

> On 15 February 2011 14:09, Lars Helge Øverland <larshelge@xxxxxxxxx>
> wrote:
> >
> >
> > On Tue, Feb 15, 2011 at 2:34 PM, Jo Størset <storset@xxxxxxxxx> 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.


>
> 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...


>
> 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@xxxxxxxxxxxxxxxxxxx
> >> Unsubscribe : https://launchpad.net/~dhis2-devs
> >> More help   : https://help.launchpad.net/ListHelp
> >
> >
>