How can I perform more complex validations

[bwl21]

I would like to implement validations which take into account not only the current attribute but also sibling attributes.

If the signature of a custom validator would be (value, object), then one could access the container object of the atttribute and thus consider sibling attributes as well.

[bwl21]

Found the solution ...

add a custom validator to the object itself, not only to the attribute.

[RST-J]

Just one comment: Too me, this sounds like a design smell.
You may have your reasons and they may be fine, just for your consideration:
If a property B may only have certain values or be present if another property A has a certain value and if A has a different value, then B must have a different value - this sounds like two schemas to me. So, one reason coming to my mind is, that this is just a matter comfort (which I personally would probably decide differently).

[bwl21]

@RST-J Jonas, thanks for your comment. It is not necessarily a design smell. A sample use case is

{ 
 "event": {
    "title" : "handling negative durations",
    "start" : "2016-02-17T12:30",
    "end" : "2016-01-17T17:00"
   }
}

Validation shall report that end date is before start date in the event "handling negative durations"

Initially I tried to do this while validating start or end as I was not aware that "format" can also be specified for objects, not only for primitives.

[RST-J]

@bwl21 Well, considerations like this were actually my thoughts for developing this feature.
But in our team we then had a discussion about responsibilities where I started to doubt my "cool, let's validate semantics within this rather syntactical tool" point of view and I haven't ultimately figured out my conviction - so for me such a discussion is also a way to elaborate on this.

The spec of format seems to tell us 'do whatever you think might help, but be careful'.
The pro side is obivous, is comfortable to have only one validation step.

On the cons side I see currently two things: First, it is not portable. No one can just take the schema and validate objects one wants to send to your system, even not using Ruby if you don't provide the semantics of your custom formats. No big deal, but at least a deal.
A second thing is, if you create entities based on the received data which can also be created by other means you'd better postpone validation to that point. This is of course no deal if it doesn't apply in one's case.
Having written down these, I don't find the cons all too convincing.

So, I'm more intereseted in hearing other's thoughts on this (and probably like to be convinced that it is a rather good thing to use it this way) than telling them that this is crap.

[bwl21]

It is indeed one ot the issues I am arguing for years, that there is a difference between structural validation and semantical validation. I was often asked why an xml file is not processed correctly even if it passes the validation against the schema. So I can really understand an accept your point of view.

Semantic validations can hardly be expressed in a portable way. There are attempts like this (e.g. OCL) but they end up implementing another programming language.

So in my rather small project I prefer semantic validation by a clear interface an implementing the rules in ruby (as the application itself is written in Ruby). In my case the objects are created i my application. I do't have a Gui so the users are (as of now) creating the objects with a DSL. There I need the validation.

Using "format" is a good approach to keep the validations in an extra rule set and use a formal reference for integration.