Why does the FDP use DASH-Editor/viewer properties to create front forms ?

[PatrickDekkerHealthRI]

Instead of use DASH properties to create the form, we can use the nodeKind. This has the following advantages:

• Most published shacl don't have DASH properties (like DCAT-AP-3, Health-DCAT),
  • They need to be manually added before you can use it in de FDP.
  • If you forget them for a field, it hard to detect, you don't get error, a property is just not shown on screen
• The number of Dash editors is limited. For instance there are DateTime and Date editors, but DCAT also uses xsd:gYearMonth, so there is no Dash editor for this. (also xsd:nonNegativeInteger from DCAT-distribution doesn't have an editor)
• There also not many (any ?) tool that have Dash support.
• It looks like DASH is not maintained anymore.
• It's just ugly to have Model and View mixed

For some enum properties, you can now use Dash to create a drop down menu. This is functionality that we will loose. or we have to find an alternative way to specify them. (in resource ?)

[dennisvang]

It's just ugly to have Model and View mixed

I completely agree with this observation. Personally I'm not opposed to using dash to specify form layout for the client, but I think it has no place in the default schemas that are stored in the FDP (backend) repo.

Instead, I would propose to move all dash-related statements from the FDP (backend) default schemas into separate schemas defined in the FDP-client repository, aimed purely at presentation.

It is important to note that the FDP-client is currently a pure "client-side" application, i.e. it is served in the form of static files, without any server-side rendering or storage. Thus, in order to make these presentation-schemas editable, we would need to define a special schemas/resources to be stored on the FDP backend side. However, the defaults for these would also be stored in the FDP-client repo.