Issues for Mailing list of the MOF QVT Finalization Task Force

To comment on any of these issues, send email to mof-qvt-ftf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 9250: Page 28 (mof-qvt-ftf)

Click here for this issue's archive.
Source: Hewlett-Packard (Ms. Susan Entwisle, susan.entwisle(at)eds.com)
Nature: Uncategorized Issue
Severity:
Summary:

states that the plugin has access to object references in models, and may do arbitrary things to those objects. The specification should state that this approach breaks encapsulation of the object.

Resolution: In section 6.2, page 25, replaces the sentence "The plugin implementation has access to object references in models, and may do arbitrary things to those objects." by: "The plugin implementation has access to object references in models, and may do arbitrary things to those objects, possibly breaking encapsulation".
Revised Text:
Actions taken:
January 19, 2006: received issue
November 7, 2007: closed issue

Issue 9251: Page 30 (mof-qvt-ftf)

Click here for this issue's archive.
Source: Hewlett-Packard (Ms. Susan Entwisle, susan.entwisle(at)eds.com)
Nature: Uncategorized Issue
Severity:
Summary:

Chapter 9 The Relations Language contains long and complex sentences, which reduce the readability of the specification

Resolution: closed no change
Revised Text:
Actions taken:
January 19, 2006: received issue
November 7, 2007: closed issue

Discussion:

Unless some explicit replacement suggestions are provided
it is difficult to solve this kind of editorial issue.

Issue 9252: Page 45 and 165 (mof-qvt-ftf)

Click here for this issue's archive.
Source: Hewlett-Packard (Ms. Susan Entwisle, susan.entwisle(at)eds.com)
Nature: Uncategorized Issue
Severity:
Summary:

the naming and diagram conventions should be introduced before they are used in Section 9.11 and 11.7, respectively

Resolution: In the introductory text of section 7.11 and sections 9.7 add the following paragraph (similar to paragraph found in 8.2): """ The metaclasses imported from other packages are shaded and annotated with 'from <package-name>' indicating the original package where they are defined. The classes defined specifically by the two packages of the QVT Operational formalism are not shaded. Within the class descriptions, metaclasses and meta-properties of the metamodel are rendered in courier font. Courier font is also used to refer to identifiers used in the examples. Keywords are written in bold face. Italics are freely used to emphasize certain words, such as specific concepts, it helps understanding. However that emphasis is not systematically repeated in all occurrences of the chosen word. """ NOTE (Correction of typo after AB review): When applying the change in section 7.11, "the two packages of the QVT Operational" should be replaced by "the packages of the QVT Relation". When applying the change in section 9.7 it should be "the packages of the QVT Core".
Revised Text:
Actions taken:
January 19, 2006: received issue
November 7, 2007: closed issue

Issue 9253: Page 117 (mof-qvt-ftf)

Click here for this issue's archive.
Source: Hewlett-Packard (Ms. Susan Entwisle, susan.entwisle(at)eds.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section 10.2.2.6 ForExp is missing from the class diagram in Section 10.2.2 The ImperativeOCL Package

Resolution: closed no change
Revised Text:
Actions taken:
January 19, 2006: received issue
November 7, 2007: closed issue

Discussion:

ForExp is already present in Figure 8.4. Because there is no
specific relation for this class there is no need to repeat its definition
in another diagram.

Issue 9254: Page 118 (mof-qvt-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Section 10.2.2.7 ImperativeIterateExp is missing from the class diagram in Section 10.2.2 The ImperativeOCL Package

Resolution: In Figure 8.4 and Figure 8.5, rename CollectorExp as ImperativeIterateExp (because CollectorExp is in fact an old name for ImperativeIterateExp).
Revised Text:
Actions taken:
January 19, 2006: received issue
November 7, 2007: closed issue

Issue 9255: Page 131 (mof-qvt-ftf)

Click here for this issue's archive.
Source: Hewlett-Packard (Ms. Susan Entwisle, susan.entwisle(at)eds.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section 10.2.2.24 third sentence �In the perspective of the runtime environment a typedef is never instantiated� appears to be redundant as the same intent is expressed in second sentence �A typedef is never instantiated�

Resolution: In Section 8.2.2.24, remove the sentence "A Typedef is never instantiated"
Revised Text:
Actions taken:
January 19, 2006: received issue
November 7, 2007: closed issue

Issue 9379: Incorrect composition of variables in patterns (mof-qvt-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

In QVTBase package, the association 'Pattern::bindsTo'
cannot be composition since variables in relations
specifications are owned by Relations and because
variables can be bound to more than one pattern.
The same applies for 'TemplateExp::Variable' in QVTRelation
package which should not be a composition.


Suggested resolution:
Change the property definitions as: 
  'Pattern::bindsTo : [*] Variable opposites pattern [*]'
  'TemplateExp::bindsTo : [0..1] Variable opposites pattern [*]
If needed add OCL well-formedness in QVT Core to restrict
multiplicity.

Resolution: (1) In 7.11.1.6, replaces "bindsTo: Variable [*] {composes}" by "bindsTo: Variable [*]" and in Figure 7.5 removes the corresponding composition symbol (2) In 7.11.2.1 replaces "bindsTo: Variable [0..1] {composes}" by "bindsTo: Variable [0..1]" and in Figure 7.6 removes the corresponding composition symbol
Revised Text:
Actions taken:
February 13, 2006: received issue
November 7, 2007: closed issue

Issue 9380: Revise the encoding of primitive domains (mof-qvt-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

Primitive domains are simpler than other relation domains
since they do are not dependent on a given typed model
(primitive types are available to all metamodels) and there
is no need to refer to a template expression. 
In QVTBase package, the multiplicity of Domain::typedModel
should be '0..1' instead of '1' to avoid an arbitrary assignment
to model typed model for the primitive diomain. In addition
the multiplicity of RelationDomain-Pattern association should
be changed to 0..1.

Resolution: (1) In Section 7.11.1.3, replace "typedModel: TypedModel [1]" by "typedModel: TypedModel [0..1]" In figure 7.4 change the corresponding multiplicity. (2) In 7.11.3.2, replace "/typedModel: TypedModel [1] (from Domain)" by "/typedModel: TypedModel [0..1] (from Domain)" and replace "pattern: DomainPattern [1] {composes}" by "pattern: DomainPattern [0..1] {composes}" Make the corresponding change in figure 7.7.
Revised Text:
Actions taken:
February 13, 2006: received issue
November 7, 2007: closed issue

Issue 9381: Bad navigability in cross-package links (mof-qvt-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

The reverse link from Transformation to Tag should become
not navigable. Otherwise there is a dependency between EMOF
and QVTBase packages.
In the QVTOperational package the same stands for navigability:
   The opposite role 'owner' of Module::ownerTag
   The opposite role 'module' of Module::configProperty
   The opposite role 'tryBodyOwner' of TryExp::tryBody
   The opposite role 'computeOwner' of ComputeExp::returnedE

Resolution: (1) In Figure 7.4 make unidirectional the link Transformation::ownedTag (2) In Figure 8.1 make unidirectional the link Module::ownedTag make unidirectional the link Module::configProperty (3) In Figure 8.6 make unidirectional the link TryExp::tryBody (4) In Figure 8.5 make unidirectional the link ComputeExp::returnedElement
Revised Text:
Actions taken:
February 13, 2006: received issue
November 7, 2007: closed issue

Issue 9382: Typo error for properties whenOwner and whereOwner (mof-qvt-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

In the QVTBase diagram 'whenOwner' should be the opposite
property of 'when' and 'whenOwner' the opposite property of
when. Currently this is reverted.

Resolution: In figure 7.7, replace 'whenOwner' by 'whereOwner' and 'whereOwner' by 'whenOwner'
Revised Text:
Actions taken:
February 13, 2006: received issue
November 7, 2007: closed issue

Issue 9383: RelationalTransformation as a subclass of Transformation (mof-qvt-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

To avoid dependency of QVTBase to QVTRelation due to the fact
that a relational transformation contains QVTRelation::Keys
Instances, the Transformation metaclass should be subtyped
within the QVTRelations package.
By the way, the association between relational transformations
and Keys is missing in the metamodel and need to be added.



Suggestion: Add a RelationalTransformation metaclass inheriting
from  Transformation and add the missing association:
   'RelationalTransformation::key : [*] Key {composes}'
Correct the type of OperationalTransformation:refined so that
it is a RelationalTransformation (instead of 'Transformation')

Resolution: (1) In section 7.11.3 insert the definition of the "RelationTransformation" class with the following description: """ A RelationalTransformation is a specialization of a Transformation representing a transformation definition that uses the QVT-Relation formalism. Superclasses Transformation (from BaseQVT) Associations key : [*] Key {composes} The keys defined within this transformation. """ (2) In Figure 7.7 inserts the class "RelationTransformation" inheriting from "Transformation" and adds the link to the "Key" class
Revised Text:
Actions taken:
February 13, 2006: received issue
November 7, 2007: closed issue

Issue 9384: RelationalTransformation as a subclass of Transformation (mof-qvt-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

To avoid dependency of QVTBase to QVTRelation due to the fact
that a relational transformation contains QVTRelation::Keys
Instances, the Transformation metaclass should be subtyped
within the QVTRelations package.
By the way, the association between relational transformations
and Keys is missing in the metamodel and need to be added.



Suggestion: Add a RelationalTransformation metaclass inheriting
from  Transformation and add the missing association:
   'RelationalTransformation::key : [*] Key {composes}'
Correct the type of OperationalTransformation:refined so that
it is a RelationalTransformation (instead of 'Transformation')

Resolution: duplicate of issue 9383, close
Revised Text:
Actions taken:
November 7, 2007: closed issue

Issue 9385: isTopLevel should not be a derived property (mof-qvt-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

For implementers discovering whether a relation is a top
level relation may be nighmare. It would be preferible that
this property be a "pain" property (not derived). This will
be aligned with the concrete syntax where the 'top' keyword
is explicitly set.

Resolution: (1) In 7.11.3.1, replace "/isTopLevel : Boolean" by "isTopLevel : Boolean". and remove the sentence "This is a derived attribute." (2) In Figure 7.7 replace "/isTopLevel" by "isTopLevel"
Revised Text:
Actions taken:
February 13, 2006: received issue
November 7, 2007: closed issue

Issue 9386: Entry operations in operational definitions (mof-qvt-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

For models that have a well identified "root" element and type,
it makes sence to designate a mapping operation on the root
type to be the entry of the transformation. Currently this is not
possible. 


Suggestion:
Replace the 'OperationalTransformation::entry : EntryOperation' 
association by a more general 'Module::entry : Operation'

Resolution: In Section 8.2.1.1 (OperationalTransformation), remove the association "entry : EntryOperation [0..1]" and in Section 8.2.1.3 (Module) inserts the association "entry : Operation [0..1]". In Figure 8.1, make the corresponding move of the 'entry' link.
Revised Text:
Actions taken:
February 13, 2006: received issue
November 7, 2007: closed issue

Issue 9387: Typo error ImperativeIteratorExp expected in diagram (mof-qvt-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

The diagram refers to a CollectorExp undefined class. In fact
This class is the ImperativeIteratorExp found in the class
description

Resolution: Duplicate of issue 9254, close
Revised Text:
Actions taken:
February 13, 2006: received issue
November 7, 2007: closed issue

Issue 9388: Missing association from MappingParameter to a ModelParameter (mof-qvt-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

Non primitive MappingParameters are related to ModelParameters
but the the association is missing in the metamodel. Also, when
The information cannot be infered from the parameter types
there is no way to indicate this when using the textual syntax.
Suggestion:
Add the association
'MappingParameter::extent : [0..1] ModelParameter'
For the concrete syntax, use the '@' character:
  mymappingparameter:MyType@mymodelparameter
Usage of this notation should not be mandatory when the model
type can be automatically infered from the parameter type.

Resolution: (1) In Section 8.2.1.16 (MappingParameter) add the association: """ extent : ModelParameter [0..1] The extent of the mapping parameter. Should be explicitly provided when there is an ambiguity on the extent that will own a potential created element corresponding to this parameter. """ (2) In the same section 8.2.1.16, add the "Notation" subtitle as follows: """ Notation The extent of a mapping parameter can be provided explicitly using its name as the scope prefix of its type, using the "::" symbol. The declarator has the form: mymappingparameter : myextent::MyType. It is not mandatory to provide the extent when it can be inferred from the type. Example: transformation T(in src:S, out dest1:D, out dest2:D); mapping X::foo(inout dest1::Y) : dest2:Y; // 'X' is a class of 'S' metamodel and 'Y' is a class of 'D' metamodel """ Remark: No changes are needed in the grammar since the 'declarator' rule already supports this syntax. (3) In Figure 8.1, add the correspond link between MappingParameter and ModelParameter. (4) In Section 8.2.1 (ObjectExp), within the "Notation" subtitle, replace: """When provided the model parameter is notated within brackets after the object keyword. object[srcmodel] x:X { ... } // x is created within the 'srcmodel """ by: """When an explicit extent is provided, the variable name prefixes the type of the object expression using the "::" symbol. object x: srcmodel::X { ... } // x is created within the 'srcmodel """ (this change is required for consistency with mapping parameter notation). (5) In Section 8.2.2.23 (InstantiationExp), within the "Notation" subtitle, replace: """ When provided the extent is notated by adding the variable name in brackets after the new keyword. column := new [mymodel] Column(n,t); // mymodel is the extent for the new instance. """ by: """When an explicit extent is provided, the variable name prefixes the type of the instantiation expression using the "::" symbol. column := new mymodel::Column(n,t); // mymodel is the extent for the new instance. """
Revised Text:
Actions taken:
February 13, 2006: received issue
November 7, 2007: closed issue

Issue 9389: Missing variable references within inlined object expressions (mof-qvt-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

Inlined ObjectExp have no explicit result variable. Nevertheless
An implicit variable is needed so that the representation of property
access within the body of ObjectExp is consistent.
These variables need to exist somewhere and so a container for these
implicit variables is needed.


Suggestion:
Adding the association:
  OperationBody::variable : [*] Variable {composes}
And make the multiplicity of ObjectExp::referredObject equal to '1'

Resolution: (1) In Section 8.2.1.17 (OperationBody), add the association """ variable : [*] Variable {composes} The variables defined implicitly within this operation body. This concerns implicit variables in object expressions (ObjectExp). """ (2) In Section 8.2.1.24, replace "referredObject: Variable [0..1]" by "referredObject: Variable [1]" (3) In figure 8.2 add the "OperationBody::variable Variable" unidirectional link (4) In figure 8.3 change multiplicity of ObjectExp::referredObject to '1'.
Revised Text:
Actions taken:
February 13, 2006: received issue
November 7, 2007: closed issue

Issue 9390: Missing iterator variable in resolve expressions (mof-qvt-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

A resolution operator implies iteration over the list of objects
transformed from a source element. However no iteration variiable
is represented.


Suggestion:
Define ResolveExp as a subclass of ImperativeLoopExp. 
As a consequence, the field ResolveExp::condition can be
removed (since already contained by ImperativeLoopExp)

Resolution: NOTE: This resolution should not be applied since superseded by resolution 10925. A Resolution operator implies iteration over the list of objects transformed from a source element. However no iteration variiable is represented. RESOLUTION: (1) In Section 8.2.1.22 (ResolveExp), define ResolveExp as a subclass of ImperativeLoopExp by replacing "CallExp" by "ImperativeLoopExp". (2) In the same section 8.2.1.22, remove the association 'condition' (since already contained by ImperativeLoopExp) (3) In Figure 8.3, remove the link ResolveExp::condition and replaces inheritance of ResolveExp so that it inherits from "ImperativeLoopExp"
Revised Text:
Actions taken:
February 13, 2006: received issue
November 7, 2007: closed issue

Issue 9391: Missing multiplicity of AnonymousLiteralPart::value (mof-qvt-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

The multiplicity of AnonymousLiteralPart::value is not indicated
in the diagram. It should be equal to 1.

Resolution: In Figure 8.7, indicate the multiplicity of AnonymousLiteralPart::value to be equal to "1".
Revised Text:
Actions taken:
February 13, 2006: received issue
November 7, 2007: closed issue

Issue 9392: When and where clause for mapping operations (mof-qvt-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

Reusing the 'when' and 'where' clauses of the refined relation
of a mapping operation to represent the 'when' and 'where' clauses
of the mapping operation is semantically not very accurate since
there are some differencies. Should better have their own
representation.


Suggestion: add specifics MappingOperation::when and
MappingOperation::where associations.

Resolution: (1) In Section 8.2.1.15, add the associations MappingOperation::when and MappingOperation::where with the following descriptions: when : OclExpression [0..1] The pre-condition or the guard of the operational mapping. It acts as a pre-condition when the operation is called with strict semantics, it acts as a guard otherwise (see MappingCallExp) where : OclExpression [0..1] The post condition for the operational mapping. (2) In Section 8.2.1.15, in the introductory part, replaces "The when clause in the refined relation acts ..." by "The when clause acts ..." and "The where clause in the refined relation always acts as a post-condition " by "The where clause always acts as a post-condition "
Revised Text:
Actions taken:
February 13, 2006: received issue
November 7, 2007: closed issue

Issue 9393: Inconsistency of multiplicity of ImperativeIterateExp::target (mof-qvt-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

According to the class description the multiplicity of
ImperativeIterateExp::target should be [0..1] not 1 in
the diagram view.

Resolution: In Figure 8.5, replace the multiplicity of role target:Variable to '0..1' (instead of '1').
Revised Text:
Actions taken:
February 13, 2006: received issue
November 7, 2007: closed issue

Issue 9394: Logging textual messages that depend on variables (mof-qvt-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

He current representation of LogExp does not allow output
messages that are variable dependent. This is not realistic.
We should use here ordinary argument representation to encode
The text of the message and the level.


Suggestion: LogExp defined as a subclass of OperationCallExp.
The 'text', 'level' and 'element' fields can therefore be removed
since encoded as positional arguments.

Resolution: RESOLUTION (1) In Section 8.2.2.18 (LogExp) before "A log expression returns null" adds the following paragraph. "A log expression is a kind of operation call expression where the first argument contains the message to be print, the second argument gives the model element to be print (using an implict call to the 'who' operation from the QVT Standard Library) , and the third argument gives a level number for the log. Only the first argument is mandatory. (1) In Section 8.2.2.18 (LogExp) change the superclasses list by replacing 'ImperativeExpression' by 'OperationCallExp'. (2) In Section 8.2.2.18, remove the properties 'text', 'level' and 'element' (3) In Figure 8.6, change the inheritance of LogExp to OperationCallExp, remove 'text' and 'level' attributes and remove 'element' link.
Revised Text:
Actions taken:
February 23, 2006: received issue
November 7, 2007: closed issue

Issue 9397: QVT Issue: Support for CMOF metamodels (mof-qvt-ftf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

The QVT spec (ptc/05-11-01) is littered with references to EMOF but has not one reference to CMOF.
Hence it's not clear whether QVT can be used to transform models that instantiate CMOF metamodels. This is a major requirement since UML2 is itself a CMOF metamodel.
 
Note that it's not important here that the QVT metamodel itself is expressed only in EMOF: but that it can be applied to CMOF metamodels. This means that references such as ObjectTemplateExp::referredClass(from EMOF) (see Fig 7.6) should also support references to CMOF metaclasses. Though CMOF is a compatible extension of EMOF, it is important that the QVT specification makes it clear that references to CMOF classes must be supported and that compliant QVT engines should not lose information when they transform models for CMOF metamodels. This is also likely to requires changes to the specification logic that describes the execution of transformations - for example to fully support non-unique Associations.

Resolution: (1) Add a new top-level section named "QVT for CMOF" with the following content: For the sake of simplicity all previous chapters assume QVT used in the context of EMOF conformant metamodels. However this specification is also applicable to CMOF metamodels with a few restrictions. 11.1 The QVT metamodel for CMOF The QVT metamodel for CMOF is a CMOF metamodel that is obtained by executing the following steps: The EMOF package is replaced by the CMOF Package. All other packages - including the EssentialOCL - are cloned, with the exception that all references to the original EMOF metaclasses are replaced by references to the corresponding CMOF metaclass. 11.2 Semantic specificities The semantics of CMOF concerning the access and the modification of properties replaces the semantics of EMOF. For instance, in CMOF, setting a property that is specified as an association end implies that the corresponding association link instance is created and that any related sub-setted association is updated accordingly. There are some limitations when using QVT on CMOF metamodels which comes from the fact that we are cloning EssentialOCL - at the time being, the OCL specification does not define an "OCL for CMOF metamodels". - It is not possible to refer directly to an association; instead an association has to be accessed as a property from one of the owning classes. However, this does not address the case where both the ends of an association are owned by the association itself. (2) In the Compliance section 2, add a sub-section named "EMOF and CMOF compliance" after Section 2.3 Interoperability Dimension with the following content: A QVT tool may declare to be EMOF-compliant or CMOF-compliant (possibly both) depending on the kind of models that it is capable of working with. The same dimensions serving to characterize QVT-EMOF compliant implementations (in Figure 2.1) are applicable to QVT CMOF-compliant implementations. Note however that the XMI for an EMOF-compliant QVT tool is not the same as the XMI for a CMOF-compliant QVT tool since the XMI generation rules for CMOF are distinct from the corresponding generation rules for EMOF.
Revised Text:
Actions taken:
February 24, 2006: received issue
November 7, 2007: closed issue

Issue 9414: Section: 8/2 (mof-qvt-ftf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

Typographic errors: - Character � appears in several pages: 13, 14, 15, 17, 18, 22, ... - Bad indented in page 15: namespace = p:Package {}, in page 16: primaryKey = k:PrimaryKey {...} in page 22: c1: Class, a1: Attribute l1: attrs (c1, a1) in page 36: <varDeclaration>* in page 37: | (<oclExpressionCS> ';')* - At page 71: "...expressions that is executed is sequence." it should say: "...expressions that is executed in sequence." - At page 71: "He self variable..." it should say: "The self variable ..." - At page 78: "An explicit usage of the population ...required is certain situations ..." it should say: "An explicit usage of the population ...required in certain situations ..." - At page 91: "Tre endif keyword ..." it should say: "The endif keyword ..." - Bad format in page 22: 7.10.3.3 (see font of 7.10.3.2) in page 23: 7.10.3.4 (see font of 7.10.3.2) - In figure 7.4 (page 26) the class Domain must be written in italic. The class Domain is abstract. - In figure 7.4 (page 26) the class Rule must be written in italic. The class Rule is abstract. - In page 49 at expression: name:=self.name;type:=getSqlType(self.type) missing a space between name and type - At page 88: "...it has four pre-defined variants named xcollect..." it should say: "...it has five pre-defined variants named xcollect..." - At page 110: "...beginning and the end of the srings and..." it should say: "...beginning and the end of the strings and..." - At page 112: "...comment delimited by "--" and the end of file" it should say: "...comment delimited by "--" and the end of line" - At page 112: "...comment delimited by "//" and the end of file" it should say: "...comment delimited by "//" and the end of line"

Resolution: (1) Replace Character � occurrences in all pages (2) Correct bad indentation : in page 15: namespace = p:Package {}, in page 16: primaryKey = k:PrimaryKey {...} in page 22: c1: Class, a1: Attribute l1: attrs (c1, a1) in page 36: * in page 37: | ( ';')* (3) Perform the following text substitutions: - At page 71: "...expressions that is executed is sequence." it should say: "...expressions that is executed in sequence." - At page 71: "He self variable..." it should say: "The self variable ..." - At page 78: "An explicit usage of the population ...required is certain situations ..." it should say: "An explicit usage of the population ...required in certain situations ..." - At page 91: "Tre endif keyword ..." it should say: "The endif keyword ..." - At page 88: "...it has four pre-defined variants named xcollect..." it should say: "...it has five pre-defined variants named xcollect..." - At page 110: "...beginning and the end of the srings and..." it should say: "...beginning and the end of the strings and..." - At page 112: "...comment delimited by "--" and the end of file" it should say: "...comment delimited by "--" and the end of line" - At page 112: "...comment delimited by "//" and the end of file" it should say: "...comment delimited by "//" and the end of line" (4) Perform the following formatting corrections: - Bad format in page 22: 7.10.3.3 (see font of 7.10.3.2) in page 23: 7.10.3.4 (see font of 7.10.3.2) - In figure 7.4 (page 26) the class Domain must be written in italic. The class Domain is abstract. - In figure 7.4 (page 26) the class Rule must be written in italic. The class Rule is abstract. - In page 49 at expression: name:=self.name;type:=getSqlType(self.type) missing a space between name and type.
Revised Text:
Actions taken:
March 11, 2006: received issue
November 7, 2007: closed issue

Issue 9415: Section: 7/11 (mof-qvt-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

CollectionKind not defined in this document in kind: CollectionKind

Resolution: IN section 7.11.2 insert the enumeration type CollectionKind with the following definition: """ CollectionKind (from EssentialOcl) The enumeration type that provides all the kind of collections. Possible values are: Set, Sequence, Bag and OrderedSet., """
Revised Text:
Actions taken:
March 11, 2006: received issue
November 7, 2007: closed issue

Issue 9417: Section: 8/2 (mof-qvt-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

enforcedDirection not defined in this document enforcedDirection: ModelParameter [0..1]

Resolution: In Figure 8.1 add the missing link 'OperationalTransformation:enforcedDirection : ModelParameter [0..1]'
Revised Text:
Actions taken:
March 14, 2006: received issue
November 7, 2007: closed issue

Issue 9418: Section: 8/2 page 79 (mof-qvt-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

isScoped not defined in this document in "Unless isScoped is true...". It should be isVirtual (see Figure 8.3)

Resolution: In section 8.2.1.20, replace "Unless isScoped..." by "Unless isVirtual". Also, in the Attributes subtitle, replace 'virual' by 'isVirtual'.
Revised Text:
Actions taken:
March 14, 2006: received issue
November 7, 2007: closed issue

Issue 9419: Section: 7/13 (mof-qvt-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Figure 16 does not exists In the first line at page 42: "...of relations. Figure 16 ..." must be Figure 7.13. Also, at same page: "The textual specification ... to Figure 16 is ..." must be Figure 7.13.

Resolution: Modify the text to replace the two references to Figure 16 with references to Figure 7.13. More precisely, in page 42, replace "Figure 16 specifies a strange relation � " by "Figure 7.13 specifies a strange relation � " and replace "The textual specification corresponding to Figure 16 �" by "The textual specification corresponding to Figure 7.13 �".
Revised Text:
Actions taken:
March 14, 2006: received issue
November 7, 2007: closed issue

Issue 9420: Section: 8/1 (mof-qvt-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Pim2Psm or PimToPsm ? At page 57: "The example below ... Pim2Psm transformation ..." "transformation PimToPsm (...)"

Resolution: In Section 8.1.18, Replace all occurences of Pim2Psm as PimToPsm.
Revised Text:
Actions taken:
March 14, 2006: received issue
November 7, 2007: closed issue

Discussion:

Issue 9421: Section: 8/2 page 88 (mof-qvt-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

ImperativeIterateExp should be named CollectorExp see Figures 8.4 and 8,5 (page 88)

Resolution: Duplicate of issue 9254
Revised Text:
Actions taken:
March 14, 2006: received issue
November 7, 2007: closed issue

Issue 9422: Section: 8/2 page 95 (mof-qvt-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

BreakExp (8.2.2.16) and ContinueExp (8.2.2.17) at page 95 are missing in the Figures 8.5 and 8.6

Resolution: close, no change
Revised Text:
Actions taken:
March 14, 2006: received issue
November 7, 2007: closed issue

Discussion:

BreakExp and ContinueExp are already defined in Figure 8.4.
Because there are no additional properties for these classes, they
are not repeated in the other figures.

Issue 9423: Section: 8/2 page 99 (mof-qvt-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

In the class InstantiationExp, the associations (page 99) are missing. It should be (see Figure 5): argument: OclExpression [*] {composes, ordered} extent: Variable [0..1] instantiatedClass: Class [1]

Resolution: In Section 8.2.2.23 (InstantiationExp) add the following Associations definitions: """ Associations argument: OclExpression [*] {composes, ordered} The arguments of the instantiation expression. Should correspond with the initialisation operation for the class (which by default is implicit and has no arguments). extent: Variable [0..1] The extent on which the new object is created. instantiatedClass: Class [1] The type of the object to be created. """
Revised Text:
Actions taken:
March 14, 2006: received issue
November 7, 2007: closed issue

Issue 9424: Section: 8/3 page 110 (mof-qvt-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

The signature of String::lastToUpper (): String (page 110) is not sound with its definition. "Converts the first character in ..." it should say: "Converts the last character in ..."

Resolution: Replaces "Converts the first character in ..." as "Converts the last character in ..." NOTE (Correction of typo after AB review): Replaces "Converts the first character in the string to a lowercase character" by: "Converts the last character in the string to a uppercase character"
Revised Text:
Actions taken:
March 14, 2006: received issue
November 7, 2007: closed issue

Issue 9425: Section: 8/3 page 110 (02) (mof-qvt-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

The definition of String::replace operation (page 110) is incomplete: the operation return a new string (as in OCL 2) or return the string modified ?

Resolution: Add the sentence: "The operation returns a new string."
Revised Text:
Actions taken:
March 14, 2006: received issue
November 7, 2007: closed issue

Issue 9426: Section: 8/3 page 110 (03) (mof-qvt-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

The definition of String::unquotify operation (page 110) is incomplete: if the string s not exists at begin or at end ?

Resolution: Adds the sentence: "if the string s does not appear at the beginning or at the end, the content of string s is returned". NOTE (Correction of typo after AB review): There is a typo error in the sentence to be added. The sentence to be added should be: "if the string s does not appear at the beginning or at the end, the content of source string is returned".
Revised Text:
Actions taken:
March 14, 2006: received issue
November 7, 2007: closed issue

Issue 9427: Section: A.2.2 (mof-qvt-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Errors in the A.2.2 Encapsulation Example (page 172) - The strings "private", "get_", "set_", "public" and "in" should be 'private', 'get_', 'set_', 'public' and 'in' - The operation upperFirst() should be written firstToUpper (see page 110)

Resolution: (1) In A.2.2, Replace 'upperFirst' by 'firstToUpper'. (2) In Section 8.4 (Concrete Syntax), after 8.4.2 Comments section, insert a new section called "Strings" with the following content. """ Literal strings that fit in a single line are delimited either by single quotes or by double quotes. Literal string that fit in multiple lines can be notated as a list of literal strings. Example: var s:String = 'This is a long string' 'that fits in two lines'; All the usual escape characters using backslash can be used including the '\n' return-line character. """
Revised Text:
Actions taken:
March 14, 2006: received issue
November 7, 2007: closed issue

Issue 9428: Section: 8/2 page 70 (mof-qvt-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Association result of the ImperativeOperation class should be (see figure 8.2) result: VarParameter [*] {composes, ordered} Association body of the ImperativeOperation class should be (see figure 8.2) body: OperationBody [0..1] {composes}

Resolution: In Section 8.2.1.10 (ImperativeOperation), replace "result: VarParameter [*] {composes}" by "result: VarParameter [*] {composes, ordered}" and replace "body: OperationBody [0..1] {composes, ordered}" by "body: OperationBody [0..1] {composes}" NOTE (FIXES after AB Review) Additional omissions concerning the {composes} and {ordered} indications in property definitions where detected (when comparing to diagrams). The following resolutions should also be applied - Add the missing {composes} indication for the following defined properties (within the class descriptions): ImperativeOperation::context , Constructor::/body, ResolveExp::condition, BlockExp::body, WhileExp::condition, WhileExp::body, ImperativeLoopExp::condition, ForExp::/condition, ForExp::body, ForExp::source, ImperativeIterateExp::/condition, ImperativeIterateExp::/body, ImperativeIterateExp::/iterator, ImperativeIterateExp::/source, SwitchExp::elsePart, AltExp::condition, AltExp::body, VariableInitExp::referredVariable, UnpackExp::source - Add the missing {ordered} indication for the following defined properties (within the class descriptions): MappingOperation::inherited, MappingOperation::merged, MappingOperation::disjunct, BlockExp::body,ImperativeIterateExp::iterator, ComputeExp::returnedElement
Revised Text:
Actions taken:
March 14, 2006: received issue
November 7, 2007: closed issue

Issue 9429: Section: 8/2 page 79 (mof-qvt-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

The attribute virtual of the ImperativeCallExp should be named (see Figure 8.3) isVirtual "...depending on the value of the strict Boolean property." it should say: "...depending on the value of the isStrict Boolean property." (see Figure 8.3) "The latter keyword is used when strict is true" it should say: "The latter keyword is used when isStrict is true" (see Figure 8.3)

Resolution: In Section 8.2.1.21, replace all occurrences of "strict" word by "isStrict".
Revised Text:
Actions taken:
March 14, 2006: received issue
November 7, 2007: closed issue

Issue 9430: Section: 8/2 page 86 (mof-qvt-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Association returnedElement of the ComputeExp class should be (see figure 8.5) returnedElement : Variable [1]

Resolution: In Section 8.2.2.3 (ComputeExp) replace "returnedElement : TypedElement [1]" by "returnedElement : Variable [1]"
Revised Text:
Actions taken:
March 14, 2006: received issue
November 7, 2007: closed issue

Issue 9431: Section: 8/2 page 91 (mof-qvt-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Association elsePart of the SwitchExp class should be (see figure 8.5) elsePart: OclExpression [0..1]

Resolution: In Section 8.2.2.8 (SwitchExp) replace "elsePart : Expression [0..1]" by "elsePart : OclExpression [0..1]"
Revised Text:
Actions taken:
March 14, 2006: received issue
November 7, 2007: closed issue

Issue 9432: Section: 8/2 page 92 (mof-qvt-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

the attribute withReturn of the VariableInitExp class should be named withResult (see Figure 8.6) "...is notated using ':=' if withReturn property..." it should say: "...is notated using ':=' if withResult property..." (see Figure 8.6) "...uses '::=' if withReturn is true." it should say: "...uses '::=' if withResult is true." (see Figure 8.6)

Resolution: In Section 8.2.2.10 5VariableInitExp), replace all occurrence of word 'withResult' by 'withReturn'. Note (Responding AB review feedback): There is a typo error in resolution text: we should read " replace all occurrence of word 'withReturn' by 'withResult'. This is consistent with Fig 8.6 (VariableInitExp::withResult defined) - which is left unchanged by the resolution - and also consistent with the summary text of the issue.
Revised Text:
Actions taken:
March 14, 2006: r5eceived issue
November 7, 2007: closed issue

Issue 9433: Section: 8/2 page 93 (mof-qvt-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Association value of the AssignExp class should be (see figure 8.6) value: OclExpression [*] {composes} Association left of the AssignExp class should be (see figure 8.6) left: OclExpression [1] {composes} Association defaultValue of the AssignExp class should be (see figure 8.6) defaultValue: OclExpression [0..1] {composes} Association item of the UnlinkExp class should be (see figure 8.6) item: OclExpression [1] {composes}

Resolution: In Section 8.2.2.11 (UnlinkExp) - replace "value: OclExpression [*]" by "value: OclExpression [*] {composes}" - replace "left: OclExpression [1]" by "left: OclExpression [1] {composes} " - replace "defaultValue: OclExpression [0..1]" by "defaultValue: OclExpression [0..1] {composes} " - replace "item: OclExpression [1]" by "item: OclExpression [1] {composes}"
Revised Text:
Actions taken:
March 14, 2006: received issue
November 7, 2007: closed issue

Issue 9434: Section: 8/2 page 94 (mof-qvt-ftf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Association target of the UnlinkExp class should be (see figure 8.6) target: OclExpression [1] {composes} Association tryBody of the TryExp class should be (see figure 8.6) tryBody: OclExpression [1] {composes} Association exceptBody of the TryExp class should be (see figure 8.6) exceptBody: OclExpression [0..1] {composes}

Resolution: In Section 8.2.2.12 (UnlinkExp) - replace "target: OclExpression [1]" by "target: OclExpression [1] {composes}" - replace "tryBody: OclExpression [1]" by "tryBody: OclExpression [1] {composes}" - replace "exceptBody: OclExpression [0..1]" by "exceptBody: OclExpression [0..1] {composes}"
Revised Text:
Actions taken:
March 14, 2006: received issue
November 7, 2007: closed issue

Issue 9435: Section: 8/2 page 95 (mof-qvt-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Association value of the ReturnExp class should be (see figure 8.6) value: OclExpression [1] {composes}

Resolution: In Section 8.2.2.15 (ReturnExp) - replace "value: OclExpression [1]" by "value: OclExpression [1] {composes}"
Revised Text:
Actions taken:
March 14, 2006: received issue
November 7, 2007: closed issue

Issue 9436: Section: 8/2 (mof-qvt-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Association assertion of the AssertExp class should be (see figure 8.6) assertion: OclExpression [1] {composes} Association log of the AssertExp class should be (see figure 8.6) log: LogExp [0..1] {composes}

Resolution: In Section 8.2.2.19 (AssertExp) - replace "assertion: OclExpression [1]" by "assertion: OclExpression [1] {composes} " - replace "log: LogExp [0..1]" by "log: LogExp [0..1] {composes}"
Revised Text:
Actions taken:
March 14, 2006: received issue
November 7, 2007: closed issue

Discussion:

Issue 9437: Section: 8/2 page 97 (mof-qvt-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Association element of the TupleExp class should be (see figure 8.6) element: OclExpression [1..*] {composes} Association variable of the UnpackExp class should be (see figure 8.6) variable: Variable [1..*] {composes}

Resolution: In Section 8.2.2.21 (TupleExp) - replace "element: OclExpression [1..*]" by "element: OclExpression [1..*] {composes} " - replace "variable: Variable [1..*]" by "variable: Variable [1..*] {composes}" Note: This resolution should not applied since it is superseded by issue 11061 (which removes the TupleExp metaclass).
Revised Text:
Actions taken:
March 14, 2006: received issue
November 7, 2007: closed issue

Issue 9438: Section: 8/2 page 98 (mof-qvt-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Association variable of the UnpackExp class should be (see figure 8.6) variable: Variable [1..*] {composes}

Resolution: In Section 8.2.2.22 (UnpackExp) - replace "variable: Variable [1..*]" by "variable: Variable [1..*] {composes}"
Revised Text:
Actions taken:
March 14, 2006: received issue
November 7, 2007: closed issue

Issue 9439: Section: 8/2 page 99 (mof-qvt-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Association condition of the Typedef class should be (see figure 8.7) condition: OclExpression [1] {composes}

Resolution: In Section 8.2.2.24 (Typedef) - replace "condition: OclExpression [1]" by "condition: OclExpression [1] {composes}"
Revised Text:
Actions taken:
March 14, 2006: received issue
November 7, 2007: closed issue

Issue 9440: Section: 8/2 page 101 (mof-qvt-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Association elementType of the AnonymousTupleType class should be (see figure 8.7) elementType: Type [*] Association part of the DictLiteralExp class should be (see figure 8.7) part: DicLiteralPart [*] {composes}

Resolution: (1) In Figure 8.7, add the {ordered} constraint to the AnonymousTupleType::elementType type. (2) In Section 8.2.2.29 (DictLiteralExp) - replace "part: OclExpression [1] {composes}" by "part: DicLiteralPart [*] {composes}"
Revised Text:
Actions taken:
March 14, 2006: received issue
November 7, 2007: closed issue

Discussion:

 The {ordered} constraint is in fact mising in the figure.

Issue 9441: Section: 8/2 page 102 (mof-qvt-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Association part of the AnonymousTupleLiteralExp class should be (see figure 8.7) part: AnonymousTupleLiteralPart [*] {composes, ordered}

Resolution: In Section 8.2.2.31 (AnonymousTupleLiteralExp) - replace "part : OclExpression [1] {composes}" by "part: AnonymousTupleLiteralPart [*] {composes, ordered}"
Revised Text:
Actions taken:
March 14, 2006: received issue
November 7, 2007: closed issue

Issue 9442: Section: 9/17 page 132 (mof-qvt-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Association local of the Mapping class should be (see figure 9.2) local: Mapping [*]

Resolution: (1) In figure 9.2, add the missing composition symbol for the association (Mapping::local : Mapping)
Revised Text:
Actions taken:
March 14, 2006: received issue
November 7, 2007: closed issue

Issue 9443: Section: 9/17 page 134 (mof-qvt-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Association slotExpression of the Assignment class should be (see figure 9.3) slotExpression: OclExpression [1] {composes} Association value of the Assignment class should be (see figure 9.3) value: OclExpression [1] {composes}

Resolution: In Section 9.17.8 (Assignment) - replace "slotExpression: OclExpression [1]" by "slotExpression: OclExpression [1] {composes}" - replace "value: OclExpression [1]" by "value: OclExpression [1] {composes} "
Revised Text:
Actions taken:
March 14, 2006: received issue
November 7, 2007: closed issue

Issue 9463: variable-assignment isn't defined in Core language (mof-qvt-ftf)

Click here for this issue's archive.
Source: Modeling Value Group (Mr. Wim Bast, wim.bast(at)modelingvalue.nl)
Nature: Uncategorized Issue
Severity:
Summary:

There exist assignments to variables in the QVT examples.

However, variable-assignment is not defined in the abstract and concrete syntax of the Core language.

This should be fixed.

Impact: only changes the QVT Core language definition.

Resolution: (1) In Section 9.17.8 (Assignment), replace all the introductory text by an "An assignment sets the property of target object or sets a the value of a variable. See PropertyAssignment and VariableAssignment definitions for detailed semantic of property assignment and variable assignment." Also, remove the 'targetProperty' association description. (2) In Section 9.17 add a new class named "PropertyAssignment" with the introductory description copy pasted from the actual description of Assignment class. Add the following sub-titles after the introductory text: """ Superclasses Assignment Associations targetProperty: Property [1] The property whose value is to be assigned. The target property should be defined on the type of the slot expression. """ (3) In Section 9.17 add a new class named "VariableAssignment" with the following definition: """ An assignment sets the value of a variable. Superclasses Assignment Associations targetVariable: Variable [1] The variable whose value is to be assigned. """ (4) In Figure, 9.3 make the needed changes so that the diagram reflects (1), (2) and (3) actions.
Revised Text:
Actions taken:
March 20, 2006: received issue
November 7, 2007: closed issue

Issue 10077: QVTrelation to QVTcore transformation (mof-qvt-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

I've started looking at implementing QVTrelation->QVTcore in UMLX, but instantly hit problems.
Since UMLX has built in type checking it identifies that:


in RelationToTraceclass


RelationDomain has a DomainPattern rather than an ObjectTemplateExp


in SubTemplateToTraceClassProps


ObjectTemplateExp has a PartTemplateItem rather than an ObjectTemplateExp


These are easily fixed, but


in TopLevelRelationToMappingForEnforcement


there are too many discrepancies to resolve without major study; I'm very puzzled by the use of Sets for individual elements.


Is there a revised draft that the FTF are working on that is any more consistent?


FYI, I enclose the first two transformations in UMLX. I think they're a bit more intelligible, type consistent, although there a
fair few UMLX loose ends to sort out.

Resolution: The relations-to-core transformation spec was out of sync with the meta models. The new updated spec is given in appendix B of this report. Replace the content of sections 10.3 by the new content in Appendix B of this report.
Revised Text:
Actions taken:
July 26, 2006: received issue
November 7, 2007: closed issue

Issue 10603: OCL extensions (mof-qvt-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

I've started writing a QVTr parser. So far it just does syntax analysis.
It highlights a number of significant issues in the grammar and enables
many mistakes to be removed from the Relations to Core example.
 
OCL extension
-------------


7.13 should enumerate the new keywords:
        checkonly
        domain
        enforce
        extends
        implementedBy
        import
        key
        overrides
        primitive
        query
        relation
        top
        transformation
        when
        where
and stress that they are not reserved words and so may appear in identifier. At least I presume this is the intent, since 'domain'
is used in the Relation To Core example. I'm not entirely sure that a domain called OclAny is unambiguous, and is one called self
useful?


The OCL and consequently the QVT syntax lack formality here.
OCL extensions

Resolution: Insert a new sub-section named "Keywords" in 7.13 to list the keywords. This section is to be inserted before the "Relations textual Syntax Grammar" sub-section. The text of the section will be as follows: Keywords: checkonly, domain, enforce, extends, implementedby, import, key, overrides primitive, query, relation, top, transformation, when, where. All these keywords are reserved words, they cannot be used as identifiers. The "_" OCL prefix convention for escaping reserved words can be used to refer to conflicting properties or class names.
Revised Text:
Actions taken:
January 21, 2007: received issue
November 7, 2007: closed issue

Issue 10604: Comments (mof-qvt-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The Relation To Core example uses a // comment, whereas OCL uses --. If this is intended then the OCL grammar must be extended

Resolution: Specify the comment convention in section 7.13 by adding, before sub-section 7.13.1 Relation Textual Syntax Grammar, a new sub-section named "Comments" with the following text: """ The syntax supports two forms of comments, a line comment, and a paragraph comment. The line comment starts with the string '--' and ends with the next newline. The paragraph comment starts with the string '/*' and ends with the string '*/.' Paragraph comments may be nested. """
Revised Text:
Actions taken:
January 21, 2007: received issue
November 7, 2007: closed issue

Issue 10605: Unquoted commas (mof-qvt-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

An unquoted comma is redundant in the BNF, so presumably the commas should quoted:


Replace: <modelDecl> ::= <modelId> ':' <metaModelId> (, <metaModelId>)*
By:      <modelDecl> ::= <modelId> ':' <metaModelId> (',' <metaModelId>)*


Replace: <keyDecl> ::= 'key' <classId> '{' <propertyId> (, <propertyId>)* '}' ';'
By:      <keyDecl> ::= 'key' <classId> '{' <propertyId> (',' <propertyId>)* '}' ';'


Replace: <varDeclaration> ::= <identifier> (, <identifier>)* ':' <typeCS> ';'
By:      <varDeclaration> ::= <identifier> (',' <identifier>)* ':' <typeCS> ';'

Resolution: Replace the content of section 7.13.1 and 7.13.2 by the new content given in Appendix A of this report. This new content is the updated grammar correcting typos and other mistakes.
Revised Text:
Actions taken:
January 21, 2007: received issue
November 7, 2007: closed issue

Issue 10608: Missing commas (mof-qvt-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

List of propertyTemplate are used without separators. The Relation To Core example uses a comma separator.


In <domain>
Replace: <propertyTemplate>*
By:      (<propertyTemplate> (',' <propertyTemplate>)*)


In <objectTemplate>
Replace: <propertyTemplate>*
By:      (<propertyTemplate> (',' <propertyTemplate>)*)

Issue 10609: Over-enthusiastic semicolon (mof-qvt-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The Relation To Core example omits trailing semicolons following a brace-termated domain.


In <domain>
Replace: ['implementedby' <OperationCallExpCS>] ';'
By:        ['implementedby' <OperationCallExpCS> ';']

Issue 10610: Unsafe oclExpressionCS (mof-qvt-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The extension to oclExpressionCS affects all cases where OCL expressions are invoked. Since the "| (<oclExpressionCS> ';')*" term
covers epsilon, this introduces near catastrophic parsing ambiguities and meaningless syntax for existing usage.


Suggest: restrict the semi-colon separated extension to the extended syntax where it has useful semantic meaning. Permitting the
final semi-colon to be omitted seem needlessly generous/confusing/complicated. Therefore:


Replace: <oclExpressionCS> ::= <propertyCallExpCS>
                                        | <variableExpCS>
                                        | <literalExpCS>
                                        | <letExpCS>
                                        | <ifExpCS>
                                        | <template>
                                        | '(' <oclExpressionCS> ')'
                                        | (<oclExpressionCS> ';')*
By:     <oclExpressionCS> ::= <propertyCallExpCS>
                                        | <variableExpCS>
                                        | <literalExpCS>
                                        | <letExpCS>
                                        | <ifExpCS>
                                        | <template>
                                        | '(' <oclExpressionCS> ')'
          <oclStatementCS> ::= (<oclExpressionCS> ';')*


and use this new construct as:


Replace: <when> ::= 'when' '{' <oclExpressionCS> '}'
By:      <when> ::= 'when' '{' <oclStatementCS> '}'


Replace: <where> ::= 'where' '{' <oclExpressionCS> '}'
By:      <where> ::= 'where' '{' <oclStatementCS> '}'


In <domain>
Replace: '{' <propertyTemplate>* '}' [ '{' <oclExpressionCS> '}' ]
By:      '{' <propertyTemplate>* '}' [ '{' <oclStatementCS> '}' ]


In <query>
Replace: ';' | '{' <oclExpressionCS> '}'
By:      ';' | '{' <oclStatementCS> '}'

Issue 10611: Member selection as domain body (mof-qvt-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Relations to Core uses a top of domain memberSelectionExprCS.


In <dommain>
Replace: '{' <propertyTemplate>* '}'
By:        '{' (<propertyTemplate>* | memberSelectionExprCS) '}'
Or rather: '{' ((<propertyTemplate> (',' <propertyTemplate>)*) | memberSelectionExprCS) '}'

Issue 10612: Missing paramDeclaration (mof-qvt-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Suggest:        <paramDeclaration> ::= <identifier> ':' <typeCS>

Issue 10613: Missing oclExpressionCSList (mof-qvt-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Sole usage in collectionTemplate is as list of list, so presumably a typo


Replace: <oclExpressionCSList> (',' <oclExpressionCSList>)*
By:        <oclExpressionCS> (',' <oclExpressionCS>)*


However I cannot get past syntax ambiguities here between the '|' in a setComprehensionExpression
and the '|' in an oclExpression. To get Relations to Core to parse I just do:


Replace: <oclExpressionCSList> (',' <oclExpressionCSList>)*
By:        <templateCS>

Issue 10614: Filename (mof-qvt-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Surely this should be a URI?
Even if it is a filename no OS can cope without dots, slashes or ...


Replace: <filename> ::= <identifier>
By:        <filename> ::= StringLiteralExpCS

Resolution: The <filename> element has been renamed <unit> to mean "compilation unit" and defined as a sequence of identifier separated by dots. It is now clear that arbitrary file names cannot be used in import statements. In order to apply the resolution: replace the content of section 7.13.1 and 7.13.2 by the new content given in Appendix A of this report. This new content is the updated grammar correcting typos and other mistakes.
Revised Text:
Actions taken:
January 21, 2007: received issue
November 7, 2007: closed issue

Issue 10615: Member selection operator (mof-qvt-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

With -- as an OCL comment, ++ seems a very unfortunate choice of operator spelling. 
It also has minimal similarity to the C/Java increment operator which is unary.
Please review. The usage seems to always be <big-clause> ++ <tiny>, so how about
just a word.


?? <big-clause> 'in' <tiny>
?? <big-clause> 'over' <tiny>
?? <big-clause> 'forall' <tiny>

Resolution: Resolution: No change Remark: Which operator to use is a matter of taste. We checked with a few users and they preferred an operator over a keyword.
Revised Text:
Actions taken:
January 21, 2007: received issue
November 7, 2007: closed issue

Issue 10616: Ambiguity (mof-qvt-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Replace: objectTemplate ::= [<identifier>] ':' <typeCS> '{'
By:      <objectTemplate> ::= [<identifier>] ':' (primitiveTypeCS | tupleTypeCS | pathNameCS) '{' 


excluding collectionType that is ambiguous wrt collectionTemplate syntax

Issue 10617: Typos (mof-qvt-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

In <domain>
Replace: ['implementedby' <OperationCallExpCS>]
By:      ['implementedby' <operationCallExpCS>]

Resolution: Resolution: No change Remark: Looks like there was a mistake in entering the issue - OCL specifies OperationCallExpCS only.
Revised Text:
Actions taken:
January 21, 2007: received issue
November 7, 2007: closed issue

Discussion:

Issue 10618: Formatting (mof-qvt-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Inconsistent font for first line of 7.13.1.

Resolution: Font to be made consistent in 7.13.1. NOTE: This issue is superseded by issue 10616 which replaces all the content of the BNF section. Hence, the resolution should not be applied.
Revised Text:
Actions taken:
January 21, 2007: received issue
November 7, 2007: closed issue

Discussion:

Issue 10619: Relation To Core Transformation (mof-qvt-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

After adjusting the syntax as above to match the author's apparent expectation,
syntax checking reveals 69 problems, marked up with --** in the attached.
(Surprisingly few for a new language that has clearly not had a machine-assisted
check before.)

Resolution: The relations-to-core transformation spec was out of sync with the meta models. The new updated spec is given in appendix B of this report. Replace the content of sections 10.3 by the new content in Appendix B of this report.
Revised Text:
Actions taken:
January 21, 2007: received issue
November 7, 2007: closed issue

Discussion:

not an issue

Issue 10624: Kind of expressions in collection patterns (mof-qvt-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

The 'kind' property in collection template expression is not meant to specify
Set/Bag/Sequence. It is meant to specify the kind of expression used in
the collection pattern.
Note: This issue is related to issue 9415. 
Suggested resolution: 
In order to avoid name clash with Ocl rename CollectionKind to CollectionPatternKind. 
IN section 7.11.2 insert the enumeration type CollectionPatternKind with the 
following definition: 

""" 
CollectionPatternKind 
The enumeration type that specifies the kind of pattern expression used to specify 
the collection pattern. Possible values are: Enumeration, Comprehension and 
MemberSelection.

Resolution: The resolution of this issue is related to the resolution of issue 10784. Please refer to the resolution of issue 10784. There is no need to specify CollectionPatternKind in the new extended collection pattern suggested in 10784.
Revised Text:
Actions taken:
January 25, 2007: received issue
November 7, 2007: closed issue

Issue 10625: Escape characters in string literals (mof-qvt-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

The escape characters used in string literals need to be adequately defined
or referenced.
Note: This issue is related to issue: 9427

Resolution: In relation with resolution 9427, replace the sentence: "All the usual escape characters using backslash can be used including the '\n' return-line character." By """ All the usual escape characters using backslash can be used including the '\n' return-line character. The list of available escape characters are those defined for the Java language. EscapeSequence: \ b /* \u0008: backspace BS */ \ t /* \u0009: horizontal tab HT */ \ n /* \u000a: linefeed LF */ \ f /* \u000c: form feed FF */ \ r /* \u000d: carriage return CR */ \ " /* \u0022: double quote" */ \ ' /* \u0027: single quote ' */ \ \ /* \u005c: backslash \ */ OctalEscape /* \u0000 to \u00ff: from octal value OctalEscape: \ OctalDigit \ OctalDigit OctalDigit \ ZeroToThree OctalDigit OctalDigit OctalDigit: one of 0 1 2 3 4 5 6 7 ZeroToThree: one of 0 1 2 3 """
Revised Text:
Actions taken:
January 25, 2007: received issue
November 7, 2007: closed issue

Issue 10626: Top-levelness in QVT relations need to be enforced by a constraint (mof-qvt-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

There should be a constraint to enforce the top-levelness when the
'Relation::toplevel' boolean is true.
Note: This issue is related to issue: 9385

Resolution: Add a "Constraints" subsection with the following content: """ A non top-level relation should be invoked from the where clause of some other relation. self.isTopLevel implies not Relation.allInstances()->exists(r | r.where.predicate.conditionExpression->exists(ce | ce.oclIsTypeOf(RelationCallExp) and ce.oclAsType(RelationCallExp).referredRelation = self ) ) """ NOTE: This issue is superseded by issue 11022. The resolution should hence not be applied.
Revised Text:
Actions taken:
January 25, 2007: received issue
November 7, 2007: closed issue

Issue 10627: Rules for infering an extent (mof-qvt-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

The rules for inferring an extent from the type are not explained or referenced.
Note: This issue is related to issue: 9388

Resolution: In relation with resolution 9388, replace the text describing the "modelParameter" role: The extent of the mapping parameter. Should be explicitly provided when there is an ambiguity on the extent that will own a potential created element corresponding to this parameter. By: """ The extent of the mapping parameter. If not provided the extent is inferred by inspecting the model types of the transformation. See the inference rules below. """ In addition, after the description of the metaclass properties, add the following paragraph: """ Extent inference rule for mapping parameters: If the mapping parameter direction is "in", inspect the input model types of the transformation to find the one that contains the type of the parameter. A model type "contains" a type if the type is directly or indirectly contained by the package defining the model type. If the model parameter direction is "inout" or "out", inspect the inout or output model types of the transformation to find the one that contains the type of the parameter. In both cases there should be a unique model type found. """
Revised Text:
Actions taken:
January 25, 2007: received issue
November 7, 2007: closed issue

Issue 10644: Query result syntax (mof-qvt-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The grammar defines a list of named and typed input parameters and a list of named and typed output results.
The example uses the conventional named and typed input parameters and a result type, which may be a set.
Since the latter is what an Operation does, I presume that the QVTrelational concrete syntax is in error.

Resolution: Replace the content of section 7.13.1 and 7.13.2 by the new content given in Appendix A of this report. This new content is the updated grammar correcting typos and other mistakes.
Revised Text:
Actions taken:
February 6, 2007: received issue
November 7, 2007: closed issue

Issue 10645: RelationalCallExp missing (mof-qvt-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Since this is missing from the specification, it is difficult to be sure what the semantics of
type discrepancies are between invocation and definition. One perspective is that mis-matches
correspond to overloaded pattern matches so that the first, best or any, or any distinct matches apply
with a total type inconsistency being a silent error/behaviour. Another perspective is that
like function calls, all implementation should derive from some abstract interface so that
all invocations can be type checked against the abstract interface. I think we need some words.
I prefer complinace with an abstract interface, and invocation of all distinct matches, so that
when someone extends the transformation exuisting behaviours are not suppressed.

Resolution: Add class RelationCallExp in Fig 7.7 QVTRelation package and the following text in section 7.11.3 RelationCallExp A relation call expression specifies the invocation of a relation. A relation may be invoked from the when or where clause of another relation. The expression contains a list of argument expressions corresponding to the domains of the relation. The number and types of the arguments must match the number of domains and types of the root variables of the domains respectively. Superclasses OclExpression Associations argument : OclExpression [2..*] {Composes, Ordered} - Arguments to the relation call. referredRelation : Relation [1] - The relation being invoked.
Revised Text:
Actions taken:
February 6, 2007: received issue
November 7, 2007: closed issue

Issue 10647: Problem with Domain syntax (mof-qvt-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

In order to accommodate top level collection templates in domains

In <domain>
Replace:        [ <identifier> ] ':' <typeCS>'{' <propertyTemplate>* '}'
By:               <templateCS>

(or rather <template> if the missing CS is left omitted)

?? since any TemplateExp can have a where, should the [ '{' <oclExpressionCS> '}' ]
in <domain> be part of <template> instead ??

Resolution: Replace the content of section 7.13.1 and 7.13.2 by the new content given in Appendix A of this report. This new content is the updated grammar correcting typos and other mistakes.
Revised Text:
Actions taken:
February 6, 2007: received issue
November 7, 2007: closed issue

Issue 10648: Collection Type syntax ambiguities (mof-qvt-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

In order to avoid ambiguities on collectionTypeCS:

In <objectTemplate >
Replace: <typeCS>
By:        <objectTypeCS >
            objectTypeCS ::= tupleTypeCS | primitiveTypeCS | pathNameCS

This disambiguates. I don't know whether the residual case of 

        ':' <colectionTypeCS> '{' ...

without an identifier has any meaning. If it does, it would seem like a collection
rather than object behaviour.

Resolution: Replace the content of section 7.13.1 and 7.13.2 by the new content given in Appendix A of this report. This new content is the updated grammar correcting typos and other mistakes.
Revised Text:
Actions taken:
February 6, 2007: received issue
November 7, 2007: closed issue

Issue 10649: Identifiers syntax to avoid reserved keywords (mof-qvt-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

In order not to define new keywords as reserved:
Define:

         <relationIdentifier> ::= 'checkonly'
         <relationIdentifier> ::= 'domain'
         <relationIdentifier> ::= 'enforce'
         <relationIdentifier> ::= 'extends'
         <relationIdentifier> ::= 'implementedBy'
         <relationIdentifier> ::= 'import'
         <relationIdentifier> ::= 'key'
         <relationIdentifier> ::= 'overrides'
         <relationIdentifier> ::= 'primitive'
         <relationIdentifier> ::= 'query'
         <relationIdentifier> ::= 'relation'
         <relationIdentifier> ::= 'top'
         <relationIdentifier> ::= 'transformation'
         <relationIdentifier> ::= 'when'
         <relationIdentifier> ::= 'where'
        
         <pathNameCS> ::= <relationIdentifier>                     -- extending OCL to allowing QVTr keywords in expressions

         <simpleNameCS> ::= <relationIdentifier>                   -- extending OCL to allowing QVTr keywords in expressions
        
         <identifier> ::= IDENTIFIER                                         -- all non keyword 'alphanumerics'
         <identifier> ::= <relationIdentifier>
         <identifier> ::= 'self'

Resolution: Resolution: No change Remark: This issue is related to issue 10603. Please refer to the resolution given for issue 10603. As per that resolution the grammar will explicitly identify and list the keywords. Keywords may be implemented in one of several ways and we do not think the standard should mandate an implementation choice.
Revised Text:
Actions taken:
February 6, 2007: received issue
November 7, 2007: closed issue

Issue 10784: Relations language (mof-qvt-ftf)

Click here for this issue's archive.
Source: TCS (Mr. Sreedhar Reddy, sreedhar.reddy(at)tcs.com)
Nature: Uncategorized Issue
Severity:
Summary:

Relations language: It appears redundant to have three different collection template 
expressions, viz. enumeration, comprehension and member selection. They can be unified into 
one expression. Suppose we have an extended member selection expression such as 
the following: 
<collectionTemplate> ::= [<identifier>] ':' <CollectionTypeIdentifierCS> 
                         '(' <TypeCS> ')' 
                         ['{' <memberSelection> '}'] 

<memberSelection> ::= (<identifier> | <objectTemplate> | '_')+ 
                                              '++' 
                              (<identifier> | '_') 

Enumeration can be specified as a collection of members to be matched: 
e.g. cs:Set(Class) { c1, c2, c3 ++ _ } 
Comprehension can be specified as a condition that each member of the collection 
must satisfy: 
e.g. cs:Set(Class) { cs->forAll(c| <condition>) }

Resolution: Suggestion accepted and reflected in the meta model and concrete syntax as follows: Meta model: Make the following changes to class CollectionTemplateExp in Figure 7.6 - QVT Template Package: � Rename the associations 'part' and 'match' to 'member' and 'rest'. � Make the 'member' association ordered and set its cardinality to '1..*'; set the cardinality of 'rest' to '1'. Modify the text explanation of CollectionTemplateExp in section 7.11.2.3 as follows: 7.11.2.3 CollectionTemplateExp A collection template expression specifies a pattern that matches a collection of elements. It specifies a set of member expressions that match individual elements, and a collection-typed variable that matches the rest of the collection. The type of collection that a template matches is given by the referred collection type. If the referred collection type is a sequence then the matching member elements must be present at the head of the sequence in the order specified by the member expressions. Superclasses TemplateExp Associations referredCollectionType : CollectionType [1] The type of the collection that is being specified. It can be any of the EMOF collection types such as Set, Sequence, OrderedSet, etc. member : OclExpression [1..*] The expressions that the elements of the collection must have matches for. A special variable _ may be used to indicate that any arbitrary element may be matched and ignored. rest : OclExpression [1] The variable that the rest of the collection (i.e. excluding elements matched by member expressions) must match. A special variable _ may be used to indicate that any arbitrary collection may be matched and ignored. Concrete syntax: <collectionTemplate> ::= [<identifier>] ':' <CollectionTypeIdentifierCS> '(' <TypeCS> ')' ['{' <memberSelection> '}'] <memberSelection> ::= (<identifier> | <objectTemplate> | '_')+ '++' (<identifier> | '_') The updated grammar is given in Appendix A of this report. This replaces the grammar given in section 7.13.
Revised Text:
Actions taken:
February 22, 2007: received issue
November 7, 2007: closed issue

Issue 10785: Relations language should support "default assignments" (mof-qvt-ftf)

Click here for this issue's archive.
Source: TCS (Mr. Sreedhar Reddy, sreedhar.reddy(at)tcs.com)
Nature: Uncategorized Issue
Severity:
Summary:

Relations language should also support the 'default assignments' feature supported by 
the core language. This feature allows default values to be specified for the variables of 
an enforced target domain. Default assignments do not play a role in checking.

Resolution: Update the relations meta model in Fig 7.7 QVT Relation Package to add class 'RelationDomainAssignment'; class Assignment to have two associations to OclExpression - 'variable' and 'value'; class RelationDomain to have the association 'defaultAssignment' with class Assignment. Add the following text description in section 7.11.3. Add the following to the description of class RelationDomain. In bidirectional relations, sometimes it is not be possible to automatically compute the values required to enforce a relation in the reverse direction. This can be addressed by allowing a domain to specify default value assignments for its variables. The default assignments are executed only during enforcement and the values they assign must be capable of satisfying the relationship condition. Default assignments do not play a role in checking. Associations defaultAssignment : RelationDomainAssignment [0..*] Composes - the assignments that set default values for the variables of the domain that are required for its enforcement. Class RelationDomainAssignment A relation domain assignment sets the value of a domain variable by evaluating the associated expression in the context of a relation. Associations variable : Variable [1] - the variable being assigned valueExp : OclExpression [1] Composes - the expression that provides the value of the variable. Concrete syntax: Extend the production of <domain> with ['default_values' '{' (<assignmentExp>)+ '}'] <assignmentExp> ::= <identifier> '=' <OclExpressionCS> ';' The updated grammar is given in Appendix A of this report. This should replace the grammar given in section 7.13. Discussion: To see how this feature helps, let's consider the following bi-directional relation: top relation AttributeToColumn { n,utyp,rtyp : String; enforce domain uml a:Attribute { name = n, type = utyp } default_values { utyp = SqlToUmlDataType(rtyp); }; enforce domain rdbms c:Column { name = n, dataType = rtyp }; where { rtyp = UmlToSqlDataType(utyp); } } This relation uses a function in its where clause to compute a database type from an uml type. This works fine when the relation is enforced in the direction of 'rdbms'. It also works fine in 'checkonly' mode. However it does not work when the relation is enforced in the direction of 'uml' as the function 'UmlToSqlDataType' cannot be used to compute the uml type from the database type. We can solve this problem by using the default values section where we put an assignment that computes the required value for the uml domain.
Revised Text:
Actions taken:
February 22, 2007: received issue
November 7, 2007: closed issue

Issue 10922: rules for solving type identifiers are missing in the QVTOperational syntax (mof-qvt-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

ISSUE: The rules for solving type identifiers are missing in the QVTOperational syntax. 

The resolution rules when referencing types identifiers is missing in the 
QVTOperational syntax. For instance it is not clear weather unqualified type references 
should first be searched in the modeltype packages or in the transformation module.

Resolution: Add a new sub-section 8.4.7 (after sub-section 8.4.6 BNF) named "Solving type identifiers" with the following content: When referring to a type within an operational transformation definition it is possible to either qualify the type name with a model type or a package name, or, alternatively, leave the name of the type unqualified. In the latter case, a list of rules applies to resolve the symbol into the denoted type. If the resolution rule provides more than one result the specification is erroneous. - Firstly a type definition existing at the level of the current module (a transformation or a library) is searched. - In not found, all the packages of the model types declared in the module are recursively visited to found a type with the same name.
Revised Text:
Actions taken:
April 17, 2007: received issue
November 7, 2007: closed issue

Issue 10923: The BNF syntax of QVTOperational is not complete (mof-qvt-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

The BNF syntax of QVTOperational is not complete. Various elements are missing in the QVTOperational BNF like the 'late' keyword and the notation for enumeration and datatypes.

Resolution: The grammar was out of sync in respect with the metamodel. The issue is resolved globally by providing by new version of the grammar. The following text should replace the actual content of section 8.4.6.1. // keywords Bag, Collection, Dict, OrderedSet, Sequence, Set, Tuple, abstract, access, and, any, assert, blackbox, break, class, collect, collectNested, collectOne, collectselect, collectselectOne, composes, compute, configuration, constructor, continue, datatype, default, derived, disjuncts, do, elif, else, end, endif, enforcing, enum, except, exists, extends, extends, false, forAll, forEach , forOne, from, helper, if, implies, import , in, inherits, init, inout, intermediate, invresolve, invresolveIn, invresolveone, invresolveoneIn , isUnique, iterate, late, let, library, literal, log, main, map, mapping, merges, metamodel, modeltype, new, not, null, object, one, or, out, package, population, primitive, property, query, raise, refines, refines, reject, resolve, resolveIn, resolveone, resolveoneIn, return, select, selectOne, sortedBy, static, static, switch, tag, then, transformation, true, try, typedef, unlimited, uses, when, where, while, with, xcollect , xmap, xor, xselect // start rule <topLevel> ::= <import>* <unit_definition>* <import> ::= 'from' <unit> 'import' (<identifier_list> | '*') ';' | 'import' <unit> ';' <unit> ::= <identifier> ('.' <identifier>)* <identifier_list> ::= <identifier> (',' <identifier>)* // definitions in a compilation unit <unit_definition> ::= <transformation> | <library> | <access_usage> ';' | <modeltype> | <metamodel> | <class> | <property> | <helper> | <constructor> | <entry> | <mapping> | <tag> | <typedef> // Transformation and library definitions <transformation> ::= <transformation_h> (";" | '{' <module_definition>* '}' ';'?) <library> ::= <library_h> (";" | '{' <module_definition>* '}' ';') // Transformation header <transformation_h> ::= <qualifier>* 'transformation' <identifier> <transformation_signature> <transformation_usage_refine>? <transformation_usage_refine> ::= <module_usage> | <transformation_refine> <transformation_signature> ::= <simple_signature> <transformation_refine> ::= 'refines' <moduleref> 'enforcing' <identifier> // Library header <library_h> ::= 'library' <identifier> <library_signature>? <module_usage>? <library_signature> ::= <simple_signature> // import of transformation and library <module_usage> ::= <access_usage> | <extends_usage> <access_usage> ::= 'access' <module_kind>? <moduleref_list> <extends_usage> ::= 'extends' <module_kind>? <moduleref_list> <module_kind> ::= 'transformation' | 'library' <moduleref_list> ::= <moduleref> (',' <moduleref>)* <moduleref> ::= <scoped_identifier> <simple_signature>? // module definitions <module_definition> ::= <class> | <property> | <helper> | <constructor> | <entry> | <mapping> | <tag> | <typedef> // general purpose grammar rules <qualifier> ::= 'blackbox' | 'abstract' | 'static' <complete_signature> ::= <simple_signature> (':' param_list)? <simple_signature> ::= '(' <param_list>? ')' <param_list> ::= <param> (',' <param>)* <param> ::= <param_direction>? <declarator> <param_direction> ::= 'in' | 'inout' | 'out' <simple_declarator> ::= <typespec> | <scoped_identifier> ':' <typespec> <declarator> ::= <typespec> <init_part>? | <scoped_identifier> ':' <typespec> <init_part>? <simple_declarator_list> ::= <simple_declarator> (',' <simple_declarator>)* <declarator_list> ::= <declarator> (',' <declarator>)* <declarator_semi_list> ::= <declarator> (';' <declarator>)* <init_part> ::= <init_op> <expression> <init_op> ::= '=' | ':=' | '::=' <typespec> ::= <type_reference> <extent_location>? <type_reference> ::= <scoped_identifier> | <complex_type> <extent_location> ::= '@' <identifier> <complex_type> ::= <complex_type_key> | <collection_key> '(' <typespec> ')' | 'Tuple' '(' <declarator_list> ')' | 'Dict' '(' <typespec> ',' <typespec> ')' <complex_type_key> ::= <collection_key> | 'Dict' | 'Tuple' <collection_key> ::= 'Collection' | 'Set' | 'OrderedSet' | 'Sequence' | 'Bag' | 'List' <scoped_identifier> ::= <identifier> ('::' <identifier>)* <scoped_identifier_list> ::= <scoped_identifier> (',' <scoped_identifier>)* <expression_list> ::= <expression_semi_list> ';'? <expression_semi_list> ::= <expression> (';' <expression>)* <expression_comma_list> ::= <expression> (',' <expression>)* <expression_block> ::= '{' <expression_list>? '}' // model types compliance and metamodel declarations <modeltype> ::= 'modeltype' <identifier> <compliance_kind>? 'uses' <packageref_list> <modeltype_where>? ';' <modeltype_where> ::= 'where' <expression_block> <packageref_list> ::= <packageref> (',' <packageref>)* <packageref> ::= (<scoped_identifier> ( '(' <uri> ')' )? | <uri>) <compliance_kind> ::= <STRING> // like: "strict" and "effective" <uri> ::= <STRING> // Syntax for defining explicitly metamodel contents <metamodel> ::= <metamodel_h> (";" | '{' <metamodel_def>* '}' ';') <metamodel_h> ::= ('metamodel' | 'package') scoped_identifier <metamodel_def> ::= <class> | <enumeration> | <tag> <class> ::= <class_h> (";" | '{' <class_feature_list>? '}' ';') <class_h> ::= <class_info> <scoped_identifier> <class_extension>? <class_info> ::= 'datatype' | 'primitive' | 'intermediate'? <qualifier>* 'class' <class_extension> ::= 'extends' <scoped_identifier_list> <class_feature_list> ::= <class_feature> (';' <class_feature>)* <class_feature> ::= <class_property> | <class_operation> | <tag> <class_property> ::= <feature_key>? <declarator> <multiplicity>? <opposite_property>? <feature_key> ::= 'composes' | 'derived' | 'static' <multiplicity> ::= '[' multiplicity_range ']' <multiplicity_range> ::= <INTEGER> | '*' | <INTEGER> '...' <INTEGER> <class_operation> ::= <feature_key>? <declarator> <complete_signature> <enumeration> ::= <enumeration_h> ';' | <enumeration_h> '{' <identifier_list> '}' ';'? <enumeration_h> ::= 'enum' <identifier> <opposite_property> ::= 'opposites' <identifier> <tag> ::= 'tag' <tagid> <scoped_identifier> ('=' <tagvalue>)? ';' <tagid> ::= <STRING> <tagvalue> :: <expression> // typedefs <typedef> ::= 'typedef' <identifier> '=' <typespec> (typedef_condition)? ';' <typedef_condition> ::= '[' <expression> ']' // Properties in transformation <property> ::= 'intermediate'? <property_key>+ <declarator> ';' <property_key> ::= 'derived' | 'literal' | 'configuration' | 'property' // Syntax for helper operations <helper> ::= <helper_decl> | <helper_simple_def> | <helper_compound_def> <helper_header> ::= <helper_info> <scoped_identifier> <complete_signature> <helper_info> ::= <qualifier>* <helper_kind> <helper_kind> ::= 'helper' | 'query' <helper_decl> ::= <helper_header> ';' <helper_simple_def> ::= <helper_header> '=' <expression> ';' <helper_compound_def> ::= <helper_header> <expression_block> ';'? // Syntax for constructors <constructor> ::= <constructor_decl> | <constructor_def> <constructor_header> ::= <qualifier>* 'constructor' <scoped_identifier> <simple_signature> <constructor_decl> ::= <constructor_header> ';' <constructor_def> ::= <constructor_header> <expression_block> ';'? // Syntax for entries <entry> ::= <entry_decl> | <entry_def> <entry_header> :: 'main' <simple_signature> <entry_decl> ::= <entry_header> ';' <entry_def> ::= <entry_header> <expression_block> ';'? // syntax for mapping operations <mapping> ::= <mapping_decl> | <mapping_def> <mapping_decl> ::= <mapping_full_header> ';' <mapping_def> ::= <mapping_full_header> '{' <mapping_body> '}' ';'? <mapping_full_header> ::= <mapping_header> <when>? <where>? <mapping_header> ::= <qualifier>* 'mapping' <param_direction>? <scoped_identifier> <complete_signature> <mapping_extra>* <mapping_extra> ::= <mapping_extension> | <mapping_refinement> <mapping_extension> ::= <mapping_extension_key> <scoped_identifier_list> <mapping_extension_key> ::= 'inherits' | 'merges' | 'disjuncts' <when> ::= 'when' <expression_block> <where> ::= 'where' <expression_block> <mapping_refinement> ::= 'refines' <scoped_identifier_list> <mapping_body> ::= <init_section>? <population_section>? <end_section>? <init_section> ::= 'init' <expression_block> <population_section> ::= <expression_list> | 'population' <expression_block> <end_section> ::= 'end' <expression_block> // Expressions <expression> ::= <assign_exp> | <let_exp> | <var_init_exp> <assign_exp> ::= <implies_exp> | <unary_exp> <assign_op> <expression> <default_val>? | <unary_exp> <assign_op> <expression_block> <default_val>? <assign_op> := ':=' | '::=' | '+=' | '-=' <default_val> ::= 'default' <assign_exp> <implies_exp> ::= <or_exp> | <implies_exp> 'implies' <or_exp> <or_exp> ::= <and_exp> | <or_exp> <or_op> <and_exp> <or_op> ::= 'or' | 'xor' <and_exp> ::= <cmp_exp> | <and_exp> 'and' <cmp_exp> <cmp_exp> ::= <additive_exp> | <cmp_exp> <cmp_op> <additive_exp> <cmp_op> ::= '=' | '==' | '<>' | '<' | '>' | '<=' | '>=' <additive_exp> ::= <mult_exp> | <additive_exp> <add_op> <mult_exp> <add_op> ::= '+' | '-' <mult_exp> ::= <unary_exp> | <mult_exp> <mult_op> <unary_exp> <mult_op> ::= '*' | '/' | '%' <unary_exp> ::= <postfix_exp> | <unary_op> <unary_exp> <unary_op> ::= '-' | 'not' | '#' | '##' | '*' <postfix_exp> ::= <primary_exp> | <postfix_exp> '(' <arg_list>? ')' | <postfix_exp> '!'? '[' <declarator_vsep>? <expression> ']' | <postfix_exp> <access_op> (<scoped_identifier> | <iterator_exp> | <block_exp> | <control_exp> | <rule_call_exp>) | <postfix_exp> <resolve_exp> | <postfix_exp> <resolve_in_exp> <declarator_vsep> ::= <simple_declarator> '|' <multi_declarator_vsep> ::= <simple_declarator_list> '|' <resolve_exp> ::= <resolve_key> '(' <resolve_condition>? ')' <resolve_condition> ::= <declarator> ('|' <expression>)? <resolve_op> ::= 'late'? <resolve_kind> <resolve_kind> ::= 'resolve' | 'resolveone' | 'invresolve' | 'invresolveone' <resolve_in_exp> ::= <resolve_in_key> '(' <scoped_identifier> (',' <resolve_condition>)?')' <resolve_in_op> ::= 'late'? <resolve_in_kind> <resolve_in_kind> ::= 'resolveIn' | 'resolveoneIn' | 'invresolveIn' | 'invresolveoneIn' <access_op> ::= '.' | '->' | '!->' <primary_exp> ::= <literal> | <scoped_identifier> | <if_exp> | <block_exp> | <control_exp> | <rule_call_exp> | <quit_exp> | <try_exp> | <raise_exp> | <assert_exp> | <log_exp> | '(' <expression> ')' <literal> ::= <literal_simple> | <literal_complex> <literal_simple> ::= <INTEGER> | <FLOAT> | <STRING> | 'true' | 'false' | 'unlimited' | 'null' <literal_complex> ::= <literal_collection> | <literal_tuple> | <literal_dict> <literal_collection> ::= <collection_key> '{' <collection_item_list>? '}' <literal_tuple> ::= 'Tuple' '{' <tuple_item_list>? '}' <literal_dict> ::= 'Dict' '{' <dict_item_list>? '}' <collection_item_list> ::= <expression_comma_list> <tuple_item_list> ::= <declarator_list> <dict_item_list> ::= <dict_item> (',' <dict_item>)* <dict_item> ::= <literal_simple> '=' <expression> <if_exp> ::= 'if' <expression> <then_part> <elif_part>* <else_part>? 'endif' <then_part> ::= 'then' <if_body> <elif_part> ::= 'elif' <if_body> <else_part> ::= 'else' <if_body> <if_body> ::= <expression> | <expression_block> <iterator_exp> ::= <simple_iterator_op> '(' <declarator_vsep>? <expression> ')' | <multi_iterator_op> '(' <multi_declarator_vsep>? <expression> ')' | <iterate_exp> <simple_iterator_op> ::= 'reject' | 'select' | 'collect' | 'exists' | 'one' | 'any' | 'isUnique' | 'collectNested' | 'sortedBy' | 'xselect' | 'xcollect' | 'selectOne' | 'collectOne' | 'collectselect' | 'collectselectOne' <multi_iterator_op> ::= 'forAll' <iterate_exp> ::= 'iterate' '(' <declarator_list> ';' <declarator> '|' <expression> ')' <iter_declarator> ::= <declarator> <iter_declarator_list> ::= <declarator_list> <block_exp> ::= (<object_exp> | <do_exp> | <switch_exp>) <object_exp> ::= 'object' ('(' <iter_declarator> ')')? <object_declarator> <expression_block> <object_declarator> ::= <typespec> | <identifier> ':' <typespec>? <do_exp> ::= 'do' <expression_block> <switch_exp> ::= 'switch' ('(' <iter_declarator> ')')? <switch_body> <switch_body> ::= '{' <switch_alt>+ <switch_else>? '}' <switch_alt> ::= '(' <expression> ')' '?' <expression> ';' <switch_else> ::= 'else' '?' <expression> ';' <control_exp> ::= (<while_exp> | <compute_exp> | <for_exp>) <while_exp> ::= 'while' '(' (<declarator> ';')? <expression> ')' <expression_block> <compute_exp> ::= 'compute' '(' <declarator> ')' <expression_block> <for_exp> ::= ('forEach' | 'forOne') '(' <iter_declarator_list> (';' <declarator>)? ('|' <expression>)? ')' <expression_block> <rule_call_exp> ::= ('map' | 'xmap' | 'new' ) ('(' <declarator> ')')? <scoped_identifier> <let_exp> ::= 'let' <declarator_list> 'in' <expression> <var_init_exp> ::= 'var' <declarator> | 'var' '(' <declarator_list> ')' <quit_exp> ::= 'break' | 'continue' | <return_exp>) <return_exp> ::= 'return' ('(' <expression> ')')? <try_exp> ::= 'try' <expression_block> <except>+ <except> ::= 'except' '(' <scoped_identifier_list> ')' <expression_block> <raise_exp> ::= 'raise' <scoped_identifier> ('(' <arg_list>? ')')? <arg_list> ::= <expression_comma_list> <assert_exp> ::= 'assert' <identifier>? '(' <expression> ')' ( 'with' <log_exp> )? <log_exp> ::= 'log' '(' <arg_list> ')' ('when' <expression>)?
Revised Text:
Actions taken:
April 17, 2007: received issue
November 7, 2007: closed issue

Issue 10924: The representation and the containment of 'this' variable is missing (mof-qvt-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

In the section defining the OperationalTransformation class a 'this' predefined variable 
is defined but its exact representation and containment in the metamodel is missing.

Resolution: Resolution: (1) Add the composite property Module::ownedVariable of type Variable, with multiplicity '*' with the following definition: "The list of variables owned by the module." (2) Update the diagram Figure 8.1 with the new 'ownedVariable' association (see diagram the Appendix C ("Updated Diagrams") of this report. (3) In section 8.2.2.1 (Operational Transformation), after the sentence " The instantiation of the transformation is either implicit (the instance being referred though the predefined this variable) or explicit. In the latter case an InstantiationExp expression is used. " add the sentence: The implicit 'this' variable is represented by a Variable instance named "this" having the transformation as its type and owned by the transformation through the 'ownedVariable' property.
Revised Text:
Actions taken:
April 17, 2007: received issue
November 7, 2007: closed issue

Issue 10925: Incomplete specification for the resolution operation ResolveExp (mof-qvt-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

The type returned by ResolveExp and ResolveInRule is not clear: a OclAny? 
The type of the filtered objects? 
The semantics of ResolveInRule when no source is passed is also unclear. 
The variant  'invresolveIn' (combining inverse and rule scope) is missing. 
Consider simplifying ResolveExp definition: instead of an arbitrary condition 
expression use a type reference representing both: the returned type and 
the filtering expression

Resolution: Resolution: (1) Skip the three resolution instructions defined for issue 9390 in ballot1. (2) Add a new property "ResolveExp::target : Variable [0..1] composes" with the following description text: """a variable whose type indicates the primary condition for filtering the potential result objects. The extra condition (see 'condition' property) may use the variable to express a complementary filtering condition. This variable also has an influence in the type returned by the resolve expression (see type returned by the resolution expression).""" (3) In Section 8.2.1.22 ResolveExp, just before "semantics" sub-section add a sub-section "Type of a resolve expression" with the following content text: "The type of a ResolveExp expression depends on the type of the 'target' variable and on the multiplicity indication (the 'one' property). If 'one' is true, the returned type is the type of the 'target' variable. Otherwise, the returned type is a Sequence of the type of the 'target' variable. If no target variable is provided the type is either Object (the type representing all types, see Section 8.3.1) either a Sequence of Objects - depending on the multiplicity" (4) In section 8.2.1.22 ResolveInExp, just before "superclasses" sub-section add the section: "The type of a ResolveInExp expression is computed using the same rules as for the type of a ResolveExp." (5) In section 8.2.1.22 ResolveInExp, after the sentence " All variants described for the resolve expression are applicable to the resolve in expression" add a new paragraph with the sentence "A resolve in expression may be applied with an empty source argument. In that case it inspects all objects created or updated by the rule (instead of inspecting only the objects created or updated from the source object) ." (6) In section 8.1.22 ResolveExp, replace the content of Notation section by: The notation uses one of these three forms: <resolve_op> '(' (<identifier> ':' )? <typespec> ')' // no extra condition | <resolve_op> '(' (<identifier> ':' )? <typespec> '|' <expression> ')' // with extra condition | <resolve_op> '(' ')' // no target, no extra condition where the <resolve_op> is one of the following: resolve and invresolve and invresolveone. When isDeferred is true the late keyword is used before the operation name. The resolution operator may be called on a list. This is a shorthand for invoking it in the body of a ForEachExpr expression. myresult := mysourceobject.resolveone(Table); myresult := mysourceobject.resolveone(t:Table | t.name.startsWith("_")); myprop := mylist->late resolve(Table); // shorthand for mylist->forEach(i) i.late resolve(Table) (7) In section 8.2.1.22 ResolveInExp, replace the sentence "The notation uses �" by the sentence "The notation uses the same syntax as ResolveExp except that the operation names are one of the following resolveIn, resolveoneIn, invresolveIn or invresolveoneIn".The two variants starting with "inv" prefix correspond to the "inverse" variant (ResolveExp::isInverse == true). Also, after "is the condition to evaluate?", add the sentence: "The reference to the rule is given by a qualified identifier (context class and name). As a limitation of the concrete syntax, it is not possible to provide a reference to a rule is there is an ambiguity (having the same name and context but different parameters). (8) In Section 8.2.2.5, replace the sentence defining the "condition" property by "An optional additional Boolean condition to be evaluated to filter the potential results."
Revised Text:
Actions taken:
April 17, 2007: received issue
November 7, 2007: closed issue

Issue 10926: Clarify the return type of xselect operator (mof-qvt-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

Various examples provided in the spec suggest that the return type of xselect operator 
(bracket notation) depends on the filter expression (implicit casting). 
However this is currently not explained in the definition of the operator.

Resolution: (1) In section 8.2.2.7 ImperativeIterateExp add the following sentence at the end of the 2nd paragraph: "Also a specific implicit type casting rule applies depending on the condition expression that is associated with the iteration (see implicit type casting rules sub-section)." (2) Before the Semantics sub-section, add a sub-section named "Type re-casting" with the following text: """The type of the sequence or the object returned by the ImperativeIterateExp construct depends on the usage of the 'condition' expression is used: if the condition is an instance of TypeExp, the condition is firstly re-interpreted as a Boolean expression of the form 'oclIsKind(TypeExp)'. Additionally, the returned sequence (resp. the returned single object) is re-casted as a sequence of the type denoted in the type expression (resp. as an instance of the denoted type). If the 'condition' expression is not used or is not a TypeExp instance no implicit re-casting semantic applies. Example: self.mysequence[MyType] // the type of this expression is a Sequence of 'MyList' self.mysequence[oclIsKind(MyType) and name=="foo"] // the type is the type of the self.mysequence source expression """ NOTE: There is a typo in the resolution text within item (2): the sentence "// the type of this expression is a Sequence of 'MyList'" should be "// the type of this expression is a Sequence of 'MyType'"
Revised Text:
Actions taken:
April 17, 2007: received issue
November 7, 2007: closed issue

Issue 10927: The QVT Operational StdLib has various mispellings and copy-paste errors (mof-qvt-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

The QVT Operational StdLib has various mispellings and copy-paste errors and lacks 
sometimes of precision. Here's a list of encountered problems: 

  - List<Element> => List(Element) 
  - MarkedAs has a string parameter 
  - Missing a 'stereotypedKindOf' 
  - Return type of Model::objects() should be a Sequence 
  - Return type of Dictionary::size should be 'Integer' 
  - Copy-paste error in values(), keys() and isEmpty() Dictionary 
      operations: unexpected 'size' in signature 
  - In List, "all aperations in OCL..." should be replaced by something 
      more precise, like 
      "all operations of the OCL Collection type are available" 
  - List::insertAt : int => Integer. Should indicate the starting position for the index. 
  - String::format Should indicate whether the type is a tuple or a dictionary, 
     may be by splitting the operation in two operations. 
  - Indentation problem starting from String::substringAfter 
  - String::equals should better be named 'match' is different than the MOF Object::equals 
  - Integer::range, the type of start and end parameters is missing 
  - An M1 type named 'Property' is missing to comply with MOF reflexive API 
  - The result type of Status::raisedException should be a M1 class named 
       'Exception' (base type of all exceptions. 
  - Methods imported from MOF::reflect should be repeated in the spec for clarity 
  - Alphanumeric names for pre-defined OCL operations like '+', '-' � were missing. 
  - The return type of objectsOfType should depend on the argument (like oclAsType).

Resolution: Resolution: (1) In Section 8.3 Replace all occurrences of List<Element> by List(Element) (2) Change the signature of markedAs: Element::markedAs(String value) : Boolean (3) After the operation "stereotypedBy", add the operation "stereotypedStrictlyBy" with the following definition: Element::stereotypedStrictlyBy(String) : Boolean : Same than stereotypedBy except that base stereotype are not taken into account. (4) Change the signature of Dictionary::size as: Dictionary(KeyT,T)::size() : Integer (5) Change the signature of Dictionary::values, Dictionary::keys and Dictionary:isEmpty as follows: Dictionary(KeyT,T)::values() : List(T) Dictionary(KeyT,T)::Keys() : List(KeyT) Dictionary(KeyT,T)::isEmpty() : Boolean, (6) Replace "all operations in OCL are available" by " all operations of the OCL Collection type are available" (7) In insertAt description, add the following sentence: "The index starts at zero (in compliance with OCL convention)" (8) Rename String::equals by String::match with the following signature and description. String::match (String matchpattern) : Boolean Returns true if the value of the String matches the regular expression, else return false. The syntax of regular expression is the syntax or regular expression in Java language. (9) Change the signature of the range operation as follows: Integer::range (start: Integer,end: Integer) : List(Element) (10) In Section 8.3.1 Predefined types, add the definition of a 'Exception' type with the following definition: This M1 class named Exception represents the base class for exceptions. The M1 Exception type is an instance of the Class metatype. (11) In Section 8.3.3, replace " All MOF reflective operations applying on Objects " by The reflective operations inherited from MOF that are available in QVT specification are: (12) In Section 8.3.2 Synonym types and synonym operations, insert the following paragraph at the end: The following synonyms are defined for the following pre-defined OCL operations: String : operator+ -> concat Integer: operator+ -> plus, operator- (binary) -> minus, operator- (unary) -> unaryminus operator* -> multiply operator/ -> divide Real: operator+ -> plus, operator- (binary) -> minus, operator- (unary) -> unaryminus operator* -> multiply operator/ -> divide (13) In the description of objectsOfType, add the following sentence: " The returned Element type is the type denoted by the type expression." And correct the signature as follow: Model::objectsOfType(OclType) : Set(Element) (14) Within section 8.3.8 Operation list, add the following operations: Set(T)::asList() : List(T) OrderedSet(T)::asList() : List(T) Sequence(T)::asList() : List(T) Bag(T)::asList() : List(T) Converts a collection into the equivalent mutable list. (15) In the signature of the following operations replace the result type by Set(Element): subobjects, allSubobjects, subobjectsOfType, allSubobjectsOfType, allsubobjectsOfKind. (Remark: this is in line with the result type of Model::objects()). Also in this signature replace 'TypeType' by 'OclType' (which is the M1 type). NOTE: Typo fixes after AB review In addition the following fixes need to be done in section 8.3.9 Operations on strings: the syntax for parameters should be: <paramname> : <type> instead of <type> <paramname> as found in: 'replace', 'equals', 'equalsIgnoreCase', 'find', 'rfind', 'startStrCounter', 'getStrCounter', 'incStrCounter'. Also 'void' type should be spelled 'Void' in 8.3.8 for 'add', 'prepend' and 'insertAt' signature.
Revised Text:
Actions taken:
April 17, 2007: received issue
November 7, 2007: closed issue

Issue 10928: Extent of intermediate classes in QVT Operational (mof-qvt-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

The extent when creating instances of intermediate classes cannot be determined 
if there is no modeltype associated with the definition of intermediate classes.

Resolution: (1) In section 8.2.1.3 Module, in the description of derived property ownedType, append the following sentence: If the module contains the declaration of intermediate classes (see OperationalTransformation::intermediateClass definition) a model type named '_INTERMEDIATE' is automatically defined and inserted in the list of owned types. The model type package is also named '_INTERMEDIATE'. This package is nested by the transformation (by means of the inherited Package::nestedPackage property). (2) In section 8.2.1.3 Module, in the description of the property usedModelType replace the description paragraph by: "The list of model types being used. This includes the implicit '_INTERMEDIATE' model type when available (see ownedType description). (3) In Section 8.2.1.1 Transformation, in the description of the property modelParameter, add the sentence "If the transformation defines intermediate classes this contains a parameter named '_intermediate' of the type '_INTERMEDIATE' (see 'Module::ownedType' property description).
Revised Text:
Actions taken:
April 17, 2007: received issue
November 7, 2007: closed issue

Issue 10929: Distinguishing pure syntactic tags from other tags in QVTOperational (mof-qvt-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

Need to distinguish between tags that are owned by model elements from tags 
which are purely syntactical (like the 'alias' tag). At least the complete list of the 
syntactical tags should be provided

Resolution: In Section 8.3.11 Predefined Tags. Add the following sentence after the sentence describing the "alias" tag. "This is a purely syntactic tag. Consequently the representation of this Tag can be skipped after parsing the source file".
Revised Text:
Actions taken:
April 17, 2007: received issue
November 7, 2007: closed issue

Issue 10949: 7.13.1 Scoped transformation name (mof-qvt-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

How can a transformation be defined in a nested package?


Surely OMG should be able to define org.omg.qvt.RelationToCore?


Suggest: introduce a Java-like package statement.

Resolution: (1) Within 7.13 Section, add a preliminary sub-section named "Compilation Units" with the following content. A relational transformation specification provided using concrete syntax in a text file may import one or more compilation units. A compilation unit corresponds to another relational transformation definition given either using the concrete syntax definition or the abstract representation. Within an import statement a compilation unit is referenced by means of a simple unqualified aplhanumeric identifier - with no special characters and blanks characters allowed - or is referenced by means of a qualified one. In the latter case, the qualification is given by a list of namespaces separated by the dot character. These namespaces have no representation in the metamodel. It is up to an implementation to make a correspondence between the namespace hierarchy and the hierarchy of the file system. (2) In section 8.4.1, replace the first paragraph by the following two paragraphs: An operational transformation specification provided using concrete syntax in a text file may import one or more compilation units. A compilation unit corresponds to another operational transformation or library definition given either using the concrete syntax definition or the abstract representation. Within an import statement a compilation unit is referenced by means of a simple unqualified aplhanumeric identifier - with no special characters and blanks characters allowed - or is referenced by means of a qualified one. In the latter case, the qualification is given by a list of namespaces separated by the dot character. These namespaces have no representation in the metamodel. It is up to an implementation to make a correspondence between the namespace hierarchy and the hierarchy of the file system.
Revised Text:
Actions taken:
March 26, 2007: received issue
November 7, 2007: closed issue

Discussion:

The resolution of issue '10614 Filename' resolves the syntax issue but creates a semantic issue and a syntactic oddity.

What does "a.b.c" mean? How is "a.b.c" found? How is "a.b.c" defined?

It is a bit odd to emulate Java for a presumably package separator when OCL has :: for a package separator.

? resolve as part of issue 10934 undefined syntax or issue 10949 scopee transformation ?

Comment
This issue does not concern nested packages for which there is already a notation (using the "::" separator) but concern namespaces to refer to compilation units (for instances the files containing a textual transformation definition)

Issue 10950: 7.13.1 Model class name semantics (mof-qvt-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Given a class pack::age::cls in mdlid, in what circumstances are


cls
age::cls
pack::cls
mdlid::cls
mdlid::pack::cls


permissible model references?


Suggest:


The full mdlid::pack::age::cls is always permissible.
Omitted qualifications are permitted if a search of all possibilities for
omitted elements yields a unique solution.


In particular same model transformations should not need the redundant mdlid.

Resolution: Comment: The semantics of how named elements are identified in package namespaces comes from MOF. QVT has no special semantics of its own for this purpose. Resolution: No change
Revised Text:
Actions taken:
March 26, 2007: received issue
November 7, 2007: closed issue

Issue 10951: 7.13.1 Collection conversions (mof-qvt-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Given a property template in which the property is a collection, under what
circumstances:


Is it permissible for the right hand side to be a non-collection?


Is it permissible for the right hand side to be a different collection kind.

Resolution: Add the following to the description of class PropertyTemplateItem in section 7.11.2.4: A property template item has a valid match when the value of the referred property matches the value specified by the value expression. The following rules apply when the value is specified by a template expression: - If the value expression is an object template expression and the referred property is single-valued then the property value must match the object template expression. - If the value expression is an object template expression and the referred property is multi-valued then at least one of the property values must match the object template expression. - If the value expression is a collection template expression and the referred property is single-valued then the property value is treated as a singleton collection that must match the collection template expression - If the value expression is a collection template expression and the referred property is multi-valued then the collection of property values must match the collection template expression. The following rules apply: o If the property value is a set, then the collection type of the collection template expression must be a set. o If the property value is an ordered set, then the collection type of the collection template expression can be one of set, sequence or ordered set. o If the property value is a sequence, then the collection type of the collection template expression can be one of set, sequence or ordered set. When the collection type is a set or an ordered set, a valid match requires that each value of the property be unique.
Revised Text:
Actions taken:
March 26, 2007: received issue
November 7, 2007: closed issue

Issue 10952: 7.11.1.2 Meta-model Id persistence (mof-qvt-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The concrete QVTrelation syntax references meta-models by an identifier,
which define TypedModel.usedPackages in the abstract syntax.


The meta-model identifier is not present in the abstract syntax,
making it difficult to unparse the abstract syntax back to concrete.


It is possible in principle to invert the meta-model-id to package
conversion to identify meta-model-ids that could give the required forward
conversion, but there is no guarantee that this would be unique.


Suggest:


Add TypedModel.metaModelNames : String[0..*] to persist these annotations

Resolution: Comment: The 'metaModelId' of concrete syntax is actually a reference to the package name of a used package in the abstract syntax. There is no need to provide anything more in the abstract syntax. Resolution: No change
Revised Text:
Actions taken:
March 26, 2007: received issue
November 7, 2007: closed issue

Issue 10953: 7.11.2.3 CollectionTemplateExp (mof-qvt-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The description for match is 'specifies a variable'. This is a poor
description for a VariableExp that references a variable.


CollectionTemplateExp.match should compose its expression.


CollectionTemplateExp.part should compose its expression

Resolution:
Revised Text:
Actions taken:
March 26, 2007: received issue
November 7, 2007: closed issue

Discussion:

Comment: 
This issue refers to an older version of CollectionTemplateExp. Please refer to the resolution of issue 10784 for the latest CollectionTemplateExp.
Resolution: No change

Issue 10954: 7.11.2.3 CollectionTemplateExp.referredCollectionType (mof-qvt-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

CollectionTemplateExp.referredCollectionType refers to a CollectionType, but that type may not exist,
since the reference is a parameterisation of a collection; the collection kinds exist in OCL, the
parameter types in the user model, but the parameterised collections exist only as references.


Suggest:
        remove: CollectionTemplateExp.referredCollectionType
        add:    CollectionTemplateExp.referredElementType : Type[0..1]
        add:    CollectionTemplateExp.collectionKind : CollectionKind[1]


to capture the reference without requiring type synthesis.

Resolution: (1) In Section 7.11.1.1, within "associations" sub-section, add the following property: /ownedType : Type [0..*] (from Package) {composes,ordered} All the types being defined by this transformation. Specifically this includes any composite type used to define the type of a variable or a parameter, for instance a 'Set(MyMetaclass)' parameterized type instance. (2) In Section 7.11.1.1, add a "Remark" sub-section with the following sentence: Remark: Instances of parameterized types defined in different transformations denote the same type if the base types are the same: for instance 'Tx1::Set(Integer)' and 'Tx2::Set(Integer)' denote the same type 'Set(Integer)'.
Revised Text:
Actions taken:
March 26, 2007: received issue
November 7, 2007: closed issue

Issue 10955: 7.13 Comments (mof-qvt-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Is there a syntax for comments?


Suggest: -- comments to avoid confusion with OCL.

Resolution: Resolution: No change. This has already been addressed by the resolution of issue 10604.
Revised Text:
Actions taken:
March 25, 2007: received issue
November 7, 2007: closed issue

Issue 10956: 7.13 Implicit Variable Declarations (mof-qvt-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The RelationsToCore example declares only those variables that are necessary. It is
possible to deduce the types of variables not declared explicitly from the property
with which the variable is associated in a property template, or from the relation
whose invocation the variable participates in.


Are QVTrelation tools required to deduce implicit declarations?


If so, what are the detailed semantics for resolution of conflicting inference between
explicit and implicit declarations and between implicit and implicit declarations.


Do these semantics depend on collection kind, enforcement direction and relation
invocation binding?


Note that invocation of a relation with ridiculous types is probably but not
necessarily an error. In some circumstances the user may not be aware that a match
is impossible. When using third party models, the user perhaps should not be aware
that a match is impossible. The ridiculous match may be a precautionary cover for
a hoped for impossible case.

Resolution: Add the following sub section in section 7.13 Concrete Syntax: Implicit declaration of variables: There is no need to explicitly declare variables that are bound to object or collection templates. All other variables must be explictly declared. Consider the following template declarations: c:Class {<template-body>} cs:Set(Class) {<template-body>} Here there is no need to have explcit declaration for variables c and cs as their types are obvious from the template declarations. If there exists an explcit declaration for a variable that is bound to an object or a collection template, then the explicitly declared type must either be the same or more generic than the type specified by the template. If an implictly declared variable has bindings with more than one object template (resp collection template), then the types of all such templates must be the same.
Revised Text:
Actions taken:
March 26, 2007: received issue
November 7, 2007: closed issue

Discussion:

Comment: 
The concrete syntax tries to balance the concerns of readability and economy of expression. It does allow implicit declarations, but only where readability is not compromised. Let's look at an example. Consider the following template declaration:
t: Table {
   primarykey = k
}
Here a reader can readily see that the type of variable 't' is Table, because type declaration is part of an object template specification. The same is the case with a collection template specification as well, i.e. it declares the type of the collection. But what about the type of variable 'k'? Is it a string? Is it a class called 'PrimaryKey' or a class called 'Key'? A reader cannot tell without refering to the meta model. So we allow optional implict declarations only for those variables that are bound to object and collection templates. All other variables must be explictly declared.

Issue 10975: 8.4.6.2 QVToperational is not a syntax extension of OCL (mof-qvt-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The syntax claims to extend the OCL syntax. But it doesn't, or
at least not with the same semantics.


For instance:


The QVToperational grammar defines:
'or' and 'xor' with lower precedence than 'and'
OCL (7.4.7) defines them the same precedence .


The QVToperational grammar defines:
'if' as primary
OCL (7.4.7) defines 'if' between relational and additive.


The changed precedences may be better, but they are not OCL.


The QVToperational type/declaration system is difficult to compare with
OCL; it certainly doesn't look compatible.  


Suggest: Re-specify the QVToperational grammar so that the
name, type and expression sub-grammars are
demonstrably an extension of their Essential OCL counterparts.


i.e. each production such as PrimitiveLiteralExpCS should be used unchanged
or reproduced preferably containing only additional clauses, but perhaps
replacement clauses that can be analyzed to provide equivalent/extended coverage


Else: Remove all claims that there is any similarity
between QVToperational and OCL.

Resolution:
Revised Text:
Actions taken:
April 30, 2007: received issue
November 7, 2007: closed issue

Discussion:

Comment: 
Precedence problem between 'or' and 'and' is solved by the new grammar (issue 10026). The difference concerning 'if/then/else' is justified by the fact that the if/then/else notation also may represent a SwitchExp construct which is the "imperative" extension of the OCL functional If expression. Defining the QVT operational BNF syntax as an extension of the OCL syntax is very difficult to achieve because there are many additions at the expression level that cannot be easily isolated.
Despite the subtle differences between OCL and QVT/op syntax the claim that there is a similarity remains entirely true.
Resolution: No change

Issue 10977: Find better notation for explicit extent indication in op mapping parameter (mof-qvt-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

Find better notation for explicit extent indication in operational mapping parameters. 

Though the type names prefixed with the extent work from the point of implementation, I suspect it
might add on complexity of type resolution. 
All the folks are pretty much used to local and qualified name convention concerning the '::' separator use.
Is 'bag::Foo' a qualified type name or unqualified one but to be created in a 'bag' extent?
I think that including model param names into type resolution may increase the level of ambiguity as in this way, param names can impose clashes with packages, model types. 

This issue is related to resolution of 9388 in Ballot1.

Resolution: Replace resolution of issue 9388 (Ballot 1) by the following resolution text. (1) In Section 8.2.1.16 (MappingParameter) add the association: """ extent : ModelParameter [0..1] The extent of the mapping parameter. Should be explicitly provided when there is an ambiguity on the extent that will own a potential created element corresponding to this parameter. """ (2) In the same section 8.2.1.16, add the "Notation" subtitle as follows: """ Notation The extent of a mapping parameter can be provided explicitly using the '@' symbol after the type of the mapping parameter. In that case the declarator has the form: mymappingparameter : myextent::MyType@mymodelparameter. It is not mandatory to provide the extent when it can be inferred from the type. Example: transformation T(in src:S, out dest1:D, out dest2:D); mapping X::foo(inout Y@dest1) : Y@dest2; // 'X' is a class of 'S' metamodel and 'Y' is a class of 'D' metamodel """ (3) In Figure 8.1, add the correspond link between MappingParameter and ModelParameter. (4) In Section 8.2.1 (ObjectExp), within the "Notation" subtitle, replace: """When provided the model parameter is notated within brackets after the object keyword. object[srcmodel] x:X { ... } // x is created within the 'srcmodel """ by: """When an explicit extent is provided, the model parameter variable name postfixes the type of the object expression using the "@" separator symbol. object x: X@srcmodel { ... } // x is created within the 'srcmodel """ (this change is required for consistency with mapping parameter notation). (5) In Section 8.2.2.23 (InstantiationExp), within the "Notation" subtitle, replace: """ When provided the extent is notated by adding the variable name in brackets after the new keyword. column := new [mymodel] Column(n,t); // mymodel is the extent for the new instance. """ by: """When an explicit extent is provided, the variable name postfixes the type of the instantiation expression using the "@" separator symbol. column := new Column@mymodel(n,t); // mymodel is the extent for the new instance. """ (6) In BNF grammar (Section 8.4.6.1), define the <typespec> rule as follows: <typespec> ::= <type_reference> <extent_location>? <type_reference> ::= <scoped_identifier> | <complex_type> <extent_location> ::= '@' <identifier>
Revised Text:
Actions taken:
April 30, 2007: received issue
November 7, 2007: closed issue

Issue 10978: QVTOperational examples have some errors and need to be inline with grammar (mof-qvt-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

Some of the examples provided in the spec have either syntax errors either or missing 
elements

Resolution: (1) Replace the contents of A2.1: Operational Mapping Examples by the following: metamodel BOOK { class Book {title: String; composes chapters: Chapter [*];} class Chapter {title : String; nbPages : Integer;} } metamodel PUB { class Publication {title : String; nbPages : Integer;} } transformation Book2Publication(in bookModel:BOOK,out pubModel:PUB); main() { bookModel->objectsOfType(Book)->map book_to_publication(); } mapping Class::book_to_publication () : Publication { title := self.title; nbPages := self.chapters->nbPages->sum(); } (3) Replace the contents of 12.2 by -- This QVT definition performs an in place transformation on -- a UML class-diagram model by privatizing the attributes and -- creating accessor methods modeltype UML uses "omg.org.uml14"; transformation Encapsulation(inout classModel:UML); // Indicating that UML1.4 Name type is to be treated as a String tag "TypeEquivalence" UML::Name = "String"; -- entry point: selects the packages and applies the transformation -- on each package main() { classModel.objectsOfType(Package) ->map encapsulateAttributesInPackageClasses(); } -- Applies the transformation to each class of the package mapping inout Package::encapsulateAttributesInPackageClasses () { init {self.ownedElement->map encapsulateAttributesInClass();} } -- Performs the encapsulation for each attribute of the class -- The initialization section is used to retrieve the list of attributes -- The population section is used to add the two accessor operations -- The end section is used to privatize each attribute mapping inout Class::encapsulateAttributesInClass () { init { var attrs := self.feature[Attribute];} operation := { -- assignment with additive semantics attrs->object(a) Operation { name := "get_" + self.name.upperFirst(); visibility := "public"; type := a.type; }; attrs->object(a) Operation { name := "set_" + self.name.upperFirst(); visibility := "public"; parameter := object Parameter { name := 'a_'+ self.name.upperFirst(); kind := "in"; type := a.type;}; }; }; end { attrs->map privatizeAttribute();} } -- in place privatization of the attribute mapping inout Attribute::privatizeAttribute () { visibility := "private"; } (4) Replaces the content of A2.3 by the following The metamodels used here are the same metamodels used for the relational version given in Appendix A.1.1. We provide below their definition using the concrete syntax for metamodels. Note we are assuming that all multi-valued associations are ordered. metamodel SimpleUml { abstract class UMLModelElement { kind : String; name : String; } class Package extends UMLModelElement { composes elements : PackageElement [*] ordered opposites namespace [1]; } abstract class PackageElement extends UMLModelElement { } class Classifier extends PackageElement { } class Attribute extends UMLModelElement { references type : Classifier [1]; } class Class extends Classifier { composes attribute : Attribute [*] ordered opposites owner [1]; references general : Classifier [*] ordered; } class Association extends PackageElement { source : Class [1] opposites reverse [*]; destination : Class [1] opposites forward [*]; } class PrimitiveDataType extends Classifier { } } metamodel SimpleRdbms { abstract class RModelElement { kind : String; name : String; } class Schema extends RModelElement { composes tables : Table [*] ordered opposites schema [1]; } class Table extends RModelElement { composes column : Column [*] ordered opposites owner[1]; composes _key : Key [*] ordered opposites owner[1]; // '_key' is an automatic alias for 'key' composes foreignKey : ForeignKey [*] ordered opposites owner[1]; } class Column extends RModelElement { type : String; } class Key extends RModelElement { references column : Column [*] ordered opposites _key [*]; } class ForeignKey extends RModelElement { references refersTo : Key [1]; references column : Column [*] ordered opposites foreignKey [*]; } } Below the transformation definition. transformation Uml2Rdb(in srcModel:UML,out dest:RDBMS); -- Aliases to avoid name conflicts with keywords tag "alias" RDBMS::Table::key_ = "key"; -- defining intermediate data to reference leaf attributes that may -- appear when struct data types are used intermediate class LeafAttribute { name:String; kind:String; attr:UML::Attribute; }; intermediate property UML::Class::leafAttributes : Sequence(LeafAttribute); -- defining specific helpers query UML::Association::isPersistent() : Boolean { result = (self.source.kind='persistent' and self.destination.kind='persistent'); } -- defining the default entry point for the module -- first the tables are created from classes, then the tables are -- updated with the foreign keys implied by the associations main() { srcModel.objects()[Class]->map class2table(); -- first pass srcModel.objects()[Association]->map asso2table(); -- second pass } -- maps a class to a table, with a column per flattened leaf attribute mapping Class::class2table () : Table when {self.kind='persistent';} { init { -- performs any needed intialization self.leafAttributes := self.attribute ->map attr2LeafAttrs("",""); // ->flatten(); } -- population section for the table name := 't_' + self.name; column := self.leafAttributes->map leafAttr2OrdinaryColumn(""); key_ := object Key { -- nested population section for a 'Key' name := 'k_'+ self.name; column := result.column[kind='primary']; }; } -- Mapping that creates the intermediate leaf attributes data. mapping Attribute::attr2LeafAttrs (in prefix:String,in pkind:String) : Sequence(LeafAttribute) { init { var k := if pkind="" then self.kind else pkind endif; result := if self.type.isKindOf(PrimitiveDataType) then -- creates a sequence with a LeafAttribute instance Sequence { object LeafAttribute {attr:=self;name:=prefix+self.name;kind:=k;} } else self.type.asType(Class).attribute ->map attr2LeafAttrs(self.name+"_",k)->asSequence() endif; } } -- Mapping that creates an ordinary column from a leaf attribute mapping LeafAttribute::leafAttr2OrdinaryColumn (in prefix:String): Column { name := prefix+self.name; kind := self.kind; type := if self.attr.type.name='int' then 'NUMBER' else 'VARCHAR' endif; } -- mapping to update a Table with new columns of foreign keys mapping Association::asso2table() : Table when {self.isPersistent();} { init {result := self.destination.resolveone(Table);} foreignKey := self.map asso2ForeignKey(); column := result.foreignKey->column ; } -- mapping to build the foreign keys mapping Association::asso2ForeignKey() : ForeignKey { name := 'f_' + self.name; refersTo := self.source.resolveone(Table).key_; column := self.source.leafAttributes[kind='primary'] ->map leafAttr2ForeignColumn(self.source.name+'_'); } -- Mapping to create a Foreign key from a leaf attributes -- Inheriting of leafAttr2OrdinaryColumn has the effect to call the -- inherited rule before entering the property population section mapping LeafAttribute::leafAttr2ForeignColumn (in prefix:String) : Column inherits leafAttr2OrdinaryColumn { kind := "foreign"; } (5) Replaces the content of A2.4 by the following modeltype UML uses "omg.org.spem_umlprofile"; modeltype SPEM uses "omg.org.spem_metamodel"; transformation SpemProfile2Metamodel(in umlmodel:UML,out spemmodel:SPEM); query UML::isStereotypedBy(stereotypeName:String) : Boolean; query UML::Classifier::getOppositeAends() : Set(UML::AssociationEnd); main () { -- first pass: create all the SPEM elements from UML elements umlmodel.rootobjects()[UML::Model]->map createDefaultPackage(); -- second pass: add the dependencies beyween SPEM elements umlmodel.objects[UML::UseCase]->map addDependenciesInWorkDefinition(); } mapping UML::Package::createDefaultPackage () : SPEM::Package { name := self.name; ownedElement := self.ownedElement->map createModelElement(); } mapping UML::Package::createProcessComponent () : SPEM::ProcessComponent inherits createDefaultPackage when {self.isStereotypedBy("ProcessComponent");} {} mapping UML::Package::createDiscipline () : SPEM::Discipline inherits createDefaultPackage when {self.isStereotypedBy("Discipline");} {} mapping UML::ModelElement::createModelElement () : SPEM::ModelElement disjuncts createProcessRole, createWorkDefinition, createProcessComponent, createDiscipline {} mapping UML::UseCase::createWorkDefinition () : SPEM::WorkDefinition disjuncts createLifeCycle, createPhase, createIteration, createActivity, createCompositeWorkDefinition {} mapping UML::Actor::createProcessRole () : SPEM::ProcessRole when {self.isStereotypedBy("ProcessRole");} {} -- rule to create the default process performer singleton mapping createOrRetrieveDefaultPerformer () : SPEM::ProcessPerformer { init { result := resolveoneByRule(createOrRetrieveDefaultPerformer); if result then return endif; } name := "ProcessPerformer"; } mapping abstract UML::UseCase::createCommonWorkDefinition () : SPEM::WorkDefinition { name := self.name; constraint := { self.constraint[isStereotypedBy("precondition")] ->map createPrecondition(); self.constraint[isStereotypedBy("goal")]->map createGoal(); }; } mapping UML::UseCase::createActivity () : SPEM::WorkDefinition inherits createCommonWorkDefinition when {self.isStereotypedBy("Activity");} {} mapping UML::UseCase::createPhase () : SPEM::Phase inherits createCommonWorkDefinition when {self.isStereotypedBy("Phase");} {} mapping UML::UseCase::createIteration () : SPEM::Iteration inherits createCommonWorkDefinition when {self.isStereotypedBy("Iteration");} {} mapping UML::UseCase::createLifeCycle () : SPEM::LifeCycle inherits createCommonWorkDefinition when {self.isStereotypedBy("LifeCycle");} {} mapping UML::UseCase::createCompositeWorkDefinition () : SPEM::WorkDefinition inherits createCommonWorkDefinition when {self.isStereotypedBy("WorkDefinition");} {} mapping UML::Constraint::createPrecondition () : SPEM::Precondition { body := self.body; } mapping UML::Constraint::createGoal () : SPEM::Goal { body := self.body; } mapping UML::UseCase::addDependenciesInWorkDefinition () : SPEM::WorkDefinition merging addDependenciesInActivity { init { result := self.resolveone(WorkDefinition); var performers := self.getOppositeAends()[i|i.association [isStereotypedBy("perform")]->notEmpty()]; assert (not performers->size()>1) with log("A unique performer is allowed",self); } subWork := self.clientDependency[*includes].supplier ->resolveone(WorkDefinition); performer := if performers then performers->first() else createOrRetrieveDefaultPerformer() endif; } mapping UseCase::addDependenciesInActivity () : WorkDefinition when {self.stereotypedBy("Activity");} { assistant := self.getOppositeAends()[i|i.association [a|a.isStereotypedBy("assist")]->notEmpty()]->resolve(); }
Revised Text:
Actions taken:
April 30, 2007: received issue
November 7, 2007: closed issue

Issue 10979: Consider renaming 'AnonymousTuple' as 'OrderedTuple' (mof-qvt-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

'Anonymous tuple' is very long. Ordered tuple is similar to 'OrderedSet' in respect 
To 'Set'. Could be a better name.

Resolution: (1) In all the document, replace all references to AnonymousTuple by OrderedTuple. (2) For impact in diagrams apply the diagram updates as specified in Appendix D.
Revised Text:
Actions taken:
April 30, 2007: received issue
November 7, 2007: closed issue

Discussion:

Discussion:
Anonymous tuple is not a good name because it suggest that the tuple is anonymous whereas the intent is to indicate that the fields are anonymous.

Issue 10984: 7.11.3.1 Relation.operationalImpl (mof-qvt-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Relation.operationalImpl is shown in Fig 7.7, but not listed in 7.11.3.1.


It should be a composition (in both).

Resolution: Update the description of class Relation in section 7.11.3.1 as follows: Insert the folloing sentence in the description part before the sentence 'Please refer to sections 7.1 - 7.9 for a detailed description of the semantics, and section 12 for a more formal description in terms of a mapping to the core model.': A relation may optionally have an associated black-box operational implementation to enforce a domain. Add the following in the 'Associations' sub-section: operationalImpl: RelationImplementation [*] {composes} The set of black-box operational implementations, if any, that are associated with the relation to enforce its domains. Also update the the diagram given in Fig 7.7 'QVT Relation Package' to show the association from Relation to RelationImplementation as a composite.
Revised Text:
Actions taken:
April 30, 2007: received issue
November 7, 2007: closed issue

Issue 10985: Chapter 7 QVTrelation Standard Library (mof-qvt-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

There is a QVT Standard Library in Chapter 8, that the Pre-ballot 2 FTF report describes
as the QVT Operational Standard Library.


QVTrelation requires a library that at least defines:
String::+ as a synonym for String::concat


That part of the Chapter 8 library that is common to all QVT languages should appear in
its own chapter along with other parts of QVT that are common e.g. QVTbase.

Resolution: Add the following subsection in the concrete syntax section 7.13: Shorthands used to invoke pre-defined operations The binary operator "+" can be used as shorthand for the string concat operation.
Revised Text:
Actions taken:
April 30, 2000: received issue
November 7, 2007: closed issue

Issue 10986: Chapter 7 Collection::=() (mof-qvt-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The QVTrelation Standard library should define additional variants of '=' to accommodate the
permitted matching in predicates.


e.g.


        Set(T)::=(Bag(T))
        Set(T)::=T


which appears in the rel2core.


This avoids the need for detailed descriptions of type conversion schemes to handle
matching of collections and alternate-kind collections/scalars.

Resolution:
Revised Text:
Actions taken:
April 30, 2007: received issue
November 7, 2007: closed issue

Discussion:

No change
Please refer to the resolution of issue 10951.

Issue 10987: Chapter 7,8,9 EssentialOCL usage (mof-qvt-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The OCL spec identifies Essential OCL as a subset of the OCL Abstract Syntax.
The OCL spec does not identify an Essential OCL Concrete Syntax.


The QVT spec should define the Essential OCL Concrete Syntax as a listed subset of
OCL Concrete Syntax clauses. Presumably all productions in OCL section 9.3 but
perhaps excluding OclMessageExpCS, OclMessageArgumentsCS and OclMessageArgCS.


The QVT spec should clearly define whether all OCL keywords are also keywords
of QVT - a convenience to tool builders re-using OCL implementations, or
alternatively enumerate only those that are appropriate:


i.e. and, else, endif, if, implies, in, let, not, or, then, xor.


(omitting: attr, context, def, endpackage, inv, oper, package, post, pre)


Perhaps some counterpart to OCL Chapter 12 is required:
'The Use of OCL Expressions in QVT Models'

Resolution:
Revised Text:
Actions taken:
April 30, 2007: received issue
November 7, 2007: closed issue

Discussion:

Resolution: No change
This has already been fixed in the grammer given in Appendix A of the FTF report of ballot 2.

Issue 10988: Pre-ballot 2 FTF Appendix A: Erroneous collectionTemplate grammar (mof-qvt-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

[ '{' <memberSelection> '}' ] in collectionTemplate should be '{' [ <memberSelection> ] '}'

Resolution: Resolution: No change This has already been fixed in the grammer given in Appendix A of the FTF report of ballot 2
Revised Text:
Actions taken:
April 30, 2007: received issue
November 7, 2007: closed issue

Issue 10989: Pre-ballot 2 FTF Appendix A: Erroneous memberSelection grammar (mof-qvt-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

memberSelection has missing , in list


<memberSelection> ::= (<identifier> | <objectTemplate> | '_') (',' (<identifier> | <objectTemplate> | '_'))* '++' (<identifier> |
'_')

Resolution: closed, no change
Revised Text:
Actions taken:
April 30, 2000: received issue
November 7, 2007: closed issue

Discussion:

This has already been fixed in the grammer given in Appendix A of the FTF report of ballot 2.

Issue 10990: 8.4.3.5 = and == (mof-qvt-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Having two identical operators is redundant and so a bad idea.


Introducing a new operator that looks just like a C/Java comparison operator is
guaranteed to confuse all novices into thinking that = obviously means assignment.


So this friendly addition is really unfriendly to novices and redundant for experts.


Suggest: remove == so that novices learn that = is comparison very quickly.

Resolution: Resolved In Section 8.4.3 "Shorthands used to invoke specific pre-defined operations", remove 'both alternative should be available' in numbers 5 and 6. In addition, at the end of this section, add the following paragraph: """ The alternative '==' and '!=' notations can only be used if the source file pre-declares the intention of using them by means of a directive placed before entering the library of the transformation definitions. The syntax of this directive should be a comment having the following form: -- directive: use-traditional-comparison-syntax or // directive: use-traditional-comparison-sysntax This declaration makes illegal the usage of the corresponding OCL-like syntax ('=' and '<>') within the compilation unit.
Revised Text:
Actions taken:
April 30, 2007: received issue
November 7, 2007: closed issue

Discussion:

The QVT operational formalism is expected to target programmers for which the mismatch with usual C++ and Java "regular" notation for comparisons could be a serious problem. This has motivated the introduction of this flexibility in the notation. To mitigate possible confusion, the resolution makes mandatory the pre-declaration of the usage of Java-like convention and also forbids the mixed usage of the two conventions within a source file.

Issue 10991: 8.4.3.5 != and <> (mof-qvt-ftf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Having two identical operators is redundant and so a bad idea and certainly contrary
to the spirit of being an OCL extension.


Suggest: remove != so that novices learn that <> is difference in OCL.

Resolution: Resolved by applying the resolution of issue 10990.
Revised Text:
Actions taken:
April 30, 2007: received issue
November 7, 2007: closed issue

Discussion:

Issue 11022: Top-level constraint too restrictive (mof-qvt-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

The constraint prevents a usage of non top-level relations in a when clause which includes a negation expression. For example:

relation A { ... } 
relation B { ... when { not A() } } 
This issue is related to resolution of issue 10626 in 2nd ballot.

Resolution: This issue resolution invalidates the instruction resolution given by issue 10626. Modify the description of property 'isTopLevel' in section 7.11.3.1 as follows: isTopLevel : Boolean Indicates whether the relation is a top-level relation or a non-top-level relation. The execution of a transformation requires that all its toplevel relations must hold, whereas a non-top-level relation is required to hold only when it is invoked from another relation.
Revised Text:
Actions taken:
May 18, 2007: received issue
November 7, 2007: closed issue

Issue 11023: Typos and omissions in the QVT operational Part (mof-qvt-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

The QVT operational part have some typos, omissions as well as some english 
language errors that need to be corrected. 
For instance: 

(1) In Type Extensions sub-section: "to the type systems" => "to the type system". 
(2) In Typedef definition, repetition of "is never instantiated". 
(3)  In AnonymousTupleLiteralExp, TupLiteralPart does not exist. Should be 
      AnonymousTupleLiteralPart. The multiplicity of 'part' should be '*' and 'ordered' 
      is missing.

Resolution: Resolution: (1) In section 8.1.1 replace "if the source text file only defines�" by "if the source text file defines �". (2) In Section 8.1.2 replace "The UML and RDBMS refer to�" by "The UML and RDBMS model types refer to �". (3) In Section 8.1.2 replace "�the transformation writer may explicitly indicate �" by "�the transformation writer may indicate�" (this avoids repetition of explicit in the following sentence). Also replace 'to be build' by 'to be built' (English). (4) In Section 8.1.4, replace "is always a refinement of a relation�" by "is always a refinement of an implicit relation�" (5) In Section 8.1.4, replace "The packageToSchema mapping operation defined below defines �" by "The packageToSchema mapping operation below defines�" (avoid redundancy). (6) In Section 8.1.4, replace "rather than a creating �" "rather than creating �" (7) In Section 8.1.5 replace "Afterthat the list of expressions of the body of the object expressions are executed�" by "The list of expressions of the body of the object expression are then executed�" (8) In Section 8.1.5 replace "implicance" by "outcome" (9) In Section 8.1.5 replace "is described in �" by "in described in Section �" (10) In Section 8.1.6 replace "do not imples�" by "does not implies�" (11) In Section 8.1.6 replace "an object expression do not creates an instance if the target variable has a non null value." By an object expression, such as 'object x:X {�}', does not create an instance if the target variable - 'x' in the example - has a non-null value". (12) In Section 8.1.6 replace "is systematically�" by "will be systematically�" (13) In Section 8.1.6 replace "we are using here the "collect shorthand" by "we are using here the collect shorthand convention". Also use italics to mark 'collect shorthand'. (14) In Section 8.1.6 replace "that create instance" by "that creates instances" (15) In Section 8.1.7 replace"various mapping" by "various mappings" (16) In Section 8.1.7, in code '�getSqlType(a.type))}' remove the final closing brace. (17) In Section 8.1.7, replace "does not interleave" by "does not interleaves" (18) In Section 8.1.7, add blank space between "best" and "solution". (19) In Section 8.1.8, replace 'list += self.retrieveCandidates();' by 'list.append(self.retrieveCandidates())'. (20) In Section 8.1.9, replace 'Below an example' 'Below we provide an example'. (21) In Section 8.1.9, replace 'scope of transformation' by 'scope of the transformation' (22) In Section 8.1.10, replace '#Table' by 'Table' and remove "(the notation '#Table' is a shorthand for isKindOf(Table))" (23) In Section 8.1.10, remove 'to the invresolve operator' (24) In Section 8.1.10, remove the open and close parenthesis introduced after 'until the end of the transformation'. Insert a comma instead of the open parenthesis. (25) In Section 8.1.10, replace ', as in the' by '. The' (to create a new sentence) (26) In Section 8.1.10, replace '#JAVA::Interface' by 'JAVA:Interface' (27) In Section 8.1.10, replace 'We provide below a solution' by 'We provide below an equivalent solution'. (28) In Section 8.1.11, replace "real" by "and complex". Also, insert "To this end " before "The language�". (29) In Section 8.1.11 replace 'almost a mapping' by ''mappings'. (30) In Section 8.1.11 replace 'This occurs in rule 2 for Foo instance" by "This occurs in Rule 2 for the Foo instances" (31) In Section 8.1.13, in the code after 'Below and example' move the open brace so that it is after the closing bracket of the when clause and not after "JAVA::Constructor". Apply this for the two operations convertConstructor and convertOperation. (32) In Section 8.1.14, replace 'a anonymous' by 'an anonymous' (33) In Section 8.1.14, replace '_parentInstance' by 'container' (34) In Section 8.1.14, before the sentence 'A typedef can also�' inserts the sentence: "The '#Metaclass" notation - respectively '##Metaclass' - is a shorthand for isKindOf(Metaclass) - respectively isTypeOf(Metaclass). (35) In Section 8.1.15 replace 'confortable' by 'comfortable', 'realize' by 'realizes', remove 'some nice' and 'that we found'. (36) In Section 8.1.15, remove "'a block expression is not a function!). (37) In Section 8.1.15, replace 'the role of a for loop in Java' by 'the role of a loop instruction is Java language'. (38) In Section 8.1.15, replace 'that is not constrained' by 'that is less constrained' (39) In Section 8.1.15 replace the code starting with var x:= by the following simplified code: var x:= if (self.name.startsWith("_") "PROTECTED" elif (self.type.isPrimitive() "NORMAL" else "UNEXPECTED"; (40) At the beginning of Section 8.1.16, replace 'This�' by 'The variable this �' (41) In Section 8.1.18 replace the quotes around 'compiling' (42) In Section 8.1.18 replace the sentence 'Synchronization is done � of the transformation' by "Synchronization is achieved through the invocation of the wait operation on the status variable returned by the 'transform' operation. (43) In Section 8.1.18 replace 'tho two pim model' by 'the two PIM models' (44) In Section 8.1.18 replace "is a magical requirement to psm transformation" by "is a 'Requirement to PSM' transformation. (45) In Section 8.2.2.1, replace '� this package grouped into�' by '� this package are grouped into �' (46) In Section 8.2.1.1.1 Operational Transformation, add missing comma in 'that is,' after 'may define configuration properties'. (47) In Section 8.2.1.1.1, Operational Transformation replace 'TransformationInstanceExp' by 'InstantiationExp'. (48) In Section 8.2.1.1.1 Operational Transformation, in constraints subsection, replace all occurrences of '<>OclUndefined' by '.isOclUndefined()'. (49) In Section 8.2.1.1.1 Operational Transformation, in semantics subsection, remove "For convenience," and replace "is described" by "is described below" (50) In Section 8.2.1.1.1 Operational Transformation, in notation subsection, replace 'within brackets' by 'within braces'. Also replaces "using the refined keyword" by "using the refines keyword". (51) In Section 8.2.1.1.2 Library, replace 'no implementation' by 'this means that no implementation'. Also in semantics sub-section, remove 'for convenience' and replace 'is described' by 'is described below'. (52) In Section 8.2.1.1.2 Library, replace 'For each declared model types there is conceptually a �' by 'For each declared model type there is, conceptually, a �'. Also, in notation section, adds commas before and after "in this case". (53) In Section 8.2.1.4 ModuleImport, replace 'non library' by 'non-library' (54) In Section 8.2.1.5 ModelParameter, in notation sub-section,, remove "If the direction kind is not provided the in value is assumed". (55) In Section 8.2.1.6 ModelType, replace the sentence "The binding between �" by the sentence "See semantics sub-section for the binding rules between actual and effective types ". Also remove sentence "In both cases �" (since already in the semantics part). (56) In Section 8.2.1.6 Model Type, replace "To restrict the set of valid participant models further�" by "To restrict further the set of valid participant models �". (57) In Section 8.2.1.6 Model Type, in "Semantics of model compliance subsection", replace "In both cases (strict or effective), model compliance implies additionally to comply with extra constraints of the model type" by "In both cases - strict of effective - model compliance implies that all the extra conditions (see extraCondition property) are satisfied as well as any pre-existing well-formedness rule that exists for the associated metamodel. (58) In Section 8.2.1.6 Model Type, in "Semantics of model compliance subsection", remove sentence "Effective compliance allows defining� with UML 1.3 models" (since it is a repetition). (59) In Section 8.2.1.6 Model Type, in Notation sub-section, add missing double quote in example "modeltype UML uses SimpleUML�". (60) In Section 8.2.1.6 Model Type, in Notation sub-section, replace "A modeltype symbol" by "A modeltype declaration in a transformation signature" (61) In Section 8.2.1.6 ImperativeOperation, within the description of the ownedParameter association, replace "The other parameters of the operation" by "The list of parameters of the operation excluding the context and result parameters". (62) In Section 8.2.1.11 EntryOperation, replace "which is invoked on entry" by "which is invoked when the transformation execution starts". (63) In Section 8.2.1.11 Helper, replace "that is executed is sequence" by "that is executed in sequence". Also replace the sentence "The notation is the notation for any imperative operation �" by "The notation uses the standard convention for notating operations in UML except that the query or helper keywords are used to prefix the declaration. The latter 'helper' prefix is used when the operation provokes side-effects. Also, replace "He self variable�" by "The self variable �". (64) In Section 8.2.1.13 Constructor, replace "A constructor operation is implicitly or explicitly invoked through instantiation expression." by "A constructor operation can be explicitly invoked through an instantiation expression." (65) In Section 8.2.1.15 MappingOperation, add 'conceptually' after 'always refines'. Also, replace "This essentially means�" by "This means�" (three occurrences). Add commas sourrounding "among the set of disjuncted mappings". Replace "the details of the semantics of the reuse facilities" by "the details of these resuse facilities". Also replace 'refinedRelation: Relation[1]' by 'refinedRelation [0..1]' (consistency with OperationalTransformation:refined multiplicity), add 'if any' after 'the refined relation' and remove sentence 'The relation defines the guard�'.. (66) In Section 8.2.1.15 MappingOperation, semantics sub-section, replace "After passing of the parameters" by "After passing the parameters". Also, replace "of the actual object parameters and the�" by "of the actual parameters as well as�". Also replace "if the out parameter was�" "if the out parameters were�". (67) In Section 8.2.1.15 OperationBody, replace "which is made of an ordered list" by "which is an ordered list". Also in Notation sub-section, replace "semi colons" by "semi-colons". (68) In Section 8.2.1.18 ConstructorBody, replace "An constructor body" by "A constructor body". Also replace "semi colons" by "semi-colons". Add comma after 'body notation'. (69) In Section 8.2.1.19 MappingBody, replace initSection : OclExpression [0..1] {ordered} by initSection : OclExpression [0..*] {composes,ordered} (70) In Section 8.2.1.19 MappingBody, replace /content : OclExpression [0..*] {ordered} by /content : OclExpression [0..*] {composes,ordered} (from OperationBody) (71) In Section 8.2.1.19 MappingBody, replace endSection : OclExpression [0..1] {ordered} by endSection : OclExpression [0..*] {composes,ordered} (72) In Section 8.2.1.19 MappingBody, notation sub-section replaces "uses firstly braces" by "uses braces". Also replace "On the contrary," by "The" (to avoid double negation). Also replace "may be required is certain " by "may, however, be required in certain ". (73) In Section 8.2.1, sub-section "Concepts related with the usage of imperative operations", replace "related with" by "related to". (74) In Section 8.2.1.20, replace "Unless isScoped is true" by "Unless isVirtual is true". Also, in attributes sub-section, replace 'virtual : Boolean = true' by 'isVirtual : Boolean = true'. (75) In Section 8.2.1.20 ImperativeCallExp in notation sub-section, replace "An imperative call is notated as any other operation call where the source �" by " An imperative call is notated as any other operation call. The source �". Also, after "in terms of the execution semantics" adds "- the source is the transformation class itself, denoted by 'this' -". (76) In Section 8.2.1.21 MappingCallExp, replace "value of the strict" by "values of the isStrict". Also remove ", that is, provokes an exception if it evaluates to false". (77) In Section 8.2.1.21 MappingCallExp in Notation section, replace "is noateted as any other imperative operation call" by "is notated as any operation call". Also replace "is used when strict is true" by "is used when isStrict is true". Also replaces "Depending whether" by "If" and replaces "the call notation will require or not require a source object" by "the call requires a source object". In all the text replace "non strict" by "non-strict". (78) In Section 8.2.1.21 MappingCallExp in Notation section, replace "on a list" by "on a list as source". Also replace #Class by Class. (79) In Section 8.2.1.21 MappingCallExp in Notation section, Replace text from "We should note that �" to "as the source of the call" by "Invoking a mapping operation with a transformation instance as the source argument may be useful when a transformation make usage of other coarse-grained transformations (transformation composition)." (80) In Section 8.2.1.22 ResolveExp, replace "Finally, the last orthogonal variant," by "The last orthogional variant". Also replace "It is typically useful" by "It may be useful". (81) In Section 8.2.1.22 ResolveExp, sub-section semantics, replace "corresponding relation" by "corresponding implicit relation". Also replace parenthesis in "or, what is equivalent�", by dashes "-". Also add add comma after "In this sense" and remove comma in "see, AssignExp". Also remove "later - more precisely -" (82) In Section 8.2.1.24 ObjectExp, remove "specific" word. Replace "non null" by "non-null". Replace "All visible variables" by "All variables" Add comma after "When provided". Replace "list->object(x) {�} // shorthand for list->xcollect(x) object {�} by : "list->object(x) X{�} // shorthand for list->xcollect(x) object X{�} (83) In Section 8.2.2.3 ComputeExp, replace "defines body" by "defines a body". Replace "and return null" by "and returns null". In the definition of the body property, add the "{composes, ordered}" indication. (84) In Section 8.2.2.3 ImperativeLoopExp, replace "imperative loop constructs" by "imperative loop constructs such as". (85) In Section 8.2.2.6 ForExp adds commas before and after "whereas". Add the {composes, ordered} indication in '/iterator' property description. Replace 'Set(T)::forEach(source, iterator, condition, body) : Seq(TT)' by 'Collection(T)::forEach(source, iterator, condition, body)'. Also replace 'Set(T)::forOne(source, iterator, condition, body) : Seq(TT)' by 'Collection(T)::forOne(source, iterator, condition, body)'. Add "T represents the type of the source element". Adds the paragraph "Collection(T) is any collection type. When applying the for expression, if the source collection is not ordered it is implicitly converted into the corresponding ordered collection (Set and Bag become respectively OrderedSet and Sequence). Replace "is embedded with" by "is embedded within". (86) In Section 8.2.2.7 ImperativeIterateExp, in semantics sub-section, replace occurrences of Seq(T) as Collection(T) and replace occurrences of Seq(TT) as Sequence(TT). Also before "If the condition�" add the sentence: " When applying the imperative iterate expression, if the source collection is not ordered it is implicitly converted into the corresponding ordered collection (Set and Bag become respectively OrderedSet and Sequence). Replace "collectectSelect" by "collectselect". Also, add comma after "hence". (87) In Section 8.2.2.7 ImperativeIterateExp, remove repeated sentence "The target variable �". Replace "the target variable is implicit here" by "the iterator variable is implicit here". (88) In Section 8.2.2.8 SwitchExp in alternativePart property definition, replace {ordered} by {ordered, composes}. Also replace "Tre endif keyword can be skipped since it �" by "The endif keyword may be skipped. It �". Also replace "produces a grammar conflict in parsers that can can be solved through look ahead" by "may produce a grammar conflict in parsers which can, however, be solved through appropriate look-ahead. (89) In Section 8.2.2.10 VariableExp replaces "A variable initialization expression represents the declaration and the initialization of a variable" by "A variable initialization expression represents the declaration of a variable with an optional initialization value". Also replace "ImpertaiveExpression by ImperativeExpression". In the description of 'withReturn' property, add "The default value is false". Also remove the sentence "See the execution semantic section for the definition of scope rules". Replace "Multiple variable declaration" by "Multiple variable declarations". (90) In Section 8.2.2.11 AssignExp, replace "If the value filed�" by "If the provided value is made�". Also replace "by a deferred resolve expressions" by "by a deferred resolve expression". Remove sentence "See semantics details below. Replace "(but null if a fuure value is in right-hand side)" by "unless it is a future value, in which case null is returned". In 'isReset' description, add commas around "for a multivalued target". In association definitions adds the following indications: {composes, ordered} for value, {composes} for left and defaultValue. In Notation section, replace "'::=' object Node" by ":= objectNode". (91) In Section 8.2.2.11 TryExp, replace "catching of the exception occurs" by "catching of an exception occurs". (92) In Section 8.2.2.10 ContinueExp, replace "A continue expression is used, within an interation over a list of expressions" by "Within an interation over a list of expressions, a continue expression is used�". Also, replace "break" by "continue" and remove "- like the side-effect free OCL iterate expression." (93) In Section 8.2.2.19 AssertExp, replace "an qassertion holds" by "a condition holds". In Associations sub-section replace: "assertion: OclExpression [0..1]" by "assertion:OclExpression [1] {composes}. Also replace "(warning or fatal keywords)" by "- warning or fatal indentifiers - ". (94) In Section 8.2.2.23 InstantiationExp, replace the code after "the following shorthand can be used" by: column := self.attribute->new(a) Column(a.name,a.type.name); // equivalent code: // column := self.attribute->xcollect(a|new Column(a.name,a.type.name)); (95) In Section 8.2.2 Type Extensions sub-chapter, replace "are two mutable extensions of Collection Types" by "are two mutable collection types". (96) In Section 8.2.2.24, replace "A typedef allows to constraint" by "A typedef allows constraining". Remove "A typedef is never instantiated" and Remove "In the perspective of the runtime environment a typedef is never instantiated. Replace "This is specifically used" by "This may be used for". Remove the paragraph starting with "When the base class is not �". (97) In Section 8.2.2.25 ListType, replace "It contains an ordered �" by "A value conforming to this type contains an ordered �" (98) In Section 8.2.2.25 DictionaryType, replace "elments" by "elements" (99) In Section 8.2.2.28, replace "used in defining" by "used when defining". Also replace "ithin" by "within". Also replace "provide means" by "provide a mean". (100) In Section 8.2.2.29 DictLiteralExp, replace "part : OclExpression [1] {composes}" by "part : OclExpression [*] {composes, ordered}" (101) In Section 8.2.2.30 AnonymousTupleLiteralExp, replace 'consist' by 'consists'. Also replace 'TupLiteralPart' by 'OrderedTupleLiteralPart'.. replaces 'part : oclxpression [1] {composes}' by 'part : OclExpression [*] {composes, ordered}
Revised Text:
Actions taken:
May 18, 2007: received issue
November 7, 2007: closed issue

Discussion:

Comment: 
The resolution below provides a list of instructions to improve the quality of the text descriptions in QVT operational part by fixing straight-forward errors, providing reformulations for bad or poor english sentences, eliminating redundancies, fixing evident omissions or inconsistencies (like the missing 'composite' and 'ordered' marks in property descriptions in respect to the respective description in the diagram). Some of these corrections are taken from the notes made by S. Mellor during the review of the document.

Issue 11024: Any used instead of MOF::Object in operational type extensions (mof-qvt-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

In OCL the Any type does not includes primitive types. In ListType and DictType 
definitions the Any is used as the more general type for elements whereas Object 
should be used to allow types like dictionaries with string as keys.

Resolution: Within the text descriptions of the classes ListType, DictionaryType, AnonymousTupleType replace all occurrences of the word Any by the word Object. Also in Section 8.2.1.14 Type Extensions, replace 'the type Any is assumed' by 'the generic MOF type Object is assumed'.
Revised Text:
Actions taken:
May 18, 2007: received issue
November 7, 2007: closed issue

Issue 11025: Missing text for notation for class properties in Section 8.4.6 (mof-qvt-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

In 8.4.5 the text describes the notation for defining classes. However the notation 
For describing properties within classes is not indicated. Also notation for primitive 
data type is not indicated

Resolution: (1) In Section 8.4.5 replace the sentence: "The properties of a class are notated using a declarator made of: a name, a type, optional property qualifiers (derived, static, �) and a initialisation expression. isStatic : Boolean = 0; " By the following, text: "The properties of a class are notated using a declarator made of: a name, a type, optional property qualifiers and an optional initialisation expression. The general syntax pattern is: <qualifier>* <propname> ':' <typespec> ('=' <init>)? '<multiplicity>'? 'ordered'? (opposites <propname>)? For properties typed by primitive types or collection of primitive types, the valid property qualifiers are 'derived' and 'readonly' to represent respectively a derived attribute or a readonly attribute. When provided, the initialization value for a derived attribute represents the expression used to compute the value of the derived property. The syntax of multiplicity specification follows the regular convention from UML, where brackets sourrounds the definition (such as [0..1], [1], [*] and [0..*]). When absent the [0..1] multiplicity is assumed. Examples: isStatic : Boolean = 0; values : Sequence(String); derived size : Integer = self.ownedElement->size(); To indicate that an attribute acts as a qualifying identifier for the class, a stereotype qualifier named 'id' is used. The syntax for stereotyped qualifiers is: '<<' <IDENTIFIER> (',' <IDENTIFIER>)? '>>' Example: <<id> uuid:String [1]; // a mandatory qualifying uuid attribute For properties referencing non primitive types, the same syntax is used except that the 'composes' or 'references' qualifier is used to distinguish between composite or non composite association ends. The 'opposites' keyword is used to indicate the opposite property if any. Example: composes ownedElement : Element [*] ordered opposites namespace; references usedElement : Element [*]; (2) In Section 8.4.5, before "an enumeration type�" add the following sentence "A primitive type is declared using the 'primitive' keyword. 'primitive' <primitivetypename>. Example: primitive Double; (3) In Section 8.4.5, after presenting the notation for primitive types, adds the following sentence. An exception is declared using the 'exception' keyword followed by the name of the exception. Inheritance between exceptions is introduced usin the 'extends' keyword. Example: exception VeryStrangeException extends UnexpectedException; Remark: For the BNF grammar modification see resolution of 10026. Note: Fix in resolution text: (opposites <propname>)? Should be replaced by (opposites '~' ? <propname> <multiplicity>?) to be inline with grammar. Also, after 'the opposite property if any.' add "When present, the '~' annotation indicates that the opposite property is not navigable".
Revised Text:
Actions taken:
May 18, 2007: received issue
November 7, 2007: closed issue

Discussion:

Comment:
The syntax for EMOF properties was very partially defined. The resolution takes into account all charateristics of EMOF properties: multiplicity, is Id, readonly and so on.
The notation for declaring primitives as well as the notation for declaring exceptions is also defined.

Issue 11026: Some errors in BNF grammar of the operational part (mof-qvt-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

The grammar defined by the resolution of issue 10923 still contains some errors. 
For instance the expression is missing in the <elif_part> definition. Also some 
uniformity could be achieved in the names of BNF rules, like using always "_header" 
suffix instead of using sometiimes "_header" and sometimes "_h". 

---------------------------------------------------------------------------------------------------------------------------

Resolution: This resolution replaces the resolution given by issue 10923 (2nd Ballot) (1) Replaces the BNF grammar with the following: // keywords Bag, Collection, Dict, OrderedSet, Sequence, Set, Tuple, abstract, access, and, any, assert, blackbox, break, case, class, collect, collectNested, collectOne, collectselect, collectselectOne, composes, compute, configuration, constructor, continue, datatype, default, derived, disjuncts, do, elif, else, end, endif, enum, except, exists, extends, exception, false, forAll, forEach , forOne, from, helper, if, implies, import , in, inherits, init, inout, intermediate, invresolve, invresolveIn, invresolveone, invresolveoneIn , isUnique, iterate, late, let, library, literal, log, main, map, mapping, merges, metamodel, modeltype, new, not, null, object, one, or, ordered, out, package, population, primitive, property, query, raise, readonly, references, refines, reject, resolve, resolveIn, resolveone, resolveoneIn, return, select, selectOne, sortedBy, static, switch, tag, then, transformation, true, try, typedef, unlimited, uses, var, when, where, while, with, xcollect , xmap, xor, xselect // start rule <topLevel> ::= <import>* <unit_element>* <import> ::= 'from' <unit> 'import' (<identifier_list> | '*') ';' | 'import' <unit> ';' <unit> ::= <identifier> ('.' <identifier>)* <identifier_list> ::= <identifier> (',' <identifier>)* // definitions in a compilation unit <unit_element> ::= <transformation> | <library> | <access_decl> | <modeltype> | <metamodel> | <classifier> | <property> | <helper> | <constructor> | <entry> | <mapping> | <tag> | <typedef> // Transformation and library definitions <transformation> ::= <transformation_decl> | <transformation_def> <transformation_decl> ::= <transformation_h> ';' <transformation_def> ::= <transformation_h> '{' <module_element>* '}' ';'? <library> ::= <library_decl> | <library_def> <library_decl> ::= <library_h> ';' <library_def> ::= <library_h> '{' <module_element>* '}' ';'? // Transformation header <transformation_h> ::= <qualifier>* 'transformation' <identifier> <transformation_signature> <transformation_usage_refine>? <transformation_usage_refine> ::= <module_usage> | <transformation_refine> <transformation_signature> ::= <simple_signature> <transformation_refine> ::= 'refines' <moduleref> // Library header <library_h> ::= 'library' <identifier> <library_signature>? <module_usage>? <library_signature> ::= <simple_signature> // import of transformation and library <module_usage> ::= <access_usage> | <extends_usage> <access_usage> ::= 'access' <module_kind>? <moduleref_list> <extends_usage> ::= 'extends' <module_kind>? <moduleref_list> <module_kind> ::= 'transformation' | 'library' <moduleref_list> ::= <moduleref> (',' <moduleref>)* <moduleref> ::= <scoped_identifier> <simple_signature>? <access_decl> ::= <access_usage> ';' // module definitions <module_element> ::= <classifier> | <property> | <helper> | <constructor> | <entry> | <mapping> | <tag> | <typedef> | <access_decl> // general purpose grammar rules <qualifier> ::= 'blackbox' | 'abstract' | 'static' <complete_signature> ::= <simple_signature> (':' param_list)? <simple_signature> ::= '(' <param_list>? ')' <param_list> ::= <param> (',' <param>)* <param> ::= <param_direction>? <declarator> <param_direction> ::= 'in' | 'inout' | 'out' <simple_declarator> ::= <typespec> | <scoped_identifier> ':' <typespec> <declarator> ::= <typespec> <init_part>? | <scoped_identifier> ':' <typespec> <init_part>? <simple_declarator_list> ::= <simple_declarator> (',' <simple_declarator>)* <declarator_list> ::= <declarator> (',' <declarator>)* <declarator_semi_list> ::= <declarator> (';' <declarator>)* <init_part> ::= <init_op> <expression> <init_op> ::= '=' | ':=' | '::=' <typespec> ::= <type_reference> <extent_location>? <type_reference> ::= <scoped_identifier> | <complex_type> <extent_location> ::= '@' <identifier> <complex_type> ::= <complex_type_key> | <collection_key> '(' <typespec> ')' | 'Tuple' '(' <declarator_list> ')' | 'Dict' '(' <typespec> ',' <typespec> ')' <complex_type_key> ::= <collection_key> | 'Dict' | 'Tuple' <collection_key> ::= 'Collection' | 'Set' | 'OrderedSet' | 'Sequence' | 'Bag' | 'List' <scoped_identifier> ::= <identifier> ('::' <identifier>)* <scoped_identifier_list> ::= <scoped_identifier> (',' <scoped_identifier>)* <expression_list> ::= <expression_semi_list> ';'? <expression_semi_list> ::= <expression> (';' <expression>)* <expression_comma_list> ::= <expression> (',' <expression>)* <expression_block> ::= '{' <expression_list>? '}' <expression_statement> ::= <expression> ';' | <expression_block> ';'? // model types compliance and metamodel declarations <modeltype> ::= 'modeltype' <identifier> <compliance_kind>? 'uses' <packageref_list> <modeltype_where>? ';' <modeltype_where> ::= 'where' <expression_block> <packageref_list> ::= <packageref> (',' <packageref>)* <packageref> ::= (<scoped_identifier> ( '(' <uri> ')' )? | <uri>) <compliance_kind> ::= <STRING> // like: "strict" and "effective" <uri> ::= <STRING> // Syntax for defining explicitly metamodel contents <metamodel> ::= <metamodel_decl> | <metamodel_def> <metamodel_decl> ::= <metamodel_h> ';' <metamodel_def> ::= <metamodel_h> '{' <metamodel_element>* '}' ';'? <metamodel_h> ::= ('metamodel' | 'package') scoped_identifier <metamodel_element> ::= <classifier> | <enumeration> | <tag> <classifier> ::= <classifier_decl> | <classifier_def> <classifier_decl> ::= <classifier_h> ';' <classifier_def> ::= <classifier_h> '{' <classifier_feature_list>? '}' ';'? <classifier_h> ::= <classifier_info> <scoped_identifier> <classifier_extension>? <classifier_info> ::= 'datatype' | 'primitive' | 'exception' | 'intermediate'? <qualifier>* 'class' <classifier_extension> ::= 'extends' <scoped_identifier_list> <classifier_feature_list> ::= <classifier_feature> (';' <classifier_feature>)* ';'? <classifier_feature> ::= <classifier_property> | <classifier_operation> | <tag> <classifier_property> ::= <feature_qualifier>? <declarator> <multiplicity>? <opposite_property>? <feature_qualifier> ::= <stereotype_qualifier>? <feature_key>* <feature_key> ::= 'composes' | 'references' | 'readonly' | 'derived' | 'static' <stereotype_qualifier> ::= '<<' <identifier_list> '>>' <multiplicity> ::= '[' multiplicity_range ']' <multiplicity_range> ::= <INTEGER> | '*' | <INTEGER> '...' <INTEGER> | <INTEGER> '...' '*' <classifier_operation> ::= <feature_qualifier>? <declarator> <complete_signature> <enumeration> ::= <enumeration_h> ';' | <enumeration_h> '{' <identifier_list> '}' ';'? <enumeration_h> ::= 'enum' <identifier> <opposite_property> ::= 'opposites' '~' <identifier> <multiplicity>? <tag> ::= 'tag' <tagid> <scoped_identifier> ('=' <tagvalue>)? ';' <tagid> ::= <STRING> <tagvalue> :: <expression> // typedefs <typedef> ::= 'typedef' <identifier> '=' <typespec> (typedef_condition)? ';' <typedef_condition> ::= '[' <expression> ']' // Properties in transformation <property> ::= 'intermediate'? <property_key>+ <declarator> ';' <property_key> ::= 'derived' | 'literal' | 'configuration' | 'property' // Syntax for helper operations <helper> ::= <helper_decl> | <helper_simple_def> | <helper_compound_def> <helper_header> ::= <helper_info> <scoped_identifier> <complete_signature> <helper_info> ::= <qualifier>* <helper_kind> <helper_kind> ::= 'helper' | 'query' <helper_decl> ::= <helper_header> ';' <helper_simple_def> ::= <helper_header> '=' <expression> ';' <helper_compound_def> ::= <helper_header> <expression_block> ';'? // Syntax for constructors <constructor> ::= <constructor_decl> | <constructor_def> <constructor_header> ::= <qualifier>* 'constructor' <scoped_identifier> <simple_signature> <constructor_decl> ::= <constructor_header> ';' <constructor_def> ::= <constructor_header> <expression_block> ';'? // Syntax for entries <entry> ::= <entry_decl> | <entry_def> <entry_header> :: 'main' <simple_signature> <entry_decl> ::= <entry_header> ';' <entry_def> ::= <entry_header> <expression_block> ';'? // syntax for mapping operations <mapping> ::= <mapping_decl> | <mapping_def> <mapping_decl> ::= <mapping_full_header> ';' <mapping_def> ::= <mapping_full_header> '{' <mapping_body> '}' ';'? <mapping_full_header> ::= <mapping_header> <when>? <where>? <mapping_header> ::= <qualifier>* 'mapping' <param_direction>? <scoped_identifier> <complete_signature> <mapping_extra>* <mapping_extra> ::= <mapping_extension> | <mapping_refinement> <mapping_extension> ::= <mapping_extension_key> <scoped_identifier_list> <mapping_extension_key> ::= 'inherits' | 'merges' | 'disjuncts' <when> ::= 'when' <expression_block> <where> ::= 'where' <expression_block> <mapping_refinement> ::= 'refines' <scoped_identifier> <mapping_body> ::= <init_section>? <population_section>? <end_section>? <init_section> ::= 'init' <expression_block> <population_section> ::= <expression_list> | 'population' <expression_block> <end_section> ::= 'end' <expression_block> // Expressions <expression> ::= <assign_exp> | <let_exp> | <var_init_exp> <assign_exp> ::= <implies_exp> | <unary_exp> <assign_op> <expression> <default_val>? | <unary_exp> <assign_op> <expression_block> <default_val>? | <assign_op> := ':=' | '::=' | '+=' | '-=' <default_val> ::= 'default' <assign_exp> <implies_exp> ::= <or_exp> | <implies_exp> 'implies' <or_exp> <or_exp> ::= <and_exp> | <or_exp> <or_op> <and_exp> <or_op> ::= 'or' | 'xor' <and_exp> ::= <cmp_exp> | <and_exp> 'and' <cmp_exp> <cmp_exp> ::= <additive_exp> | <cmp_exp> <cmp_op> <additive_exp> <cmp_op> ::= '=' | '==' | '<>' | '<' | '>' | '<=' | '>=' <additive_exp> ::= <mult_exp> | <additive_exp> <add_op> <mult_exp> <add_op> ::= '+' | '-' <mult_exp> ::= <unary_exp> | <mult_exp> <mult_op> <unary_exp> <mult_op> ::= '*' | '/' | '%' <unary_exp> ::= <postfix_exp> | <unary_op> <unary_exp> <unary_op> ::= '-' | 'not' | '#' | '##' | '*' <postfix_exp> ::= <primary_exp> | <postfix_exp> '(' <arg_list>? ')' | <postfix_exp> '!'? '[' <declarator_vsep>? <expression> ']' | <postfix_exp> <access_op> (<scoped_identifier> | <iterator_exp> | <block_exp> | <control_exp> | <rule_call_exp> | <resolve_exp> | <resolve_in_exp>) <declarator_vsep> ::= <simple_declarator> '|' <multi_declarator_vsep> ::= <simple_declarator_list> '|' <resolve_exp> ::= <resolve_key> '(' <resolve_condition>? ')' <resolve_condition> ::= <declarator> ('|' <expression>)? <resolve_key> ::= 'late'? <resolve_kind> <resolve_kind> ::= 'resolve' | 'resolveone' | 'invresolve' | 'invresolveone' <resolve_in_exp> ::= <resolve_in_key> '(' <scoped_identifier> (',' <resolve_condition>)?')' <resolve_in_key> ::= 'late'? <resolve_in_kind> <resolve_in_kind> ::= 'resolveIn' | 'resolveoneIn' | 'invresolveIn' | 'invresolveoneIn' <access_op> ::= '.' | '->' | '!->' <primary_exp> ::= <literal> | <scoped_identifier> | <if_exp> | <block_exp> | <control_exp> | <rule_call_exp> | <quit_exp> | <try_exp> | <raise_exp> | <assert_exp> | <log_exp> | '(' <expression> ')' <literal> ::= <literal_simple> | <literal_complex> <literal_simple> ::= <INTEGER> | <FLOAT> | <STRING> | 'true' | 'false' | 'unlimited' | 'null' <literal_complex> ::= <literal_collection> | <literal_tuple> | <literal_dict> <literal_collection> ::= <collection_key> '{' <collection_item_list>? '}' <literal_tuple> ::= 'Tuple' '{' <tuple_item_list>? '}' <literal_dict> ::= 'Dict' '{' <dict_item_list>? '}' <collection_item_list> ::= <expression_comma_list> <tuple_item_list> ::= <declarator_list> <dict_item_list> ::= <dict_item> (',' <dict_item>)* <dict_item> ::= <literal_simple> '=' <expression> <if_exp> ::= 'if' <expression> <then_part> <elif_part>* <else_part>? 'endif' <then_part> ::= 'then' <if_body> <elif_part> ::= 'elif' <if_body> <else_part> ::= 'else' <if_body> <if_body> ::= <expression> | <expression_block> <iterator_exp> ::= <simple_iterator_op> '(' <declarator_vsep>? <expression> ')' | <multi_iterator_op> '(' <multi_declarator_vsep>? <expression> ')' | <iterate_exp> <simple_iterator_op> ::= 'reject' | 'select' | 'collect' | 'exists' | 'one' | 'any' | 'isUnique' | 'collectNested' | 'sortedBy' | 'xselect' | 'xcollect' | 'selectOne' | 'collectOne' | 'collectselect' | 'collectselectOne' <multi_iterator_op> ::= 'forAll' <iterate_exp> ::= 'iterate' '(' <declarator_list> ';' <declarator> '|' <expression> ')' <iter_declarator> ::= <declarator> <iter_declarator_list> ::= <declarator_list> <block_exp> ::= (<object_exp> | <do_exp> | <switch_exp>) <object_exp> ::= 'object' ('(' <iter_declarator> ')')? <object_declarator> <expression_block> <object_declarator> ::= <typespec> | <identifier> ':' <typespec>? <do_exp> ::= 'do' <expression_block> <switch_exp> ::= 'switch' ('(' <iter_declarator> ')')? <switch_body> <switch_body> ::= '{' <switch_alt>+ <switch_else>? '}' <switch_alt> ::= 'case' '(' <expression> ')' <expression_statement> <switch_else> ::= 'else' <expression_statement> <control_exp> ::= (<while_exp> | <compute_exp> | <for_exp>) <while_exp> ::= 'while' '(' (<declarator> ';')? <expression> ')' <expression_block> <compute_exp> ::= 'compute' '(' <declarator> ')' <expression_block> <for_exp> ::= ('forEach' | 'forOne') '(' <iter_declarator_list> (';' <declarator>)? ('|' <expression>)? ')' <expression_block> <rule_call_exp> ::= ('map' | 'xmap' | 'new' ) ('(' <declarator> ')')? <scoped_identifier> <let_exp> ::= 'let' <declarator_list> 'in' <expression> <var_init_exp> ::= 'var' <declarator_list> | 'var' '(' <declarator_list> ')' <quit_exp> ::= 'break' | 'continue' | <return_exp>) <return_exp> ::= 'return' <expression>? <try_exp> ::= 'try' <expression_block> <except>+ <except> ::= 'except' '(' <scoped_identifier_list> ')' <expression_block> <raise_exp> ::= 'raise' <scoped_identifier> ('(' <arg_list>? ')')? <arg_list> ::= <expression_comma_list> <assert_exp> ::= 'assert' <identifier>? '(' <expression> ')' ( 'with' <log_exp> )? <log_exp> ::= 'log' '(' <arg_list> ')' ('when' <expression>)?
Revised Text:
Actions taken:
May 18, 2007: received issue
November 7, 2007: closed issue

Discussion:

Comment

New version of grammar is given. This version in addition to fix some errors uniformizes some conventions: 
-	Having separated rules to distinguish a definition for a declaration (like a helper declaration versus helper definition).
-	Renaming suffix '_h' as '_header'
The grammar assumes resolution text for issue 11025.

Issue 11057: Missing notation to indicate the enforced direction in mapping operations (mof-qvt-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

The enforced direction cannot be indicated when the 'refined' keyword is used to 
Indicate that a mapping operation refines a relation

Resolution: (1) In Section 8.2.1.1 OperationalTransformation, replaces the sentence starting with "When an operational transformation refines a relational transformation, �" by the following sentence: "An operational transformation may be explicitly declared as the 'refinement' of a relational transformation. In that case each model parameter in the operational transformation corresponds to a typed model in the relational transformation. The enforced direction is the one corresponding to the output parameter of the operational transformation". Also remove constraint concerning enforcedDirection. (2) In Section 8.2.1.1 OperationalTransformation, removes the enforcedDirection property definition. Note: This resolution also implies removing the first constraint in Constraints section of 8.2.1.1 section.
Revised Text:
Actions taken:
May 24, 2007: received issue
November 7, 2007: closed issue

Discussion:

Comment
The indication of the enforced direction of a transformation is not needed because it is derived from the signature of transformation. The same is for the relationship between mapping operations and relations. In the current specification, the Transformation::enforcedDirection is defined in the class description but not in the diagram. In fact we can remove from the class description if we define how the enforced direction is deduced from the transformation signature.

Issue 11059: Inconsistency in definition of TryExp with figure (mof-qvt-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

The tryBody property is multivalued in the class description but monovalued in the 
Diagram. What is the correct multiplicity?

Resolution: (1) In the class description of TryExp, in the property 'tryBody' description add the '{composes, ordered}' mention. (2) In the class description of TryExp, replaces the exceptBody property by the following: exceptClause : CatchExp [*] {composes, ordered} The exception clauses providing the code to execute in case of failure. (3) In the class description of TryExp, removes the 'exception : Type' property description. (4) Replaces the exceptBody property by the following: exceptClause : CatchExp [*] {composes, ordered} The exception clauses providing the code to execute in case of failure. (5) After the section describind the TryExp, add a new section to describe the CatchExp class with the following content.: """ A catch expression represents the the code to be executed when a exception matching a given list of exception types is fired durin the execution of the containing try expression. Superclasses ImperativeExpression Associations exception : Type [*] {ordered} The list of exceptions being treated by this catch handler. body : OclExpression [*] {composes, ordered} The list of expressions to execute in sequence. Notation: The notation uses the 'except' keyword with the list of exception types in parenthesis and the body in braces. except (exception1,exception2) { expression1; � } (5) Update Figure 8.6 anf Figure 8.3 using the new version of Appendix D of this report. Remark: For the BNF grammar modification see resolution of 10026.
Revised Text:
Actions taken:
May 24, 2007: received issue
November 7, 2007: closed issue

Discussion:

Comment:
The try body and the exception bodies are sequence of expressions.
The resolution also fixes an unexpected restriction in the number of exception clauses that can be defined which one limited to one.

Issue 11060: Consider adjusting the notation for unpack (mof-qvt-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

The notation x,y, z = foo() may be difficult to parse. Consider revising it. 
For instance using parenthesis: (x,y,z) = foo(). 
Also consider extending this notation to non anonymous tuples

Resolution: 1) In Section 8.2.2.22, add a property named 'source' with the following definition: source : OclExpression [1] {composes} The source expression to be unpacked. The type of the expression should necessarily be an ordered tuple. (2) In Section 8.2.2.22, rename the property 'variable' as 'targetVariable' (3) In Section 8.2.2.22, in the Notation section, replace all the text by the following: The notation is similar to an assignment expression except that the list of variables is in parenthesis and prefixed by the var keyword. var (x,y,z) := self.foo(); // assuming 'foo' returns a tuple of three elements 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(); es equivalent to: var x:X; var y:Y; var (x,y,z) := foo(); (3) Update the diagram 8.6 as given by appendix D
Revised Text:
Actions taken:
May 24, 2007: received issue
November 7, 2007: closed issue

Discussion:

The source expression to be unpacked is missing in the description of the UnpackExp class. This resolution also fix this problem. There is no need to extend the notation to OCL tuples since the conversion operation asOrderedTuple can be called previous to unpacking the tuple.

Issue 11062: Argument list missing in raise expression (mof-qvt-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

The RaiseExp does not allow the possibility to pass ramaters to the exception. 
Also, the use of strings instead of exception class references should be clarified

Resolution: (1) In Section 10.2.2.14 RaiseExp, add the following property: argument : OclExpression [0..1] {composes} - The argument accompagning the raised exception (2) Apply update of diagram Figure 8.6 as defined in Appendix D Updated Diagrams -2nd ballot.. (3) Within the Notation sub-section, after "can be provided a simple strings." Add the sentence: In that case the implicit referred exception is the user Exception defined in the QVT standard library and the string is the argument of the raise expression. (4) Within the Section 8.3.1 Predefined Types, add, after Status definition, a new sub-section named Exception with the following definition: "This M1 class named Exception represents a base class for all instantiated Exceptions. It is itself an instance of the Exception metatype. For any impact in BNF see resolution of issue 10026.
Revised Text:
Actions taken:
May 24, 2007: received issue
November 7, 2007: closed issue

Issue 11063: Consider using the case keyword within swith expression (mof-qvt-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

Consider using the 'case' keyword within swith expressions to have a similar 
notation as in other languages.

Resolution: In Section8.2.2.8 SwitchExp, replace the code after "following syntax pattern" by switch { case cond1 ? exp1; case cond2 ? exp2; � else ? expN; } For the change in the BNF grammar, see resolution of issue 10026.
Revised Text:
Actions taken:
May 24, 2007: received issue
November 7, 2007: closed issue

Issue 11064: Consider using the package keyword instead of metamodel (mof-qvt-ftf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

In Section 8.4.5 Notation for metamodels, the keyword 'package' could be more appropriate 
to represent nested packages within a metamodel definition or even a package containing 
only tags

Resolution: (1) In section 8.4.5, replace "A MOF Package is notated using the metamodel keyword followed by a name" by "A MOF Package is notated either using the 'package' keyword or the 'metamodel' keyword followed by a name. Both notations are equivalent when translating to the corresponding EMOF metamodel representation. The 'metamodel' keyword should preferably be used when referring to a top-level package that represents a complete metamodel. For the impact in BNF grammar, see issue resolution for 10026.
Revised Text:
Actions taken:
May 24, 2007: received issue
November 7, 2007: closed issue