We have implemented CIS and TMPlan in our traffic management R&D, and we are now looking at a new potential use - all to allow national traffic managers and local traffic managers to collaborate.
The question is about the ServiceFeedback class – I’m not sure we fully understand the intention of the two attributes called “general”. One is a status, and there is also a very similar status attribute
(serviceActivationStatus) in the class. The definitions of the two status attributes are subtly different – one (general) is about the status of the service request, and the other (serviceActivationStatus) is about the activation status of the service requested. I see a difference, but let’s consider an example where the values would be different, to check that we understand. So for example if there was a service which was to activate a plan, let’s say the plan is scheduled for activation anyway, but a new CIS service request is made to activate it, and that request is invalid, say because of lack of authorisation of the requester. So the serviceActivationStatus might be “scheduled” but the generalServiceRequestStatus might be “notCompliant”. Is that the correct understanding of the intended semantics of these two attributes? If so then is it correct that serviceActivationStatus is mandatory but generalServiceRequestStatus is optional? It occurs to me that you will always know something about the request, but if a system is just passing on the request (like ours is) then it may not know any extra different information about the service itself – it can only judge the service status by the status of the request.
And also if that understanding is correct then we wondered if there was a need for another text attribute to give additional information about the status of the service requested, since the generalServiceRequestFeedbackReason applies to the service request rather than the service requested. (We added a new attribute serviceRequestResponseComment to allow the latter.)
One more small thing – the request statuses in the legacy systems included timedOut. We could map that to ServiceActionStatusEnum.failed, but that would lose a small amount of information, so we added a new literal timedOut.