On 1 September 2011 20:49, Jo Størset <stor...@gmail.com> wrote:
> Den 1. sep. 2011 kl. 17.04 skrev Bob Jolliffe:
>
>>>> 1. We should shift storedBy up to the dataValueSet level.
>>
>> My thinking would be that what is relevant is who has
>> stored this value in *this* database. Usernames from strange
>> databases wouldn't make much sense anyway.
>
>> Its not critical either way at the moment - just looks a bit untidy.
>> Thus far, unless I hear compelling argument to the contrary, it seems
>> better to move it up. Will wait and listen.
>
> We haven't really talked about who is "doing the storing" in cases like this,
> but I would think a system user scenario, where a system user ("systemX")
> would be the most correct?
>
> In the current handling, this attribute is an optional value, if it's empty
> currentUserService.getCurrentUsername() will be used. So I think maybe just
> removing this option for the time being (until it is actually needed) is just
> as well. Unless we have a use case where we explicitly need to allow the
> external system to set it, in which case we could let that use case decide.
+1 to that
>
>>>> 2. I don't think categoryOptionCombo should *necessarily* be exposed
>>>> to the external world.
>
> Trusting you to have to oversight over the mapping to the internal model, I
> think this makes sense, it should make the meta model easier to articulate in
> a rest api, as well.
>
>>>> 3. On the question of identifiers ....
>
>> I agree that uuid is not the most gentle default. I just suggested it
>> because you were already using it.
>
> I just used uuids because you were already using it :) I guess choosing the
> default is not an immediate problem, anyway..
>
>>>> I can live with long names or short.
>
> Me too (with an ever so slight preference for understandability vs.
> "premature" optimization)
right. we'll stick with long for now.
>
> I certainly support the changes. With a couple of cases of external mobile
> solutions needing an api for this, it is a good time to stabilize this and
> get it clearly documented. What is your use case, btw? Thought you were all
> sdmx :)
The sdmx mapping strategy is never far in the background. But mapping
sdmx to categorycombos is a terrible headache. Regarding flexible
identifiers, we have a (good) situation in Kenya where there is an
authoritative 3rd party master facility registry which dictates the
codes for facilities - the same codes we use in the code field in our
orgunits. External systems are going to identify facilities using
these codes so the little attribute can help greatly. Truth is we
will often not be able to play god when dictating identifiers so we
need a flexible mechanism to deal with what's out there. It's always
possible to translate these externally (using xslt for example) and
that will remain an option, but translating codes to ids when we
already have the codes in our model is a bit redundant.
The data will actually be coming in as an sdmx-hd dataset, but the
closer our datavalueset looks like an sdmx dataset, the easier it is.
Cheers
Bob
>
> 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
