Issue 12370: Section 8.7.1a production rule seems to be missing (qvt-rtf) Source: (, ) Nature: Revision Severity: Minor Summary: a production rule seems to be missing: <module_element> ::= <modeltype> Since, a transformation file can define several transformations and libraries (modules), it is desirable having the possibility of defining modeltypes exclusively to a module. These "local" modelTypes should belong to the scope of a module, and it shouldn't be accessible to the remaining defined modules (unless the use of extension mechanisms is specified). Resolution: Section 8.7.1a production rule seems to be missing a production rule seems to be missing: <module_element> ::= <modeltype> Since, a transformation file can define several transformations and libraries (modules), it is desirable having the possibility of defining modeltypes exclusively to a module. These "local" modelTypes should belong to the scope of a module, and it shouldn't be accessible to the remaining defined modules (unless the use of extension mechanisms is specified). Discussion A transformation is a major programming element so multiple transformations per file seems as unusual as multiple Java classes per file. But we do already support transformation X(...) {...} transformation Y(...) {...} so perhaps we need per transformation modeltypes. But if we provided them as suggested: we would have transformation X(in q : Q) { modeltype Q uses ....; } allowing an outer declaration to depend on an inner. If a user really wants many transformations per file with many distinct conflicting modeltypes, then the user has the option to use distinctive names for each modeltype. Much more sensible to use multiple files in the first place. Similarly we don't want or support per-transformation imports. Revised Text: Actions taken: April 4, 2008: received issue December 22, 2015: Closed; No Change March 29, 2016: closed issue Discussion: It is not clear whether this is necessary or just a convenience. Disposition: Deferred End of Annotations:===== m: webmaster@omg.org Date: 04 Apr 2008 09:28:15 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Adolfo Sánchez-Barbudo Herrera Company: Open Canarias S.L. mailFrom: adolfosbh@opencanarias.com Notification: Yes Specification: MOF. Query / Views / Transformations Section: 8.7.1 FormalNumber: qvt-rtf Version: QVT 1.1 RTF RevisionDate: 07/07/07 Page: 120 Nature: Revision Severity: Minor HTTP User Agent: Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.8.1.13) Gecko/20080325 Ubuntu/7.10 (gutsy) Firefox/2.0.0.13 Description a production rule seems to be missing: ::= Since, a transformation file can define several transformations and libraries (modules), it is desirable having the possibility of defining modeltypes exclusively to a module. These "local" modelTypes should belong to the scope of a module, and it shouldn't be accessible to the remaining defined modules (unless the use of extension mechanisms is specified). Subject: RE: Re-starting work on QVT 1.1 Date: Thu, 13 Nov 2008 04:28:31 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re-starting work on QVT 1.1 Thread-Index: Ack4L6ZsGHviX+whTmKHWxd5wVmQuwAFJfHAA1EtdIA= From: "Radek Dvorak" To: Cc: X-OriginalArrivalTime: 13 Nov 2008 12:27:11.0101 (UTC) FILETIME=[26D4A2D0:01C9458B] Hi Mariano, I know I'm late, but can we still take into account some comments on the 'Issue 12370: Section 8.4.1.a production rule seems to be missing' Sorry, I haven't raised that earlier. Actually, I don't see a clear way how to realize the statement "model types are local to QVT modules (transformation or libraries)." without having the proposed rule added. A modeltype, being a top level element in a unit with multiple modules is defined in a scope, where I can't see any relation of the modeltype to a particular module. Also, if modeltype would be a special case manifested as 'always local' element, what would be the difference to a metamodel, for instance? Anyway, I agree there is no need for a new rule and we should rather try to solve the problem by clarification of existing concepts. My question is "do we need that local"? To me, it looks a bit contradictory, if used in a transformation signature. Would importers be forced to define its own modeltype in order to use a transf? Besides, I think a modeltype could still be made "local" from the importer perspective by using the import statement 'from' 'import' '. The top level modeltypes should not be imported if not mentioned in the import explicitly. Perhaps, we could rather be more specific in how possible clashes are to be resolved and when ambiguities should be reported? In the scope of a single unit it's under control of the writer to resolve local clashes and should be pretty feasible. In a real word, my transf might certainly be a client to other imported compilation units, which are likely to evolve. I believe, it's desirable not to be affected by new modeltype (not only) definitions coming from dependencies, in a way that cause compilation errors in the importer. In order to minimize such an impact, it seems natural that modeltypes, which are defined in the importing unit should take precedence. Actually, this would not be a completely new concept, as it has already been outlined in 8.2.1.4 ModuleImport ... a symbol defined locally has always precedence in respect to the imported symbols. Obviously, we can still be affected by multiple imports that define the same modeltype, in which case an importer (not having its local definition) should see such reference as ambiguous, resulting in an error. Regards, /Radek -------------------------------------------------------------------------------- From: mariano.belaunde@orange-ftgroup.com [mailto:mariano.belaunde@orange-ftgroup.com] Sent: Monday, October 27, 2008 4:12 PM To: sreedhar.reddy@tcs.com; qvt-rtf@omg.org Subject: RE: Re-starting work on QVT 1.1 Hi Sreedhar and all, Thanks for these issue proposals. We have now on the table resolutions for the issues: 10646, 11341, 12173, 12198, 12362, 12370, 12373, 12374, 12375 I propose to let people react on these resolutions until November 7th and then we will start a first vote ballot. By the way, I will ask for moving the deadline for the RTF report so that it can presented in the March meeting (synchronized with OCL 2.1 RTF).. Best Regards, Mariano -------------------------------------------------------------------------------- De : Sreedhar Reddy [mailto:sreedhar.reddy@tcs.com] Envoyé : lundi 27 octobre 2008 13:23 À : qvt-rtf@omg.org Cc : BELAUNDE Mariano RD-MAPS-LAN Objet : Re: Re-starting work on QVT 1.1 Hi all, Pl find attached proposed resolutions for two issues related to QVT/relations: - Issue 10646: Concrete to abstract syntax mapping - Issue 11341: Navigating non-navigable opposite roles Regards, Sreedhar Sreedhar S Reddy Tata Consultancy Services Mailto: sreedhar.reddy@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Outsourcing ____________________________________________ 07/07/2008 04:26 PM To cc Subject Re-starting work on QVT 1.1 Hi all, In order to be able to have a new release of QVT (QVT 1.1) at the end of this year we need to start working on the pending issues. We have 10 issues at http://www.omg.org/issues/mof-qvt-ftf.open.html And 39 Issues at http://www.omg.org/issues/qvt-rtf.open.html. I invite all members of the RTF to propose/comment possible resolutions. In terms of schedule, I propose to prepare a first ballot mid of September based on received material. Notice the actual formal doc to be referred in resolutions is: http://www.omg.org/docs/formal/08-04-03.pdf Below there is a first set of proposed issue resolutions (issues 12173, 12198, 12362, 12370, 12373, 12374, 12375) which are issues posted by Open Canarias Inc related to the QVT/Operational formalism. Regards, Mariano ************************************* Issue 12173: Section: 8.2.1.6 Summary: The extraCondition association needs revision: 1. The name does match with the diagram. 2. The cardinality is incorrect. Suggestion: Change the text with the following line: additionalCondition: OclExpression [*] {composes, ordered} Comment: That's true. The class description is obsolete in respect with the role naming found in Figure 8.1. Resolution: In Section 8.2.1.6, replace extraCondition: OclExpression [1..*] {composes, ordered} By: additionalCondition: OclExpression [*] {composes, ordered} *************************************** Issue 12198: Section: 8.2.1.7 Summary: A clarification is needed in the text because it says "A variable parameter is an abstract concept..." and it can lead to confussion. A variable parameter can not be abstract because we could not create VarParameters for Helpers or Constructors (We could just create ModelParameters or MappingParameters). Suggestion: Remove the word "abstract". Resolution: In Section 8.2.1.7, replace "A variable parameter is an abstract concept." By: "A variable parameter is a concept." ****************************************** Issue 12362: Section 8.4.7 Summary: The grammar rule used to produce a forExp doesn't coincide with the notation specified in the abstract syntax section for it (Pag 89, Section 8.2.2.6). The rule production in the grammar is wrong. Suggestion: Change the production rule: ::= ('forEach' | 'forOne') '(' ('|' )? ')' Comment: The intent of syntax rule: ::= ('forEach' | 'forOne') '(' (';' )? ('|' )? ')' Was to allow shorthand with the computeExp compute (x:X) mylist->forEach(i|cond) { . } <==> mylist->forEach(i;x|cond) { . } Similarly with what happens with While expression. However the explanation was missing in the notation sub-section. Resolution: In Section 8.2.2.6, at the end of the "Notation" sub-section add the following text. """ When using a foreach expression in conjunction with a compute expression the following shorthand can be used: mylist->forEach(i;x:X=...|cond) { . } Which is equivalent to: compute (x:X=...) mylist->forEach(i|cond) { . } This is similar to the shorthand notation for while expression (see 8.2.2.4). """ ****************************************** Issue 12370: Section 8.4.1.a production rule seems to be missing Summary a production rule seems to be missing: ::= Since, a transformation file can define several transformations and libraries (modules), it is desirable having the possibility of defining modeltypes exclusively to a module. These "local" modelTypes should belong to the scope of a module, and it shouldn't be accessible to the remaining defined modules (unless the use of extension mechanisms is specified). Comment: Model types are always local (belong to the scope of a module). A clarification sentence is needed here but there is no need to add a new production rule. Resolution: At the end of Notation sub-section, within 8.2.1.6, add the following text: """ Note: Model types are local to QVT modules (transformation or libraries). If multiple transformations or libraries are defined in a single QVT file, each module has its own instance of a model type. Model type instances referring to the same metamodel definition are indeed compatible. """ **************************** Issue 12373: Section: 8.2.2.22 Summary: UnpackExp should not compose targetVariable There are a lot of issues in this section: 1. name of Variable association was not updated to targetVariable. 2. {ordered} is missed. 3. variable should not compose. They should refer for instance a previously defined VarInitExp::referredVariable. 4. Parenthesis are missed in the first example (notation section). 5. Remember to update the diagram in figure 8.6 (pag 86). Note: These proposed changes are needed if you want to allow unpacking OrderedTuples using previously defined variables (which makes sense). Another (worst) alternative is forcing to declare new variables . In this case, the notation section should be changed. Resolution: (1) Replace: variable : Variable [1..*] {composes} by targetVariable : Variable [1..*] {ordered} (2) Replace var x, y , z := self.foo(); // assuming foo returns a tuple of three elements. By var (x,y,z) := self.foo(); // assuming foo returns a tuple of three elements. **************************** Issue 12374: Section: 8.2.2.22: Unclear specification of Unpack notation shorthand Summary: Section 8.2.2.22 provides no guidance on the meaning of: var x:X; var y:Y; var z:Z; ... var (x:X,y,z) := self.foo(); [If one of the variables in the left hand side, does exist ...] Resolution: (1) Replace the text: """If one of the variables in the left hand side does not exist, the notation is a shorthand for declaring the missing variables prior to the unpack expression. In such case, the type of the variables can be given. For instance, in the example above, if .x. and .y. does not exist, the expression var (x:X,y:Y,z) := self.foo(); is equivalent to: var x:X; var y:Y; var (x,y,z) := foo(); """ By the following text: """The following example demonstrates a shorthand in which variables are both declared and assigned. var (x:X,y:Y,z) := self.foo(); Any variable name which specifies a type name is both a declaration and an assignment, with all declarations proceding the unapack assignment. The above example should therefore be analyzed as: var x:X; var y:Y; var (x,y,z) := self.foo();" """ **************************** Issue 12375: Section: 8.1.14 Summary: QVT Operational Mappings claims in the overview section, the use of ListLiteralExpression (for instance to initialize a list), as in the section 8.1.14 (Pag 55) is shown. However, there is no way to represent this literal expression in the abstract syntax, due to: 1. There is no ListLiteralExp in the imperativeOCL package. 2. CollectionLiteralExp (from EssentialOCL) can't be used. There is a way to initialize lists, making use of the asList operator which appears in the Standard Library section (8.3.85 / Pag 112), however this should be clarified. Therefore, two possible solutions could be taken: Suggestion 1: Create a ListLiteralExp which should extend CollectionLiteralExp (From EssentialOCL). Suggestion 2: Update the overview examples, to properly ilustrate how to initialize lists. Besides, the grammar ( Pag 124) )should be consequently changed as well. (List { 1, 2, 3, } literal expressions wouldn't be supported). Resolution: (1) Add a new subsection 8.2.2.33 ListLiteralExp, with the following content: A list literal expression is a literal definition for a mutable list type (see 8.2.2.25) . Superclasses: CollectionLiteralExp (From EssentialOCL) Associations: element : OclExpression [*] {composes,ordered} The values of the literal list. (2) Update the Figure 8.7 with the ListLiteralExp definition (3) Add the 'List' keyword in 8.4.7.1. ForwardSourceID:NT0003637A =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you Subject: RE: Re-starting work on QVT 1.1: Issue 12370 Date: Thu, 20 Nov 2008 15:39:30 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re-starting work on QVT 1.1: Issue 12370 Thread-Index: Ack4L6ZsGHviX+whTmKHWxd5wVmQuwAFJfHAA1EtdIAABLwRwA== From: To: , X-OriginalArrivalTime: 20 Nov 2008 14:39:28.0726 (UTC) FILETIME=[CAEA5760:01C94B1D] Hi Radek, Here's some feedback concerning your remark on issue 12370. I think your remark make sence: model types declarations could simply be instantiated at same level of modules (instead of being necessarily owned by modules, using the 'ownedType' association). This has one advantage: parsing is simpler when constructing the QVT model from the QVT text. This also has one disadvantage: in most cases instead of having a single root object, we will have many, implying some filtering before inspecting the module definition. Now from a conceptual point of view, I see no problem with having local modeltypes since model type equivalence can be established by looking at the declared metamodels. So I have personally no definitive preference concerning the two possibilities: modeltypes are local to modules or globally defined and shared. Any further opinion here? Regards, Mariano -------------------------------------------------------------------------------- De : Radek Dvorak [mailto:Radek.Dvorak@borland.com] Envoyé : jeudi 13 novembre 2008 13:29 À : qvt-rtf@omg.org Cc : BELAUNDE Mariano RD-MAPS-LAN Objet : RE: Re-starting work on QVT 1.1 Hi Mariano, I know I'm late, but can we still take into account some comments on the 'Issue 12370: Section 8.4.1.a production rule seems to be missing' Sorry, I haven't raised that earlier. Actually, I don't see a clear way how to realize the statement "model types are local to QVT modules (transformation or libraries)." without having the proposed rule added. A modeltype, being a top level element in a unit with multiple modules is defined in a scope, where I can't see any relation of the modeltype to a particular module. Also, if modeltype would be a special case manifested as 'always local' element, what would be the difference to a metamodel, for instance? Anyway, I agree there is no need for a new rule and we should rather try to solve the problem by clarification of existing concepts. My question is "do we need that local"? To me, it looks a bit contradictory, if used in a transformation signature. Would importers be forced to define its own modeltype in order to use a transf? Besides, I think a modeltype could still be made "local" from the importer perspective by using the import statement 'from' 'import' '. The top level modeltypes should not be imported if not mentioned in the import explicitly. Perhaps, we could rather be more specific in how possible clashes are to be resolved and when ambiguities should be reported? In the scope of a single unit it's under control of the writer to resolve local clashes and should be pretty feasible. In a real word, my transf might certainly be a client to other imported compilation units, which are likely to evolve. I believe, it's desirable not to be affected by new modeltype (not only) definitions coming from dependencies, in a way that cause compilation errors in the importer. In order to minimize such an impact, it seems natural that modeltypes, which are defined in the importing unit should take precedence. Actually, this would not be a completely new concept, as it has already been outlined in 8.2.1.4 ModuleImport ... a symbol defined locally has always precedence in respect to the imported symbols. Obviously, we can still be affected by multiple imports that define the same modeltype, in which case an importer (not having its local definition) should see such reference as ambiguous, resulting in an error. Regards, /Radek -------------------------------------------------------------------------------- From: mariano.belaunde@orange-ftgroup.com [mailto:mariano.belaunde@orange-ftgroup.com] Sent: Monday, October 27, 2008 4:12 PM To: sreedhar.reddy@tcs.com; qvt-rtf@omg.org Subject: RE: Re-starting work on QVT 1.1 Hi Sreedhar and all, Thanks for these issue proposals. We have now on the table resolutions for the issues: 10646, 11341, 12173, 12198, 12362, 12370, 12373, 12374, 12375 I propose to let people react on these resolutions until November 7th and then we will start a first vote ballot. By the way, I will ask for moving the deadline for the RTF report so that it can presented in the March meeting (synchronized with OCL 2.1 RTF).. Best Regards, Mariano -------------------------------------------------------------------------------- De : Sreedhar Reddy [mailto:sreedhar.reddy@tcs.com] Envoyé : lundi 27 octobre 2008 13:23 À : qvt-rtf@omg.org Cc : BELAUNDE Mariano RD-MAPS-LAN Objet : Re: Re-starting work on QVT 1.1 Hi all, Pl find attached proposed resolutions for two issues related to QVT/relations: - Issue 10646: Concrete to abstract syntax mapping - Issue 11341: Navigating non-navigable opposite roles Regards, Sreedhar Sreedhar S Reddy Tata Consultancy Services Mailto: sreedhar.reddy@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Outsourcing ____________________________________________ 07/07/2008 04:26 PM To cc Subject Re-starting work on QVT 1.1 Hi all, In order to be able to have a new release of QVT (QVT 1.1) at the end of this year we need to start working on the pending issues. We have 10 issues at http://www.omg.org/issues/mof-qvt-ftf.open.html And 39 Issues at http://www.omg.org/issues/qvt-rtf.open.html. I invite all members of the RTF to propose/comment possible resolutions. In terms of schedule, I propose to prepare a first ballot mid of September based on received material. Notice the actual formal doc to be referred in resolutions is: http://www.omg.org/docs/formal/08-04-03.pdf Below there is a first set of proposed issue resolutions (issues 12173, 12198, 12362, 12370, 12373, 12374, 12375) which are issues posted by Open Canarias Inc related to the QVT/Operational formalism. Regards, Mariano ************************************* Issue 12173: Section: 8.2.1.6 Summary: The extraCondition association needs revision: 1. The name does match with the diagram. 2. The cardinality is incorrect. Suggestion: Change the text with the following line: additionalCondition: OclExpression [*] {composes, ordered} Comment: That's true. The class description is obsolete in respect with the role naming found in Figure 8.1. Resolution: In Section 8.2.1.6, replace extraCondition: OclExpression [1..*] {composes, ordered} By: additionalCondition: OclExpression [*] {composes, ordered} *************************************** Issue 12198: Section: 8.2.1.7 Summary: A clarification is needed in the text because it says "A variable parameter is an abstract concept..." and it can lead to confussion. A variable parameter can not be abstract because we could not create VarParameters for Helpers or Constructors (We could just create ModelParameters or MappingParameters). Suggestion: Remove the word "abstract". Resolution: In Section 8.2.1.7, replace "A variable parameter is an abstract concept." By: "A variable parameter is a concept." ****************************************** Issue 12362: Section 8.4.7 Summary: The grammar rule used to produce a forExp doesn't coincide with the notation specified in the abstract syntax section for it (Pag 89, Section 8.2.2.6). The rule production in the grammar is wrong. Suggestion: Change the production rule: ::= ('forEach' | 'forOne') '(' ('|' )? ')' Comment: The intent of syntax rule: ::= ('forEach' | 'forOne') '(' (';' )? ('|' )? ')' Was to allow shorthand with the computeExp compute (x:X) mylist->forEach(i|cond) { . } <==> mylist->forEach(i;x|cond) { . } Similarly with what happens with While expression. However the explanation was missing in the notation sub-section. Resolution: In Section 8.2.2.6, at the end of the "Notation" sub-section add the following text. """ When using a foreach expression in conjunction with a compute expression the following shorthand can be used: mylist->forEach(i;x:X=...|cond) { . } Which is equivalent to: compute (x:X=...) mylist->forEach(i|cond) { . } This is similar to the shorthand notation for while expression (see 8.2.2.4). """ ****************************************** Issue 12370: Section 8.4.1.a production rule seems to be missing Summary a production rule seems to be missing: ::= Since, a transformation file can define several transformations and libraries (modules), it is desirable having the possibility of defining modeltypes exclusively to a module. These "local" modelTypes should belong to the scope of a module, and it shouldn't be accessible to the remaining defined modules (unless the use of extension mechanisms is specified). Comment: Model types are always local (belong to the scope of a module). A clarification sentence is needed here but there is no need to add a new production rule. Resolution: At the end of Notation sub-section, within 8.2.1.6, add the following text: """ Note: Model types are local to QVT modules (transformation or libraries). If multiple transformations or libraries are defined in a single QVT file, each module has its own instance of a model type. Model type instances referring to the same metamodel definition are indeed compatible. """ **************************** Issue 12373: Section: 8.2.2.22 Summary: UnpackExp should not compose targetVariable There are a lot of issues in this section: 1. name of Variable association was not updated to targetVariable. 2. {ordered} is missed. 3. variable should not compose. They should refer for instance a previously defined VarInitExp::referredVariable. 4. Parenthesis are missed in the first example (notation section). 5. Remember to update the diagram in figure 8.6 (pag 86). Note: These proposed changes are needed if you want to allow unpacking OrderedTuples using previously defined variables (which makes sense). Another (worst) alternative is forcing to declare new variables . In this case, the notation section should be changed. Resolution: (1) Replace: variable : Variable [1..*] {composes} by targetVariable : Variable [1..*] {ordered} (2) Replace var x, y , z := self.foo(); // assuming foo returns a tuple of three elements. By var (x,y,z) := self.foo(); // assuming foo returns a tuple of three elements. **************************** Issue 12374: Section: 8.2.2.22: Unclear specification of Unpack notation shorthand Summary: Section 8.2.2.22 provides no guidance on the meaning of: var x:X; var y:Y; var z:Z; ... var (x:X,y,z) := self.foo(); [If one of the variables in the left hand side, does exist ...] Resolution: (1) Replace the text: """If one of the variables in the left hand side does not exist, the notation is a shorthand for declaring the missing variables prior to the unpack expression. In such case, the type of the variables can be given. For instance, in the example above, if .x. and .y. does not exist, the expression var (x:X,y:Y,z) := self.foo(); is equivalent to: var x:X; var y:Y; var (x,y,z) := foo(); """ By the following text: """The following example demonstrates a shorthand in which variables are both declared and assigned. var (x:X,y:Y,z) := self.foo(); Any variable name which specifies a type name is both a declaration and an assignment, with all declarations proceding the unapack assignment. The above example should therefore be analyzed as: var x:X; var y:Y; var (x,y,z) := self.foo();" """ **************************** Issue 12375: Section: 8.1.14 Summary: QVT Operational Mappings claims in the overview section, the use of ListLiteralExpression (for instance to initialize a list), as in the section 8.1.14 (Pag 55) is shown. However, there is no way to represent this literal expression in the abstract syntax, due to: 1. There is no ListLiteralExp in the imperativeOCL package. 2. CollectionLiteralExp (from EssentialOCL) can't be used. There is a way to initialize lists, making use of the asList operator which appears in the Standard Library section (8.3.85 / Pag 112), however this should be clarified. Therefore, two possible solutions could be taken: Suggestion 1: Create a ListLiteralExp which should extend CollectionLiteralExp (From EssentialOCL). Suggestion 2: Update the overview examples, to properly ilustrate how to initialize lists. Besides, the grammar ( Pag 124) )should be consequently changed as well. (List { 1, 2, 3, } literal expressions wouldn't be supported). Resolution: (1) Add a new subsection 8.2.2.33 ListLiteralExp, with the following content: A list literal expression is a literal definition for a mutable list type (see 8.2.2.25) . Superclasses: CollectionLiteralExp (From EssentialOCL) Associations: element : OclExpression [*] {composes,ordered} The values of the literal list. (2) Update the Figure 8.7 with the ListLiteralExp definition (3) Add the 'List' keyword in 8.4.7.1. ForwardSourceID:NT0003637A =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you Subject: RE: Re-starting work on QVT 1.1: Issue 12370 Date: Fri, 21 Nov 2008 05:18:40 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re-starting work on QVT 1.1: Issue 12370 Thread-Index: Ack4L6ZsGHviX+whTmKHWxd5wVmQuwAFJfHAA1EtdIAABLwRwAGP6yAA From: "Radek Dvorak" To: , X-OriginalArrivalTime: 21 Nov 2008 13:18:11.0726 (UTC) FILETIME=[9A68F2E0:01C94BDB] Hi Mariano, I think nothing prevents the QVT model from living under a single root, if possible. However, it seems to be only the case when a compilation unit defines a single module. Here, I can see a logical connection of modeltypes to the module, so it can be set to 'ownedType'. As long as multiple modules in a single file are allowed, they do not have a common root container anyway, so multiple root objects should not break anything. Actually, I could not find any statement in the spec, saying a model should have just a single root object. I do not see any problem in modeltype equivalence. IOW, once it's local, an importer can (has to) to define a modeltype that references the same metamodels. However, another situation might arise: 1) A modeltype is a subclass of 'Class', one can define operations or properties on it. Provided, the modeltype is local, the importer would not get access to it. 2) A local modeltype that uses 'extraCondition' to further restrict models could not be reused as is by import. Should the importer to copy/paste the condition expressions in order to construct an equivalent modeltype, if the same restriction is required? 3) How do I define multiple modules in a single file, that need access to the same modeltype? Should I create copies? How should the locality be realized? It's possible to import top entities: transformations, libraries, modeltypes, metamodels and the import statement can select the entities to be visible in the importing file. Therefore, I do not see a great benefit in modeltypes being 'always local' and IMO, it kind of contradicts to what has been stated above. That is why I proposed to clarify the existing concept of import instead of creating a special rule for modeltype. Regards, /Radek -------------------------------------------------------------------------------- From: mariano.belaunde@orange-ftgroup.com [mailto:mariano.belaunde@orange-ftgroup.com] Sent: Thursday, November 20, 2008 3:40 PM To: Radek Dvorak; qvt-rtf@omg.org Subject: RE: Re-starting work on QVT 1.1: Issue 12370 Hi Radek, Here's some feedback concerning your remark on issue 12370. I think your remark make sence: model types declarations could simply be instantiated at same level of modules (instead of being necessarily owned by modules, using the 'ownedType' association). This has one advantage: parsing is simpler when constructing the QVT model from the QVT text. This also has one disadvantage: in most cases instead of having a single root object, we will have many, implying some filtering before inspecting the module definition. Now from a conceptual point of view, I see no problem with having local modeltypes since model type equivalence can be established by looking at the declared metamodels. So I have personally no definitive preference concerning the two possibilities: modeltypes are local to modules or globally defined and shared. Any further opinion here? Regards, Mariano -------------------------------------------------------------------------------- De : Radek Dvorak [mailto:Radek.Dvorak@borland.com] Envoyé : jeudi 13 novembre 2008 13:29 À : qvt-rtf@omg.org Cc : BELAUNDE Mariano RD-MAPS-LAN Objet : RE: Re-starting work on QVT 1.1 Hi Mariano, I know I'm late, but can we still take into account some comments on the 'Issue 12370: Section 8.4.1.a production rule seems to be missing' Sorry, I haven't raised that earlier. Actually, I don't see a clear way how to realize the statement "model types are local to QVT modules (transformation or libraries)." without having the proposed rule added. A modeltype, being a top level element in a unit with multiple modules is defined in a scope, where I can't see any relation of the modeltype to a particular module. Also, if modeltype would be a special case manifested as 'always local' element, what would be the difference to a metamodel, for instance? Anyway, I agree there is no need for a new rule and we should rather try to solve the problem by clarification of existing concepts. My question is "do we need that local"? To me, it looks a bit contradictory, if used in a transformation signature. Would importers be forced to define its own modeltype in order to use a transf? Besides, I think a modeltype could still be made "local" from the importer perspective by using the import statement 'from' 'import' '. The top level modeltypes should not be imported if not mentioned in the import explicitly. Perhaps, we could rather be more specific in how possible clashes are to be resolved and when ambiguities should be reported? In the scope of a single unit it's under control of the writer to resolve local clashes and should be pretty feasible. In a real word, my transf might certainly be a client to other imported compilation units, which are likely to evolve. I believe, it's desirable not to be affected by new modeltype (not only) definitions coming from dependencies, in a way that cause compilation errors in the importer. In order to minimize such an impact, it seems natural that modeltypes, which are defined in the importing unit should take precedence. Actually, this would not be a completely new concept, as it has already been outlined in 8.2.1.4 ModuleImport ... a symbol defined locally has always precedence in respect to the imported symbols. Obviously, we can still be affected by multiple imports that define the same modeltype, in which case an importer (not having its local definition) should see such reference as ambiguous, resulting in an error. Regards, /Radek -------------------------------------------------------------------------------- From: mariano.belaunde@orange-ftgroup.com [mailto:mariano.belaunde@orange-ftgroup.com] Sent: Monday, October 27, 2008 4:12 PM To: sreedhar.reddy@tcs.com; qvt-rtf@omg.org Subject: RE: Re-starting work on QVT 1.1 Hi Sreedhar and all, Thanks for these issue proposals. We have now on the table resolutions for the issues: 10646, 11341, 12173, 12198, 12362, 12370, 12373, 12374, 12375 I propose to let people react on these resolutions until November 7th and then we will start a first vote ballot. By the way, I will ask for moving the deadline for the RTF report so that it can presented in the March meeting (synchronized with OCL 2.1 RTF).. Best Regards, Mariano -------------------------------------------------------------------------------- De : Sreedhar Reddy [mailto:sreedhar.reddy@tcs.com] Envoyé : lundi 27 octobre 2008 13:23 À : qvt-rtf@omg.org Cc : BELAUNDE Mariano RD-MAPS-LAN Objet : Re: Re-starting work on QVT 1.1 Hi all, Pl find attached proposed resolutions for two issues related to QVT/relations: - Issue 10646: Concrete to abstract syntax mapping - Issue 11341: Navigating non-navigable opposite roles Regards, Sreedhar Sreedhar S Reddy Tata Consultancy Services Mailto: sreedhar.reddy@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Outsourcing ____________________________________________ 07/07/2008 04:26 PM To cc Subject Re-starting work on QVT 1.1 Hi all, In order to be able to have a new release of QVT (QVT 1.1) at the end of this year we need to start working on the pending issues. We have 10 issues at http://www.omg.org/issues/mof-qvt-ftf.open.html And 39 Issues at http://www.omg.org/issues/qvt-rtf.open.html. I invite all members of the RTF to propose/comment possible resolutions. In terms of schedule, I propose to prepare a first ballot mid of September based on received material. Notice the actual formal doc to be referred in resolutions is: http://www.omg.org/docs/formal/08-04-03.pdf Below there is a first set of proposed issue resolutions (issues 12173, 12198, 12362, 12370, 12373, 12374, 12375) which are issues posted by Open Canarias Inc related to the QVT/Operational formalism. Regards, Mariano ************************************* Issue 12173: Section: 8.2.1.6 Summary: The extraCondition association needs revision: 1. The name does match with the diagram. 2. The cardinality is incorrect. Suggestion: Change the text with the following line: additionalCondition: OclExpression [*] {composes, ordered} Comment: That's true. The class description is obsolete in respect with the role naming found in Figure 8.1. Resolution: In Section 8.2.1.6, replace extraCondition: OclExpression [1..*] {composes, ordered} By: additionalCondition: OclExpression [*] {composes, ordered} *************************************** Issue 12198: Section: 8.2.1.7 Summary: A clarification is needed in the text because it says "A variable parameter is an abstract concept..." and it can lead to confussion. A variable parameter can not be abstract because we could not create VarParameters for Helpers or Constructors (We could just create ModelParameters or MappingParameters). Suggestion: Remove the word "abstract". Resolution: In Section 8.2.1.7, replace "A variable parameter is an abstract concept." By: "A variable parameter is a concept." ****************************************** Issue 12362: Section 8.4.7 Summary: The grammar rule used to produce a forExp doesn't coincide with the notation specified in the abstract syntax section for it (Pag 89, Section 8.2.2.6). The rule production in the grammar is wrong. Suggestion: Change the production rule: ::= ('forEach' | 'forOne') '(' ('|' )? ')' Comment: The intent of syntax rule: ::= ('forEach' | 'forOne') '(' (';' )? ('|' )? ')' Was to allow shorthand with the computeExp compute (x:X) mylist->forEach(i|cond) { . } <==> mylist->forEach(i;x|cond) { . } Similarly with what happens with While expression. However the explanation was missing in the notation sub-section. Resolution: In Section 8.2.2.6, at the end of the "Notation" sub-section add the following text. """ When using a foreach expression in conjunction with a compute expression the following shorthand can be used: mylist->forEach(i;x:X=...|cond) { . } Which is equivalent to: compute (x:X=...) mylist->forEach(i|cond) { . } This is similar to the shorthand notation for while expression (see 8.2.2.4). """ ****************************************** Issue 12370: Section 8.4.1.a production rule seems to be missing Summary a production rule seems to be missing: ::= Since, a transformation file can define several transformations and libraries (modules), it is desirable having the possibility of defining modeltypes exclusively to a module. These "local" modelTypes should belong to the scope of a module, and it shouldn't be accessible to the remaining defined modules (unless the use of extension mechanisms is specified). Comment: Model types are always local (belong to the scope of a module). A clarification sentence is needed here but there is no need to add a new production rule. Resolution: At the end of Notation sub-section, within 8.2.1.6, add the following text: """ Note: Model types are local to QVT modules (transformation or libraries). If multiple transformations or libraries are defined in a single QVT file, each module has its own instance of a model type. Model type instances referring to the same metamodel definition are indeed compatible. """ **************************** Issue 12373: Section: 8.2.2.22 Summary: UnpackExp should not compose targetVariable There are a lot of issues in this section: 1. name of Variable association was not updated to targetVariable. 2. {ordered} is missed. 3. variable should not compose. They should refer for instance a previously defined VarInitExp::referredVariable. 4. Parenthesis are missed in the first example (notation section). 5. Remember to update the diagram in figure 8.6 (pag 86). Note: These proposed changes are needed if you want to allow unpacking OrderedTuples using previously defined variables (which makes sense). Another (worst) alternative is forcing to declare new variables . In this case, the notation section should be changed. Resolution: (1) Replace: variable : Variable [1..*] {composes} by targetVariable : Variable [1..*] {ordered} (2) Replace var x, y , z := self.foo(); // assuming foo returns a tuple of three elements. By var (x,y,z) := self.foo(); // assuming foo returns a tuple of three elements. **************************** Issue 12374: Section: 8.2.2.22: Unclear specification of Unpack notation shorthand Summary: Section 8.2.2.22 provides no guidance on the meaning of: var x:X; var y:Y; var z:Z; ... var (x:X,y,z) := self.foo(); [If one of the variables in the left hand side, does exist ...] Resolution: (1) Replace the text: """If one of the variables in the left hand side does not exist, the notation is a shorthand for declaring the missing variables prior to the unpack expression. In such case, the type of the variables can be given. For instance, in the example above, if .x. and .y. does not exist, the expression var (x:X,y:Y,z) := self.foo(); is equivalent to: var x:X; var y:Y; var (x,y,z) := foo(); """ By the following text: """The following example demonstrates a shorthand in which variables are both declared and assigned. var (x:X,y:Y,z) := self.foo(); Any variable name which specifies a type name is both a declaration and an assignment, with all declarations proceding the unapack assignment. The above example should therefore be analyzed as: var x:X; var y:Y; var (x,y,z) := self.foo();" """ **************************** Issue 12375: Section: 8.1.14 Summary: QVT Operational Mappings claims in the overview section, the use of ListLiteralExpression (for instance to initialize a list), as in the section 8.1.14 (Pag 55) is shown. However, there is no way to represent this literal expression in the abstract syntax, due to: 1. There is no ListLiteralExp in the imperativeOCL package. 2. CollectionLiteralExp (from EssentialOCL) can't be used. There is a way to initialize lists, making use of the asList operator which appears in the Standard Library section (8.3.85 / Pag 112), however this should be clarified. Therefore, two possible solutions could be taken: Suggestion 1: Create a ListLiteralExp which should extend CollectionLiteralExp (From EssentialOCL). Suggestion 2: Update the overview examples, to properly ilustrate how to initialize lists. Besides, the grammar ( Pag 124) )should be consequently changed as well. (List { 1, 2, 3, } literal expressions wouldn't be supported). Resolution: (1) Add a new subsection 8.2.2.33 ListLiteralExp, with the following content: A list literal expression is a literal definition for a mutable list type (see 8.2.2.25) . Superclasses: CollectionLiteralExp (From EssentialOCL) Associations: element : OclExpression [*] {composes,ordered} The values of the literal list. (2) Update the Figure 8.7 with the ListLiteralExp definition (3) Add the 'List' keyword in 8.4.7.1. ForwardSourceID:NT0003637A =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you Subject: RE: Re-starting work on QVT 1.1: Issue 12370 Date: Mon, 24 Nov 2008 08:55:09 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re-starting work on QVT 1.1: Issue 12370 Thread-Index: Ack4L6ZsGHviX+whTmKHWxd5wVmQuwAFJfHAA1EtdIAABLwRwAGP6yAAAAZ0/vAAl+6LIA== From: "Radek Dvorak" To: , X-OriginalArrivalTime: 24 Nov 2008 16:53:58.0789 (UTC) FILETIME=[3EB33B50:01C94E55] Hi Mariano, I propose the following: Section: 8.4.1 Files 1) Replacement: "If more than one element in this list is defined, the import statement designates the entities that need to be visible in the importing file. This is done using the syntax: from import , , ." By: "Importing a unit results in bringing its all top level entities into the scope of the importer. Optionally, the import statement may designate only the entities that need to be visible. This is done using the syntax: from import , , .; 2) Addition: (just behind the replacement above) "An entity which is local (defined) in an importer always takes precedence over an imported one, having the same identifier. If multiple imported entities can be resolved for a single identifier, ambiguity error must be reported." Regards, /Radek -------------------------------------------------------------------------------- From: mariano.belaunde@orange-ftgroup.com [mailto:mariano.belaunde@orange-ftgroup.com] Sent: Friday, November 21, 2008 5:30 PM To: Radek Dvorak; qvt-rtf@omg.org Subject: RE: Re-starting work on QVT 1.1: Issue 12370 Hi Radek, I'm fine with your proposal. Could you provide a replacement text for the resolution of issue 12370 that follows your idea of clarifying the existing concept of import instead of creating a special rule for modeltype?. Such resolution proposal could be included in the 2nd ballot to come. Thanks, Mariano -------------------------------------------------------------------------------- De : Radek Dvorak [mailto:Radek.Dvorak@borland.com] Envoyé : vendredi 21 novembre 2008 14:19 À : BELAUNDE Mariano RD-MAPS-LAN; qvt-rtf@omg.org Objet : RE: Re-starting work on QVT 1.1: Issue 12370 Hi Mariano, I think nothing prevents the QVT model from living under a single root, if possible. However, it seems to be only the case when a compilation unit defines a single module. Here, I can see a logical connection of modeltypes to the module, so it can be set to 'ownedType'. As long as multiple modules in a single file are allowed, they do not have a common root container anyway, so multiple root objects should not break anything. Actually, I could not find any statement in the spec, saying a model should have just a single root object. I do not see any problem in modeltype equivalence. IOW, once it's local, an importer can (has to) to define a modeltype that references the same metamodels. However, another situation might arise: 1) A modeltype is a subclass of 'Class', one can define operations or properties on it. Provided, the modeltype is local, the importer would not get access to it. 2) A local modeltype that uses 'extraCondition' to further restrict models could not be reused as is by import. Should the importer to copy/paste the condition expressions in order to construct an equivalent modeltype, if the same restriction is required? 3) How do I define multiple modules in a single file, that need access to the same modeltype? Should I create copies? How should the locality be realized? It's possible to import top entities: transformations, libraries, modeltypes, metamodels and the import statement can select the entities to be visible in the importing file. Therefore, I do not see a great benefit in modeltypes being 'always local' and IMO, it kind of contradicts to what has been stated above. That is why I proposed to clarify the existing concept of import instead of creating a special rule for modeltype. Regards, /Radek -------------------------------------------------------------------------------- From: mariano.belaunde@orange-ftgroup.com [mailto:mariano.belaunde@orange-ftgroup.com] Sent: Thursday, November 20, 2008 3:40 PM To: Radek Dvorak; qvt-rtf@omg.org Subject: RE: Re-starting work on QVT 1.1: Issue 12370 Hi Radek, Here's some feedback concerning your remark on issue 12370. I think your remark make sence: model types declarations could simply be instantiated at same level of modules (instead of being necessarily owned by modules, using the 'ownedType' association). This has one advantage: parsing is simpler when constructing the QVT model from the QVT text. This also has one disadvantage: in most cases instead of having a single root object, we will have many, implying some filtering before inspecting the module definition. Now from a conceptual point of view, I see no problem with having local modeltypes since model type equivalence can be established by looking at the declared metamodels. So I have personally no definitive preference concerning the two possibilities: modeltypes are local to modules or globally defined and shared. Any further opinion here? Regards, Mariano -------------------------------------------------------------------------------- De : Radek Dvorak [mailto:Radek.Dvorak@borland.com] Envoyé : jeudi 13 novembre 2008 13:29 À : qvt-rtf@omg.org Cc : BELAUNDE Mariano RD-MAPS-LAN Objet : RE: Re-starting work on QVT 1.1 Hi Mariano, I know I'm late, but can we still take into account some comments on the 'Issue 12370: Section 8.4.1.a production rule seems to be missing' Sorry, I haven't raised that earlier. Actually, I don't see a clear way how to realize the statement "model types are local to QVT modules (transformation or libraries)." without having the proposed rule added. A modeltype, being a top level element in a unit with multiple modules is defined in a scope, where I can't see any relation of the modeltype to a particular module. Also, if modeltype would be a special case manifested as 'always local' element, what would be the difference to a metamodel, for instance? Anyway, I agree there is no need for a new rule and we should rather try to solve the problem by clarification of existing concepts. My question is "do we need that local"? To me, it looks a bit contradictory, if used in a transformation signature. Would importers be forced to define its own modeltype in order to use a transf? Besides, I think a modeltype could still be made "local" from the importer perspective by using the import statement 'from' 'import' '. The top level modeltypes should not be imported if not mentioned in the import explicitly. Perhaps, we could rather be more specific in how possible clashes are to be resolved and when ambiguities should be reported? In the scope of a single unit it's under control of the writer to resolve local clashes and should be pretty feasible. In a real word, my transf might certainly be a client to other imported compilation units, which are likely to evolve. I believe, it's desirable not to be affected by new modeltype (not only) definitions coming from dependencies, in a way that cause compilation errors in the importer. In order to minimize such an impact, it seems natural that modeltypes, which are defined in the importing unit should take precedence. Actually, this would not be a completely new concept, as it has already been outlined in 8.2.1.4 ModuleImport ... a symbol defined locally has always precedence in respect to the imported symbols. Obviously, we can still be affected by multiple imports that define the same modeltype, in which case an importer (not having its local definition) should see such reference as ambiguous, resulting in an error. Regards, /Radek -------------------------------------------------------------------------------- From: mariano.belaunde@orange-ftgroup.com [mailto:mariano.belaunde@orange-ftgroup.com] Sent: Monday, October 27, 2008 4:12 PM To: sreedhar.reddy@tcs.com; qvt-rtf@omg.org Subject: RE: Re-starting work on QVT 1.1 Hi Sreedhar and all, Thanks for these issue proposals. We have now on the table resolutions for the issues: 10646, 11341, 12173, 12198, 12362, 12370, 12373, 12374, 12375 I propose to let people react on these resolutions until November 7th and then we will start a first vote ballot. By the way, I will ask for moving the deadline for the RTF report so that it can presented in the March meeting (synchronized with OCL 2.1 RTF).. Best Regards, Mariano -------------------------------------------------------------------------------- De : Sreedhar Reddy [mailto:sreedhar.reddy@tcs.com] Envoyé : lundi 27 octobre 2008 13:23 À : qvt-rtf@omg.org Cc : BELAUNDE Mariano RD-MAPS-LAN Objet : Re: Re-starting work on QVT 1.1 Hi all, Pl find attached proposed resolutions for two issues related to QVT/relations: - Issue 10646: Concrete to abstract syntax mapping - Issue 11341: Navigating non-navigable opposite roles Regards, Sreedhar Sreedhar S Reddy Tata Consultancy Services Mailto: sreedhar.reddy@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Outsourcing ____________________________________________ 07/07/2008 04:26 PM To cc Subject Re-starting work on QVT 1.1 Hi all, In order to be able to have a new release of QVT (QVT 1.1) at the end of this year we need to start working on the pending issues. We have 10 issues at http://www.omg.org/issues/mof-qvt-ftf.open.html And 39 Issues at http://www.omg.org/issues/qvt-rtf.open.html. I invite all members of the RTF to propose/comment possible resolutions. In terms of schedule, I propose to prepare a first ballot mid of September based on received material. Notice the actual formal doc to be referred in resolutions is: http://www.omg.org/docs/formal/08-04-03.pdf Below there is a first set of proposed issue resolutions (issues 12173, 12198, 12362, 12370, 12373, 12374, 12375) which are issues posted by Open Canarias Inc related to the QVT/Operational formalism. Regards, Mariano ************************************* Issue 12173: Section: 8.2.1.6 Summary: The extraCondition association needs revision: 1. The name does match with the diagram. 2. The cardinality is incorrect. Suggestion: Change the text with the following line: additionalCondition: OclExpression [*] {composes, ordered} Comment: That's true. The class description is obsolete in respect with the role naming found in Figure 8.1. Resolution: In Section 8.2.1.6, replace extraCondition: OclExpression [1..*] {composes, ordered} By: additionalCondition: OclExpression [*] {composes, ordered} *************************************** Issue 12198: Section: 8.2.1.7 Summary: A clarification is needed in the text because it says "A variable parameter is an abstract concept..." and it can lead to confussion. A variable parameter can not be abstract because we could not create VarParameters for Helpers or Constructors (We could just create ModelParameters or MappingParameters). Suggestion: Remove the word "abstract". Resolution: In Section 8.2.1.7, replace "A variable parameter is an abstract concept." By: "A variable parameter is a concept." ****************************************** Issue 12362: Section 8.4.7 Summary: The grammar rule used to produce a forExp doesn't coincide with the notation specified in the abstract syntax section for it (Pag 89, Section 8.2.2.6). The rule production in the grammar is wrong. Suggestion: Change the production rule: ::= ('forEach' | 'forOne') '(' ('|' )? ')' Comment: The intent of syntax rule: ::= ('forEach' | 'forOne') '(' (';' )? ('|' )? ')' Was to allow shorthand with the computeExp compute (x:X) mylist->forEach(i|cond) { . } <==> mylist->forEach(i;x|cond) { . } Similarly with what happens with While expression. However the explanation was missing in the notation sub-section. Resolution: In Section 8.2.2.6, at the end of the "Notation" sub-section add the following text. """ When using a foreach expression in conjunction with a compute expression the following shorthand can be used: mylist->forEach(i;x:X=...|cond) { . } Which is equivalent to: compute (x:X=...) mylist->forEach(i|cond) { . } This is similar to the shorthand notation for while expression (see 8.2.2.4). """ ****************************************** Issue 12370: Section 8.4.1.a production rule seems to be missing Summary a production rule seems to be missing: ::= Since, a transformation file can define several transformations and libraries (modules), it is desirable having the possibility of defining modeltypes exclusively to a module. These "local" modelTypes should belong to the scope of a module, and it shouldn't be accessible to the remaining defined modules (unless the use of extension mechanisms is specified). Comment: Model types are always local (belong to the scope of a module). A clarification sentence is needed here but there is no need to add a new production rule. Resolution: At the end of Notation sub-section, within 8.2.1.6, add the following text: """ Note: Model types are local to QVT modules (transformation or libraries). If multiple transformations or libraries are defined in a single QVT file, each module has its own instance of a model type. Model type instances referring to the same metamodel definition are indeed compatible. """ **************************** Issue 12373: Section: 8.2.2.22 Summary: UnpackExp should not compose targetVariable There are a lot of issues in this section: 1. name of Variable association was not updated to targetVariable. 2. {ordered} is missed. 3. variable should not compose. They should refer for instance a previously defined VarInitExp::referredVariable. 4. Parenthesis are missed in the first example (notation section). 5. Remember to update the diagram in figure 8.6 (pag 86). Note: These proposed changes are needed if you want to allow unpacking OrderedTuples using previously defined variables (which makes sense). Another (worst) alternative is forcing to declare new variables . In this case, the notation section should be changed. Resolution: (1) Replace: variable : Variable [1..*] {composes} by targetVariable : Variable [1..*] {ordered} (2) Replace var x, y , z := self.foo(); // assuming foo returns a tuple of three elements. By var (x,y,z) := self.foo(); // assuming foo returns a tuple of three elements. **************************** Issue 12374: Section: 8.2.2.22: Unclear specification of Unpack notation shorthand Summary: Section 8.2.2.22 provides no guidance on the meaning of: var x:X; var y:Y; var z:Z; ... var (x:X,y,z) := self.foo(); [If one of the variables in the left hand side, does exist ...] Resolution: (1) Replace the text: """If one of the variables in the left hand side does not exist, the notation is a shorthand for declaring the missing variables prior to the unpack expression. In such case, the type of the variables can be given. For instance, in the example above, if .x. and .y. does not exist, the expression var (x:X,y:Y,z) := self.foo(); is equivalent to: var x:X; var y:Y; var (x,y,z) := foo(); """ By the following text: """The following example demonstrates a shorthand in which variables are both declared and assigned. var (x:X,y:Y,z) := self.foo(); Any variable name which specifies a type name is both a declaration and an assignment, with all declarations proceding the unapack assignment. The above example should therefore be analyzed as: var x:X; var y:Y; var (x,y,z) := self.foo();" """ **************************** Issue 12375: Section: 8.1.14 Summary: QVT Operational Mappings claims in the overview section, the use of ListLiteralExpression (for instance to initialize a list), as in the section 8.1.14 (Pag 55) is shown. However, there is no way to represent this literal expression in the abstract syntax, due to: 1. There is no ListLiteralExp in the imperativeOCL package. 2. CollectionLiteralExp (from EssentialOCL) can't be used. There is a way to initialize lists, making use of the asList operator which appears in the Standard Library section (8.3.85 / Pag 112), however this should be clarified. Therefore, two possible solutions could be taken: Suggestion 1: Create a ListLiteralExp which should extend CollectionLiteralExp (From EssentialOCL). Suggestion 2: Update the overview examples, to properly ilustrate how to initialize lists. Besides, the grammar ( Pag 124) )should be consequently changed as well. (List { 1, 2, 3, } literal expressions wouldn't be supported). Resolution: (1) Add a new subsection 8.2.2.33 ListLiteralExp, with the following content: A list literal expression is a literal definition for a mutable list type (see 8.2.2.25) . Superclasses: CollectionLiteralExp (From EssentialOCL) Associations: element : OclExpression [*] {composes,ordered} The values of the literal list. (2) Update the Figure 8.7 with the ListLiteralExp definition (3) Add the 'List' keyword in 8.4.7.1. ForwardSourceID:NT0003637A =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you Subject: RE: Re-starting work on QVT 1.1: Issue 12370 Date: Tue, 25 Nov 2008 20:44:16 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re-starting work on QVT 1.1: Issue 12370 Thread-Index: Ack4L6ZsGHviX+whTmKHWxd5wVmQuwAFJfHAA1EtdIAABLwRwAGP6yAAAAZ0/vAAl+6LIAA4P30Q From: To: , X-OriginalArrivalTime: 25 Nov 2008 19:44:13.0212 (UTC) FILETIME=[31623DC0:01C94F36] Thanks. This looks fine. -Mariano -------------------------------------------------------------------------------- De : Radek Dvorak [mailto:Radek.Dvorak@borland.com] Envoyé : lundi 24 novembre 2008 17:55 À : BELAUNDE Mariano RD-MAPS-LAN; qvt-rtf@omg.org Objet : RE: Re-starting work on QVT 1.1: Issue 12370 Hi Mariano, I propose the following: Section: 8.4.1 Files 1) Replacement: "If more than one element in this list is defined, the import statement designates the entities that need to be visible in the importing file. This is done using the syntax: from import , , ." By: "Importing a unit results in bringing its all top level entities into the scope of the importer. Optionally, the import statement may designate only the entities that need to be visible. This is done using the syntax: from import , , .; 2) Addition: (just behind the replacement above) "An entity which is local (defined) in an importer always takes precedence over an imported one, having the same identifier. If multiple imported entities can be resolved for a single identifier, ambiguity error must be reported." Regards, /Radek -------------------------------------------------------------------------------- From: mariano.belaunde@orange-ftgroup.com [mailto:mariano.belaunde@orange-ftgroup.com] Sent: Friday, November 21, 2008 5:30 PM To: Radek Dvorak; qvt-rtf@omg.org Subject: RE: Re-starting work on QVT 1.1: Issue 12370 Hi Radek, I'm fine with your proposal. Could you provide a replacement text for the resolution of issue 12370 that follows your idea of clarifying the existing concept of import instead of creating a special rule for modeltype?. Such resolution proposal could be included in the 2nd ballot to come. Thanks, Mariano -------------------------------------------------------------------------------- De : Radek Dvorak [mailto:Radek.Dvorak@borland.com] Envoyé : vendredi 21 novembre 2008 14:19 À : BELAUNDE Mariano RD-MAPS-LAN; qvt-rtf@omg.org Objet : RE: Re-starting work on QVT 1.1: Issue 12370 Hi Mariano, I think nothing prevents the QVT model from living under a single root, if possible. However, it seems to be only the case when a compilation unit defines a single module. Here, I can see a logical connection of modeltypes to the module, so it can be set to 'ownedType'. As long as multiple modules in a single file are allowed, they do not have a common root container anyway, so multiple root objects should not break anything. Actually, I could not find any statement in the spec, saying a model should have just a single root object. I do not see any problem in modeltype equivalence. IOW, once it's local, an importer can (has to) to define a modeltype that references the same metamodels. However, another situation might arise: 1) A modeltype is a subclass of 'Class', one can define operations or properties on it. Provided, the modeltype is local, the importer would not get access to it. 2) A local modeltype that uses 'extraCondition' to further restrict models could not be reused as is by import. Should the importer to copy/paste the condition expressions in order to construct an equivalent modeltype, if the same restriction is required? 3) How do I define multiple modules in a single file, that need access to the same modeltype? Should I create copies? How should the locality be realized? It's possible to import top entities: transformations, libraries, modeltypes, metamodels and the import statement can select the entities to be visible in the importing file. Therefore, I do not see a great benefit in modeltypes being 'always local' and IMO, it kind of contradicts to what has been stated above. That is why I proposed to clarify the existing concept of import instead of creating a special rule for modeltype. Regards, /Radek -------------------------------------------------------------------------------- From: mariano.belaunde@orange-ftgroup.com [mailto:mariano.belaunde@orange-ftgroup.com] Sent: Thursday, November 20, 2008 3:40 PM To: Radek Dvorak; qvt-rtf@omg.org Subject: RE: Re-starting work on QVT 1.1: Issue 12370 Hi Radek, Here's some feedback concerning your remark on issue 12370. I think your remark make sence: model types declarations could simply be instantiated at same level of modules (instead of being necessarily owned by modules, using the 'ownedType' association). This has one advantage: parsing is simpler when constructing the QVT model from the QVT text. This also has one disadvantage: in most cases instead of having a single root object, we will have many, implying some filtering before inspecting the module definition. Now from a conceptual point of view, I see no problem with having local modeltypes since model type equivalence can be established by looking at the declared metamodels. So I have personally no definitive preference concerning the two possibilities: modeltypes are local to modules or globally defined and shared. Any further opinion here? Regards, Mariano -------------------------------------------------------------------------------- De : Radek Dvorak [mailto:Radek.Dvorak@borland.com] Envoyé : jeudi 13 novembre 2008 13:29 À : qvt-rtf@omg.org Cc : BELAUNDE Mariano RD-MAPS-LAN Objet : RE: Re-starting work on QVT 1.1 Hi Mariano, I know I'm late, but can we still take into account some comments on the 'Issue 12370: Section 8.4.1.a production rule seems to be missing' Sorry, I haven't raised that earlier. Actually, I don't see a clear way how to realize the statement "model types are local to QVT modules (transformation or libraries)." without having the proposed rule added. A modeltype, being a top level element in a unit with multiple modules is defined in a scope, where I can't see any relation of the modeltype to a particular module. Also, if modeltype would be a special case manifested as 'always local' element, what would be the difference to a metamodel, for instance? Anyway, I agree there is no need for a new rule and we should rather try to solve the problem by clarification of existing concepts. My question is "do we need that local"? To me, it looks a bit contradictory, if used in a transformation signature. Would importers be forced to define its own modeltype in order to use a transf? Besides, I think a modeltype could still be made "local" from the importer perspective by using the import statement 'from' 'import' '. The top level modeltypes should not be imported if not mentioned in the import explicitly. Perhaps, we could rather be more specific in how possible clashes are to be resolved and when ambiguities should be reported? In the scope of a single unit it's under control of the writer to resolve local clashes and should be pretty feasible. In a real word, my transf might certainly be a client to other imported compilation units, which are likely to evolve. I believe, it's desirable not to be affected by new modeltype (not only) definitions coming from dependencies, in a way that cause compilation errors in the importer. In order to minimize such an impact, it seems natural that modeltypes, which are defined in the importing unit should take precedence. Actually, this would not be a completely new concept, as it has already been outlined in 8.2.1.4 ModuleImport ... a symbol defined locally has always precedence in respect to the imported symbols. Obviously, we can still be affected by multiple imports that define the same modeltype, in which case an importer (not having its local definition) should see such reference as ambiguous, resulting in an error. Regards, /Radek -------------------------------------------------------------------------------- From: mariano.belaunde@orange-ftgroup.com [mailto:mariano.belaunde@orange-ftgroup.com] Sent: Monday, October 27, 2008 4:12 PM To: sreedhar.reddy@tcs.com; qvt-rtf@omg.org Subject: RE: Re-starting work on QVT 1.1 Hi Sreedhar and all, Thanks for these issue proposals. We have now on the table resolutions for the issues: 10646, 11341, 12173, 12198, 12362, 12370, 12373, 12374, 12375 I propose to let people react on these resolutions until November 7th and then we will start a first vote ballot. By the way, I will ask for moving the deadline for the RTF report so that it can presented in the March meeting (synchronized with OCL 2.1 RTF).. Best Regards, Mariano -------------------------------------------------------------------------------- De : Sreedhar Reddy [mailto:sreedhar.reddy@tcs.com] Envoyé : lundi 27 octobre 2008 13:23 À : qvt-rtf@omg.org Cc : BELAUNDE Mariano RD-MAPS-LAN Objet : Re: Re-starting work on QVT 1.1 Hi all, Pl find attached proposed resolutions for two issues related to QVT/relations: - Issue 10646: Concrete to abstract syntax mapping - Issue 11341: Navigating non-navigable opposite roles Regards, Sreedhar Sreedhar S Reddy Tata Consultancy Services Mailto: sreedhar.reddy@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Outsourcing ____________________________________________ 07/07/2008 04:26 PM To cc Subject Re-starting work on QVT 1.1 Hi all, In order to be able to have a new release of QVT (QVT 1.1) at the end of this year we need to start working on the pending issues. We have 10 issues at http://www.omg.org/issues/mof-qvt-ftf.open.html And 39 Issues at http://www.omg.org/issues/qvt-rtf.open.html. I invite all members of the RTF to propose/comment possible resolutions. In terms of schedule, I propose to prepare a first ballot mid of September based on received material. Notice the actual formal doc to be referred in resolutions is: http://www.omg.org/docs/formal/08-04-03.pdf Below there is a first set of proposed issue resolutions (issues 12173, 12198, 12362, 12370, 12373, 12374, 12375) which are issues posted by Open Canarias Inc related to the QVT/Operational formalism. Regards, Mariano ************************************* Issue 12173: Section: 8.2.1.6 Summary: The extraCondition association needs revision: 1. The name does match with the diagram. 2. The cardinality is incorrect. Suggestion: Change the text with the following line: additionalCondition: OclExpression [*] {composes, ordered} Comment: That's true. The class description is obsolete in respect with the role naming found in Figure 8.1. Resolution: In Section 8.2.1.6, replace extraCondition: OclExpression [1..*] {composes, ordered} By: additionalCondition: OclExpression [*] {composes, ordered} *************************************** Issue 12198: Section: 8.2.1.7 Summary: A clarification is needed in the text because it says "A variable parameter is an abstract concept..." and it can lead to confussion. A variable parameter can not be abstract because we could not create VarParameters for Helpers or Constructors (We could just create ModelParameters or MappingParameters). Suggestion: Remove the word "abstract". Resolution: In Section 8.2.1.7, replace "A variable parameter is an abstract concept." By: "A variable parameter is a concept." ****************************************** Issue 12362: Section 8.4.7 Summary: The grammar rule used to produce a forExp doesn't coincide with the notation specified in the abstract syntax section for it (Pag 89, Section 8.2.2.6). The rule production in the grammar is wrong. Suggestion: Change the production rule: ::= ('forEach' | 'forOne') '(' ('|' )? ')' Comment: The intent of syntax rule: ::= ('forEach' | 'forOne') '(' (';' )? ('|' )? ')' Was to allow shorthand with the computeExp compute (x:X) mylist->forEach(i|cond) { . } <==> mylist->forEach(i;x|cond) { . } Similarly with what happens with While expression. However the explanation was missing in the notation sub-section. Resolution: In Section 8.2.2.6, at the end of the "Notation" sub-section add the following text. """ When using a foreach expression in conjunction with a compute expression the following shorthand can be used: mylist->forEach(i;x:X=...|cond) { . } Which is equivalent to: compute (x:X=...) mylist->forEach(i|cond) { . } This is similar to the shorthand notation for while expression (see 8.2.2.4). """ ****************************************** Issue 12370: Section 8.4.1.a production rule seems to be missing Summary a production rule seems to be missing: ::= Since, a transformation file can define several transformations and libraries (modules), it is desirable having the possibility of defining modeltypes exclusively to a module. These "local" modelTypes should belong to the scope of a module, and it shouldn't be accessible to the remaining defined modules (unless the use of extension mechanisms is specified). Comment: Model types are always local (belong to the scope of a module). A clarification sentence is needed here but there is no need to add a new production rule. Resolution: At the end of Notation sub-section, within 8.2.1.6, add the following text: """ Note: Model types are local to QVT modules (transformation or libraries). If multiple transformations or libraries are defined in a single QVT file, each module has its own instance of a model type. Model type instances referring to the same metamodel definition are indeed compatible. """ **************************** Issue 12373: Section: 8.2.2.22 Summary: UnpackExp should not compose targetVariable There are a lot of issues in this section: 1. name of Variable association was not updated to targetVariable. 2. {ordered} is missed. 3. variable should not compose. They should refer for instance a previously defined VarInitExp::referredVariable. 4. Parenthesis are missed in the first example (notation section). 5. Remember to update the diagram in figure 8.6 (pag 86). Note: These proposed changes are needed if you want to allow unpacking OrderedTuples using previously defined variables (which makes sense). Another (worst) alternative is forcing to declare new variables . In this case, the notation section should be changed. Resolution: (1) Replace: variable : Variable [1..*] {composes} by targetVariable : Variable [1..*] {ordered} (2) Replace var x, y , z := self.foo(); // assuming foo returns a tuple of three elements. By var (x,y,z) := self.foo(); // assuming foo returns a tuple of three elements. **************************** Issue 12374: Section: 8.2.2.22: Unclear specification of Unpack notation shorthand Summary: Section 8.2.2.22 provides no guidance on the meaning of: var x:X; var y:Y; var z:Z; ... var (x:X,y,z) := self.foo(); [If one of the variables in the left hand side, does exist ...] Resolution: (1) Replace the text: """If one of the variables in the left hand side does not exist, the notation is a shorthand for declaring the missing variables prior to the unpack expression. In such case, the type of the variables can be given. For instance, in the example above, if .x. and .y. does not exist, the expression var (x:X,y:Y,z) := self.foo(); is equivalent to: var x:X; var y:Y; var (x,y,z) := foo(); """ By the following text: """The following example demonstrates a shorthand in which variables are both declared and assigned. var (x:X,y:Y,z) := self.foo(); Any variable name which specifies a type name is both a declaration and an assignment, with all declarations proceding the unapack assignment. The above example should therefore be analyzed as: var x:X; var y:Y; var (x,y,z) := self.foo();" """ **************************** Issue 12375: Section: 8.1.14 Summary: QVT Operational Mappings claims in the overview section, the use of ListLiteralExpression (for instance to initialize a list), as in the section 8.1.14 (Pag 55) is shown. However, there is no way to represent this literal expression in the abstract syntax, due to: 1. There is no ListLiteralExp in the imperativeOCL package. 2. CollectionLiteralExp (from EssentialOCL) can't be used. There is a way to initialize lists, making use of the asList operator which appears in the Standard Library section (8.3.85 / Pag 112), however this should be clarified. Therefore, two possible solutions could be taken: Suggestion 1: Create a ListLiteralExp which should extend CollectionLiteralExp (From EssentialOCL). Suggestion 2: Update the overview examples, to properly ilustrate how to initialize lists. Besides, the grammar ( Pag 124) )should be consequently changed as well. (List { 1, 2, 3, } literal expressions wouldn't be supported). Resolution: (1) Add a new subsection 8.2.2.33 ListLiteralExp, with the following content: A list literal expression is a literal definition for a mutable list type (see 8.2.2.25) . Superclasses: CollectionLiteralExp (From EssentialOCL) Associations: element : OclExpression [*] {composes,ordered} The values of the literal list. (2) Update the Figure 8.7 with the ListLiteralExp definition (3) Add the 'List' keyword in 8.4.7.1. ForwardSourceID:NT0003637A =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you Sender: Adolfo Sanchez Barbudo Date: Tue, 23 Dec 2008 12:57:44 +0000 From: Adolfo Sánchez-Barbudo Herrera Organization: Open Canarias S.L. User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) To: qvt-rtf@omg.org Subject: Re-starting work on QVT 1.1: Issue 12370 Hi Mariano, Radek Some thoughts about your interesting debate. I don't really conceive the idea of having a ModelType as a root element of a QVTo model. IMHO, a MOF type should always belong to a Package (i.e, a QVTo Module). Some times, when I'm confused, I try to think in the Java world (which usually is mentioned in the Operational Mappings section for analogy). Do you believe in the existence of a java class which doesn't belong to a java package?. The problem here is that a Module is both, a Package and Class. However, I try to think in the following QVTo2Java mapping: modeltype MT1 uses .... typedef myNewType = .... transformation myTransformation (....) { .... } A "equivalent" java structure could be: mytransformation.MyTransformation -> a java class which represent the transformation, in a java package. mytransformation.MT1 -> a java class class which represents the model type, in a java package. mytransformation.MyNewType -> a java class which represents a new type, in a java package. Another idea, is that we should clearly distinguish between concrete and abstract syntax. On the one hand, having top level entities in a QVTo file, shouldn't mean that we must obligatorily have these same top entities for the correspondent AST. How must the import be considered, at abstract syntax level? at concrete syntax level?. taking into account only qvto files? or the correponsdant models? What happens if I have QVTo generated from a transformation or modelled by hand?. Am I allowed to import it ? Which are the top entities in that case, and the compilation unit ?. On the other hand, having the possibility of writing several transformations in the same file is a concrete syntax feature which may help the transformation writer. However, from my point of view, the result (the equivalent abstract syntax) must have been the same if I had written them in separated files. So that: file.qvto modeltype mt1 uses .... transformation t1 (inout a: mt1) { .... } transforamtion t2 (inout b: mt1) { .... } should produce same packages (transformations) and types(modeltypes) than doing: file1.qvto modeltype mt1 uses .... transformation t1(inout a: mt1) { ... } file2.qvto modeltype mt1 uses ... transforamtion t2(inout b:mt1) { ... } Again, mapping to a java world, we would have the following structure: t1.T1 -> one transformation in a package. t1.Mt1 -> one modeltype in the same package. t2.T2 -> another transforamtion in another package. t2.Mt1 -> another modeltype in the same previous package. The original idea of creating new rules for ModelType inside module, is just for coherence. We can create "global" and "local" (in the concrete syntax) Typedefs. Nevertheless, we can only create "global" model types. I don't find any inconvenience creating "local" as well, they are just types !!. Why should not the following example be supported ? file.qvto modeltype mt 1 uses .... transformation t1(in a: mt1, out b:mt2) { modeltype mt2 uses .... ... } transformation t2(in a:mt1, out b:mt2, out c:mt3) { modeltype mt2 uses ..... modeltype mt3 uses ..... ... } In separated files: file1.qvto modeltype mt1 uses ... modeltype mt2 uses ... transformation t1(in a: mt1, out b:mt2) { -- The model types could have been defined here } file2.qvto modeltype mt1 uses modeltype mt2 uses modeltype mt3 uses transformation t2(in a:mt1, out b:mt2, out c:mt3) { -- The model types could have been defined here } In java world: t1.T1 t1.Mt1 t1.Mt2 t2.T2 t2.Mt1 t2.Mt2 t2.Mt3 Taking into account all the related above. For the import concept (at concrete syntax level) is clear for me. You can import a whole package (or a module), or some specific types of a package (or a module). Again thinking in Java: in QVTo the following sentence: import ; would be interpreted in Java as: import package_or_module_name_space.*; in QVTo the following sentence: from import , would be interpreted in Java as: import package_or_module_name_space.type1; import package_or_module_name_space.type2; - The unique needed clarification is when doing from .... definition .... is when a the specified name_space corresponds to a Module, so that the own class which also represents the module would be always implicitly imported. - Extra considerations about name's clash, such us the suggested by Radek, must be considered and clarified. Again thinking in Java could give us a good solution. Finally, one could think in the examples above that you are always creating a lot of classes which could conceptually represent the same model type. However, I must add - My transformation (at abstract syntax level) doesn't depend on anything else that itself (I have not declared in it any dependency on any other module) - You can always create libraries with defined model types and use, in this case, the import mechanisms at abstract syntax level. Regards, Adolfo. -- Adolfo Sánchez-Barbudo Herrera adolfosbh@opencanarias.com C/Elías Ramos González, 4, ofc. 304 38001 SANTA CRUZ DE TENERIFE Tel.: +34 922 240231 / +34 617 718268