Talk:De-blue MessageCommunicationsControl

Transmission wrappers

Use, but remove from RIM

Dan Russler (in an e-mail, paraphrasing) suggests not to include the blue classes in the RIM anymore (but to keep on using them)

Replace by RIM classes

Replacing the blue classes by RIM classes is an option. This adds some abstraction (Structural Attributes) which will show at the XML level.

There is a secundary motivation for doing this: it will allow for requirements analysis to be (re)done. The existing blue classes were mostly ported from v2 and are based on requirements that may not exist for v3. The fact that INM has already removed attributes from the blue classes because of a "lack of underlying use-case" is a symptom of the need to do a requirements analysis.

A mapping is feasable:

RIM based wrappers (mockup)

• Message is an act,there is a participation/role/entity for for CommunicationFunction
• Attachment is just message.txt
• There is an ActRelationship for Acknowledgement to another message or transmission
• Batch has an ActRelationship to batches or messages.
• Acknowledgement detail is another act relationship/act?
• QueryByParameter is the act of querying. ParameterList is some kind of collection Act.
• ParameterItem is a problem if one attempts to fully model it - it can be any of the 6 base classes or an attribute. Only real options are to either stick with blue for parameter, or to be creative and use a "creative" act (the act of "selecting a subset") which is essentially a key/value pair.

WGM Sept2006, 20060911

At the joint MnM/INM meeting the issue was discussed. Rene reviewed the contents of the Wiki page (as of 20060911), and showed the mockup model. Grahame: another reason for doing this is related to ITS problems, because blue classes are different, no structural attributes. Initial response awful, but looking at it there may be good reasons. Woody: a RIM question. Will it lead to greater clarity. Document is a precedent, unfortunately. Grahame: initially felt the same, spent time working on what it would look like. More expressive, if you understand RIM more naturally, not convinced that its particularly worse. Craig: if redone, through ballot process, let it go ahead, go to ballot. Lloyd: any specific questions that INM should answer? Woordy: Can all of the concepts be expressed? Would some UML transport standards not be more appropriate? Charlie: mutiple options there. Grahame: grey zone advanced/simple transport.

Woody felt that moving the communications information into the backbone would obscure the content. He feels that the RIM backbone should be focused on Acts, and that communications concerns should not pollute the backbone. He suggested that finding an external approach that is commonly accepted may be preferable to spending significant effort maintaining our own.

There is some question as to the mappability from the existing model to the proposed model. However, this may be an opportunity to clean up the communications model.

Lee Coller expressed a reluctance to make significant changes to the transmission infrastructure based on the number of existing implementations of these. However, he also expressed a desire to have the query infrastructure revamped.

Lee C: There are R1 implementations, this is a radical change.

Charlie: slight disquite, not a methodlogical objection.

2006911: While there were some concerns MnM sees no functional objection and request a proposal (to represent the existing structures based on analysis supported by requirements) to do a mapping to RIM backbone. Evaluation of this more proposal [outcome by MnM to see if there is no methodlogical misfit] (Charlie/Woody, 21-0-3)

Jan2007 WGM

• Committee agrees to "de-blue" the current models. Some problems are expected with parameterItem.
• Motion: committee feels we should move forward and de-blue the models as a strategy. Has a number of advantages. (Mark/Rene, 6-0-0)

An advantage which has not yet been explicitely documented: de-blueing would allow the use of templates in queries.