[UI] SHACL UI Form error handling guidance

[edmondchuc]

The task force discussed this topic and agreed that the SHACL UI document would benefit from a dedicated guidance section on form error handling for SHACL constraint violations, specifically on how implementations might map SHACL validation reports back to form fields.

This section should cover both client-side and server-side form validation, weighing the trade-offs of each approach. For instance, not all shapes are suitable for client-side validation: those containing SPARQL-based constraints require access to the full dataset, rather than the subset rendered in the form. For server-side validation, when either the data graph or the shapes graph contains blank nodes, implementations must use skolemisation whenever data crosses document boundaries, so that constraint violations in the validation report can be reliably traced back to the originating form field.

Below are some of the areas we intend to explore for the section:

• Mapping validation results to the form: How validation results from the report are linked back to nodes and fields in the data graph.
• Normative vs. guidance status: This content is likely better framed as non-normative guidance rather than a formal requirement.
• Client-side vs. server-side validation: The relative merits of each, including which classes of shapes are unsuitable for client-side evaluation (e.g. SPARQL-based constraints) and when skolemisation becomes necessary on the server side.
• Validation timing: Whether validation should be triggered on form submission, on field blur, or both.
• Shape categorisation: Whether shapes should be classified by their suitability for client-side or server-side validation.
• Field-level vs. focus-node-level errors: Not all validation errors map cleanly to a single field; some must be surfaced at the focus node level instead.