Breaking out from our current hard coded set of object attributes is certainly a great step forward. There is also some advantage in trying to think a bit generally about what we are doing. We are seeing lots of progress in the right direction. I was about to start a discussion about names earlier, but maybe it makes sense to consider some of these things together.
In general an entity within the dhis model universe has: (i) a set of identifiers (ii) a set of names (iii) a set of attributes (iv) a set of relations with other attributes One could think of names as attributes, but there are reasonable semantic reasons to consider them separately. On top of this generic view we have classes or categories of entity. Such as DataElement, OrgUnit etc, where the class of the entity determines the set of attributes and the type of relations between them. I think from an xml metadata representation perspective, this is probably how it should be modelled. The fact that some of the attributes may be fixed database fields and some dynamically configured attributes is incidental and purely historical. If you had the benefit of hindsight and were designing a datadictionary from scratch, you might never have had the fixed fields in the database. Or you might have come up with different ones. On import/export I think the distinction should simply be masked by the API. Fixed or non-fixed is an internal arrangement of little interest outside the system. Bob PS. One of the possible uses of attributes which I am seeing is the in fact the possibility of dynamically adding new identifiers for objects. On 8 September 2011 15:55, Jo Størset <stor...@gmail.com> wrote: > Thanks for the responses. > > So I guess this might very well be a start of a general evolution in the meta > model? It might be worth already now thinking a little through the possible > consequences of this direction going forward. I think this is something we > need :) > > As we work through how to represent the meta model in external formats (xml > and so on), this might have implications on how generic a model we should > create for these formats (and I guess the attribute definitions themselves > have to represented in some way). In that context it might make sense to > generalize both the objects these attributes apply to and the way we > represent atrributes more generally. And also at least look at and specify > likely future harmonization now? > > Changing the external formats once they are created is much more difficult > than changing implementation details, so it might be worth it to think a > little bit broader already now. > > A minor point - when I saw the term dynamic attributes, I was immediately > thinking free-form attributes (more like tags you could put on individual org > units). But I guess this is about predefined attribute types applied to > (specific) meta objects(?) Maybe just calling it "attributes" might be good > enough, if that is what it is? > > 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
