memberSelection has missing , in list

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

closed, no change

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.

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.

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

'
Correct the type of OperationalTransformation:refined so that
it is a RelationalTransformation (instead of 'Transformation')

duplicate of issue 9383, close

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

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.

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

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
"""

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

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.
"""

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.

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.

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: 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.

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.)

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.

Inconsistent font for first line of 7.13.1.

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.

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

Resolution: No change

Remark:
Looks like there was a mistake in entering the issue - OCL specifies OperationCallExpCS only.

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

excluding collectionType that is ambiguous wrt collectionTemplate syntax

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.

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

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.

Relations to Core uses a top of domain memberSelectionExprCS.

In <dommain>
Replace: '

'
By: '

'
Or rather: '

'

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.

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>

and use this new construct as:

Replace: <when> ::= 'when' '

'
By: <where> ::= 'where' '

' ]

In <query>
Replace: ';' | '

'
By: ';' | '

'

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.

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

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.

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>

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.

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

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

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.

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>)*)

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.

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> '

' ';'
By: <keyDecl> ::= 'key' <classId> '

' ';'

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

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.

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

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.
"""

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

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.

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.

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.

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.

(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.

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.

(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.

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)

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"

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

In Figure 8.5, replace the multiplicity of role target:Variable to '0..1' (instead of '1').

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.

(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 "

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

In Figure 8.7, indicate the multiplicity of AnonymousLiteralPart::value
to be equal to "1".

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
(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.

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

And make the multiplicity of ObjectExp::referredObject equal to '1'

(1) In Section 8.2.1.17 (OperationBody), add the association
"""
variable : [*] Variable

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'.

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.

(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, out dest2);
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
"""
(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.
"""

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

Duplicate of issue 9254, close

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'

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.

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.

(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"

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

'
Correct the type of OperationalTransformation:refined so that
it is a RelationalTransformation (instead of 'Transformation')

(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

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

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

In figure 7.7, replace 'whenOwner' by 'whereOwner'
and 'whereOwner' by 'whenOwner'

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

(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

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.

(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]

"
Make the corresponding change in figure 7.7.

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.

(1) In 7.11.1.6, replaces "bindsTo: Variable [*]

"
by "bindsTo: Variable [0..1]"
and in Figure 7.6 removes the corresponding composition symbol

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”

In Section 8.2.2.24, remove the sentence "A Typedef is never instantiated"

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

closed no change

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

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".

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

closed no change

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

In Figure 8.4 and Figure 8.5, rename CollectorExp as ImperativeIterateExp
(because CollectorExp is in fact an old name for ImperativeIterateExp).

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.

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".

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

In Section8.2.2.8 SwitchExp, replace the code after "following syntax pattern" by
switch

For the change in the BNF grammar, see resolution of issue 10026.

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

(1) In Section 10.2.2.14 RaiseExp, add the following property:
argument : OclExpression [0..1]

- 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.

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

(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.

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

(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.

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".

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

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> | '*') ';'

<identifier_list> ::= <identifier> (',' <identifier>)*

// definitions in a compilation unit
<unit_element>
::= <transformation>

// Transformation and library definitions

<transformation> ::= <transformation_decl> | <transformation_def>
<transformation_decl> ::= <transformation_h> ';'
<transformation_def> ::= <transformation_h> '

' ';'?

// 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>

// 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>

// 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_h> ::= ('metamodel' | 'package') scoped_identifier
<metamodel_element> ::= <classifier> | <enumeration> | <tag>

<classifier> ::= <classifier_decl> | <classifier_def>
<classifier_decl> ::= <classifier_h> ';'
<classifier_def> ::= <classifier_h> '

' ';'?

<classifier_h> ::= <classifier_info> <scoped_identifier> <classifier_extension>?
<classifier_info> ::= 'datatype'

<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> ::= '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_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>

// Expressions

<expression> ::= <assign_exp>

<assign_exp> ::= <implies_exp>

<assign_op> := ':=' | '::=' | '+=' | '-='

<default_val> ::= 'default' <assign_exp>

<implies_exp> ::= <or_exp>

<or_exp> ::= <and_exp>

<or_op> ::= 'or' | 'xor'

<and_exp> ::= <cmp_exp>

<cmp_exp> ::= <additive_exp>

<cmp_op> ::= '=' | '==' | '<>' | '<' | '>' | '<=' | '>='

<additive_exp> ::= <mult_exp>

<add_op> ::= '+' | '-'

<mult_exp> ::= <unary_exp>

<mult_op> ::= '*' | '/' | '%'

<unary_exp> ::= <postfix_exp>

<unary_op> ::= '-' | 'not' | '#' | '##' | '*'

<postfix_exp> ::= <primary_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>

<literal> ::= <literal_simple>

<literal_simple> ::= <INTEGER> | <FLOAT> | <STRING>

<literal_complex> ::= <literal_collection>

<literal_collection> ::= <collection_key> '

'

<literal_tuple> ::= 'Tuple' '

'

<literal_dict> ::= 'Dict' '

'

<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> ')'

<simple_iterator_op> ::= 'reject' | 'select' | 'collect' | 'exists'

<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> ::= '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>

<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>)?

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

1) In Section 8.2.2.22, add a property named 'source' with the following definition:
source : OclExpression [1]

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

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

(1) In the class description of TryExp, in the property 'tryBody' description add the '

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 [*]

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)

(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.

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

(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".

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.

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'.

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:

(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

// shorthand for list->xcollect object

// shorthand for list->xcollect 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 "

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

by

. 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:

"
(101) In Section 8.2.2.30 AnonymousTupleLiteralExp, replace 'consist' by 'consists'. Also replace 'TupLiteralPart' by 'OrderedTupleLiteralPart'.. replaces 'part : oclxpression [1]

' by 'part : OclExpression [*]

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

}
This issue is related to resolution of issue 10626 in 2nd ballot.

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.

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.

Resolved by applying the resolution of issue 10990.

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.

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.

[ '

' ] in collectionTemplate should be '

'

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

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'

No Data Available

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.

No Data Available

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

(1) Replace the contents of A2.1: Operational Mapping Examples by the following:

metamodel BOOK {
class Book

class Chapter

}

metamodel PUB {
class Publication

}

transformation Book2Publication(in bookModel:BOOK,out pubModel:PUB);

main()

mapping Class::book_to_publication () : Publication

(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()

– Applies the transformation to each class of the package

mapping inout Package::encapsulateAttributesInPackageClasses () {
init

}

– 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

operation := { – assignment with additive semantics
attrs->object(a) Operation

;
attrs->object(a) Operation {
name := "set_" + self.name.upperFirst();
visibility := "public";
parameter := object Parameter

;
};
};
end

}

– in place privatization of the attribute

mapping inout Attribute::privatizeAttribute ()

(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

class Package extends UMLModelElement

abstract class PackageElement extends UMLModelElement {
}

class Classifier extends PackageElement {
}

class Attribute extends UMLModelElement

class Class extends Classifier

class Association extends PackageElement

class PrimitiveDataType extends Classifier {
}

}

metamodel SimpleRdbms {

abstract class RModelElement

class Schema extends RModelElement

class Table extends RModelElement

class Column extends RModelElement

class Key extends RModelElement

class ForeignKey extends RModelElement

}

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

;
intermediate property UML::Class::leafAttributes : Sequence(LeafAttribute);

– defining specific helpers

query UML::Association::isPersistent() : Boolean

– 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()

– maps a class to a table, with a column per flattened leaf attribute

mapping Class::class2table () : Table
when

{
init

– population section for the table
name := 't_' + self.name;
column := self.leafAttributes->map leafAttr2OrdinaryColumn("");
key_ := object Key

;
}

– 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

}
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

– mapping to update a Table with new columns of foreign keys

mapping Association::asso2table() : Table
when

{
init

foreignKey := self.map asso2ForeignKey();
column := result.foreignKey->column ;
}

– mapping to build the foreign keys

mapping Association::asso2ForeignKey() : ForeignKey

– 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

(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 ()

mapping UML::Package::createDefaultPackage () : SPEM::Package

mapping UML::Package::createProcessComponent () : SPEM::ProcessComponent
inherits createDefaultPackage
when

{}

mapping UML::Package::createDiscipline () : SPEM::Discipline
inherits createDefaultPackage
when

{}

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

{}

– rule to create the default process performer singleton
mapping createOrRetrieveDefaultPerformer () : SPEM::ProcessPerformer {
init

name := "ProcessPerformer";
}

mapping abstract UML::UseCase::createCommonWorkDefinition ()
: SPEM::WorkDefinition
{
name := self.name;
constraint :=

;
}

mapping UML::UseCase::createActivity () : SPEM::WorkDefinition
inherits createCommonWorkDefinition
when

{}

mapping UML::UseCase::createPhase () : SPEM::Phase
inherits createCommonWorkDefinition
when

{}

mapping UML::UseCase::createIteration () : SPEM::Iteration
inherits createCommonWorkDefinition
when

{}

mapping UML::UseCase::createLifeCycle () : SPEM::LifeCycle
inherits createCommonWorkDefinition
when

{}

mapping UML::UseCase::createCompositeWorkDefinition () : SPEM::WorkDefinition
inherits createCommonWorkDefinition
when

{}

mapping UML::Constraint::createPrecondition () : SPEM::Precondition

mapping UML::Constraint::createGoal () : SPEM::Goal

mapping UML::UseCase::addDependenciesInWorkDefinition ()
: SPEM::WorkDefinition
merging addDependenciesInActivity
{
init

subWork := self.clientDependency[*includes].supplier
->resolveone(WorkDefinition);
performer := if performers then performers->first()
else createOrRetrieveDefaultPerformer() endif;
}

mapping UseCase::addDependenciesInActivity () : WorkDefinition
when

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

It should be a composition (in both).

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 [*]

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.

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

(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.

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.

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, out dest2);
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
"""
(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>

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.

No Data Available

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.

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

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.

Is there a syntax for comments?

Suggest: – comments to avoid confusion with OCL.

Resolution: No change.
This has already been addressed by the resolution of issue 10604.

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.

(1) In Section 7.11.1.1, within "associations" sub-section, add the following property:

/ownedType : Type [0..*] (from Package)

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)'.

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

No Data Available

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

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

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.

(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.

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

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".

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.

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.

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.

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

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

(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).

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:

(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.

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.

(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'"

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:

(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.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."

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:

(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.

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.

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> | '*') ';'

<identifier_list> ::= <identifier> (',' <identifier>)*

// definitions in a compilation unit
<unit_definition>
::= <transformation>

// Transformation and library definitions

<transformation> ::= <transformation_h> (";" | '

' ';')

// 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>

// 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>

// 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_h> ::= ('metamodel' | 'package') scoped_identifier
<metamodel_def> ::= <class> | <enumeration> | <tag>

<class> ::= <class_h> (";" | '

' ';')
<class_h> ::= <class_info> <scoped_identifier> <class_extension>?
<class_info> ::= 'datatype'

<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> ::= '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_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>

// Expressions

<expression> ::= <assign_exp>

<assign_exp> ::= <implies_exp>

<assign_op> := ':=' | '::=' | '+=' | '-='

<default_val> ::= 'default' <assign_exp>

<implies_exp> ::= <or_exp>

<or_exp> ::= <and_exp>

<or_op> ::= 'or' | 'xor'

<and_exp> ::= <cmp_exp>

<cmp_exp> ::= <additive_exp>

<cmp_op> ::= '=' | '==' | '<>' | '<' | '>' | '<=' | '>='

<additive_exp> ::= <mult_exp>

<add_op> ::= '+' | '-'

<mult_exp> ::= <unary_exp>

<mult_op> ::= '*' | '/' | '%'

<unary_exp> ::= <postfix_exp>

<unary_op> ::= '-' | 'not' | '#' | '##' | '*'

<postfix_exp> ::= <primary_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>

<literal> ::= <literal_simple>

<literal_simple> ::= <INTEGER> | <FLOAT> | <STRING>

<literal_complex> ::= <literal_collection>

<literal_collection> ::= <collection_key> '

'

<literal_tuple> ::= 'Tuple' '

'

<literal_dict> ::= 'Dict' '

'

<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> ')'

<simple_iterator_op> ::= 'reject' | 'select' | 'collect' | 'exists'

<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> ::= '(' <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>

<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>)?

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.

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.

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.

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> ::= <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

default_values

;

enforce domain rdbms
c:Column

;

where

}

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.

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> ::= (<identifier> | <objectTemplate> | '_')+
'++'
(<identifier> | '_')

Enumeration can be specified as a collection of members to be matched:
e.g. cs:Set(Class)

Comprehension can be specified as a condition that each member of the collection
must satisfy:
e.g. cs:Set(Class)

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> ::= (<identifier> | <objectTemplate> | '_')+
'++'
(<identifier> | '_')

The updated grammar is given in Appendix A of this report. This replaces the grammar given in section 7.13.

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: 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.

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.

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.

In order to accommodate top level collection templates in domains

In <domain>
Replace: [ <identifier> ] ':' <typeCS>'

'
By: <templateCS>

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

?? since any TemplateExp can have a where, should the [ '

' ]
in <domain> be part of <template> instead ??

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.

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.

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..*]

- Arguments to the relation call.
referredRelation : Relation [1] - The relation being invoked.

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.

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.