Issue 17584: Clarification on the semantics of Parameters (uml25-ftf) Source: THALES (Mr. Hugues Vincent, hugues.vincent(at)thalesgroup.com) Nature: Clarification Severity: Minor Summary: Title: Clarification on the semantics of Parameters Where: section 9.4.3 Nature of Issue: Clarification Severity of Issue: Minor Full Description of the Issue: the 'effect' on a Parameter is not multiple but couldn't a parameter be read *and* updated or created? Resolution: Revised Text: Actions taken: September 13, 2012: received issue Discussion: End of Annotations:===== s is issue # 17584 Title: Clarification on the semantics of Parameters Where: section 9.4.3 Nature of Issue: Clarification Severity of Issue: Minor Full Description of the Issue: the 'effect' on a Parameter is not multiple but couldn't a parameter be read *and* updated or created? From: "BERNARD, Yves" To: "uml25-ftf@omg.org" Date: Thu, 14 Feb 2013 17:45:39 +0100 Subject: [UML 2.5 FTF] ballot2 review: #17584 Thread-Topic: [UML 2.5 FTF] ballot2 review: #17584 Thread-Index: Ac4K0ricN+bINS+DQE6+WGCux4701w== Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US X-Virus-Scanned: amavisd-new at omg.org I think, we could be more accurate. All those .effects. are related to assumptions which can be made on the values held by the corresponding parameters: the value held by the parameter as the result of the invocation does not exist before this invocation the parameter is expected to be given a value at the moment of the invocation the value of the parameter is expected to change as a result of the allocation the value given to the parameter at the moment of the invocation will not exist anymore once the invoked execution has ended Note that all these assumption are not independent. For example: a => c d => b a => not b etc. Finally it appears that only a restricted set of all the possible combinations really makes sense. The possible values for .effect. intend to represent these meaningful combinations and have to be chosen depending on the assumption(s) the modeler want to express: Create: a (and then c) Read: b and not c Update: b and c Delete: d (and then b) Do you agree? If you support it, I think I can write a draft for a new version of the resolution based on this approach. Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: Steve Cook To: "BERNARD, Yves" , "uml25-ftf@omg.org" Subject: RE: [UML 2.5 FTF] ballot2 review: #17584 Thread-Topic: [UML 2.5 FTF] ballot2 review: #17584 Thread-Index: Ac4K0ricN+bINS+DQE6+WGCux4701wAAvYvw Date: Thu, 14 Feb 2013 17:34:58 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.104] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(365934001)(199002)(189002)(55846006)(56776001)(56816002)(47446002)(31966008)(79102001)(54316002)(5343635001)(15202345001)(46102001)(76482001)(16236675001)(44976002)(74662001)(512954001)(77982001)(65816001)(33656001)(4396001)(63696002)(53806001)(74502001)(49866001)(47976001)(51856001)(5343655001)(16406001)(80022001)(50986001)(54356001)(20776003)(59766001)(47736001);DIR:OUT;SFP:;SCL:1;SRVR:BL2FFO11HUB017;H:TK5EX14HUBC101.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0757EEBDCA X-Virus-Scanned: amavisd-new at omg.org Yves I.d be interested to see your proposed improved resolution. The issue actually suggested that Read and Update are compatible, which they are not according to your logic. I think I agree with you that they are not compatible: at least by convention, Read implies no Update. Thanks -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 14 February 2013 16:46 To: uml25-ftf@omg.org Subject: [UML 2.5 FTF] ballot2 review: #17584 I think, we could be more accurate. All those .effects. are related to assumptions which can be made on the values held by the corresponding parameters: the value held by the parameter as the result of the invocation does not exist before this invocation the parameter is expected to be given a value at the moment of the invocation the value of the parameter is expected to change as a result of the allocation the value given to the parameter at the moment of the invocation will not exist anymore once the invoked execution has ended Note that all these assumption are not independent. For example: · a => c · d => b · a => not b · etc. Finally it appears that only a restricted set of all the possible combinations really makes sense. The possible values for .effect. intend to represent these meaningful combinations and have to be chosen depending on the assumption(s) the modeler want to express: Create: a (and then c) Read: b and not c Update: b and c Delete: d (and then b) Do you agree? If you support it, I think I can write a draft for a new version of the resolution based on this approach. Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: Steve Cook To: "BERNARD, Yves" , "uml25-ftf@omg.org" Subject: RE: [UML 2.5 FTF] ballot2 review: #17584 Thread-Topic: [UML 2.5 FTF] ballot2 review: #17584 Thread-Index: Ac4K0ricN+bINS+DQE6+WGCux4701wAAvYvwACi5hZAAAnhsoA== Date: Fri, 15 Feb 2013 13:45:19 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.101] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(365934001)(199002)(189002)(51856001)(512934001)(31966008)(74502001)(44976002)(47736001)(54316002)(49866001)(50986001)(47976001)(56776001)(47446002)(56816002)(54356001)(53806001)(4396001)(20776003)(79102001)(77982001)(76482001)(5343655001)(65816001)(74662001)(33656001)(5343635001)(16406001)(80022001)(55846006)(46102001)(63696002)(59766001)(16236675001);DIR:OUT;SFP:;SCL:1;SRVR:BL2FFO11HUB023;H:TK5EX14HUBC105.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07584EDBCD X-Virus-Scanned: amavisd-new at omg.org Yves I.ve made some changes with tracking on. Are these changes ok with you? I note that this new resolution would also resolve issue 17890, which could then be merged with it. - - Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 15 February 2013 12:36 To: Steve Cook; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot2 review: #17584 Steeve, Here is the new version I propose. Yves From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: jeudi 14 féier 2013 18:35 To: BERNARD, Yves; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot2 review: #17584 Yves I.d be interested to see your proposed improved resolution. The issue actually suggested that Read and Update are compatible, which they are not according to your logic. I think I agree with you that they are not compatible: at least by convention, Read implies no Update. Thanks -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 14 February 2013 16:46 To: uml25-ftf@omg.org Subject: [UML 2.5 FTF] ballot2 review: #17584 I think, we could be more accurate. All those .effects. are related to assumptions which can be made on the values held by the corresponding parameters: a. the value held by the parameter as the result of the invocation does not exist before this invocation b. the parameter is expected to be given a value at the moment of the invocation c. the value of the parameter is expected to change as a result of the allocation d. the value given to the parameter at the moment of the invocation will not exist anymore once the invoked execution has ended Note that all these assumption are not independent. For example: · a => c · d => b · a => not b · etc. Finally it appears that only a restricted set of all the possible combinations really makes sense. The possible values for .effect. intend to represent these meaningful combinations and have to be chosen depending on the assumption(s) the modeler want to express: Create: a (and then c) Read: b and not c Update: b and c Delete: d (and then b) Do you agree? If you support it, I think I can write a draft for a new version of the resolution based on this approach. Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. #17584_resolved_v21.doc From: "BERNARD, Yves" To: Steve Cook , "uml25-ftf@omg.org" Date: Fri, 15 Feb 2013 15:17:00 +0100 Subject: RE: [UML 2.5 FTF] ballot2 review: #17584 Thread-Topic: [UML 2.5 FTF] ballot2 review: #17584 Thread-Index: Ac4K0ricN+bINS+DQE6+WGCux4701wAAvYvwACi5hZAAAnhsoAABJUCQ Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US X-Virus-Scanned: amavisd-new at omg.org Steeve, Yes, they are. Thanks, Yves From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: vendredi 15 féier 2013 14:45 To: BERNARD, Yves; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot2 review: #17584 Yves I.ve made some changes with tracking on. Are these changes ok with you? I note that this new resolution would also resolve issue 17890, which could then be merged with it. - - Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 15 February 2013 12:36 To: Steve Cook; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot2 review: #17584 Steeve, Here is the new version I propose. Yves From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: jeudi 14 féier 2013 18:35 To: BERNARD, Yves; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot2 review: #17584 Yves I.d be interested to see your proposed improved resolution. The issue actually suggested that Read and Update are compatible, which they are not according to your logic. I think I agree with you that they are not compatible: at least by convention, Read implies no Update. Thanks -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 14 February 2013 16:46 To: uml25-ftf@omg.org Subject: [UML 2.5 FTF] ballot2 review: #17584 I think, we could be more accurate. All those .effects. are related to assumptions which can be made on the values held by the corresponding parameters: a. the value held by the parameter as the result of the invocation does not exist before this invocation b. the parameter is expected to be given a value at the moment of the invocation c. the value of the parameter is expected to change as a result of the allocation d. the value given to the parameter at the moment of the invocation will not exist anymore once the invoked execution has ended Note that all these assumption are not independent. For example: · a => c · d => b · a => not b · etc. Finally it appears that only a restricted set of all the possible combinations really makes sense. The possible values for .effect. intend to represent these meaningful combinations and have to be chosen depending on the assumption(s) the modeler want to express: Create: a (and then c) Read: b and not c Update: b and c Delete: d (and then b) Do you agree? If you support it, I think I can write a draft for a new version of the resolution based on this approach. Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "BERNARD, Yves" To: Steve Cook , "uml25-ftf@omg.org" Date: Fri, 15 Feb 2013 13:35:38 +0100 Subject: RE: [UML 2.5 FTF] ballot2 review: #17584 Thread-Topic: [UML 2.5 FTF] ballot2 review: #17584 Thread-Index: Ac4K0ricN+bINS+DQE6+WGCux4701wAAvYvwACi5hZA= Accept-Language: fr-FR, en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US X-Virus-Scanned: amavisd-new at omg.org Steeve, Here is the new version I propose. Yves From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: jeudi 14 féier 2013 18:35 To: BERNARD, Yves; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot2 review: #17584 Yves I.d be interested to see your proposed improved resolution. The issue actually suggested that Read and Update are compatible, which they are not according to your logic. I think I agree with you that they are not compatible: at least by convention, Read implies no Update. Thanks -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 14 February 2013 16:46 To: uml25-ftf@omg.org Subject: [UML 2.5 FTF] ballot2 review: #17584 I think, we could be more accurate. All those .effects. are related to assumptions which can be made on the values held by the corresponding parameters: a. the value held by the parameter as the result of the invocation does not exist before this invocation b. the parameter is expected to be given a value at the moment of the invocation c. the value of the parameter is expected to change as a result of the allocation d. the value given to the parameter at the moment of the invocation will not exist anymore once the invoked execution has ended Note that all these assumption are not independent. For example: · a => c · d => b · a => not b · etc. Finally it appears that only a restricted set of all the possible combinations really makes sense. The possible values for .effect. intend to represent these meaningful combinations and have to be chosen depending on the assumption(s) the modeler want to express: Create: a (and then c) Read: b and not c Update: b and c Delete: d (and then b) Do you agree? If you support it, I think I can write a draft for a new version of the resolution based on this approach. Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "Chonoles, Michael J" To: "koethe@88solutions.com" , "uml25-ftf@omg.org" Subject: RE: EXTERNAL: [UML 2.5 FTF] Ballot 6 -- Review Comment Thread-Topic: EXTERNAL: [UML 2.5 FTF] Ballot 6 -- Review Comment Thread-Index: Ac5gdXUOJsnYnF8FQ/u0/mZ4zMuiiw== Date: Mon, 3 Jun 2013 16:14:55 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [158.186.156.82] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-06-03_04:2013-06-03,2013-06-03,1970-01-01 signatures=0 X-Virus-Scanned: amavisd-new at omg.org Just looking at issue 17584.s resolution. Concentrating on the table. create Objects passed out of executions of the behavior as values of the parameter do Not exist before those executions start. read Objects that are values of the parameter have values of their properties or links in which they participate retrieved during executions of the behavior. update Objects that are values of the parameter have values of their properties changed during executions of the behavior. delete Objects that are values of the parameter do not exist after executions of the behavior are finished. Are these effects mandatory? I assume not, if so, then the table should be updated to clearly state what is optional. create Any objects passed out of executions of the behavior as values of the parameter do Not exist before those executions start. read Objects that are values of the parameter may have values of their properties or links in which they participate retrieved during executions of the behavior. update Objects that are values of the parameter may have values of their properties changed during executions of the behavior. delete Objects that are values of the parameter may not exist after executions of the behavior are finished. This allows an operation with effect marked parameters to fail in some way to do its intended job. I.m also a bit concerned that when create is used, the object returned may preexist, as long as it.s existence was not in the space of the caller. E.g., an object could be returned that existed in a stack maintained by the behavior. It may be useful to show this table in a more graphical form. Direction Effect Exist Before Exist After In Read Y Y InOut Update Y y Out Create N Y InOut Delete Y N Return Create N Y Assuming I have the table right, .effect. is redundant with direction, if we could distinguish .detete. That is, there isn.t a need for Read or Create Michael From: Manfred R. Koethe [mailto:koethe@88solutions.com] Sent: Sunday, June 02, 2013 6:45 PM To: uml25-ftf@omg.org Subject: EXTERNAL: [UML 2.5 FTF] Ballot 6 -- Preview 1 (same content-formatting fixed) -- PLEASE READ Dear Colleagues, I just recognized that a file rename had failed which prevented attachment of the latest Ballot 6 - Preview 1. But here it is. Content is the same as the one I sent out before, but formatting is improved. Manfred ---- the following was my previous e-mail ---- After some unfortunate delay, here is Preview 1 of the UML 2.5 FTF Ballot 6. (The proposed voting period has been adjusted accordingly) Kind regards, Manfred --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (510) 246 8611 fax: +1 (815) 550 2086 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)-------- Subject: Re: EXTERNAL: [UML 2.5 FTF] Ballot 6 -- Review Comment From: "Manfred R. Koethe" Date: Mon, 3 Jun 2013 10:33:00 -0700 Cc: "Chonoles, Michael J" To: "uml25-ftf@omg.org" X-Mailer: Apple Mail (2.1499) X-Provags-ID: V02:K0:hCfUHwzWTGBC4Nw5quoAGTqUPL80ym/KJtHToQFmT5S 85DPA48P1DRRK9jofROG0J2zMpGWZMjiQ0nW6wJ5zJBrbVaFcm /W78cbVJ2QYWBOPSOB9HWlcjBe0DuPfk8hfTC7tz+AJKNlKhkP HlWz6uzGgEowUz7iIcY9tGpakmwXzGaFOxdQW+FRR5SoiMAGdI 0GCOA5Uchjyst6rV2X2pm5ga4M0ix5xIpVQngQkHYPoU/FkIHa fErBmvhrCpduqWhO2dQYOvzV5vnyaHNBIkoBXUc3OZhdMtm/9X Et5zRdsgLNsAbb4++6iQhbtorlBoS45wNSzg8VsC3iIItWvmbh IGKHEEVjGf/6J/2mgg9ek9LaXT+cVcHMPC/03Dsf9VJ+3i+9+p 6RSZDBkmiBiKQ== X-Virus-Scanned: amavisd-new at omg.org Michael, I'm all in favor of your proposed simplified table. It communicates the facts right to the point with one glance, while in the original table(s) are hard to parse (but that might just my non-native-speakerness). I suggest an additional column to your table "Value may change", which is in particular true for update. Kind regards, Manfred On Jun 3, 2013, at 9:14 , "Chonoles, Michael J" wrote: Just looking at issue 17584.s resolution. Concentrating on the table. create Objects passed out of executions of the behavior as values of the parameter do Not exist before those executions start. read Objects that are values of the parameter have values of their properties or links in which they participate retrieved during executions of the behavior. update Objects that are values of the parameter have values of their properties changed during executions of the behavior. delete Objects that are values of the parameter do not exist after executions of the behavior are finished. Are these effects mandatory? I assume not, if so, then the table should be updated to clearly state what is optional. create Any objects passed out of executions of the behavior as values of the parameter do Not exist before those executions start. read Objects that are values of the parameter may have values of their properties or links in which they participate retrieved during executions of the behavior. update Objects that are values of the parameter may have values of their properties changed during executions of the behavior. delete Objects that are values of the parameter may not exist after executions of the behavior are finished. This allows an operation with effect marked parameters to fail in some way to do its intended job. I.m also a bit concerned that when create is used, the object returned may preexist, as long as it.s existence was not in the space of the caller. E.g., an object could be returned that existed in a stack maintained by the behavior. It may be useful to show this table in a more graphical form. Direction Effect Exist Before Exist After In Read Y Y InOut Update Y y Out Create N Y InOut Delete Y N Return Create N Y Assuming I have the table right, .effect. is redundant with direction, if we could distinguish .detete. That is, there isn.t a need for Read or Create Michael From: Manfred R. Koethe [mailto:koethe@88solutions.com] Sent: Sunday, June 02, 2013 6:45 PM To: uml25-ftf@omg.org Subject: EXTERNAL: [UML 2.5 FTF] Ballot 6 -- Preview 1 (same content-formatting fixed) -- PLEASE READ Dear Colleagues, I just recognized that a file rename had failed which prevented attachment of the latest Ballot 6 - Preview 1. But here it is. Content is the same as the one I sent out before, but formatting is improved. Manfred ---- the following was my previous e-mail ---- After some unfortunate delay, here is Preview 1 of the UML 2.5 FTF Ballot 6. (The proposed voting period has been adjusted accordingly) Kind regards, Manfred --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (510) 246 8611 fax: +1 (815) 550 2086 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)-------- --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (510) 246 8611 fax: +1 (815) 550 2086 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)-------- signature3.asc signature3.asc From: "Bock, Conrad" To: "uml25-ftf@omg.org" Date: Wed, 5 Jun 2013 14:35:02 -0400 Subject: RE: EXTERNAL: [UML 2.5 FTF] Ballot 6 -- Review Comment, 17584 table Thread-Topic: EXTERNAL: [UML 2.5 FTF] Ballot 6 -- Review Comment, 17584 table Thread-Index: Ac5iGjMZ4eRFSqkXSJuN5V+3IuO/mw== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Virus-Scanned: amavisd-new at omg.org Michael, Thanks for your comments. > Are these effects mandatory? I assume not, if so, then the table > should be updated to clearly state what is optional. The 2.4.1 and beta wording doesn't have "may", presumably because if effects "may happen", they would cover behaviors that never have the intended effect, which I'd think would be confusing. With "may", the only conclusion the modeler could draw is to assume the effect might happen, but might not. > This allows an operation with effect marked parameters to fail in > some way to do its intended job. Adding "may" would mean the effect was no longer the "intended job". Just something that might happen, but not necessarily. > I'm also a bit concerned that when create is used, the object > returned may preexist, as long as it's existence was not in the space > of the caller. E.g., an object could be returned that existed in a > stack maintained by the behavior. UML doesn't have the notation of "space of caller" or "stack". Objects exist regardless of where references to them live. > It may be useful to show this table in a more graphical form. Didn't see any graphics in the table (see the ascii below), but some comments on it: - It's indexed to the parameter direction (the reader looks down the left side and reads to the right), rather than the enumeration literals, which would seem more relevant to the subject (direction isn't the same as effect, see below). - The only constraints currently between direction and effect are: - Only in and inout Parameters may have a delete effect [CB: the out value would need to be null] - Only out, inout, and return Parameters may have a create effect [CB: the in value would need to be null] so the direction column should be multi-valued, in particular: - Reads can happen to inout, out, and return parameters as well as in. An execution finds an object somewhere, reads it, and passes it out. - Updates can happen on inout, out, and return parameters (analogous to read). - Creates can happen on inout parameters (the in value would need to be null) - Deletes can happen on in parameters. After the above corrections, you can see there isn't much correlation between direction and effect (beyond the constraints in the previous bullet), so I don't think the table should include direction, or at least not be indexed on it. - As Manfred mentioned, existence isn't of concern to all the effects, sometimes it's just changes, so columns for these don't seem useful. Conrad Direction Effect Exist Before Exist After In Read Y Y InOut Update Y y Out Create N Y InOut Delete Y N Return Create N Y From: "Chonoles, Michael J" To: "conrad.bock@nist.gov" , "uml25-ftf@omg.org" Subject: RE: EXTERNAL: [UML 2.5 FTF] Ballot 6 -- Review Comment, 17584 table Thread-Topic: EXTERNAL: [UML 2.5 FTF] Ballot 6 -- Review Comment, 17584 table Thread-Index: Ac5iGjMZ4eRFSqkXSJuN5V+3IuO/mwAAZ3Zw Date: Wed, 5 Jun 2013 19:03:44 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [158.186.156.82] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-06-05_08:2013-06-05,2013-06-05,1970-01-01 signatures=0 X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r55J4tRf026498 Thanks. I see your point about the "may" However, perhaps I'm confused about formal parameters and invocation parameters But it doesn't seem to make sense to have a formal "inout" to also have the formal effect "delete", because it would be clearer to say "in" Similarly, it doesn't seem to make sense to a formal "inout" to also have the formal effect "create", because it would be clearer to say "out" Michael -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: Wednesday, June 05, 2013 2:35 PM To: uml25-ftf@omg.org Subject: RE: EXTERNAL: [UML 2.5 FTF] Ballot 6 -- Review Comment, 17584 table Michael, Thanks for your comments. > Are these effects mandatory? I assume not, if so, then the table > should be updated to clearly state what is optional. The 2.4.1 and beta wording doesn't have "may", presumably because if effects "may happen", they would cover behaviors that never have the intended effect, which I'd think would be confusing. With "may", the only conclusion the modeler could draw is to assume the effect might happen, but might not. > This allows an operation with effect marked parameters to fail in > some way to do its intended job. Adding "may" would mean the effect was no longer the "intended job". Just something that might happen, but not necessarily. > I'm also a bit concerned that when create is used, the object > returned may preexist, as long as it's existence was not in the space > of the caller. E.g., an object could be returned that existed in a > stack maintained by the behavior. UML doesn't have the notation of "space of caller" or "stack". Objects exist regardless of where references to them live. > It may be useful to show this table in a more graphical form. Didn't see any graphics in the table (see the ascii below), but some comments on it: - It's indexed to the parameter direction (the reader looks down the left side and reads to the right), rather than the enumeration literals, which would seem more relevant to the subject (direction isn't the same as effect, see below). - The only constraints currently between direction and effect are: - Only in and inout Parameters may have a delete effect [CB: the out value would need to be null] - Only out, inout, and return Parameters may have a create effect [CB: the in value would need to be null] so the direction column should be multi-valued, in particular: - Reads can happen to inout, out, and return parameters as well as in. An execution finds an object somewhere, reads it, and passes it out. - Updates can happen on inout, out, and return parameters (analogous to read). - Creates can happen on inout parameters (the in value would need to be null) - Deletes can happen on in parameters. After the above corrections, you can see there isn't much correlation between direction and effect (beyond the constraints in the previous bullet), so I don't think the table should include direction, or at least not be indexed on it. - As Manfred mentioned, existence isn't of concern to all the effects, sometimes it's just changes, so columns for these don't seem useful. Conrad Direction Effect Exist Before Exist After In Read Y Y InOut Update Y y Out Create N Y InOut Delete Y N Return Create N Y From: "Bock, Conrad" To: "uml25-ftf@omg.org" Date: Wed, 5 Jun 2013 15:10:02 -0400 Subject: RE: EXTERNAL: [UML 2.5 FTF] Ballot 6 -- Review Comment, 17584 table Thread-Topic: EXTERNAL: [UML 2.5 FTF] Ballot 6 -- Review Comment, 17584 table Thread-Index: Ac5iGjMZ4eRFSqkXSJuN5V+3IuO/mwAAZ3ZwAADzN4A= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Virus-Scanned: amavisd-new at omg.org Michael, > But it doesn't seem to make sense to have a formal "inout" to also > have the formal effect "delete", because it would be clearer to say > "in" > Similarly, it doesn't seem to make sense to a formal "inout" to also > have the formal effect "create", because it would be clearer to say > "out" Was noticing that also, and the only thing I think it could mean is: - Delete inouts have null as their output value. - Create inouts have null as their input value. These are runtime rather than modeling constraints, so don't appear in the constraints sections. Seems like we could change the modeling constraints to prevent inouts for create and delete, if we didn't mind the backward incompatibility. Conrad From: "Chonoles, Michael J" To: "conrad.bock@nist.gov" , "uml25-ftf@omg.org" Subject: RE: EXTERNAL: [UML 2.5 FTF] Ballot 6 -- Review Comment, 17584 table Thread-Topic: EXTERNAL: [UML 2.5 FTF] Ballot 6 -- Review Comment, 17584 table Thread-Index: Ac5iGjMZ4eRFSqkXSJuN5V+3IuO/mwAAZ3ZwAADzN4AAADdloA== Date: Wed, 5 Jun 2013 19:15:13 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [158.186.156.82] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-06-05_08:2013-06-05,2013-06-05,1970-01-01 signatures=0 X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r55JGU96027423 Yes, it would require an incompatibility. Michael -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: Wednesday, June 05, 2013 3:10 PM To: uml25-ftf@omg.org Subject: RE: EXTERNAL: [UML 2.5 FTF] Ballot 6 -- Review Comment, 17584 table Michael, > But it doesn't seem to make sense to have a formal "inout" to also > have the formal effect "delete", because it would be clearer to say > "in" > Similarly, it doesn't seem to make sense to a formal "inout" to also > have the formal effect "create", because it would be clearer to say > "out" Was noticing that also, and the only thing I think it could mean is: - Delete inouts have null as their output value. - Create inouts have null as their input value. These are runtime rather than modeling constraints, so don't appear in the constraints sections. Seems like we could change the modeling constraints to prevent inouts for create and delete, if we didn't mind the backward incompatibility. Conrad X-Virus-Scanned: OK From: Ed Seidewitz To: "uml25-ftf@omg.org" Subject: RE: EXTERNAL: [UML 2.5 FTF] Ballot 6 -- Review Comment, 17584 table Thread-Topic: EXTERNAL: [UML 2.5 FTF] Ballot 6 -- Review Comment, 17584 table Thread-Index: Ac5iGjMZ4eRFSqkXSJuN5V+3IuO/mwAAZ3ZwAADzN4AAAHvd8A== Date: Wed, 5 Jun 2013 19:23:56 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.178.82.93] X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r55JO0Pk028082 The object passed out in on inout parameter doesn't have to be the same one that was passed in. For a "create" effect, the text says "Objects passed out of executions of the behavior as values of the parameter do not exist before those executions start." It doesn't say anything about objects passed in. Therefore, you could pass a non-null value into an inout parameter with the "create" effect, as long as the object passed out is a different, new object. The wording for "delete" is a little less clear, but I think it is reasonable to assume that it means that the object passed in on an inout parameter is destroyed, but that some other object could be passed out. Indeed, conceptually, an inout parameter could conceptually be both "delete" AND "create", meaning you pass in an object that gets destroyed and then get out a newly created object. However, the abstract syntax only allows at most one effect on a parameter. -- Ed -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: Wednesday, June 05, 2013 3:10 PM To: uml25-ftf@omg.org Subject: RE: EXTERNAL: [UML 2.5 FTF] Ballot 6 -- Review Comment, 17584 table Michael, > But it doesn't seem to make sense to have a formal "inout" to also > have the formal effect "delete", because it would be clearer to say > "in" > Similarly, it doesn't seem to make sense to a formal "inout" to also > have the formal effect "create", because it would be clearer to say > "out" Was noticing that also, and the only thing I think it could mean is: - Delete inouts have null as their output value. - Create inouts have null as their input value. These are runtime rather than modeling constraints, so don't appear in the constraints sections. Seems like we could change the modeling constraints to prevent inouts for create and delete, if we didn't mind the backward incompatibility. Conrad From: "Bock, Conrad" To: "uml25-ftf@omg.org" Date: Wed, 5 Jun 2013 15:39:59 -0400 Subject: RE: EXTERNAL: [UML 2.5 FTF] Ballot 6 -- Review Comment, 17584 table Thread-Topic: EXTERNAL: [UML 2.5 FTF] Ballot 6 -- Review Comment, 17584 table Thread-Index: Ac5iGjMZ4eRFSqkXSJuN5V+3IuO/mwAAZ3ZwAADzN4AAAHvd8AAAokGw Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Virus-Scanned: amavisd-new at omg.org Ed, > The object passed out in on inout parameter doesn't have to be the same one > that was passed in. Thx, that's sort of the whole point of inouts, because the caller already knows what's passed in and doesn't need it passed back out! Conrad From: "Chonoles, Michael J" To: "conrad.bock@nist.gov" , "uml25-ftf@omg.org" Subject: RE: EXTERNAL: [UML 2.5 FTF] Ballot 6 -- Review Comment, 17584 table Thread-Topic: EXTERNAL: [UML 2.5 FTF] Ballot 6 -- Review Comment, 17584 table Thread-Index: Ac5iGjMZ4eRFSqkXSJuN5V+3IuO/mwAAZ3ZwAADzN4AAAHvd8AAAokGwACb4zaA= Date: Thu, 6 Jun 2013 14:13:52 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [158.186.156.82] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-06-06_06:2013-06-06,2013-06-06,1970-01-01 signatures=0 X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r56EEb4D032559 I can see that, but then we need the ability to specify both delete and create. Michael -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: Wednesday, June 05, 2013 3:40 PM To: uml25-ftf@omg.org Subject: RE: EXTERNAL: [UML 2.5 FTF] Ballot 6 -- Review Comment, 17584 table Ed, > The object passed out in on inout parameter doesn't have to be the same one > that was passed in. Thx, that's sort of the whole point of inouts, because the caller already knows what's passed in and doesn't need it passed back out! Conrad From: "Bock, Conrad" To: "uml25-ftf@omg.org" Date: Thu, 6 Jun 2013 11:53:36 -0400 Subject: RE: EXTERNAL: [UML 2.5 FTF] Ballot 6 -- Review Comment, 17584 table Thread-Topic: EXTERNAL: [UML 2.5 FTF] Ballot 6 -- Review Comment, 17584 table Thread-Index: Ac5iGjMZ4eRFSqkXSJuN5V+3IuO/mwAAZ3ZwAADzN4AAAHvd8AAAokGwACb4zaAAA2VGUA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Virus-Scanned: amavisd-new at omg.org Michael, > I can see that, but then we need the ability to specify both delete and > create. This would require an abstract syntax change. Since that's out of scope, the revised text explains that multiple effects might occur during execution even though only one can be specified in the model. Conrad From: "Chonoles, Michael J" To: "conrad.bock@nist.gov" , "uml25-ftf@omg.org" Subject: RE: EXTERNAL: [UML 2.5 FTF] Ballot 6 -- Review Comment, 17584 table Thread-Topic: EXTERNAL: [UML 2.5 FTF] Ballot 6 -- Review Comment, 17584 table Thread-Index: Ac5iGjMZ4eRFSqkXSJuN5V+3IuO/mwAAZ3ZwAADzN4AAAHvd8AAAokGwACb4zaAAA2VGUAAAMe/w Date: Thu, 6 Jun 2013 15:56:05 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [158.186.156.82] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-06-06_07:2013-06-06,2013-06-06,1970-01-01 signatures=0 X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r56Fubd6015508 Yes, my issues is ultimately for 2.6 -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: Thursday, June 06, 2013 11:54 AM To: uml25-ftf@omg.org Subject: RE: EXTERNAL: [UML 2.5 FTF] Ballot 6 -- Review Comment, 17584 table Michael, > I can see that, but then we need the ability to specify both delete and > create. This would require an abstract syntax change. Since that's out of scope, the revised text explains that multiple effects might occur during execution even though only one can be specified in the model. Conrad From: "Bock, Conrad" To: "sysml-rtf@omg.org" Date: Mon, 10 Jun 2013 09:56:20 -0400 Subject: Re: Ballot 6 checkin, 17584, OCL Thread-Topic: Ballot 6 checkin, 17584, OCL Thread-Index: Ac5l4doyGvNZS7I+SK+xPTxZq+sznQ== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Virus-Scanned: amavisd-new at omg.org P.S. Just wanted to check if the OCL knowledgeable see any problems with this on Parameter: inv: (type.isKindOf(DataType)) implies (effect = null) I heard maybe the type should be checked for having a value when applying isKindOf, but if having no type causes the antecedent to be false, then it would be doing the right thing. Conrad From: "Rouquette, Nicolas F (313K)" To: "Bock, Conrad" , "sysml-rtf@omg.org" Subject: Re: Ballot 6 checkin, 17584, OCL Thread-Topic: Ballot 6 checkin, 17584, OCL Thread-Index: Ac5l4doyGvNZS7I+SK+xPTxZq+sznQAAVOQA Date: Mon, 10 Jun 2013 14:02:46 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [128.149.137.113] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r5AE2wl9018405 Conrad, Here's the corrected constraint: type.oclIsKindOf(DataType) implies effect = null - Nicolas. On 6/10/13 6:56 AM, "Bock, Conrad" wrote: >P.S. Just wanted to check if the OCL knowledgeable see any problems with >this on Parameter: > > inv: (type.isKindOf(DataType)) implies (effect = null) > >I heard maybe the type should be checked for having a value when >applying isKindOf, but if having no type causes the antecedent to be >false, then it would be doing the right thing. > >Conrad From: "BERNARD, Yves" To: "Bock, Conrad" , "sysml-rtf@omg.org" Date: Tue, 11 Jun 2013 12:18:06 +0200 Subject: RE: Ballot 6 checkin, 17584, OCL Thread-Topic: Ballot 6 checkin, 17584, OCL Thread-Index: Ac5l4doyGvNZS7I+SK+xPTxZq+sznQApogjA Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r5BAIGrP009366 Conrad, I think you need to check that the type is defined before applying any operation on it, otherwise the value of the OCL expression that would be undefined. This is at least as my OCL checker works and you can either get "false" or "true". Anyway, the OCL we use in the spec shall not make any assumption about the implementation of the OCL. So, I believe it's worth rewriting your invariant in a more reliable way: inv: (type->notEmpty() and type.isKindOf(DataType)) implies (effect = null) Yves -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: lundi 10 juin 2013 15:56 To: sysml-rtf@omg.org Subject: Re: Ballot 6 checkin, 17584, OCL P.S. Just wanted to check if the OCL knowledgeable see any problems with this on Parameter: inv: (type.isKindOf(DataType)) implies (effect = null) I heard maybe the type should be checked for having a value when applying isKindOf, but if having no type causes the antecedent to be false, then it would be doing the right thing. Conrad This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "Bock, Conrad" To: "'Manfred R. Koethe'" , "sysml-rtf@omg.org" Date: Tue, 11 Jun 2013 11:14:32 -0400 Subject: Re: Ballot 6 checkin, 17584 Thread-Topic: Ballot 6 checkin, 17584 Thread-Index: Ac5mtlUJmIq55NWIRPSlfbyiN0ot3g== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Virus-Scanned: amavisd-new at omg.org P.S. This is checked in now as Clause-9-17584_resolved_v6.doc. Conrad -----Original Message----- From: Bock, Conrad Sent: Monday, June 10, 2013 9:48 AM To: Manfred R. Koethe; sysml-rtf@omg.org Subject: Re: Ballot 6 checkin, 17584, SVN error Manfred, Here's an update to 17584 for preview 3. I tried checking it in, but SVN said "Can't flush file /svn/root/repository/repos/txn-current.13.tmp: No space left on device". Tried deleting the earlier version of the attached file in SVN and got the same error. Conrad From: "Bock, Conrad" To: "'Manfred R. Koethe'" , "uml25-ftf@omg.org" Date: Tue, 11 Jun 2013 11:16:44 -0400 Subject: Re: Ballot 6 checkin, 17584 Thread-Topic: Ballot 6 checkin, 17584 Thread-Index: Ac5mtlUJmIq55NWIRPSlfbyiN0ot3g== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-pp-spamdetails: rule=spampolicy2_notspam policy=spampolicy2 score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1211240000 definitions=main-1306110113 x-proofpoint-virus-version: vendor=fsecure engine=2.50.10432:5.10.8794,1.0.431,0.0.0000 definitions=2013-06-11_06:2013-06-11,2013-06-11,1970-01-01 signatures=0 x-pp-spamscore: 0 x-virus-scanned: amavisd-new at omg.org X-Virus-Scanned: amavisd-new at omg.org Sorry, I've been sending to the wrong list. :) P.S. This is checked in now as Clause-9-17584_resolved_v6.doc. Conrad -----Original Message----- From: Bock, Conrad Sent: Monday, June 10, 2013 9:48 AM To: Manfred R. Koethe; sysml-rtf@omg.org Subject: Re: Ballot 6 checkin, 17584, SVN error Manfred, Here's an update to 17584 for preview 3. I tried checking it in, but SVN said "Can't flush file /svn/root/repository/repos/txn-current.13.tmp: No space left on device". Tried deleting the earlier version of the attached file in SVN and got the same error. Conrad From: "Bock, Conrad" To: "Manfred R. Koethe" , "" Date: Fri, 14 Jun 2013 13:08:57 -0400 Subject: RE: [UML 2.5 FTF] Ballot 6 - Preview 4 --- PLEASE READ, 17584 Thread-Topic: [UML 2.5 FTF] Ballot 6 - Preview 4 --- PLEASE READ, 17584 Thread-Index: Ac5pISLyrOuxpBbAQYyahXVMk0kpMQ== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Virus-Scanned: amavisd-new at omg.org Manfred, One change to 17584 didn't make it in (I might have forgotten to change bar it), see update in: Clause-9-17584_resolved_v7.doc change to the update row of the table. Thx, Conrad Subject: Re: [UML 2.5 FTF] Ballot 6 - Preview 4 --- PLEASE READ, 17584 From: "Manfred R. Koethe" Date: Fri, 14 Jun 2013 13:30:28 -0700 Cc: "" To: Conrad Bock X-Mailer: Apple Mail (2.1499) X-Provags-ID: V02:K0:WXJty2NCXnIAUR47sMCf53SzwWWmbmUmtImmDtL3b61 hp5wlEAN3iSEzZEnOVJGutDd8Z4Am4zcimkunZqpordEs6szY0 zWM0EDg3Gg9aJSRRwAqbUew21JHiIkqIPhB0Og8OV54vu/CJzV f04Qu4JPeDLUsLG/XzFKpchRvkniMSbcLQ0jtTSlpDqizns0p3 vjaJfxARfKpTO2uAM4O915ih5d9NFzhFKOgalA6FAtoB0yPO4O pKvHb0FviygObcccILmebobW8JdKx2Yn/coAzrxz/i0nIAkVIW hgbyhhGgnxON+2YXUMvD4PsJlfWLRlvi/6k7UAgLtY3hW3EzAL aZt+qmbTbJHf+WHdyPyVaHh7t76jBVsQKSI1Wa5xlLWQf7a/7E mE46EAsS9/tMA== X-Virus-Scanned: amavisd-new at omg.org Conrad, I didn't overlook that change, but I took the liberty to rephrase this part of the sentence. Your phrase "elements which classify them" makes the sentence hard to read, so I changed it to "their classifiers", which has to my view the identical meaning and also streamlines it with the other rows in that column in the table, which also use "their classifier". Regards, Manfred On Jun 14, 2013, at 10:08 , "Bock, Conrad" wrote: Manfred, One change to 17584 didn't make it in (I might have forgotten to change bar it), see update in: Clause-9-17584_resolved_v7.doc change to the update row of the table. Thx, Conrad --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (510) 246 8611 fax: +1 (815) 550 2086 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)-------- signature17.asc signature17.asc From: "Bock, Conrad" To: "Manfred R. Koethe" , "" Date: Sun, 16 Jun 2013 05:07:39 -0400 Subject: RE: [UML 2.5 FTF] Ballot 6 - Preview 4 --- PLEASE READ, 17584 Thread-Topic: [UML 2.5 FTF] Ballot 6 - Preview 4 --- PLEASE READ, 17584 Thread-Index: Ac5pPgf3olCY8ceRQkGW6tSFJQ1HWgBMc05Q Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Virus-Scanned: amavisd-new at omg.org Manfred, > I didn't overlook that change, but I took the liberty to rephrase this > part of the sentence. Your phrase "elements which classify them" makes the > sentence hard to read, so I changed it to "their classifiers", which has > to my view the identical meaning and also streamlines it with the other > rows in that column in the table, which also use "their classifier". The wording "their classifiers" in this context could mean that the classifiers themselves are changed, rather than which classifiers classify the object are changed. Also, the wording in the table is out of synch with the classifier descriptions now. Can you update the ballot with Clause-9-17584_resolved_v7.doc? Let me know if you have suggestions for wording changes so we can discuss. Conrad