Context
Raised by @nicholascar in #1083 and by @danielbeeke in the task force meeting of 11 August.
The same shapes are used across several deployments, and each needs a slightly different form:
- a different field order for different clients or user groups
- some properties not displayed at all in one deployment, while remaining part of the data model
@nicholascar's example is VocPub used by two client deployments. @danielbeeke's is clients using profiles such as DCAT-AP where UI choices need to be overridden without touching the profile.
The need
The variation is real and should be supported. The question is where it is expressed.
Today it is typically expressed in each product's own configuration. That works, but it is not portable: the deployment cannot be moved to another implementation and keep its arrangement, because the arrangement is not in the shapes and there is no standard way to state it.
Where the shapes come from a published application profile (see the application profiles use case to be created by @danielbeeke), editing them to change the order is often not an option at all.
Two parts
Ordering. A deployment needs to state an order that differs from the one the shapes give, without editing the shapes. A sketch discussed in the meeting:
<#myOverrideShape>
a sh:OverrideShape ;
sh:target ex:CompanyShapeName ;
sh:order 3 .
Hiding. A deployment needs to state that a property is not displayed while remaining subject to validation. sh:deactivated does not express this, because deactivating a property shape also removes its constraints from validation. A dedicated term, for example shui:hidden, would.
These are related but not the same kind of thing. Hiding needs a property that does not exist yet, and that property is useful on its own: an author who owns their shapes may want to mark a property as not displayed without any override involved. Ordering already has a property, so the gap there is not the term but the ability to apply it to a shape someone else owns.
Open questions
- Whether a property for hiding, such as
shui:hidden, should be defined independently of any override mechanism, given it is useful to authors who do own their shapes
- Whether an override mechanism should be able to carry any UI property, including a hiding property once one exists, or be specific to ordering
- Where such a mechanism belongs, given a term like
sh:OverrideShape would sit in the sh namespace while shui:hidden would not
Context
Raised by @nicholascar in #1083 and by @danielbeeke in the task force meeting of 11 August.
The same shapes are used across several deployments, and each needs a slightly different form:
@nicholascar's example is VocPub used by two client deployments. @danielbeeke's is clients using profiles such as DCAT-AP where UI choices need to be overridden without touching the profile.
The need
The variation is real and should be supported. The question is where it is expressed.
Today it is typically expressed in each product's own configuration. That works, but it is not portable: the deployment cannot be moved to another implementation and keep its arrangement, because the arrangement is not in the shapes and there is no standard way to state it.
Where the shapes come from a published application profile (see the application profiles use case to be created by @danielbeeke), editing them to change the order is often not an option at all.
Two parts
Ordering. A deployment needs to state an order that differs from the one the shapes give, without editing the shapes. A sketch discussed in the meeting:
Hiding. A deployment needs to state that a property is not displayed while remaining subject to validation.
sh:deactivateddoes not express this, because deactivating a property shape also removes its constraints from validation. A dedicated term, for exampleshui:hidden, would.These are related but not the same kind of thing. Hiding needs a property that does not exist yet, and that property is useful on its own: an author who owns their shapes may want to mark a property as not displayed without any override involved. Ordering already has a property, so the gap there is not the term but the ability to apply it to a shape someone else owns.
Open questions
shui:hidden, should be defined independently of any override mechanism, given it is useful to authors who do own their shapessh:OverrideShapewould sit in theshnamespace whileshui:hiddenwould not