Issue 4295: MofError when Operation impl violates structural constraints (mof-rtf) Source: DSTC (Dr. Stephen Crawley, nobody) Nature: Uncategorized Issue Severity: Summary: The description of the behaviour of an Operation does not say what ought to happen if an Operation's implementation returns parameters or results that violate multiplicity constraints. Similarly, for Exception parameters. This affects sections 5.8.13 and 6.2.3 ("refInvokeOperation"). Resolution: see above Revised Text: At the end of 5.8.13 add the following paragraph. "If an Operation has a multi-valued 'out', 'inout' or 'return' Parameter, or if it can raise an Exception with a multi-valued field, its implementation shall ensure that the returned collection or collections satisfy the Parameters' multiplicity constraints. If they do not, the implementation shall use MofError to signal a Semantic Error. (Since this case is deemed to be an error in the implementation, "Overflow, Underflow, Duplicate or Invalid Object must not be signalled here.)" In Section 6.2.3, add "Semantic Errors" to the list of MofError exception kinds for "refInvokeOperation". In Section 6.2.3, add the following as the second to last paragraph of the description of "refInvokeOperation": "A "Semantic Error" will occur if the invoked Operation tries to return a collection value as a result, out or inout parameter that violates the Parameter's structural constraints. This will also occur if an Exception Parameter's value is similarly incorrect." Actions taken: Actions taken: May 8, 2001: received issue December 3, 2001: closed issue Discussion: The current text does not say whether any checking should be done, and if it is done, what flavours of MofError should be thrown. This needs to be tied down. My recommendation is to make the checking mandatory. IMO, it would be a Bad Thing to return parameter collections to the client that don't match the multiplicity "contract". My recommendation is to use the standard 'reason' strings for Underflow, Overflow, Duplicate and Invalid Object. IMO, they adequately cover the situation(s). (Another alternative would be to invent new reason strings that indicate that the fault is in the server implementation not the client's usage. But I think this is overkill, because the MofError error description field could be used to make this distinction.)Underflow, Overflow, Duplicate and Invalid Object should not be used since this tends to imply that the error condition is the caller's fault. This would be rather confusing. Instead, a "semantic" MofError should be raised. There is not need to specify an error code, but we will make the checking mandatory. End of Annotations:===== X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: issues@omg.org, mof-rtf@omg.org Subject: MofError when Operation impl violates structural constraints Mime-Version: 1.0 Date: Tue, 08 May 2001 16:25:46 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: `p*!!!DK!!l2L!!:#l!! Summary: The description of the behaviour of an Operation does not say what ought to happen if an Operation's implementation returns parameters or results that violate multiplicity constraints. Similarly, for Exception parameters. This affects sections 5.8.13 and 6.2.3 ("refInvokeOperation"). Discussion: The current text does not say whether any checking should be done, and if it is done, what flavours of MofError should be thrown. This needs to be tied down. My recommendation is to make the checking mandatory. IMO, it would be a Bad Thing to return parameter collections to the client that don't match the multiplicity "contract". My recommendation is to use the standard 'reason' strings for Underflow, Overflow, Duplicate and Invalid Object. IMO, they adequately cover the situation(s). (Another alternative would be to invent new reason strings that indicate that the fault is in the server implementation not the client's usage. But I think this is overkill, because the MofError error description field could be used to make this distinction.) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: mof-rtf@omg.org Subject: Re: Issue 4295: MofError when Operation impl violates structural constraints Mime-Version: 1.0 Date: Thu, 05 Jul 2001 22:43:41 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: X`R!!:a!!!<_nd9Cehd9 > Source: DSTC (Dr. Stephen Crawley, crawley@dstc.edu.au) > Nature: Uncategorized Issue > Severity: > > Summary: The description of the > behaviour of an Operation does not say what ought to happen if an > Operation's implementation returns parameters or results that > violate > multiplicity constraints. Similarly, for Exception parameters. This > affects sections 5.8.13 and 6.2.3 ("refInvokeOperation"). > > Discussion: The current text does not say whether any checking > should > be done, and if it is done, what flavours of MofError should be > thrown. This needs to be tied down. My recommendation is to make > the > checking mandatory. IMO, it would be a Bad Thing to return parameter > collections to the client that don't match the multiplicity > "contract". My recommendation is to use the standard 'reason' > strings > for Underflow, Overflow, Duplicate and Invalid Object. IMO, they > adequately cover the situation(s). (Another alternative would be to > invent new reason strings that indicate that the fault is in the > server implementation not the client's usage. But I think this is > overkill, because the MofError error description field could be > used > to make this distinction.) Proposed Resolution: Underflow, Overflow, Duplicate and Invalid Object should not be used since this tends to imply that the error condition is the caller's fault. This would be rather confusing. Instead, a "semantic" MofError should be raised. There is not need to specify an error code, but we will make the checking mandatory. Proposed Text: At the end of 5.8.13 add the following paragraph. "If an Operation has a multi-valued 'out', 'inout' or 'return' Parameter, or if it can raise an Exception with a multi-valued field, its implementation shall ensure that the returned collection or collections satisfy the Parameters' multiplicity constraints. If they do not, the implementation shall use MofError to signal a Semantic Error. (Since this case is deemed to be an error in the implementation, "Overflow, Underflow, Duplicate or Invalid Object must not be signalled here.)" In Section 6.2.3, add "Semantic Errors" to the list of MofError exception kinds for "refInvokeOperation". In Section 6.2.3, add the following as the second to last paragraph of the description of "refInvokeOperation": "A "Semantic Error" will occur if the invoked Operation tries to return a collection value as a result, out or inout parameter that violates the Parameter's structural constraints. This will also occur if an Exception Parameter's value is similarly incorrect."