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: EDS (Ms. Susan Entwisle, susan.entwisle@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: EDS (Ms. Susan Entwisle, susan.entwisle@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: EDS (Ms. Susan Entwisle, susan.entwisle@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: EDS (Ms. Susan Entwisle, susan.entwisle@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: EDS (Ms. Susan Entwisle, susan.entwisle@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@orange-ftgroup.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@orange-ftgroup.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@orange-ftgroup.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@orange-ftgroup.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@orange-ftgroup.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@orange-ftgroup.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@orange-ftgroup.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@orange-ftgroup.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@orange-ftgroup.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@orange-ftgroup.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@orange-ftgroup.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@orange-ftgroup.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@orange-ftgroup.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@orange-ftgroup.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@orange-ftgroup.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@orange-ftgroup.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@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.
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: THALES (Dr. Edward Willink, ed.willink@thalesgroup.com ed@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: THALES (Dr. Edward Willink, ed.willink@thalesgroup.com ed@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: THALES (Dr. Edward Willink, ed.willink@thalesgroup.com ed@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: THALES (Dr. Edward Willink, ed.willink@thalesgroup.com ed@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: THALES (Dr. Edward Willink, ed.willink@thalesgroup.com ed@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: THALES (Dr. Edward Willink, ed.willink@thalesgroup.com ed@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: THALES (Dr. Edward Willink, ed.willink@thalesgroup.com ed@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: THALES (Dr. Edward Willink, ed.willink@thalesgroup.com ed@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: THALES (Dr. Edward Willink, ed.willink@thalesgroup.com ed@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: THALES (Dr. Edward Willink, ed.willink@thalesgroup.com ed@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: THALES (Dr. Edward Willink, ed.willink@thalesgroup.com ed@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: THALES (Dr. Edward Willink, ed.willink@thalesgroup.com ed@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: THALES (Dr. Edward Willink, ed.willink@thalesgroup.com ed@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: THALES (Dr. Edward Willink, ed.willink@thalesgroup.com ed@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: THALES (Dr. Edward Willink, ed.willink@thalesgroup.com ed@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: THALES (Dr. Edward Willink, ed.willink@thalesgroup.com ed@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@orange-ftgroup.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@orange-ftgroup.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 u