Add TemperatureCelsius as contraint type enumeration value

[BobZuidhoek]

I'd like to add something to the OTM 5 spec.

Background / context
In the perishables and refrigerated transport industry, it is very common to specify a minimum, maximum or range of temperatures that a consignment must be transported in. Currently, there is no explicit Constraint>Value>Type for TemperatureCelsius.

My opinion is that a temperature constraint is so common, that it deserves to have its own type. The type SensorValueConstaint or GenericContraint does not quite cut it.

Describe the solution you'd like

• Add TemperatureCelsius to Constraint>Value>Type enumeration
• Have the same setup as currently for weightConstraint (i.e. maximum, minimum, range).

Additional context and considerations
I think that we do not have to make it that flexible so you can specify the temperature type (Celsius, Fahrenheit or Kelvin). Fahrenheit is only used in the United States. Kelvin is more for scientific purposes.

I do not know if it should be allowed that 2 goods-lines in 1 consignment could be transported at 2 different temperatures (e.g. the frozen fish must be transported below -5 degrees and the fruit between 5 to 10 degrees). I presume a scenario like that is, also from a legal perspective, best handled using 2 separate consignments (and 2 different CMR's). I hope other people can comment on how this works.

[bmeesters]

Originally OTM was aiming to provide generic constructs so the specification could remain small. However, I think in hindsight it would have been better to be more specific. So I agree that the Temperature and Weight (and Speed) constraints are good additions in favor of the SensorValueConstraint that can then be deprecated.

However, I would like not include the unit. I agree that Celsius is likely the only one that is going to be used for the forseeable future but it would be inconsistent with all other units of measure and I think consistency in the specification will result in less confusion and less chance it will be used wrongly.

do not know if it should be allowed that 2 goods-lines in 1 consignment could be transported at 2 different temperatures (e.g. the frozen fish must be transported below -5 degrees and the fruit between 5 to 10 degrees).

I am also not sure, will check whether any of the parties we work with models something like this as one or two consignments.

[BobZuidhoek]

Hi Bas,

I was under the impression that you couldn't specify the unit of measure. Turns out, you can specify the unit of measure but only in case of SizeConstraint. For WeightConstraint and SpeedConstraint, the unit-field does not seem available when looking at the OTM5 developer docs page (then you would also expect these there).

My opinion would be to simplify these 4 by having a pre-set unit of measure:

• SizeConstraintMeters (and then allowing up til 3 decimals to you can specify up to mm).
• WeightConstraintKgs (and then allowing up til 3 decimals to you can specify up to gram).
• SpeedConstraintKmH
• TemperatureCelsius

Or specify the (single) unit of measure in documentation and drop if from the attribute names.

This avoids having to maintain a dedicated enumeration list of allowed unit of measures for each constraint-type (i.e. you don't want everyone to go out and start picking whatever unit of measure is out there). You also avoid needing extensive conversion tables within TMS-systems (e.g. to convert between gramm to kg, lbs to kg, etc).

All in all, my opinion is that in this case flexibility does not yield any benefit. OTM5 is of course only used for system integration (messages). If everyone just maps ountbound messages to 1 unit of measure per constraint, and for inbound messages everyone just has to map 1 unit of measure per constraint to how your internal system deals with that , then that simplifies things a lot.

[bmeesters]

Not sure what you are looking at, but I just checked and the size, weight, speed and sensor constraints all use the value with unit approach. I don't think we are going to change those, since that would be backwards incompatible.

So I don't think it would be a good idea to add a new TemperatureConstraint and make it different than literally everything else in OTM5 right now.

I am sympathetic to your point of view of not maintaining any lists that are supported and reducing the amount of mapping. But I think changing all the constraint types will have a bigger impact. We would basically completely change how constraints work currently.

[BobZuidhoek]

Hi Bas, see attached screenshots of what I get from the interactive OTM5 developer page (at Put Constraint and then use the dropdown of type)



.

In the screenshots, you only see the unit attribute at SizeConstraint. You don't see unit at WeightConstraint or SpeedConstraint.

PS: I also noted an inconsistency: at SizeConstraint you have an attribute called bounds, where for WeightConstraint that attribute is called WeightConstraintType and in case of SpeedConstraint the attribute is called SpeedConstraintType.

[bmeesters]

Ah I see what you mean now. The original intended use is that you select a 'constraintType' of either minimum, maximum or range. Then you can use the minimum and maximum object that both contain a value and a unit field. Size having a separate unit is actually an oversight as well. So you should indicate what you are going to use (either minimum, maximum or both) and then use the appropriate fields. This is actually almost unchanged from OTM4.

I think this changes things a bit, because there are multiple oversights that need to be fixed now, so we might want to consider a more drastic change, like including the units in the constraint themselves. As a I said, I am sympathetic to the argument to make it simpler and have less conversions. However I am also on the fence since larger changes like this might punish parties already using constraints.

[BobZuidhoek]

Aha, I see now that you could also expand the "maximum" and "mimimum" attributes, and then find the unit of measure. I probably was looking at this with something else than my eyes :-).

For everyone reading along, then this is what you see:

So all in all, there actually are 3 possibilities now to make this overall consistent:

1. Keep the flexibility of specifying the unit of measure as sub-level under the "minimum" and "maximum" attribute. This would imply that for Sizeconstraint the "bounds" attribute needs to get deprecated.

2. Keep the flexibility of specifying the unit of measure, but set this directly under the constraint type (i.e. as SizeConstraint does it). The given unit then applies to the values set at minimum and maximum. I think this is a bit more logical then possibility 1, because I find it difficult to understand why you for example would specify a maximumweight in KGs and the a mimimumweight in Gramms. This would imply that SpeedConstraint and Weightconstraint need to get the "unit" attribute added directly under them. And the "minimum" and "maximum" attribute can directly be the values (they don't need a sub-level anymore). and the "unit" attribute under "maximum" and "minimum" gets deprecated from all constraint types.

3. Hardcodedly prescribe a single unit of measure for each constraint type. This is the most favorable I think.

As you said Bas, there of course is the refactoring of current implementations to take into consideration here. The impact of that is something I cannot oversee (i.e. I don't know how many current implementations will be impacted). I think it largely depends on what the % of current implementations is relative to the total foreseen implementations. For example, if we think we currently are only at 5% (or less) of implementations relative to the number of total future implementations, my opinion would be that it's really best to pick the most optimal solution each time. I also presume the current implementors know they are early adaptors and foresee having to deal with the occasional breaking change now and then.

So do know I approach everything here from the angle of what I think is most logical. You and DALTI need to figure out to what degree that is also seen as the best and achievable solution.

[bmeesters]

I also presume the current implementors know they are early adaptors and foresee having to deal with the occasional breaking change now and then.

While it is true that OTM is still quite young and is evolving a bit more, this statement is not correct. One of the defining reasons why early adopters adopt OTM is because some stability is promised. So, there will be no removals from OTM5 until we bump OTM6, which we will not do for the foreseeable future. We can - and occasionally will - deprecate fields or even whole entities in favor of better ones. Meaning that the 'old' way is still official OTM5. But this should be done sparingly.

I think constraints are not widely used yet, so this could be a good time to improve them. I will create a new change request specifically addressing the units with measure. Regarding this ticket, the temperature constraint is accepted, whether or not the unit Celsius will be included is a separate concern.

[BobZuidhoek]

Okido