Issue 19254: InstanceSpecification validity is not modelable (uml2-rtf) Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk) Nature: Clarification Severity: Minor Summary: InstanceSpecifications may be used to indicate intermeditea states in a transaction and so may not necessarily be valid. InstanceSpecification may be used to create test models and so should necessarily be valid. It is not easy for tooling to detect which is the design intent. Suggest adding an InstanceSpecification::isValidatable property to enable tools to behave usefully. Resolution: Revised Text: Actions taken: February 21, 2014: received issue Discussion: End of Annotations:===== vered-To: spamcop-net-omg4web@spamcop.net X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on filter8 X-Spam-Level: X-Spam-Status: hits=0.0 tests=none version=3.2.4 From: webmaster@omg.org Date: 21 Feb 2014 10:00:49 -0500 To: Subject: Issue/Bug Report X-SpamCop-Checked: 23.30.177.17 23.30.177.16 ******************************************************************************* Name: Edward Willink Employer: mailFrom: ed@willink.me.uk Terms_Agreement: I agree Specification: UML Section: 9.8 FormalNumber: 2.5 Version: 2.5 Doc_Year: Year Doc_Month: Month Doc_Day: Day Page: 128 Title: InstanceSpecification validity is not modelable Nature: Clarification Severity: Minor CODE: 3TMw8 B1: Report Issue Remote Name: edwillink.plus.com Remote User: HTTP User Agent: Mozilla/5.0 (Windows NT 6.0; rv:27.0) Gecko/20100101 Firefox/27.0 Time: 10:00 AM Description: InstanceSpecifications may be used to indicate intermeditea states in a transaction and so may not necessarily be valid. InstanceSpecification may be used to create test models and so should necessarily be valid. It is not easy for tooling to detect which is the design intent. Suggest adding an InstanceSpecification::isValidatable property to enable tools to behave usefully. Delivered-To: spamcop-net-omg4web@spamcop.net X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on filter8 X-Spam-Level: * X-Spam-Status: hits=1.0 tests=EXTRA_MPART_TYPE,HTML_MESSAGE version=3.2.4 From: "Wendland, Marc-Florian" To: Ed Seidewitz , "uml2-rtf@omg.org" CC: Juergen Boldt , "issues@omg.org" Subject: AW: issue 19254 -- UML 2.6 RTF issue Thread-Topic: issue 19254 -- UML 2.6 RTF issue Thread-Index: AQHPLyRJChUiJI8a1E6O8OWDoQKH9prAEjwAgAGao3A= Date: Sat, 22 Feb 2014 19:45:09 +0000 Accept-Language: de-DE, en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [2001:638:806:9::121] x-kse-antivirus-interceptor-info: protection disabled X-cloud-security-sender: marc-florian.wendland@fokus.fraunhofer.de X-cloud-security-recipient: juergen@omg.org X-cloud-security-Virusscan: CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mx-gate07-dus with BDF812118004 X-cloud-security-connect: pluto.fokus.fraunhofer.de[195.37.77.164], TLS=, IP=195.37.77.164 X-cloud-security: scantime:.1290 X-Virus-Scanned: amavisd-new at omg.org X-SpamCop-Checked: 23.30.177.17 23.30.177.10 94.100.134.207 195.37.77.164 14.3.174.1 Hi Ed, I do not think that either of the cases your described matched with what Ed Willink wanted to introduce. It is rather the case that if you have some OCL constraints added to a Classifier (so some StructuralFeatures are constrained to comply with a certain specification). An InstanceSpecification of that Classifier does not necessarily have to abide by these constraints for the StructuralFeatures. E.g., Classifier A + property B : Integer [0..1] + ownedRule : OCL {self.B > 0 and self.B < 10} would still allow to build an InstanceSpecification of A with a value that evaluates to either < 0 and > 10 for the slot that refers to B. I think Ed asked for a flag that requires the InstanceSpecification of A as a strict compliant InstanceSpecification according to the constraints given for A. Best regards, Marc-Florian Von: Ed Seidewitz [mailto:eseidewitz@ivarjacobson.com] Gesendet: Freitag, 21. Februar 2014 21:08 An: uml2-rtf@omg.org Cc: Juergen Boldt; issues@omg.org Betreff: RE: issue 19254 -- UML 2.6 RTF issue What is meant by .validation. here? More specifically, what validation would not be done if isValidatable is false? From the constraints on InstanceSpecification, the only one that I could see would make sense to .turn off. under the cases considered by the issue would be this one: defining_feature The definingFeature of each slot is a StructuralFeature related to a classifier of the InstanceSpecification, including direct attributes, inherited attributes, private attributes in generalizations, and memberEnds of Associations, but excluding redefined StructuralFeatures. That is, if isValidatable=false, then the InstanceSpecification could have slots that had StructuralFeatures that were not valid features of a classifier of the InstanceSpecification. I am not sure what use this really is. Note that slots still would have to have a StructuralFeature specified, which would have to be owned by some Classifier, so it is always straightforward to add that to the set of classifiers for an InstanceSpecification if you need a feature from it. Note that Slot itself has no constraints at all. UML does not prevent modeling situations in which multiplicity is violated or even when a slot indicates that a feature has a value of the wrong type. This would seem to already cover the cases mentioned in the issue. Or is the intent that, if isValidatable is true, then there are additional constraints on InstanceSpecification such that the multiplicity, typing, etc. for all its slots are valid? This would be a more significant enhancement to current InstanceSpecification modeling. But it is not clear that the submitter was asking for that. -- Ed From: Juergen Boldt [mailto:juergen@omg.org] Sent: Friday, February 21, 2014 11:45 AM To: issues@omg.org; uml2-rtf@omg.org Subject: issue 19254 -- UML 2.6 RTF issue Delivered-To: spamcop-net-omg4web@spamcop.net X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on filter8 X-Spam-Level: X-Spam-Status: hits=0.0 tests=none version=3.2.4 From: webmaster@omg.org Date: 21 Feb 2014 10:00:49 -0500 To: Subject: Issue/Bug Report X-SpamCop-Checked: 23.30.177.17 23.30.177.16 ******************************************************************************* Name: Edward Willink Employer: mailFrom: ed@willink.me.uk Terms_Agreement: I agree Specification: UML Section: 9.8 FormalNumber: 2.5 Version: 2.5 Doc_Year: Year Doc_Month: Month Doc_Day: Day Page: 128 Title: InstanceSpecification validity is not modelable Nature: Clarification Severity: Minor CODE: 3TMw8 B1: Report Issue Remote Name: edwillink.plus.com Remote User: HTTP User Agent: Mozilla/5.0 (Windows NT 6.0; rv:27.0) Gecko/20100101 Firefox/27.0 Time: 10:00 AM Description: InstanceSpecifications may be used to indicate intermeditea states in a transaction and so may not necessarily be valid. InstanceSpecification may be used to create test models and so should necessarily be valid. It is not easy for tooling to detect which is the design intent. Suggest adding an InstanceSpecification::isValidatable property to enable tools to behave usefully. Juergen Boldt Director, Member Services 109 Highland Ave Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org Das Bild wurde vom Absender entfernt. []  Delivered-To: spamcop-net-omg4web@spamcop.net X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on filter8 X-Spam-Level: * X-Spam-Status: hits=1.0 tests=EXTRA_MPART_TYPE,HTML_MESSAGE version=3.2.4 X-Virus-Scanned: OK From: Ed Seidewitz To: "Wendland, Marc-Florian" CC: Juergen Boldt , "issues@omg.org" , "uml2-rtf@omg.org" Subject: RE: issue 19254 -- UML 2.6 RTF issue Thread-Topic: issue 19254 -- UML 2.6 RTF issue Thread-Index: AQHPLyRNflOoHcj1vE6Nc2EpsbEs1ZrAIIowgAHy8YD//6drcA== Date: Sat, 22 Feb 2014 20:40:33 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [64.134.240.49] X-Virus-Scanned: amavisd-new at omg.org X-SpamCop-Checked: 23.30.177.17 23.30.177.10 173.203.6.137 184.106.31.85 14.3.169.1 Marc-Florian . Well, this certainly isn.t clear to me from the statement of the issue. As I originally wrote, it comes down to what is meant by .validation.. Right now, UML does not have any semantics on InstanceSpecifications relative to constraints modeled on classifiers of that InstanceSpecification. So it there is currently no restriction on modeling InstanceSpecifications that don.t satisfy such constraints. So, if your interpretation is correct, what is being asked for is a flag InstanceSpecification::isValidatable such that, if it is true, the InstanceSpecification should not violate any constraints attached to its classifiers. However, what is the conformance requirement for this? The issue says that the flag is intended to .enable tools to behave usefully., but what tools? Should a UML tool be required to check such constraints and consider an InstanceSpecification with isValidatable=true but that violates a constraint to be ill-formed? I think not, since this would require the tool to be able to evaluate arbitrary constraints, and there is no requirement that constraints in UML be necessarily specified in a formal or evaluatable language. I guess, then, that isValidatable would simply be a flag to indicate the intention of the modeler that the InstanceSpecification does meet all applicable constraints, but it would be a modeler responsibility, not a UML modeling tool responsibility, to make sure this is true. Some other, specialized tool could then check that the modeling intent is correct in the case of constraints specified in a specific, computable way (such as in OCL), but this would be outside what is defined in the UML specification. Maybe Ed can verify that this was what he had in mind. -- Ed From: Wendland, Marc-Florian [mailto:marc-florian.wendland@fokus.fraunhofer.de] Sent: Saturday, February 22, 2014 2:45 PM To: Ed Seidewitz; uml2-rtf@omg.org Cc: Juergen Boldt; issues@omg.org Subject: AW: issue 19254 -- UML 2.6 RTF issue Hi Ed, I do not think that either of the cases your described matched with what Ed Willink wanted to introduce. It is rather the case that if you have some OCL constraints added to a Classifier (so some StructuralFeatures are constrained to comply with a certain specification). An InstanceSpecification of that Classifier does not necessarily have to abide by these constraints for the StructuralFeatures. E.g., Classifier A + property B : Integer [0..1] + ownedRule : OCL {self.B > 0 and self.B < 10} would still allow to build an InstanceSpecification of A with a value that evaluates to either < 0 and > 10 for the slot that refers to B. I think Ed asked for a flag that requires the InstanceSpecification of A as a strict compliant InstanceSpecification according to the constraints given for A. Best regards, Marc-Florian Von: Ed Seidewitz [mailto:eseidewitz@ivarjacobson.com] Gesendet: Freitag, 21. Februar 2014 21:08 An: uml2-rtf@omg.org Cc: Juergen Boldt; issues@omg.org Betreff: RE: issue 19254 -- UML 2.6 RTF issue What is meant by .validation. here? More specifically, what validation would not be done if isValidatable is false? From the constraints on InstanceSpecification, the only one that I could see would make sense to .turn off. under the cases considered by the issue would be this one: defining_feature The definingFeature of each slot is a StructuralFeature related to a classifier of the InstanceSpecification, including direct attributes, inherited attributes, private attributes in generalizations, and memberEnds of Associations, but excluding redefined StructuralFeatures. That is, if isValidatable=false, then the InstanceSpecification could have slots that had StructuralFeatures that were not valid features of a classifier of the InstanceSpecification. I am not sure what use this really is. Note that slots still would have to have a StructuralFeature specified, which would have to be owned by some Classifier, so it is always straightforward to add that to the set of classifiers for an InstanceSpecification if you need a feature from it. Note that Slot itself has no constraints at all. UML does not prevent modeling situations in which multiplicity is violated or even when a slot indicates that a feature has a value of the wrong type. This would seem to already cover the cases mentioned in the issue. Or is the intent that, if isValidatable is true, then there are additional constraints on InstanceSpecification such that the multiplicity, typing, etc. for all its slots are valid? This would be a more significant enhancement to current InstanceSpecification modeling. But it is not clear that the submitter was asking for that. -- Ed From: Juergen Boldt [mailto:juergen@omg.org] Sent: Friday, February 21, 2014 11:45 AM To: issues@omg.org; uml2-rtf@omg.org Subject: issue 19254 -- UML 2.6 RTF issue Delivered-To: spamcop-net-omg4web@spamcop.net X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on filter8 X-Spam-Level: X-Spam-Status: hits=0.0 tests=none version=3.2.4 From: webmaster@omg.org Date: 21 Feb 2014 10:00:49 -0500 To: Subject: Issue/Bug Report X-SpamCop-Checked: 23.30.177.17 23.30.177.16 ******************************************************************************* Name: Edward Willink Employer: mailFrom: ed@willink.me.uk Terms_Agreement: I agree Specification: UML Section: 9.8 FormalNumber: 2.5 Version: 2.5 Doc_Year: Year Doc_Month: Month Doc_Day: Day Page: 128 Title: InstanceSpecification validity is not modelable Nature: Clarification Severity: Minor CODE: 3TMw8 B1: Report Issue Remote Name: edwillink.plus.com Remote User: HTTP User Agent: Mozilla/5.0 (Windows NT 6.0; rv:27.0) Gecko/20100101 Firefox/27.0 Time: 10:00 AM Description: InstanceSpecifications may be used to indicate intermeditea states in a transaction and so may not necessarily be valid. InstanceSpecification may be used to create test models and so should necessarily be valid. It is not easy for tooling to detect which is the design intent. Suggest adding an InstanceSpecification::isValidatable property to enable tools to behave usefully. Juergen Boldt Director, Member Services 109 Highland Ave Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org Das Bild wurde vom Absender entfernt. [] Delivered-To: spamcop-net-omg4web@spamcop.net X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on filter8 X-Spam-Level: * X-Spam-Status: hits=1.7 tests=HTML_MESSAGE,MIME_HTML_ONLY version=3.2.4 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=WPfxXxcR c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=tQt9_D6HG1wA:10 a=C5xgZNGczHsA:10 a=YYzpnO7rAAAA:8 a=nkCGRI4cN4gA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=9iDbn-4jx3cA:10 a=cKsnjEOsciEA:10 a=JIVOxcAaAAAA:8 a=vrshd3w6AAAA:8 a=KHpXyVWLAAAA:8 a=5DqnjfGMAAAA:8 a=9BvCZD0AAAAA:8 a=EBOSESyhAAAA:8 a=oCcaPWc0AAAA:8 a=gTq4AbIIRtS3XJPJeh4A:9 a=LPsUaETOAbPc1zhj:21 a=0RyVl3XJcpFYQYlG:21 a=HRuXhCV0Di2klVh_:21 a=QEXdDO2ut3YA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=c9tJgGcuwpQA:10 a=WP4_USCxRkkA:10 a=ngL6kCF7wasA:10 a=xM-QfRgW2ikA:10 a=FoLopk8cqeGNkQHUyrUA:9 a=-9q-DjnZ9x2sl4iQ:18 a=KQqxNPgzF0kA:10 Date: Sun, 23 Feb 2014 10:19:00 +0000 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 To: Ed Seidewitz , "Wendland, Marc-Florian" CC: Juergen Boldt , "issues@omg.org" , "uml2-rtf@omg.org" Subject: Re: issue 19254 -- UML 2.6 RTF issue X-Virus-Scanned: amavisd-new at omg.org X-SpamCop-Checked: 23.30.177.17 23.30.177.10 84.93.230.244 80.229.165.239 Hi Ed, Marc-Florian For Eclipse OCL/UML/Papyrus, we are trying to improve the coverage of OCL validation with InstanceSpecifications being an area where users complain about the lack of validation. I was endeavouring to escalate Marc-Florian's insight from https://bugs.eclipse.org/bugs/show_bug.cgi?id=417062#c4 to enable tooling to be helpful to users. From a toolsmith's point of view, I want a flag to suppress validation errors from an InstanceSpecification that is not expected to be fully valid. From a compatibility point of view, the default for such a flag should be the current state of the art, so adding an isValidatable with default false, seems to handle the use case. Regards Ed Willink On 22/02/2014 20:40, Ed Seidewitz wrote: Marc-Florian . Well, this certainly isn.t clear to me from the statement of the issue. As I originally wrote, it comes down to what is meant by .validation.. Right now, UML does not have any semantics on InstanceSpecifications relative to constraints modeled on classifiers of that InstanceSpecification. So it there is currently no restriction on modeling InstanceSpecifications that don.t satisfy such constraints. So, if your interpretation is correct, what is being asked for is a flag InstanceSpecification::isValidatable such that, if it is true, the InstanceSpecification should not violate any constraints attached to its classifiers. However, what is the conformance requirement for this? The issue says that the flag is intended to .enable tools to behave usefully., but what tools? Should a UML tool be required to check such constraints and consider an InstanceSpecification with isValidatable=true but that violates a constraint to be ill-formed? I think not, since this would require the tool to be able to evaluate arbitrary constraints, and there is no requirement that constraints in UML be necessarily specified in a formal or evaluatable language. I guess, then, that isValidatable would simply be a flag to indicate the intention of the modeler that the InstanceSpecification does meet all applicable constraints, but it would be a modeler responsibility, not a UML modeling tool responsibility, to make sure this is true. Some other, specialized tool could then check that the modeling intent is correct in the case of constraints specified in a specific, computable way (such as in OCL), but this would be outside what is defined in the UML specification. Maybe Ed can verify that this was what he had in mind. -- Ed From: Wendland, Marc-Florian [mailto:marc-florian.wendland@fokus.fraunhofer.de] Sent: Saturday, February 22, 2014 2:45 PM To: Ed Seidewitz; uml2-rtf@omg.org Cc: Juergen Boldt; issues@omg.org Subject: AW: issue 19254 -- UML 2.6 RTF issue Hi Ed, I do not think that either of the cases your described matched with what Ed Willink wanted to introduce. It is rather the case that if you have some OCL constraints added to a Classifier (so some StructuralFeatures are constrained to comply with a certain specification). An InstanceSpecification of that Classifier does not necessarily have to abide by these constraints for the StructuralFeatures. E.g., Classifier A + property B : Integer [0..1] + ownedRule : OCL {self.B > 0 and self.B < 10} would still allow to build an InstanceSpecification of A with a value that evaluates to either < 0 and > 10 for the slot that refers to B. I think Ed asked for a flag that requires the InstanceSpecification of A as a strict compliant InstanceSpecification according to the constraints given for A. Best regards, Marc-Florian Von: Ed Seidewitz [mailto:eseidewitz@ivarjacobson.com] Gesendet: Freitag, 21. Februar 2014 21:08 An: uml2-rtf@omg.org Cc: Juergen Boldt; issues@omg.org Betreff: RE: issue 19254 -- UML 2.6 RTF issue What is meant by .validation. here? More specifically, what validation would not be done if isValidatable is false? From the constraints on InstanceSpecification, the only one that I could see would make sense to .turn off. under the cases considered by the issue would be this one: defining_feature The definingFeature of each slot is a StructuralFeature related to a classifier of the InstanceSpecification, including direct attributes, inherited attributes, private attributes in generalizations, and memberEnds of Associations, but excluding redefined StructuralFeatures. That is, if isValidatable=false, then the InstanceSpecification could have slots that had StructuralFeatures that were not valid features of a classifier of the InstanceSpecification. I am not sure what use this really is. Note that slots still would have to have a StructuralFeature specified, which would have to be owned by some Classifier, so it is always straightforward to add that to the set of classifiers for an InstanceSpecification if you need a feature from it. Note that Slot itself has no constraints at all. UML does not prevent modeling situations in which multiplicity is violated or even when a slot indicates that a feature has a value of the wrong type. This would seem to already cover the cases mentioned in the issue. Or is the intent that, if isValidatable is true, then there are additional constraints on InstanceSpecification such that the multiplicity, typing, etc. for all its slots are valid? This would be a more significant enhancement to current InstanceSpecification modeling. But it is not clear that the submitter was asking for that. -- Ed From: Juergen Boldt [mailto:juergen@omg.org] Sent: Friday, February 21, 2014 11:45 AM To: issues@omg.org; uml2-rtf@omg.org Subject: issue 19254 -- UML 2.6 RTF issue Delivered-To: spamcop-net-omg4web@spamcop.net X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on filter8 X-Spam-Level: X-Spam-Status: hits=0.0 tests=none version=3.2.4 From: webmaster@omg.org Date: 21 Feb 2014 10:00:49 -0500 To: Subject: Issue/Bug Report X-SpamCop-Checked: 23.30.177.17 23.30.177.16 ******************************************************************************* Name: Edward Willink Employer: mailFrom: ed@willink.me.uk Terms_Agreement: I agree Specification: UML Section: 9.8 FormalNumber: 2.5 Version: 2.5 Doc_Year: Year Doc_Month: Month Doc_Day: Day Page: 128 Title: InstanceSpecification validity is not modelable Nature: Clarification Severity: Minor CODE: 3TMw8 B1: Report Issue Remote Name: edwillink.plus.com Remote User: HTTP User Agent: Mozilla/5.0 (Windows NT 6.0; rv:27.0) Gecko/20100101 Firefox/27.0 Time: 10:00 AM Description: InstanceSpecifications may be used to indicate intermeditea states in a transaction and so may not necessarily be valid. InstanceSpecification may be used to create test models and so should necessarily be valid. It is not easy for tooling to detect which is the design intent. Suggest adding an InstanceSpecification::isValidatable property to enable tools to behave usefully. Juergen Boldt Director, Member Services 109 Highland Ave Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org Das Bild wurde vom Absender entfernt. [] No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4335 / Virus Database: 3705/7116 - Release Date: 02/22/14 Delivered-To: spamcop-net-omg4web@spamcop.net X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on filter8 X-Spam-Level: X-Spam-Status: hits=0.0 tests=HTML_MESSAGE version=3.2.4 Date: Sun, 23 Feb 2014 12:33:47 -0700 From: Lonnie VanZandt User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 To: Ed Willink , Ed Seidewitz , "Wendland, Marc-Florian" CC: Juergen Boldt , "issues@omg.org" , "uml2-rtf@omg.org" Subject: Re: issue 19254 -- UML 2.6 RTF issue X-Enigmail-Version: 1.6 X-Virus-Scanned: amavisd-new at omg.org X-SpamCop-Checked: 23.30.177.17 23.30.177.10 12.208.99.107 12.208.99.108 174.29.109.156 Could we change the name to make it imperative versus existential? I suggest "ignoreInValidations". Because humans are too prone to mistakes, the default value should be false. For me, "isValidatable" is too definitive. On 2/23/14, 3:19 AM, Ed Willink wrote: Hi Ed, Marc-Florian For Eclipse OCL/UML/Papyrus, we are trying to improve the coverage of OCL validation with InstanceSpecifications being an area where users complain about the lack of validation. I was endeavouring to escalate Marc-Florian's insight from https://bugs.eclipse.org/bugs/show_bug.cgi?id=417062#c4 to enable tooling to be helpful to users. From a toolsmith's point of view, I want a flag to suppress validation errors from an InstanceSpecification that is not expected to be fully valid. From a compatibility point of view, the default for such a flag should be the current state of the art, so adding an isValidatable with default false, seems to handle the use case. Regards Ed Willink On 22/02/2014 20:40, Ed Seidewitz wrote: Marc-Florian . Well, this certainly isn.t clear to me from the statement of the issue. As I originally wrote, it comes down to what is meant by .validation.. Right now, UML does not have any semantics on InstanceSpecifications relative to constraints modeled on classifiers of that InstanceSpecification. So it there is currently no restriction on modeling InstanceSpecifications that don.t satisfy such constraints. So, if your interpretation is correct, what is being asked for is a flag InstanceSpecification::isValidatable such that, if it is true, the InstanceSpecification should not violate any constraints attached to its classifiers. However, what is the conformance requirement for this? The issue says that the flag is intended to .enable tools to behave usefully., but what tools? Should a UML tool be required to check such constraints and consider an InstanceSpecification with isValidatable=true but that violates a constraint to be ill-formed? I think not, since this would require the tool to be able to evaluate arbitrary constraints, and there is no requirement that constraints in UML be necessarily specified in a formal or evaluatable language. I guess, then, that isValidatable would simply be a flag to indicate the intention of the modeler that the InstanceSpecification does meet all applicable constraints, but it would be a modeler responsibility, not a UML modeling tool responsibility, to make sure this is true. Some other, specialized tool could then check that the modeling intent is correct in the case of constraints specified in a specific, computable way (such as in OCL), but this would be outside what is defined in the UML specification. Maybe Ed can verify that this was what he had in mind. -- Ed From: Wendland, Marc-Florian [mailto:marc-florian.wendland@fokus.fraunhofer.de] Sent: Saturday, February 22, 2014 2:45 PM To: Ed Seidewitz; uml2-rtf@omg.org Cc: Juergen Boldt; issues@omg.org Subject: AW: issue 19254 -- UML 2.6 RTF issue Hi Ed, I do not think that either of the cases your described matched with what Ed Willink wanted to introduce. It is rather the case that if you have some OCL constraints added to a Classifier (so some StructuralFeatures are constrained to comply with a certain specification). An InstanceSpecification of that Classifier does not necessarily have to abide by these constraints for the StructuralFeatures. E.g., Classifier A + property B : Integer [0..1] + ownedRule : OCL {self.B > 0 and self.B < 10} would still allow to build an InstanceSpecification of A with a value that evaluates to either < 0 and > 10 for the slot that refers to B. I think Ed asked for a flag that requires the InstanceSpecification of A as a strict compliant InstanceSpecification according to the constraints given for A. Best regards, Marc-Florian Von: Ed Seidewitz [mailto:eseidewitz@ivarjacobson.com] Gesendet: Freitag, 21. Februar 2014 21:08 An: uml2-rtf@omg.org Cc: Juergen Boldt; issues@omg.org Betreff: RE: issue 19254 -- UML 2.6 RTF issue What is meant by .validation. here? More specifically, what validation would not be done if isValidatable is false? From the constraints on InstanceSpecification, the only one that I could see would make sense to .turn off. under the cases considered by the issue would be this one: defining_feature The definingFeature of each slot is a StructuralFeature related to a classifier of the InstanceSpecification, including direct attributes, inherited attributes, private attributes in generalizations, and memberEnds of Associations, but excluding redefined StructuralFeatures. That is, if isValidatable=false, then the InstanceSpecification could have slots that had StructuralFeatures that were not valid features of a classifier of the InstanceSpecification. I am not sure what use this really is. Note that slots still would have to have a StructuralFeature specified, which would have to be owned by some Classifier, so it is always straightforward to add that to the set of classifiers for an InstanceSpecification if you need a feature from it. Note that Slot itself has no constraints at all. UML does not prevent modeling situations in which multiplicity is violated or even when a slot indicates that a feature has a value of the wrong type. This would seem to already cover the cases mentioned in the issue. Or is the intent that, if isValidatable is true, then there are additional constraints on InstanceSpecification such that the multiplicity, typing, etc. for all its slots are valid? This would be a more significant enhancement to current InstanceSpecification modeling. But it is not clear that the submitter was asking for that. -- Ed From: Juergen Boldt [mailto:juergen@omg.org] Sent: Friday, February 21, 2014 11:45 AM To: issues@omg.org; uml2-rtf@omg.org Subject: issue 19254 -- UML 2.6 RTF issue Delivered-To: spamcop-net-omg4web@spamcop.net X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on filter8 X-Spam-Level: X-Spam-Status: hits=0.0 tests=none version=3.2.4 From: webmaster@omg.org Date: 21 Feb 2014 10:00:49 -0500 To: Subject: Issue/Bug Report X-SpamCop-Checked: 23.30.177.17 23.30.177.16 ******************************************************************************* Name: Edward Willink Employer: mailFrom: ed@willink.me.uk Terms_Agreement: I agree Specification: UML Section: 9.8 FormalNumber: 2.5 Version: 2.5 Doc_Year: Year Doc_Month: Month Doc_Day: Day Page: 128 Title: InstanceSpecification validity is not modelable Nature: Clarification Severity: Minor CODE: 3TMw8 B1: Report Issue Remote Name: edwillink.plus.com Remote User: HTTP User Agent: Mozilla/5.0 (Windows NT 6.0; rv:27.0) Gecko/20100101 Firefox/27.0 Time: 10:00 AM Description: InstanceSpecifications may be used to indicate intermeditea states in a transaction and so may not necessarily be valid. InstanceSpecification may be used to create test models and so should necessarily be valid. It is not easy for tooling to detect which is the design intent. Suggest adding an InstanceSpecification::isValidatable property to enable tools to behave usefully. Juergen Boldt Director, Member Services 109 Highland Ave Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org Das Bild wurde vom Absender entfernt. [] No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4335 / Virus Database: 3705/7116 - Release Date: 02/22/14 signature.asc signature.asc