This wiki has undergone a migration to Confluence found Here
ControlAct.id
Revision as of 23:54, 14 September 2006 by Rene spronk (talk | contribs)
This page documents an INM Finalized Workitem, i.e. an issue within scope of the INM Committee that has been finalized, and which (if applicable) has been included in an INM ballot.
Make ControlAct.id mandatory ?.
- It is currently an optional attribute. The ControlAct is the key thing in every message, so for it to not be identified makes little sense. We can set an expectation that responses to requests must echo back the ControlAct.id. This makes good modeling sense. What you're responding to is not the payload but the request about the payload. If I send you 20 requests for modification messages, and your response just includes the id of the thing to be modified (which is contained in the payload of the application response), I have no idea which request you're responding to. If you send me the ControlAct.id, I know *exactly* what you're responding to. I might not have a prescription.id or an annotation.id, but I will always have a ControlAct.id, and that id will be unique to the request.
- Using ControlAct.id is a little better than Transmission.id, because ControlAct.id is probably an end-to-end concept, whereas Transmission.id is peer-to-peer (or hop-to-hop).
- MnM will discuss Interaction Patterns during the May2006 WGM. The outcome of that discussion may influence the discussion of this issue.
- May2006 out of cycle: Motion: We ask MnM to consider what interaction pattern support should be provided to the domain committees, so that we can decide what support is required in the wrappers (Grahame / Charles) 0-1-34.
Discussion probably needs to be reviewed in the light of the CPM. The Communication Process Instance (CPI) provides the type of ID discussed above.
