[UI] Decision: what does a conformance claim guarantee, and do claims name what they cover?

[smessie]

Split from #1083. The specification's conformance section is currently a TODO, and much of the rest depends on what goes in it.

Questions

1. What does "conforms to SHACL UI" guarantee to a shape author or an adopting organisation?
2. Do we adopt profiles or declared features, and if so, must a conformance claim name the ones it meets?
3. Which profiles or features, if any, are required for a claim to be made at all?

Use cases

• [UI] Use case: moving an existing deployment to a different SHACL UI implementation #1160: Moving a deployment to a different implementation, including the procurement dimension
• Application profiles the organisation does not control (see use case issue to be created by @danielbeeke)
• [UI] Use case - Closed-World Systems HTML Forms #1142: whether a build-time generator can make a conformance claim, and of what

Proposed resolution

There was broad agreement in the task force meeting of 18 August on a direction, and I would like to write it down here so people can say whether they agree.

1. Map the specification to features. The specification defines a set of named features. Each feature covers a coherent piece of behaviour and is something an implementation can meaningfully say it does or does not support. Roughly: label and language resolution, ordering, widget matching, and so on. The exact set is work to be done, and doing that work is the next step.

2. An implementation lists the features it implements. This is what makes implementations comparable, and it's the part I'd most like to see agreed. An adopter can see what an implementation covers, and a shape author knows what to target.

3. The specification designates which features are required for conformance. Not every feature is required. The specification says which set an implementation must support before it can claim conformance at all.

4. Start with features, and decide about profiles afterwards. Rather than designing a profile mechanism now, I would suggest we define the features first and see how many there are and how they group. It is possible that one required set is all we need, in which case we may not need the term "profile" at all. If the features turn out to fall into natural groupings, we can name those then, with the evidence in front of us.

The thing I would ask us to settle regardless of how much structure we end up with: a conformance claim says what it covers. No unqualified "conforms to SHACL UI" that leaves an adopter unable to tell what they are getting.

Anything published as a feature set or profile should be a deliverable in the specification, subject to the same process and review as the rest of it.

What this leaves open

• The feature set itself: what the features are and where the boundaries fall
• Which features are required for a conformance claim
• Whether we need more than one required set, and whether "profile" is the right term for that
• How an implementation records and publishes its feature support

[danielbeeke]

I agree with proposed solution 1, 3 and 4.
I think we can ask 2 but I do not see a way of enforcing. We could have a simple checklist that makes it easy for implementations to publish this information.

[edmondchuc]

Thank you @smessie for summarising the discussion. I have to say, I really like the proposed solution. As you mentioned, once we define the set of features in SHACL UI and specify which ones are required and which are optional, we may find that we don't need profiling after all.

My proposal is to address the first open point:

• The feature set itself: what the features are and where the boundaries fall.

Should we create a PR adding a table of SHACL UI features and see whether that helps guide us on the remaining open points?

[smessie]

I agree it's good to start with the first point @edmondchuc.
I'm happy to create a PR for that and see how far I come, which we can then discuss together.
We'll have to see if a table is the best format to structure this, but in general, I agree to your proposal.

[smessie]

I've opened #1173 tackling the first open point — the feature set itself: what the features are and where the boundaries fall.

It replaces the Conformance TODO with a feature catalogue: a single index table of 26 features, each with a short behavioural description, the specification sections that define it, and a suggested conformance level. The authoritative behaviour stays in the linked sections; the table doesn't restate the normative requirements.

The boundary rule is: a behaviour graded SHOULD or MAY becomes its own feature, so an implementation can report it independently and it can be marked not-required. That keeps the distinction between what an implementation must do and what it may optionally do visible in its feature list. Property paths, for example, are split by kind and by view/edit mode.

Deliberately not settled here (separate open points): which features are required, and whether we need profiles/groupings — that's easier to judge once we can see how the features cluster. The feature set's checkability also depends on #1165 (whether the spec defines an abstract rendering model as the basis for conformance testing).

This is a proposal for discussion, not settled text — feedback on the boundaries (anywhere a feature seems too fine or too coarse) and on the suggested levels is very welcome.

Rendered: https://raw.githack.com/w3c/data-shapes/ui/feature-set/shacl12-ui/index.html