[UI] #609: Add SHACL Render Manager and Focus Node and Node Shape Resolution

[bergos]

Introduces the SHACL Render Manager concept, which manages SHACL Renderer instances and uses Focus Node and Node Shape Resolution to determine which (focus node, node shape) pairs to render. Also lists it among the concepts available for composing profiles.

Closes #609

• See this document rendered online here

This is an alternative to PR #1118 for issue #609. I believe it's leaner while still covering all the necessary cases, and it maintains a clear separation between the algorithm and its impact on the render logic. It also handles all variations of the given input parameters.

[danielbeeke]

This pull requests has three parts:

1. SHACL Render manager
2. Changes of conformance statements in 9.4 Grouping, Ordering, and Layout Hints
3. A profile section

Section 1
I think section 1 is an improvement over the pull request #1118, I personally find it clearer that it is defined as a component vs. the algorithm in Smessies PR. Would it be fine to interpret 'component' here as just a part of the software? I am wondering if we could tweak it a little bit such that implementations have the freedom to choose themselves if they want one root component with many props / attributes or various components with controlled interfaces.

@smessie implementations could also have a root component called <shacl-ui /> and wrap <shacl-renderer />. What are your thoughts on that?

Section 2
From my perspective should only be changed after we settle on #1083.

Section 3
I would put this in a different pull request.

If you would remove section 2 and section 3 and place those in other PR's I would be close to approving this. I do want to hear Smessies perspective about props as he has the idea to create one root component.

[smessie]

@danielbeeke thanks for splitting this out clearly. I agree section 2 should wait for #1083 and section 3 belongs in its own PR, so let me focus on section 1.

On "component" vs. algorithm: I think the freedom you are describing is exactly what #1118 already gives you. An implementation is free to expose resolution as one root component with many props, or as several components with controlled interfaces, or as a plain function, because the algorithm framing says only what is computed and stays silent on structure. A root <shacl-ui> that wraps a <shacl-renderer> is a perfectly valid implementation of #1118, and the spec does not need to say anything for that to be conformant.

My hesitation with defining it as a "component" is that it pulls an implementation-architecture concept into the normative text. Even read as "just a part of the software," it still presupposes a boundary, props, or an interface. That is the thing we agreed earlier the specification should not mandate: it should define what each step does, never how it is exposed. So I would rather the normative text not privilege a one-root-component arrangement or a multi-component one; #1118 stays neutral on that by design, and that neutrality is deliberate, not an omission.

Yes, interpret "one root component with props" as just one valid arrangement. It is the arrangement I happen to prefer for my own implementation, which is exactly why I would not want the spec to prescribe it for everyone.

I do take the point that the algorithm framing can read as abstract. I am happy to add a non-normative example to #1118 showing how it maps to a component composition (for instance a <shacl-ui> wrapper around a <shacl-renderer>), so readers get that concreteness without the specification committing implementers to any particular structure.

[bergos]

The word "component" doesn't imply any implementation detail. Both, a custom element and a plain JS function are components. That said, I'm open to suggestions on how to improve the wording.

The PR depends on the profile PR, because it defines the SHACL Render Manager as a concept for a profile. I want to avoid duplicate work, so let's keep it as is. I hope the task force can agree on the profile approach. If it goes to the WG, I think there's much higher chance we'll settle on the profile approach. But we can always change it with another PR afterward.