Repository navigation
Add lifecycle to trip and consignment and a way to remark on the lifecycle #4
Description
Type of request
- I'd like to add something to the OTM 5 spec
- I'd like to change something in the OTM 5 spec
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 Consignments and Trips have a status, but the status options are not complete. It is not possible to mark a Trip or Consignment as Finished/Delivered.
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.
The status in a Consignment and in a Trip is remarable similar to the lifecycles we already use. It might be better to deprecate the status and use a lifecycle instead. Also, to support everything the current status can we should have a new lifecycle cancelled. However, sometimes a status alone is not enough, we might want to know why something was cancelled, so we also propose to add a statusRemark. Lastly, the modified field is not very helpful since it does not provide any information on what was modified or when. So a final proposal is to add a 'lastModified to each entity (like the creationdate), it is very easy to determine then whether something was modified (creationDate != lastModified). If you want more information about an audit trail using events is the most appropriate choice.
To sum everything up:
- Add a
lifecyclefield to Consignments and Trips. - Add a new lifecycle
cancelled. Add astatusRemarkto entities/actions/events that have a lifecycle.- Add a
lastModifiedto every entity.
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.
Another alternative is to extend the status field with completed. However maintaining two lists might be confusing. On the other hand, how should the actions below a 'cancelled' trip behave? Should all of them be cancelled?
Additional context
Add any other context or screenshots about the feature request here.
Activity
bmeesters commentedon Mar 4, 2021
After internal discussion at Simacan the conclusion was that we try to combine things that cannot be combined. In general OTM5 expects nested actions to be of the same lifecycle. For example a load action in a planned stop is expected to also be planned. However if you add a lifecycle to a trip or a consignment this severely limits how you can use the actions within those entities. For example cancelling a trip would require to also change all actions within that trip to cancelled.
So the proposal from Simacan is to just extend the current Status field with a complete.
thomaskolmans commentedon Mar 4, 2021
I do not understand how a this would change it to the worse from how it is now, the opposit actually. Let's say you cancel a trip, the lifeCycle of the related actions are now still "active" and that does not make sense to me either. It would make more sense to me if you cancel a Trip or Consignment that the underlying actions are also cancelled. I actually really liked the proposed changes, they made total sense to me at least.
In regards to those last 2 points, what will happen with the "statusRemark" and "lastModified"? I think those are good changes in any case. As well as, will there be a
in_transit/activestatus too apart from the "complete"? Then we pretty much have a full lifeCycle again...bartkummel commentedon Mar 4, 2021
Hi Thomas,
I was part of the internal discussion mentioned by @bmeesters , so let me explain our considerations.
If you zoom out, you can see that OTM is merely a language to share data between multiple systems and even multiple domains. That means, there will be multiple states within those systems. Some states might map well to the life cycles in OTM, but others probably won't. (This wil stay true, no matter how many life cycles you would add.) I think the best OTM can do is being transparant about the differences between systems and domains, instead of trying to unify everything.
The way we envision life cycles is: there are a limited number of life cycle phases that are common to the whole domain that is covered by OTM. And life cycles are limited to actions and events in OTM for a good reason. In OTM, the entities are the constant factor, they exist over all life cycles. The actions and events happen in a specific life cycle. We would like to keep the model clear and keep this clear distinction. There can be an event to cancel something. That might lead to some state field to change, but that has nothing to do with the life cycle. (Note that OTM itself doesn't do anything. It is the systems that "talk" OTM that do stuff, like changing the state of an entity whenever an event occurs.)
That said, we must not deny that there are multiple systems communicating with each other and that the state of an entity within one or more of those systems is valuable information; OTM should be able to express that information. But I think that, by limiting it to just that –information about the state of an entity in some system– we can keep simple things simple, while staying open to do complicated things with more effort.
So, what to conclude? I think we should consider:
lastModifiedfield, as proposed by Bas;I hope this helps and are looking forward to seeing this boil down to concrete improvements in OTM.
Best regards,
Bart Kummel
thomaskolmans commentedon Mar 4, 2021
Hi Bart,
Agreed! As these objects are clearly statefull and those states are not yet enitrely defined in my opinion. Thus when communicating between systems they will miss vital information right now.
Look forward to the suggested state fields, in the discussion on the website itself there was an interesting suggestion already.
bartkummel commentedon Mar 4, 2021
For future reference, @thomaskolmans is referring to this discussion, I think: https://www.opentripmodel.org/discuss/602ea278d8d02a0035a56952
I'll leave it to @bmeesters to come with a more concrete proposal.
bmeesters commentedon Mar 5, 2021
I think the suggestions in the opentripmodel.org chat are good. So then the full proposal would be:
activeandcompletedas status fields on both the consignment and the trip.lastModifiedto every entity.On top of that, a
statusRemarkwould be very useful. However I think we might want more. A realized action for example does not indicate whether something realized successfully or was failed/cancelled. A remark could help here but is very unstructured and hard to process automatically.So my proposal is to add a new ticket for a status result as some complex object and discuss that separately. Any thoughts?
thomaskolmans commentedon Mar 7, 2021
Yes, those 2 changes sound good to me. I also agree that we should be wanting more, I actually ran into this thought breakpoint just now while implementing a cancellation flow.
If an object with a
statusorlifeCycleis cancelled or has changed status, there is no field (apart fromexternalAttributesorremarkin some cases) that communicates well what actually happened. With actions you could use theremarkfield for it.I'll have a think for a solution from our perspective in the coming days.
bmeesters commentedon Mar 12, 2021
@thomaskolmans Any new thoughts on this? Otherwise I suggest to just go with my previous proposal and open a new ticket.
rvanweegberg commentedon Mar 25, 2021
A bit late, but I want to suggest to add as status field on both the consignment and the trip.
bmeesters commentedon Mar 25, 2021
@rvanweegberg Sorry I don't fully understand, what new status do you want to propose?
rvanweegberg commentedon Mar 25, 2021
I want to add status 'Confirmed'.
bmeesters commentedon Mar 26, 2021
Alright, let's zoom out a bit and look at the complete process of either delivering some consignment and driving a trip (since they are very similar). I think they contain the following steps that each should be a status:
requestedand not yet confirmed. An alternative torequestedcould bedraftin case it is not complete yet, but the party creating doesn't have to request it since it has the authority toacceptit themselves.accepted. Since we already haveacceptedI don't think we also needconfirmed. Even though I thinkconfirmedis a little bit better. However cannot remove a status, so better to have one than have both IMO.active. Personally I prefer inin transit, since that would better for both trips and consignments, especially if they are not actively moving but also not at their final destination.completedcould work for both.This brings us to the following list:
requested,accepted,inTransit,completedandcancelled.Alternatively we can use:
draft,confirmed,inTransit,completedandcancelled.draftandrequestedare not entirely the same, but close enough that I question whether we need both. The same goes foracceptedandconfirmed.In case of option 1 we need to deprecate
modified, in case of option 2 we would also need to deprecaterequestedon top ofmodified. Any preferences? @thomaskolmans, @rvanweegberg, @bartkummel?thomaskolmans commentedon Apr 6, 2021
Is it possible to both have
requestedanddraft, especially for the TransportOrder as both of these states are a very likely possibility with other interpretation for systems too.Further, I understand the preference for
in transitas opposed toactive, howeveractivewould also cover TransportOrders. Themodifiedstate does not communicate anything in context of the Trip, Consignment or TransportOrder state, as it does not communicate anything that alastModifieddoesn't.bmeesters commentedon Apr 7, 2021
I think that both
draftandrequestedcould work. As long as we clearly describe when to use which. I personally don't see howactivewould be better thanin transitfor TransportOrders? It's in transit as long as not all consignments have been delivered. I thinkactiveis not great for something that is static and not actively doing anything.thomaskolmans commentedon Apr 7, 2021
No, sorry I actually agree now thinking about it again.
inTransitis a lot more explanatory thenactive, just on that front alone I think it's better.Yes a clear definition should be provided between
draftandrequested.How about:
draft: a preliminary versionrequested: asking for something officiallyThose definitions have to be adjusted to the context of course, but I thought this was pretty clear from the dictionary.
bmeesters commentedon Apr 8, 2021
Sounds good to me,
so the new list would be:
draft,requested,confirmed,inTransit,completedandcancelled, right?bmeesters commentedon Jun 1, 2021
Closing this as it is now official part of OTM5.1