multiple invocation states within one report
At least one, non-empty. Not sure if we should put up any rules in addition to those we alredy imposed on the usage of pm:Identification. Subject to review, I would say.
B.99 rank is ambiguous
Proposal from today's discussion: introduce a coded value in the Revision that contains an "invocation state reason" that is applicable (not only) to failed operations. (We may want to express a reason, e.g., for cancelled operations, too.)
Proposal from today's discussion: introduce a coded value in the Revision that contains an "invocation state reason" that is applicable (not only) to failed operations. (We may want to express a reason, e.g., for cancelled operations, too.
Closed [#112] as duplicate. Original ticket text: In case an operation fails, there is only a limited amount of information to classify the error in a machine readable way. We should consider adding an extension that adds an optional (mustUnderstand=false) coded value to a failed operation result in order to classify the error for further processing.
Error types for operation results
Discussion continued in duplicate ticket [#114].