Why does Angular Schema Form have both a json form and a json schema that are separate? It seems that some of the properties in the form could be in the schema and vice-versa. For example, in the simple example on the schemaform.io website we have the form as:
[
"name",
"email",
{
"key": "comment",
"type": "textarea",
"placeholder": "Make a comment"
},
{
"type": "submit",
"style": "btn-info",
"title": "OK"
}
]
And the schema as:
{
"type": "object",
"title": "Comment",
"properties": {
"name": {
"title": "Name",
"type": "string"
},
"email": {
"title": "Email",
"type": "string",
"pattern": "^\\S+@\\S+$",
"description": "Email will be used for evil."
},
"comment": {
"title": "Comment",
"type": "string",
"maxLength": 20,
"validationMessage": "Don't be greedy!"
}
},
"required": [
"name",
"email",
"comment"
]
}
It seems that in the email property in the schema both the title and the description could just as well be in the form definition as in the schema. Can someone explain the meaning of both the form and the schema and why they are separate?
JSON Schema
JSON Schema is a IETF standard (as linked to from the JSON-Schema docs)
JSON Schema Form org (which ASF is part of) cannot make changes to the JSON Schema standard on their own. JSON Schema is designed as a model / validation / hypermedia definition format only, at this stage.
The JSON Schema Form org is in direct discussion with the JSON Schema org and I am now part of that org too as we look to eventually define a JSON Schema UI standard as well, which could end up as anything from simply being a method to ensure no property collisions occur in future or a more detailed standard.
For now the manner in which Angular Schema Form evolved from jsonForm does create some confusion with similar terms that cannot be used in the same manner between formats and variations in format like the use of dot notation keys or readOnly vs readonly.
UI Schema
The need of many organisations using JSON Schema is to present a UI for editing the data format defined by the schema, thus the UI Schema defines how the model should be presented. It allows overriding the schema values, so most, if not all values in the schema can be changed, but also adds additional types based on templates defined within the framework (which may change to a different term like widgets in future).
The UI Schema also uses arrays to ensure that the ordering of the fields is as expected while providing the ability to define just a key to generate the form field from only the data found in the JSON Schema definition. You can also use wildcards, and soon ellipsis, to generate form elements without even using the keys if no overrides are needed at all.
Separation of concerns
The reason to not try and combine the two is for separation of concerns, the UI Schema is essentially acting as a type of view controller. Many corporate applications will use the same data in many different views, for example when an admin has more access to edit data than a regular employee. It doesn't make sense to duplicate the data model each time, only the view.
This may seem like overkill for a very basic form, but you never know when requirements will expand and new functionality will be added to necessitate a new view of the data.
There is also often a need to support state information in the browser with attributes defined in the form that are not found within the model.
Disclosure: I am the maintainer of Angular Schema Form at the time of writing.