[db-wg] More-specific abuse-c

Hi Sander,

> On 14 Nov 2016, at 00:05, Sander Steffann <sander at steffann.nl> wrote:
> 
> Hi Tim,
> 
> I like the idea in general. I have some questions though:
> 
>> If a user then queries and re-submits the object with minor changes (a common practice), we can detect whether any change was made to the "abuse-c:" attribute. If so, we can assume that the user intended to stop using inheritance for this attribute. But, if the user made other changes and kept the same "abuse-c:", then we can assume that inheritance is still desired.
> 
> 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.

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

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.

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.

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

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

Cheers

Tim



> 
> Cheers,
> Sander
>