Hi Tim, >> Making assumptions is dangerous. Would this logic only be applied if >> inheritance is already in use? If not then the results could be surprising. > > Yes, only if inheritance is already in use. > > I think that the assumption that the inheritance preference should not change > is safe to make if no changes were made to the attributes.
I think that is a good balance. > The one downside I can see to this is that it will be impossible to specify > that you want to stop using inheritance, but keep the exact same set values. > This will then require a work-around: submit object with different values, > and shortly after re-submit with original values. However, I expect that this > is a very uncommon scenario (you may have to use it if you want to remove > admin-c/tech-c from an ORGANISATION object). True. > The alternative is to keep things explicit. So only use inheritance when the > object is submitted without these attributes. The drawback of this approach > is that it would break the "query -> change one or two things -> resubmit" > routine that is used a lot, because the queried object would have the > resolved values. Yeah, keeping that working is the most important I think. > Note that when we build a user interface for incidental updates by users we > can go with either option - we would know that inheritance is used or not so > we can present the user with an explicit choice on this. But existing > automated systems would likely break inheritance if the explicit option is > required. I think the first option would actually result in the least > surprising behaviour, and the work-around described above is a small price to > pay for having the option of inheritance. Also, remember that none of this > applies unless you first opted in to this. +1 >>> On the other hand it's very simple to opt-in for users who do want to use >>> this. Just set up "admin-c:", "tech-c:" and "abuse-c:" on your ORGANISATION >>> object, and resubmit your resource objects without these attributes to >>> start using inheritance. Then when for example you want to remove one >>> "admin-c:" you only need to change your ORGANISATION object and everything >>> else will follow. >> >> What would happen if inheritance is used and then admin-c or tech-c is >> removed from the ORGANISATION object? Would those attributes be considered >> mandatory when inheritance is used, or would the attributes automatically be >> set on the inheriting objects? > > Good point. Either could work. I prefer mandatory and keep things explicit. Me too. If that can be implemented then great. >> I like adding such inheritance to the database, it would make common data >> structures a lot easier to maintain, but we should also be careful not to >> create unanticipated surprises for users :) > > I agree. The intention is of course to avoid nasty surprises. Thanks! Sander
signature.asc
Description: Message signed with OpenPGP using GPGMail
