View source for Lab Issues Table - 2006-09

[[Category:Referred Reconciliation Issues]]
Return to [[:Category:Referred Reconciliation Issues]]

This is the Set of the Issues forwarded from LB (Lab SIG) to Methodology and Modeling between May and September, 2006. 

{| border='1' style="background:#efefef;" 
|+ Content from Reconciliation Spreadsheet
!width='5%'|Item ID !!width='7%'|Source!!width='6%'|Level!!width='45%'|Issue!!width="37%" style='background:white'|Proposed Disposition
|- valign='top' |
|LB 106
|Richard HARDING
|Neg-Mj
|This is Dick's old Name Change problem which i am balloting yet again.  This is really important - it upsets casual readers immensely.
This matter was referred to MnM by PA at the January 2005 Ballot and has not been fixed and no resolution has been communicated to me about that ballot comment since then.
replacementOf in the RMIM diagram and in the walkthrough, appears as ReplacementOf2 in the TableView and excelView.
fulfillment in the RMIM diagram and in the walkthrough appears as InFulfillmentOf2 in the tableView. It is particularly important that readers do not confuse "fulfillment" aka "InFulfillmentOf2" with inFulfillmentOf aka"InFulfillmentOF".
author (with a lowercase initial a) becomes Author (uppercase initial A). 
Really confusingly subjectOf2 becomes Subject1, at the same time as subjectOf1 becomes Subject.

I wish to be present when this matter is discussed. Otherwise, I need written advice of three questions: a) is this behaviour acceptable, b) will this be fixed and c) by which ballot cycle will it be fixed.

I intend to take the "Paul Biron approach" with this ballot - I will not withdraw my negative on this item without greater assurance that the matter identified has been fixed.

I intend to take this issue to the Board if not satisfactorily resolved.
|style='background:white'|This is a summary of the resolution M&M proposes to adopt.  

M&M voted to recommend to the referring committee that they find this negative vote "Not Persuasive."  The reason for this recommendation is expressed in [[Reconciliation Rationale - 2006-09-29-001]]. Further, with regard to this concern, M&M agreed to seek improvement in the representation to ease this confusion.  This is detailed in [[Reconciliation Undertaking - 2006-09-29-001]]. 

|- valign='top' |
|LB 107
|Richard HARDING
|Neg-Mj
|Must get consistent naming of a class (the sequence of letters and their case must be identical), for the same class in the RMIM diagram, the DMIM walkthrough, the TableView and the ExcelView.
|style='background:white'|This is a summary of the resolution M&M proposes to adopt.  

M&M voted to recommend to the referring committee that they find this negative vote "Not Persuasive."  The reasons for this recommendation are partially expressed in [[Reconciliation Rationale - 2006-09-29-001]], which explains why certain names will be different in Table Views, etc. than they are in the RMIM diagram.  Further, however, M&M notes that the methodology allows the name of a clone to be different in an RMIM than it was in the DMIM from which that RMIM is derived.  Indeed, this difference is '''required''' in circumstances where a DMIM clone appears twice in an RMIM. Further, with regard to this concern, M&M agreed to seek improvement in the representation to ease this confusion.  This is detailed in [[Reconciliation Undertaking - 2006-09-29-001]]. 
|- valign='top' |
|LB 128
|Richard HARDING
|Neg-Mi
|Aborted is a terminal state - it should therefore connect to the sink symbol.
The same comment applies to "Cancelled".
Consider  moving aborted to the right of suspended. 
Note that Laboratory relies heavily on this diagram and would need to change all of its derivative diagrams.
|style='background:white'|This is a summary of the resolution M&M proposes to adopt.  

M&M voted to recommend to the referring committee that they find this negative vote "Not related" because the issue is with the representation of a RIM state diagram which is '''not part of the LB ballot'''.

Nevertheless, M&M asked LB to forward a RIM harmonization proposal to address this concern.
|- valign='top' |
|LB 129
|Richard HARDING
|A-S
|Is there a UML-standard way of showing the "Replace" transition on the ACT state-machine.
Lab requires this to allow: One order replaced by many orders, one order replaced by one order, multiple orders replaced by one order, multiple orders replaced by multiple orders. The orders being replaced become Obsoleted.
Perhaps we have a transition arrow from active to active that bifurcates and one part goes to "Obsoleted". 
|style='background:white'|In discussion, M&M noted that the voter's inquiry reflects an attempt to read more from a state diagram than it contains.  Specifically, a state machine tracks a single object.  It is not a process diagram nor multi-object coordination diagram, which would be required to address the voters interest in multiple order objects.  The meeting asked LB to draft a position on these distinctions that M&M can endorse for return to the voter.
|- valign='top' |
|LB 147
|Richard HARDING
|A-S
|We need some discussion about how someone looking at the real world can determine if an order is active. This should probably be done in the RIM documentation adjacent to the ACT state Machine diagram. While you are at this, a discussion of what NEW actually means in the real world is lacking as well.
|style='background:white'|M&M finds this concern "not persuasive", although this was not a negative vote.  The RIM documentation cannot begin to encompass all possible combinations of Act classCodes, moodCodes and use cases.  This must be done in the domain discussion, such as the wording that the voter cited.
|- valign='top' |
|LB 109
|Richard HARDING
|A-Q
|Do we have a clear definition of a fixed value for a code and a default value?  Where is this defined? I am unable to find it in the Rim and vocubulary documents. Fixed and default are used to describe codes in table views.
|style='background:white'|Deferred because we wished to address "negatives".
|- valign='top' |
|LB 110
|Richard HARDING
|A-Q
|CONCEPT OF FIXED AND DEFAULT CODED VALUES.
What behaviour do we expect of a sender when valuing an attribute defined as {CNE:IRCP, default= "IRCP"} where the default value is a Specialised term? This appears in POLB_HD004000. I am sure that other examples exist.
Do we expect the user to select the most appropriate child of IRCP? That imposes some difficult responsibilities on the receiver. If this is so, will all receiving applications be programmed to correctly interpret this? I suspect this behaviour is unsafe.
Do we expect the user to always use IRCP and never select a child? That implies that the value is fixed and the word "default" should actually be "fixed".
Do we expect either IRCP or its children will be used? I find this to be unsafe as well.
Where is any of this documented? The words "default and "fixed" do not appear in either the RIM or Vocabulary documents
|style='background:white'|Deferred because we wished to address "negatives".
|- valign='top' |
|LB 149
|Richard HARDING
|A-Q
|Can you tell me what vocabulary domain defines the transitions in the Act state Machine?
Should the transitions have their own vocabulary domain?
|style='background:white'|Deferred because we wished to address "negatives".
|- valign='top' |
|LB 113
|Richard HARDING
|Neg-Mj
|Tooling must be upgraded to allow entry of attribute-level descriptions.
This must now be a high-priority item.
I intend to take the "Paul Biron approach" with this ballot - I will not withdraw my negative on this item without greater assurance that the matter identified has been fixed.
|style='background:white'|This is a summary of the resolution M&M proposes to adopt.  

M&M voted to recommend to the referring committee that they find this negative vote "Not related." This issue was drawn from an LB ballot but it expressly addresses tooling for line item descriptions. 

Despite this recommendation, however, M&M notes that Tooling has made the requisite changes. This observation should '''not be construed''' as agreement by M&M that all attributes must have line-item descriptions.
|- valign='top' |
|LB 93
|Richard HARDING
|Neg-Mi
|The names of classes frequently morph in confusing ways. My V3 reference group are immensely critical of this aspect of V3. THIS ALSO HAS BEEN BALLOTTED ON SEVERAL BALLOT CYCLES - I CANNOT RECALL RECEIVING ANY NOTIFICATION OF THE DISPOSITION OF THIS MATTER.
I intend to take the "Paul Biron approach" with this ballot - I will not withdraw my negative on this item without greater assurance that the matter identified has been fixed.
Specific instances are described below for Lab DMIM POLB_RM002000.
|style='background:white'|M&M grouped this item with item LB # 106 for a single response.  Please see the earlier discussion.
|- valign='top' |
|LB 130
|Richard HARDING
|A-S
|Consider providing a working version of this diagram to domain content creators - It will ensure consistent look-and-feel and save them some effort.
I note that Lab made some typos when transcibing the diagram.
|style='background:white'|M&M returns this to LB, as it does not appear to address an M&M issue.
|- valign='top' |
|LB 119
|Richard HARDING
|
|This is great content!!!!! Congratulations!
Now all Tooling has to do is move it out of here to the Table and Excel Views.
|style='background:white'|M&M returns this to LB, as it does not appear to address an M&M issue.
|}