Page MenuHomePhabricator

Don’t always check “type” constraint on qualifiers
Closed, ResolvedPublic


In T175570: Don’t check some constraint types on non-statement contexts, I thought it didn’t make sense to check “type” constraints on qualifiers and references, so I disabled them.

Then, in T177388: Check “type” constraint on qualifiers and references, I noticed that it does make a lot of sense to check “type” constraints on qualifiers, so I enabled them again.

And now I noticed the “type: occurrence or time interval” constraints on “start time” and “end time”, which make sense when the property is used for the main statement, but not in a qualifier…

In this case, I think a distinction is possible between the two cases because the constraints where the “type” constraint does make sense are on qualifier-only properties (have a “used as qualifier” constraint), while “start time” and “end time” are not qualifier-only properties. But I think looking at other constraints (“used as qualifier”) to check whether to apply some property or not is too complicated and confusing, so we probably need some parameter, e. g. “constraint scope”, which determines where to check constraints (main snak, qualifier and/or reference context).

Event Timeline

Lucas_Werkmeister_WMDE claimed this task.

This has been resolved with the addition of the “constraint scope” parameter – by default, we don’t check type constraints on qualifiers and references, but individual constraints can opt-in by specifying those scopes explicitly.