Closed bmeesters closed 3 years ago
After discussion there might be simpler solutions. Also it won't be in time for OTM5.1 so it will be moved to OTM5.X
Having thought about this some more, we see that the constraint we see most often in planning-systems is are the time-based constraints. Now you would need to do that using three constraints (one for And which contains a StartTimeConstraint and an EndTimeConstraint). We can make this simpler by introducing a new constraint type where you can - but are not required to - provide them both at once:
So the current solution to provide both looks like this:
{
"id": "48c484f7-54ad-4209-b251-44abef26f6b0",
"value": {
"and": [
{
"startDateTime": "2021-03-12T10:00:00Z",
"type": "startDateTimeConstraint"
},
{
"endDateTime": "2021-03-12T11:00:00Z",
"type": "endDateTimeConstraint"
}
],
"type": "andConstraint"
}
}
I would like to propose this as an alternative (where both start and end times are optional).
{
"id": "48c484f7-54ad-4209-b251-44abef26f6b0",
"value": {
"timeWindows": {
"startDateTime": "2021-03-12T10:00:00Z",
"endDateTime": "2021-03-12T11:00:00Z",
}
}
}
This is now part of OTM5.2
Type of request
Is your feature request related to a problem? If so, please describe the problem. For example: with the current specification I cannot model [...]. Or: I'm unable to provide the use case [...].
Currently
startDateTimeConstraint
andendtDateTimeConstraint
use different fields to indicate the time of the constraint (startDateTime
andendDateTime
respectively). This makes the implementation harder without any clear benefit, whereas the type is really the only difference.Describe the solution you'd like What would you like to add or change to the specification? Please be as clear and concise as possible.
Add a
time
field on both type of constraints and deprecate the separate fields. This make it simpler and more consistent with each other.Describe alternatives you've considered Did you try to solve it with the current specification? If so, how? Please be as clear and concise as possible.
You could keep it as is, since fundamentally it does not change what can be expressed, the proposal is just to make it simpler and more consistent.
Additional context Add any other context or screenshots about the feature request here.