Issue 12853: More than one constraint block of the same type in a parametric diagram (sysml-rtf) Source: oose Innovative Informatik GmbH (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de) Nature: Uncategorized Issue Severity: Summary: I'm just experimenting with the parametric diagram and detected a problem. I'm not sure if it is a SysML problem or if I am the problem. A block A has a composition relationship to a constraint block with multiplicity * and property name cstr. I like to use the constraint property cstr in a parametric diagram of block A multiple times. That doesn't work, because the constraint property occurs only once in the diagram. I don't like to define a constraint property for every usage of the constraint in the parametric diagram, because it's not two or three times, but really many many times I want to use the constraint. I think of something like the selector in sequence diagrams, i.e. the name of the constraint property in the parametric diagram is cstr[1] : MyConstraintBlock, cstr[2] : MyConstraintBlock, and so on. What do you think? Am I completely wrong? Resolution: Revised Text: Actions taken: September 12, 2008: received issue Discussion: This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred End of Annotations:===== ubject: More than one constraint block of the same type in a parametric diagram Date: Fri, 12 Sep 2008 08:29:21 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: More than one constraint block of the same type in a parametric diagram Thread-Index: AckUmkCePjCj2OrcQCygZ2d7splFig== From: "Tim Weilkiens" To: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m8C6YR3e014124 I'm just experimenting with the parametric diagram and detected a problem. I'm not sure if it is a SysML problem or if I am the problem. A block A has a composition relationship to a constraint block with multiplicity * and property name cstr. I like to use the constraint property cstr in a parametric diagram of block A multiple times. That doesn't work, because the constraint property occurs only once in the diagram. I don't like to define a constraint property for every usage of the constraint in the parametric diagram, because it's not two or three times, but really many many times I want to use the constraint. I think of something like the selector in sequence diagrams, i.e. the name of the constraint property in the parametric diagram is cstr[1] : MyConstraintBlock, cstr[2] : MyConstraintBlock, and so on. What do you think? Am I completely wrong? Tim ----------------------------------------------------------------- Tim Weilkiens Head of Systems Engineering OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Bernd Schröder-Oestereich, Christian Weiss Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de Date: Fri, 12 Sep 2008 05:50:53 -0400 From: "Friedenthal, Sanford" Subject: RE: More than one constraint block of the same type in a parametric diagram To: Tim Weilkiens , sysml-rtf@omg.org Thread-Topic: More than one constraint block of the same type in a parametric diagram Thread-Index: AckUmkCePjCj2OrcQCygZ2d7splFigAIbl5Q X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 12 Sep 2008 09:50:53.0840 (UTC) FILETIME=[0BEFA900:01C914BD] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m8C9ooJr025406 Tim Representing multiple constraint properties on a parametric diagram should be the same as representing multiple parts on an ibd assuming they both have a multiplicity of '*' on the bdd. Sandy Sanford Friedenthal Lockheed Martin (703) 293-5557 -----Original Message----- From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Friday, September 12, 2008 2:29 AM To: sysml-rtf@omg.org Subject: More than one constraint block of the same type in a parametric diagram I'm just experimenting with the parametric diagram and detected a problem. I'm not sure if it is a SysML problem or if I am the problem. A block A has a composition relationship to a constraint block with multiplicity * and property name cstr. I like to use the constraint property cstr in a parametric diagram of block A multiple times. That doesn't work, because the constraint property occurs only once in the diagram. I don't like to define a constraint property for every usage of the constraint in the parametric diagram, because it's not two or three times, but really many many times I want to use the constraint. I think of something like the selector in sequence diagrams, i.e. the name of the constraint property in the parametric diagram is cstr[1] : MyConstraintBlock, cstr[2] : MyConstraintBlock, and so on. What do you think? Am I completely wrong? Tim ----------------------------------------------------------------- Tim Weilkiens Head of Systems Engineering OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Bernd Schröder-Oestereich, Christian Weiss Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de Subject: RE: More than one constraint block of the same type in a parametric diagram Date: Fri, 12 Sep 2008 13:24:31 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: More than one constraint block of the same type in a parametric diagram Thread-Index: AckUmkCePjCj2OrcQCygZ2d7splFigAIbl5QAANyzHA= From: "Tim Weilkiens" To: "Friedenthal, Sanford" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m8CBQ1SX008763 Sandy, Attached you see a picture that shows my problem. The constraint property is shown correctly with multiplicity [0..*]. But I don't like to bind my elements to a set of these constraints, but to only one of it. And I like to bind other two elements to another constraint property and so on. Tim > -----Original Message----- > From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] > Sent: Friday, September 12, 2008 11:51 AM > To: Tim Weilkiens; sysml-rtf@omg.org > Subject: RE: More than one constraint block of the same type > in a parametric diagram > > Tim > > Representing multiple constraint properties on a parametric > diagram should be the same as representing multiple parts on > an ibd assuming they both have a multiplicity of '*' on the bdd. > > Sandy > > Sanford Friedenthal > Lockheed Martin > (703) 293-5557 > > > -----Original Message----- > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > Sent: Friday, September 12, 2008 2:29 AM > To: sysml-rtf@omg.org > Subject: More than one constraint block of the same type in a > parametric diagram > > I'm just experimenting with the parametric diagram and > detected a problem. I'm not sure if it is a SysML problem or > if I am the problem. > > A block A has a composition relationship to a constraint > block with multiplicity * and property name cstr. > I like to use the constraint property cstr in a parametric > diagram of block A multiple times. > That doesn't work, because the constraint property occurs > only once in the diagram. > > I don't like to define a constraint property for every usage > of the constraint in the parametric diagram, because it's not > two or three times, but really many many times I want to use > the constraint. > I think of something like the selector in sequence diagrams, > i.e. the name of the constraint property in the parametric > diagram is cstr[1] : MyConstraintBlock, cstr[2] : > MyConstraintBlock, and so on. > > What do you think? Am I completely wrong? > > Tim > > ----------------------------------------------------------------- > Tim Weilkiens > Head of Systems Engineering > OMG Representative, INCOSE member > > oose Innovative Informatik GmbH > Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 Hamburg, > Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO > Bernd Schröder-Oestereich, Christian Weiss > Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 > Internet: www.oose.de, E-Mail: office@oose.de > Subject: RE: More than one constraint block of the same type in a parametric diagram - WITH ATTACHMENT Date: Fri, 12 Sep 2008 20:57:42 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: More than one constraint block of the same type in a parametric diagram - WITH ATTACHMENT Thread-Index: AckUmkCePjCj2OrcQCygZ2d7splFigAIbl5QAANyzHAAABgTYAAAA2XAAAJOOgAAAIXR0AALTxcw From: "Tim Weilkiens" To: "Friedenthal, Sanford" Cc: "Juergen Boldt" X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m8CIwR9Z024387 Sandy, I think it is worth to discuss it and force a decision (closed, deferred, resolved). >From my current point of view that would be a good feature. But I think there could be several side-effects I don't overlook right now. @Juergen: Please file an issue for that. Tim > -----Original Message----- > From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] > Sent: Friday, September 12, 2008 2:53 PM > To: Tim Weilkiens > Subject: RE: More than one constraint block of the same type > in a parametric diagram - WITH ATTACHMENT > > Tim > > If you have a selector, then you are in affect identifying > the specific part that would show up on the bdd as a separate > association. However, I do understand that this would be > cumbersome and if you could just specify the nth item with a > part name (e.g. n = partN), that would be good. > > Sandy > > > Sanford Friedenthal > Lockheed Martin > (703) 293-5557 > > > -----Original Message----- > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > Sent: Friday, September 12, 2008 8:35 AM > To: Friedenthal, Sanford > Subject: RE: More than one constraint block of the same type > in a parametric diagram - WITH ATTACHMENT > > I'm not sure if that this is a tool issue. I couldn't find a > hint in the UML or SysML specification how to show multiple > parts on an ibd except showing the multiplicity within the > box. I think it isn't possible. > > If we would like to have something like that we need an > extension as defined for lifelines in sequence diagrams: > > If the referenced ConnectableElement is multivalued (i.e, has > a multiplicity > 1), then the Lifeline may have an expression > (the 'selector') that specifies which particular part is > represented by this Lifeline. If the selector is omitted, > this means that an arbitrary representative of the > multivalued ConnectableElement is chosen. > > selector : ValueSpecification[0..1] > If the referenced ConnectableElement is multivalued, then > this specifies the specific individual part within that set. > > > Tim > > > -----Original Message----- > > From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] > > Sent: Friday, September 12, 2008 1:27 PM > > To: Tim Weilkiens > > Subject: RE: More than one constraint block of the same type in a > > parametric diagram - WITH ATTACHMENT > > > > I understand the issue. I believe this is a tool issue. If you have > > multiplicity greater than one, I would assume you can show multiple > > constraint usages on a parametric and multiple parts on an ibd. > > > > > > Sanford Friedenthal > > Lockheed Martin > > (703) 293-5557 > > > > > > -----Original Message----- > > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > > Sent: Friday, September 12, 2008 7:25 AM > > To: Friedenthal, Sanford; sysml-rtf@omg.org > > Subject: FW: More than one constraint block of the same type in a > > parametric diagram - WITH ATTACHMENT > > > > Now with attachment. Sorry for the mistake. > > > > Tim > > > > > -----Original Message----- > > > From: Tim Weilkiens > > > Sent: Friday, September 12, 2008 1:25 PM > > > To: 'Friedenthal, Sanford'; sysml-rtf@omg.org > > > Subject: RE: More than one constraint block of the same type in a > > > parametric diagram > > > > > > Sandy, > > > > > > Attached you see a picture that shows my problem. The constraint > > > property is shown correctly with multiplicity [0..*]. > > > > > > But I don't like to bind my elements to a set of these > constraints, > > > but to only one of it. And I like to bind other two elements to > > > another constraint property and so on. > > > > > > Tim > > > > > > > -----Original Message----- > > > > From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] > > > > Sent: Friday, September 12, 2008 11:51 AM > > > > To: Tim Weilkiens; sysml-rtf@omg.org > > > > Subject: RE: More than one constraint block of the same > type in a > > > > parametric diagram > > > > > > > > Tim > > > > > > > > Representing multiple constraint properties on a > > parametric diagram > > > > should be the same as representing multiple parts on an ibd > > > assuming > > > > they both have a multiplicity of '*' on the bdd. > > > > > > > > Sandy > > > > > > > > Sanford Friedenthal > > > > Lockheed Martin > > > > (703) 293-5557 > > > > > > > > > > > > -----Original Message----- > > > > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > > > > Sent: Friday, September 12, 2008 2:29 AM > > > > To: sysml-rtf@omg.org > > > > Subject: More than one constraint block of the same type in a > > > > parametric diagram > > > > > > > > I'm just experimenting with the parametric diagram and > detected a > > > > problem. I'm not sure if it is a SysML problem or if I am > > > the problem. > > > > > > > > A block A has a composition relationship to a constraint > > block with > > > > multiplicity * and property name cstr. > > > > I like to use the constraint property cstr in a parametric > > > diagram of > > > > block A multiple times. > > > > That doesn't work, because the constraint property occurs > > > only once in > > > > the diagram. > > > > > > > > I don't like to define a constraint property for every > > usage of the > > > > constraint in the parametric diagram, because it's not > > two or three > > > > times, but really many many times I want to use the constraint. > > > > I think of something like the selector in sequence > > > diagrams, i.e. the > > > > name of the constraint property in the parametric diagram > > > is cstr[1] : > > > > MyConstraintBlock, cstr[2] : > > > > MyConstraintBlock, and so on. > > > > > > > > What do you think? Am I completely wrong? > > > > > > > > Tim > > > > > > > > > ----------------------------------------------------------------- > > > > Tim Weilkiens > > > > Head of Systems Engineering > > > > OMG Representative, INCOSE member > > > > > > > > oose Innovative Informatik GmbH > > > > Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 > > > Hamburg, Germany > > > > HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Bernd > > > > Schröder-Oestereich, Christian Weiss > > > > Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 > > > > Internet: www.oose.de, E-Mail: office@oose.de > > > > > > To: , From: "Tim Weilkiens" Cc: Thread-Topic: Constraint Blocks issues in ballot 1 thread-index: Aczq6do722AeWa5sQq6PP+Ej2b4iOA== Date: Tue, 14 Feb 2012 08:26:08 +0100 X-Mailer: TouchDown Subject: RE: Constraint Blocks issues in ballot 1 X-XWALL-BCKS: auto 12853 The discussion about the issue reminds me more clearly about my intent of the issue. One part was clarified by Roger in our teleconference. The other one is the multiplicity issue that Yves mentioned in his mail. That issue is already covered by 11333. I propose we close 12853 and refer to 11333. Tim -----Original Message----- From: Burkhart Roger M [BurkhartRogerM@JohnDeere.com] Received: Montag, 13 Feb. 2012, 20:21 To: BERNARD, Yves [Yves.Bernard@airbus.com]; Tim Weilkiens [Tim.Weilkiens@oose.de] CC: sysml-rtf@omg.org [sysml-rtf@omg.org] Subject: Constraint Blocks issues in ballot 1 Yves-- From your comments below: [YB] #12130: The ambiguity pointed out by Darren is not fully removed by the proposed resolution. I think we could do better by modifying the moved sentences like this: .A constraint property is a property typed by a constraint block. It holds a localized usage of the constraint block.. [RB] I like your simplified wording and will use it in an updated version of the resolution. [YB] #12132: Not sure we should discard the entire paragraph since .constraint properties. might have specificities. See below. [RB] There's no discarded paragraph in this resolution, just slight edits and expansion of existing text. For now I'll keep the resolution as is. [YB] #12853: I disagree with the content of the discussion paragraph since I.ve the feeling that there is a confusion between .representing the same part/role (with multiplicity [1..1]) multiple time. and .representing the multiples part corresponding to a role which have a multiplicity greater than 1.. To my understanding, the issue raised by Tim refers to the second case and then we cannot say that it is .the same element appearing multiple times on the same diagram.. My feeling is that we should remove this issue from this ballot because it is not that .easily disposed.. For instance, one could also ask was would actually mean a constraint property which would have a multiplicity different from [1..1]? [RB] Tim was on last Thursday's telecon and indicated, based on our brief review, that this resolution seemed to be OK. As a process issue, I'd rather not hold an issue open based on a new question it might be interpreted as raising. If there's a new issue that grows out of an old one, it's OK to close the old one and to raise a new one. On multiplicities used with binding connectors, note also that we have a more general issue 11333, "Semantics of BindingConnector multiplicities" (listed under the Blocks chapter because Blocks are where binding connectors are defined) which definitely isn't easily disposed and which would remain to discuss binding connectors to parameters with non-single multiplicities. I still don't understand any proposal for constraint properties with extra multiplicity, however, since I've only ever expected them to be typed by a single constraint block with single multiplicity. If Tim confirms this was part of the intent, or is a suggestion of something to consider, we could either hold the issue open but with followup discussion to further explain such a proposal, or close this issue and raise a new one with a specific new proposal and the motivations to drive it. [YB] #16332: I disagree with both the issue and the resolution. The current statement: .the only connectors that may be shown are binding connectors connected to constraint parameters on at least one end. does not prevent the usage of binding connectors to link properties which are not constraint parameters but it does actually prevent to show such binding connectors in a parametric diagram. I suggest a .Closed, no change. disposition. [RB] If I understand correctly, you do not think that binding connectors directly between value properties should be allowed to be shown on a parametric diagram, even though that's specifically the capability requested by the issue. In drafting the proposed resolution, I thought this capability was safe and natural enough. A binding connector is like a constraint block that states nothing more than that its ends are equal. If such an "equality" constraint block had already been defined in a library, it would clearly be valid to show on a parametric diagram. It seems natural enough to allow a binding connector to indicate such equality directly. A Closed, no change disposition wouldn't be any less controversial since it disallows what the issue specifically requested. If you disagree directly with the original issue, that certainly means we'll need to remove it from ballot 1 and move it to another ballot where we can discuss it further and if need be vote to resolve any disagreeement. I'll hold off updating the ballot until I hear back from you and/or Tim on 12853, and confirmation you'd like to see us pull 16332 to further consider whether binding connectors directly between value properties should be allowed on a parametric diagram. --Roger From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Monday, February 13, 2012 9:43 AMTo: Sysml-Rtf (sysml-rtf@omg.org)Subject: [SysML RTF v1.4] Ballot 1 review. During the last RTF telecom we quickly reviewed most of the resolution proposed for ballot 1. However, after a more in-deep reading, I have the following remarks: #12130: The ambiguity pointed out by Darren is not fully removed by the proposed resolution. I think we could do better by modifying the moved sentences like this: .A constraint property is a property typed by a constraint block. It holds a localized usage of the constraint block.. #12132: Not sure we should discard the entire paragraph since .constraint properties. might have specificities. See below. #12853: I disagree with the content of the discussion paragraph since I.ve the feeling that there is a confusion between .representing the same part/role (with multiplicity [1..1]) multiple time. and .representing the multiples part corresponding to a role which have a multiplicity greater than 1.. To my understanding, the issue raised by Tim refers to the second case and then we cannot say that it is .the same element appearing multiple times on the same diagram.. My feeling is that we should remove this issue from this ballot because it is not that .easily disposed.. For instance, one could also ask was would actually mean a constraint property which would have a multiplicity different from [1..1]? #16332: I disagree with both the issue and the resolution. The current statement: .the only connectors that may be shown are binding connectors connected to constraint parameters on at least one end. does not prevent the usage of binding connectors to link properties which are not constraint parameters but it does actually prevent to show such binding connectors in a parametric diagram. I suggest a .Closed, no change. disposition. 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: "BERNARD, Yves" To: Tim Weilkiens , "BurkhartRogerM@JohnDeere.com" CC: "sysml-rtf@omg.org" Date: Tue, 14 Feb 2012 09:42:39 +0100 Subject: RE: Constraint Blocks issues in ballot 1 Thread-Topic: Constraint Blocks issues in ballot 1 Thread-Index: Aczq6do722AeWa5sQq6PP+Ej2b4iOAABMyug Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Roger, Tim, See my comments and suggestions below. Thanks, Yves -----Original Message----- From: Burkhart Roger M [BurkhartRogerM@JohnDeere.com] [YB] #12132: Not sure we should discard the entire paragraph since .constraint properties. might have specificities. See below. [RB] There's no discarded paragraph in this resolution, just slight edits and expansion of existing text. For now I'll keep the resolution as is. [BERNARD, Yves] You.re right, sorry: the paragraph I refer to are discarded in the proposed resolution to #12130, so just .move. the comment to this issue. [YB] #12853: I disagree with the content of the discussion paragraph since I.ve the feeling that there is a confusion between .representing the same part/role (with multiplicity [1..1]) multiple time. and .representing the multiples part corresponding to a role which have a multiplicity greater than 1.. To my understanding, the issue raised by Tim refers to the second case and then we cannot say that it is .the same element appearing multiple times on the same diagram.. My feeling is that we should remove this issue from this ballot because it is not that .easily disposed.. For instance, one could also ask was would actually mean a constraint property which would have a multiplicity different from [1..1]? [RB] Tim was on last Thursday's telecon and indicated, based on our brief review, that this resolution seemed to be OK. As a process issue, I'd rather not hold an issue open based on a new question it might be interpreted as raising. If there's a new issue that grows out of an old one, it's OK to close the old one and to raise a new one. On multiplicities used with binding connectors, note also that we have a more general issue 11333, "Semantics of BindingConnector multiplicities" (listed under the Blocks chapter because Blocks are where binding connectors are defined) which definitely isn't easily disposed and which would remain to discuss binding connectors to parameters with non-single multiplicities. I still don't understand any proposal for constraint properties with extra multiplicity, however, since I've only ever expected them to be typed by a single constraint block with single multiplicity. If Tim confirms this was part of the intent, or is a suggestion of something to consider, we could either hold the issue open but with followup discussion to further explain such a proposal, or close this issue and raise a new one with a specific new proposal and the motivations to drive it. [BERNARD, Yves] Maybe I put too many things in my comment. Let.s try to sort: 1. I.ve the feeling that Tim.s point is actually about .representing a part which has a multiplicity > 1. and the resolution deals with representing multiple time in the same diagrams the same part (i.e. multiplicity = 1) => if there is such a misunderstanding the text of the resolution has to be corrected 2. The second point is about the multiplicity of a constraint property. It is in some way similar the issue raised about multiplicities on binding connectors but I.m not sure it is exactly the same since the question can be raised for any kind of property (and not only those typed by a constraint block). See UML v2.4 semantic variation point sub-section in §9.3.14 .StructuredClassifier. [YB] #16332: I disagree with both the issue and the resolution. The current statement: .the only connectors that may be shown are binding connectors connected to constraint parameters on at least one end. does not prevent the usage of binding connectors to link properties which are not constraint parameters but it does actually prevent to show such binding connectors in a parametric diagram. I suggest a .Closed, no change. disposition. [RB] If I understand correctly, you do not think that binding connectors directly between value properties should be allowed to be shown on a parametric diagram, even though that's specifically the capability requested by the issue. In drafting the proposed resolution, I thought this capability was safe and natural enough. A binding connector is like a constraint block that states nothing more than that its ends are equal. If such an "equality" constraint block had already been defined in a library, it would clearly be valid to show on a parametric diagram. It seems natural enough to allow a binding connector to indicate such equality directly. A Closed, no change disposition wouldn't be any less controversial since it disallows what the issue specifically requested. If you disagree directly with the original issue, that certainly means we'll need to remove it from ballot 1 and move it to another ballot where we can discuss it further and if need be vote to resolve any disagreeement. [BERNARD, Yves] Ok, I did not understand it that way but your point makes sense to me. However, I still believe that the issue is not well stated since this is not the binding connector definition that was restricted by the current sentence but the definition of what a parametric diagram can show. Could we enhance the text of the resolution to something like: .Remove the overly restrictive language in the referenced sentence since binding connectors can be considered by themselves as a parametric constraint indicating the equality.? 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. >