Provide indication of missing support for form vocab features?
Opened this issue · 2 comments
The GitHub repository clearly labels this as a proof of concept, and the available form fields are clearly shown, but it would be useful to also indicate in the demo that the form vocabs do support elements not included in this tool, and perhaps even provide a warning when unsupported field types are found when loading an existing form.
Related to this, if I understand correctly, the supported elements are being loaded by class from the store rather than by "following your nose" from the root form object. This means that information about order of subelements is being ignored, and that fields from multiple different forms in one document would be mixed together.
This is also an example of implicit semantics, which should be avoided:
https://twitter.com/RubenVerborgh/status/1582357537864945665
Apologies if I've misunderstood how this code works.
I've added a warning in bc310c8
I agree that it would even be better to give warnings when unsupported field types are detected, but doing so would require more work. Especially because ember-solid is used for loading and writing data, things are a bit less easy customizable.
fields from multiple different forms in one document would be mixed together
Yes, that's unfortunately true, http://rdf.danielbeeke.nl/form/form-dev.ttl# however requires this by design, it only supports one form per file because the fields are not linked to the form by triples but just by the fact that they are in the same file.
This code was made with this in mind and later extended to support the other vocabularies.
I agree that it would be better to change this for the other supported vocabularies so we don't need the assumption that all forms are in separate files.
Thanks. I appreciate the extra background information and clarity around the intended scope of the proof of concept.