declaring (practically) insensible shapes to be ill-formed

I know that this topic has been previously discussed in https://www.w3.org/2014/data-shapes/track/issues/139 <https://www.w3.org/2014/data-shapes/track/issues/139>

However, we now have a couple of WG members who have not participated in this discussion and we are starting to get some questions on this from the broader community as evidenced in a recent comment from Olivier Corby as to why all constraint components are available with both node shapes and property shapes. Thus, I thought, perhaps, we should revisit the topic.

At one point we used to disallow some constraint components for node shapes, but currently all are allowed. With this, a user can write a shape such as
>> 
>> ex:MinCountExampleShape
>>  a sh:NodeShape ;
>>  sh:targetClass ex:Person;
>>    sh:maxCount 2 ;
>>  sh:minCount 2 .

It will be considered a well-formed shape. Given any data graph with instances of ex:Person, the validation result will always be the same:

The maxCount constraint will never produce a validation result - because any resource is always just one resource.
The minCount constraint will always produce a validation result - because any resource is always just one resource.

I see this shape as an “insensible shape” in that no one would ever create such a shape except as a mistake i.e., what they really meant to say and check for was something else. I considered calling it an “illogical shape”, but I didn’t because my use of the word “illogical” would be colloquial - the spec defines what such shape means and how it should be interpreted. 

Nevertheless, the interpretation is so completely impractical, I believe a typical developer or a data modeler is very unlikely to correctly understand it on their own - no matter what we say in the spec unless we explicitly prohibit it. Further, it would be very hard to explain the meaning of such shape to them and, once they understood it, they will wonder why such shapes are allowed in the first place. Even further, the explanation is so counter-intuitive that they are very likely to quickly forget it and go back to a more intuitive/plausible interpretation of this shape - which is that it constraints the number of members of the ex:Person class.

Does anyone sees an issue with saying that the use of certain constraint components (such as min and max count, QCR and property pair constraints) in a node shape creates an ill formed shape? The cost of disallowing certain constraints is very low. 

Additionally, by doing this, the WG will save time because we will have fewer cases to cover by tests. Given the WG time line it is an important additional argument for returning to this issue. Disallowing such shapes is also likely to decrease costs for implementers.

Regards,

Irene