Overview OTM5.3 - Githubissues

This will be the biggest release since OTM5.0, and to get an overview of what happened I want to introduce an overview ticket that has a short summary of everything that is currently planned to make it in. This makes it easier than going through all the tickets. I will also update this description whenever anything changes, since not everything is final yet.

Support 204 responses for deletes (https://github.com/opentripmodel/otm5-change-requests/issues/23) and make those the preferred responses over 200. status accepted, no open discussion points. why: whenever something is deleted there is no use in returning the same entity again, this makes it simpler for implementing parties to just remove it from the database instead of fetching it to return it again. how: just add a new status code for each entity that is supported and make it clear that the 200 status is less favored.
Add classification field to goods (https://github.com/opentripmodel/otm5-change-requests/issues/26) status: accepted, but not all details are complete yet. why: This information is required for some Customs check in multi-country transport. how: add a new optional field to goods called classification. This field can have multiple classificationLines where each can have a hsCode, description, weight (net), grossweight. There is still some discussion on what other fields are necessary. example TODO
Maintain code lists in OTM itself (https://github.com/opentripmodel/otm5-change-requests/issues/27) status: accepted, but not all code lists are complete yet. why: currently there is a lot of freedom in certain fields which might result in parties choosing different fields that mean the same. To avoid this as much as possible OTM is explicitly naming the fields that are possible. how: Add ISO country codes for supported countries, ISO currency codes for supported currencies, units of measure (there is some discussion in how much OTM should incorporate). Using more lists is still open, though the question is how much time we have to incorporate them.
Add result to an action (https://github.com/opentripmodel/otm5-change-requests/issues/30) status accepted, no open discussion points. why Currently it is impossible to see what happened to some action (whether it failed or succeeded or something in between). A result would make it possible to check the what happened and deal with it automatically in systems. how Add a new optional field result to each action. This result has a mandatory status and reason, and an optional remark and description (in case the reason is other). example
```
{
 "actionType": "load",
 "consignment": { ... },
 "result": {
   "status": "failed",  // alternatives: succeeded, partiallySucceeded
   "remark": "somebody dropped the goods and they broke",
   "reason": "damage",
 },
 .. etc
}
```
Add points and transportCategory to ADR (https://github.com/opentripmodel/otm5-change-requests/issues/31) status accepted, no open discussion points. why These fields were simply missing from the OTM implementation of the official ADR spec. how Simply add these fields to the ADR field in goods as optional. example
```
{
  "entityType": "goods",
  "goodsType": "items",
  .. fields like productType, etc.
  "adr": {
    "points": "100",
    "transportCategory": "1" // possible values 1-4
 } 
}
```
Add relatedConsignments to Consignment (https://github.com/opentripmodel/otm5-change-requests/issues/32) status accepted, no open discussion points. why When creating consignments it can happen that it needs to result in new consignments because they are either too big to be transported as one, or delivery failed and a new consignment is created. It is helpful to be able to see what consignments are related and how. how Create an optional field relatedConsignments to Consignment that is a list of associations. Each association has - in contrast to other associations - an optional relation field that is either split or superseded. Relations only go from the old consignment to the new consignment. example
```
{
 "entityType": "consignment",  
 "id": "432f2bec-afef-48f7-b582-1a51bb939387",
 "goods": [ ],
 "actors": [ ],
 "relatedConsignments": [
     {
         "associationType": "reference",
         "relation": "postponed",
         "description": "previous delivery attempt failed",
         "uuid": "7df465e8-fe77-4e8a-a7e2-95836b832c72"
     }
 ]
}
```
Add unCode and glnCode to Location (https://github.com/opentripmodel/otm5-change-requests/issues/36) status accepted, no open discussion points. why The UN code and the GLN code are international standards to refer to a location. These can be added to the external attributes but since they are part of the domain it makes more sense to add them as separate fields. how Simply add the two new fields to location. example (note that these codes do not overlap, this is just an example)
```
{
 "entityType": "location",
 "geoReference": { ...},
 "unCode": "NLDHR",
 "glnCode": "0847976000005"
}
```
Add TemperatureConstraint as a constraint type (https://github.com/opentripmodel/otm5-change-requests/issues/37) status accepted, but how to deal with units of measure is still an open discussion point. why You can already communicate temperature constraints using the sensor constraint, however it makes sense to add more specialized constraints for systems so it is easier to parse and process. how Create a new constraint value type (temperature) with the same setup as the others (minimum, maximum, rannge) and value + unit fields. example
```
{
 "id": "e69aaecc-e7bf-46d4-b691-1cc92dbe4a30",
 "value": {
   "type": "temperatureConstraint",
   "bounds": "range",
   "minimum": {
     "value": 0.0,
     "unit": "C"
   },
   "maximum": {
     "value": 5.6,
     "unit": "C"
   }
 }
}
```

opentripmodel / otm5-change-requests

Overview OTM5.3 #45