Re: Using Hydra for Data Model Genration and Validation

> I don't think we should start talking about widgets.. but if you know how the data should look like and what it represents it is typically very simple to automatically choose the "right" widget. If you know it's a date, display a calendar widget.. a checkbox for a boolean, etc.

Yes, I understand your argument, but the data type does not always map
to a definite widget. Of course there could be a safe standard. If you
want to create more refined and feature rich forms there would be a
need to have more "annotation" or hints regarding which widget to use
and maybe even an additional widget configuration. But like I said,
this could only work on an annotation level.

> Yes, HTML5 is a good starting point. Other than that, I think it would make sense to look at popular frameworks/validation libraries

Let me throw in: http://json-schema.org/latest/json-schema-validation.html

2014-10-14 13:05 GMT+02:00 Markus Lanthaler <markus.lanthaler@gmx.net>:
> Hi Simon,
>
> On 14 Okt 2014 at 12:45, Simon Heimler wrote:
>>> That depends on what you are trying to achieve. You can of course
>>> limit your validation to a document and "close the world" by doing
>>> so. But obviously your validation results would just be true for
>>> that document.
>>
>> Yes, but this would be completely sufficient for the creation and
>> validation of forms. The idea would be to have hard validation prevent
>> the users from entering crude mistakes that can easily be avoided,
>> even on the front-end side. After that could still be an open world
>> system that can do further reasoning. But if the validation and form
>> is rather rigid, a lot of problems wouldn't even enter.
>
> Right. In that case, you don't need to be concerned too much about the open world assumption.
>
>
>>> I don't see a problem with that. We don't support any validation
>>> constraints apart from readable/writeable/required at the moment but
>>> I see no reason for not extending that in the future if people find
>>> it useful.
>>
>> That sounds interesting! but Its not my intention to "bloat" Hydra
>> with additional features to allow form and validation - escept this
>> makes sense anyway. Sometimes its a better solution to have modular
>> "extensions" that can be used if required?
>
> Exactly for that reason Hydra has been conceived as a modular vocabulary from the very beginning. Currently we just have the Core vocabulary.. if there's enough interest, we could of course start working on a separate Constraints or Validation vocabulary.
>
>
>>> Yes, with RDFS (a simple, standardized vocabulary) you can define
>>> that a class is a subclass of another class. You can do the same
>>> with properties as they are first class citizens (they aren't in
>>> most programming languages).
>>
>> Correct me if I'm wrong on that.. but isn't the RDFS Class and
>> Property system in some aspects very different from "usual" object
>> orientation? But I guess if it is used only for inheritance and not
>> for reasoning this makes not much difference?
>
> Yes, the main difference is that properties are first class citizens instead of being strictly bound to a class. I think it doesn't matter much for what you are trying to do. Please also note that in Hydra we have "supportedProperty" which aligns the model closer to what developers are used to. If you combine these aspects of Hydra with RDFS it should reflect quite closely the "usual object orientation" as you call it.
>
>
>>> Yep. Hydra puts a strong focus on simplicity (but that's of course a
>>> subjective measure). The HydraConsole already leverages Hydra to
>>> dynamically render forms. If we would add more constraints to Hydra,
>>> the HydraConsole could support more client-side validation.
>>
>>> Yes, validation could make sense there. What do you think about
>>> making suggests about which input types / widgets to use? Maybe this
>>> is a bad idea since this can heavily depend on the client
>>> implementation. But if used for own purposes (like your
>>> HydraConsole) it would be useful for auto generation if this could
>>> be somehow added on top. Of course this is nothing that could be
>>> standardized.
>
> I don't think we should start talking about widgets.. but if you know how the data should look like and what it represents it is typically very simple to automatically choose the "right" widget. If you know it's a date, display a calendar widget.. a checkbox for a boolean, etc.
>
>
>> Maybe the HTML5 Input Types are a good place to start?
>> http://www.w3schools.com/html/html5_form_input_types.asp I also like
>> the ability to just define a Regular Expression if the standardized
>> types do not suffice. This is of course not semantic, but it is
>> sufficient for validation purposes.
>
> Yes, HTML5 is a good starting point. Other than that, I think it would make sense to look at popular frameworks/validation libraries. Things like
>
>   https://github.com/chriso/validator.js
>   https://github.com/symfony/Validator
>   https://jcp.org/en/jsr/detail?id=303
>
>
> Cheers,
> Markus
>
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>

Received on Tuesday, 14 October 2014 12:48:23 UTC