`sh:xone` and list length

[ajnelson-nist]

Originally raised in this comment, excerpted here:

Section 4.6.4 of the 1.0 spec., consistent with today's draft state, reads:

sh:xone specifies the condition that each value node conforms to exactly one of the provided shapes.

However, the remainder of that section doesn't talk about whether sh:xone can or can't be empty. This shape in SHACL-SHACL is consistent with that lack of detail, but the validation for a user with any targeted nodes would always fail, because there isn't exactly one match.

Thinking about it a bit, this seems like it would be a backwards-incompatible change to add a sh:minListLength 1 here that fails a SHACL-SHACL run, because the sh:xone subject could be defined with no targets and sneak in as valid against SHACL-SHACL of SHACL 1.0.

Should SHACL 1.2 do anything about empty sh:xone lists? We have a few options:

• Update the spec to say sh:xone must have a member, and add a sh:minListLength 1 constraint to SHACL-SHACL with sh:Violation severity.
• Update the spec to say sh:xone should have a member, and add a sh:minListLength 1 constraint to SHACL-SHACL with a lesser severity.
• Update the spec to say sh:xone should have a member, and do not update SHACL-SHACL.

If updating the spec, this is my first sketch of wording for the sh:xone spec. section, added to the spans of data-syntax-rules a new rule xone-members-minCount:

There must be at least one member of such list.

If updating SHACL-SHACL to report less-than-sh:Violation severity, then we could use sh:Warning for the shape authors that they're about to cause trouble for their shape users. #192 goes into other severities if we end up thinking a non-violation level would be better.

A PR for this Issue should be built on:

• Issue 415: Use sh:memberShape in SHACL SHACL #417
• feat: #192 add severity levels that are not violations #409 (if group decides on non-violation severity)

[HolgerKnublauch]

I think sh:and and sh:or have the same open interpretation and I don't think there is a problem with that. I wouldn't change anything in the spec.

[ajnelson-nist]

I think sh:and and sh:or have the same open interpretation and I don't think there is a problem with that. I wouldn't change anything in the spec.

I agree with sh:and and sh:or having the same open interpretation on list length. However, those don't have a condition that automatically generates violations for shape users, while sh:xone does.

[TallTed]

@jeswr — You seemed to be in agreement with @ajnelson-nist (which I think is in disagreement with @HolgerKnublauch) on this, in #417 (comment). Would you mind chiming in here, and explaining your reasoning more fully?

[jeswr]

My reasoning is the same as @ajnelson-nist, which is that it seems odd to support a state that will always fail; and when such a constraints does occur in the wild - it is likely unintended so it would be best if tooling calls this out.

The added SHOULD statement in the text + warning violation in the SHACL SHACL - as suggested in this issue - seems like a reasonable middle ground to me.

[HolgerKnublauch]

People do stupid things. They can also model sh:in () which will equally always fail. Or mutually exclusive min/max combinations. I don't think we can enumerate all cases that are impossible to fulfill in the spec. But: The SHACL-SHACL could create a warning or info for sure.

[ajnelson-nist]

I'm leaning towards a sh:Warning-severity violation, housed on a shape in SHACL-SHACL named with an IRI. Reasoning for the IRI: If some use case actually demands the empty sh:xone, a supplementary graph should be able to provide a sh:deactivated true triple to turn the shape off.

I'm tempted to expand this to empty sh:in too, keeping the scope of these checks to empty-list checks in line with what initially triggered this Issue report.