As interpretation from the especification (pag 104), the way of adding new operations to OCL predefined types is creating new Typedef instances
which must have the OCL predefined type as the base type. The new operations are added to this new typedef. However there are several problems:
1. The specification doesn't provide any name for these typedefs.
2. The specification doesn't specify which type (QVT typedef or OCL predefined type) should be used when referencing such OCL predefined types in a QVTo transformation.

Solution for 1).
Suggestion a: Name the typedef with the same name of the base type. This provokes name's clash with the predefined type's name, due to there are two different types from two standard libraries
which have the same name. A possible solution, would be expliciting that typedefs (aliases) will never clash its name with its base type.

Suggestion b: Name the tpyedef with a different name, such as QVToXXXXXX or XXXX_Alias.

Solution for 2).
Suggestion a: Taking the typedef as the referenced type in QVTo transformations.
Suggestion b: Taking the OCL predefined type as the referenced type in QVTo transformations.
Suggestion c: Considering resolution of issue 13168, so that only OCL predefined exists, and therefore, the only type which can be referenced.

It's a little bit weird having 2 different types (a type, and its alias typedef) which represent just the same type, specially when they are related by a reference.
My solution's preference in order are:
c) Just having one type to refer.
a) Since the typedef "extends" the behaviour of the predefined type (adding new operations), the former must be the referred one.
b) The OCL predefined type is referenced, but we must taking into account that operations added to the typedef are available.

issue closed, duplicate of issue # 13252

The concrete syntax for a query uses a pathNameCS, yet the query is defined
within the scope of a transformation.

How should a scoped name be interpreted?

? is a scoped name only applicable for declaring externally definedc queries ?

Comment:
Concrete syntax is incorrect.

Resolution:
The concrete syntax of the production <query> given in Appendix A of this report is changed as follows:
<query> ::= 'query' <identifier>
'(' [<paramDeclaration> (',' <paramDeclaration>)*] ')' ':' <TypeCS>
(';' | '

')
Replace the content of section 7.13.1 and 7.13.2 by the new content given in Appendix A of this report.

The concrete syntax for transformation supports multiple extension.
The abstract syntax supports only single extension.

Suggest: change the concrete syntax.

Comment:
Concrete syntax is incorrect.
Resolution:
The concrete syntax of the production <transformation> given in Appendix A of this report is changed as follows:
<transformation> ::= 'transformation' <identifier>
'(' <modelDecl> (';' <modelDecl>)* ')'
['extends' <identifier>]
'

'
Replace the content of section 7.13.1 and 7.13.2 by the new content given in Appendix A of this report.

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

In Section 9.17.8 (Assignment)

• replace "slotExpression: OclExpression [1]"
  by "slotExpression: OclExpression [1] {composes}"
  - replace "value: OclExpression [1]"
  by "value: OclExpression [1] {composes}

  "

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

(1) In figure 9.2, add the missing composition symbol for the
association (Mapping::local : Mapping)

Association part of the AnonymousTupleLiteralExp class should be (see figure 8.7) part: AnonymousTupleLiteralPart [*]

In Section 8.2.2.31 (AnonymousTupleLiteralExp)

• replace "part : OclExpression [1] {composes}

  "
  by "part: AnonymousTupleLiteralPart [*]

  {composes, ordered}

  "

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

(1) In Figure 8.7, add the

constraint to the
AnonymousTupleType::elementType type.
(2) In Section 8.2.2.29 (DictLiteralExp)

• replace "part: OclExpression [1] {composes}"
  by "part: DicLiteralPart [*] {composes}

  "

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

In Section 8.2.2.24 (Typedef)

• replace "condition: OclExpression [1]"
  by "condition: OclExpression [1] {composes}

  "

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

In Section 8.2.2.22 (UnpackExp)

• replace "variable: Variable [1..*]"
  by "variable: Variable [1..*] {composes}

  "

Association element of the TupleExp class should be (see figure 8.6) element: OclExpression [1..*]

In Section 8.2.2.21 (TupleExp)

• replace "element: OclExpression [1..*]"
  by "element: OclExpression [1..*] {composes} "
  - replace "variable: Variable [1..*]"
  by "variable: Variable [1..*] {composes}

  "

Note:
This resolution should not applied since it is superseded by issue 11061
(which removes the TupleExp metaclass).

Association assertion of the AssertExp class should be (see figure 8.6) assertion: OclExpression [1]

In Section 8.2.2.19 (AssertExp)

• replace "assertion: OclExpression [1]"
  by "assertion: OclExpression [1] {composes} "
  - replace "log: LogExp [0..1]"
  by "log: LogExp [0..1] {composes}

  "

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

In Section 8.2.2.15 (ReturnExp)

• replace "value: OclExpression [1]"
  by "value: OclExpression [1] {composes}

  "

Association target of the UnlinkExp class should be (see figure 8.6) target: OclExpression [1]

Association exceptBody of the TryExp class should be (see figure 8.6) exceptBody: OclExpression [0..1]

In Section 8.2.2.12 (UnlinkExp)

• replace "target: OclExpression [1]"
  by "target: OclExpression [1] {composes}"
  - replace "tryBody: OclExpression [1]"
  by "tryBody: OclExpression [1] {composes}

  "

• replace "exceptBody: OclExpression [0..1]"
  by "exceptBody: OclExpression [0..1] {composes}

  "

Association value of the AssignExp class should be (see figure 8.6) value: OclExpression [*]

Association defaultValue of the AssignExp class should be (see figure 8.6) defaultValue: OclExpression [0..1]

In Section 8.2.2.11 (UnlinkExp)

• replace "value: OclExpression [*]"
  by "value: OclExpression [*] {composes}"
  - replace "left: OclExpression [1]"
  by "left: OclExpression [1] {composes}

  "

• replace "defaultValue: OclExpression [0..1]"
  by "defaultValue: OclExpression [0..1] {composes} "
  - replace "item: OclExpression [1]"
  by "item: OclExpression [1] {composes}

  "

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

In Section 8.2.2.10 5VariableInitExp), replace all occurrence of
word 'withResult' by 'withReturn'.

Note (Responding AB review feedback):
There is a typo error in resolution text: we should read " replace all occurrence of
word 'withReturn' by 'withResult'. This is consistent with Fig 8.6 (VariableInitExp::withResult defined) - which is left unchanged by the resolution - and also consistent with the summary text of the issue.

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

In Section 8.2.1.21, replace all occurrences of "strict" word by "isStrict".

Association result of the ImperativeOperation class should be (see figure 8.2) result: VarParameter [*]

Association body of the ImperativeOperation class should be (see figure 8.2) body: OperationBody [0..1]

In Section 8.2.1.10 (ImperativeOperation), replace
"result: VarParameter [*]

"

NOTE (FIXES after AB Review)
Additional omissions concerning the

indication for the following defined properties (within the class descriptions):
ImperativeOperation::context , Constructor::/body, ResolveExp::condition, BlockExp::body, WhileExp::condition, WhileExp::body, ImperativeLoopExp::condition, ForExp::/condition, ForExp::body, ForExp::source, ImperativeIterateExp::/condition, ImperativeIterateExp::/body, ImperativeIterateExp::/iterator, ImperativeIterateExp::/source, SwitchExp::elsePart, AltExp::condition, AltExp::body, VariableInitExp::referredVariable, UnpackExp::source

• Add the missing {ordered}

  indication for the following defined properties (within the class descriptions):
  MappingOperation::inherited, MappingOperation::merged, MappingOperation::disjunct, BlockExp::body,ImperativeIterateExp::iterator, ComputeExp::returnedElement

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

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

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

In Section 8.2.2.8 (SwitchExp) replace
"elsePart : Expression [0..1]"
by "elsePart : OclExpression [0..1]"

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

In Section 8.2.2.3 (ComputeExp) replace
"returnedElement : TypedElement [1]"
by "returnedElement : Variable [1]"

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

Adds the sentence: "if the string s does not appear at the beginning or at the end, the content of string s is returned".

NOTE (Correction of typo after AB review):
There is a typo error in the sentence to be added. The sentence to be added should be:
"if the string s does not appear at the beginning or at the end, the content of source string is returned".

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

Add the sentence: "The operation returns a new string."

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

Replaces "Converts the first character in ..." as "Converts the last character in ..."

NOTE (Correction of typo after AB review):
Replaces "Converts the first character in the string to a lowercase
character" by:
"Converts the last character in the string to a uppercase character"

In the class InstantiationExp, the associations (page 99) are missing. It should be (see Figure 5): argument: OclExpression [*]

extent: Variable [0..1] instantiatedClass: Class [1]

In Section 8.2.2.23 (InstantiationExp) add the following
Associations definitions:
"""
Associations
argument: OclExpression [*]

The arguments of the instantiation expression. Should correspond with
the initialisation operation for the class (which by default is
implicit and has no arguments).
extent: Variable [0..1]
The extent on which the new object is created.
instantiatedClass: Class [1]
The type of the object to be created.
"""

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

close, no change

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

Duplicate of issue 9254

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

In Section 8.1.18, Replace all occurences of Pim2Psm as PimToPsm.

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

Modify the text to replace the two references to Figure 16 with references to Figure 7.13.
More precisely, in page 42, replace "Figure 16 specifies a strange relation … " by "Figure 7.13 specifies a strange relation … " and replace "The textual specification corresponding to Figure 16 …" by "The textual specification corresponding to Figure 7.13 …".

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

In section 8.2.1.20, replace "Unless isScoped..." by "Unless isVirtual".
Also, in the Attributes subtitle, replace 'virual' by 'isVirtual'.

CollectionKind not defined in this document in kind: CollectionKind

IN section 7.11.2 insert the enumeration type CollectionKind with the
following definition:

"""
CollectionKind (from EssentialOcl)
The enumeration type that provides all the kind of collections.
Possible values are: Set, Sequence, Bag and OrderedSet.,
"""

Typographic errors: - Character ñ appears in several pages: 13, 14, 15, 17, 18, 22, ... - Bad indented in page 15: namespace = p:Package {}, in page 16: primaryKey = k:PrimaryKey

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

(1) Replace Character ñ occurrences in all pages
(2) Correct bad indentation :
in page 15: namespace = p:Package {},
in page 16: primaryKey = k:PrimaryKey

in page 22: c1: Class, a1: Attribute l1: attrs (c1, a1)
in page 36: *
in page 37: | ( ';')*
(3) Perform the following text substitutions:

• At page 71: "...expressions that is executed is sequence." it should say: "...expressions that is executed in sequence."
• At page 71: "He self variable..." it should say: "The self variable ..."
• At page 78: "An explicit usage of the population ...required is certain situations ..." it should say: "An explicit usage of the population ...required in certain situations ..."
• At page 91: "Tre endif keyword ..." it should say: "The endif keyword ..."
• At page 88: "...it has four pre-defined variants named xcollect..." it should say: "...it has five pre-defined variants named xcollect..."
• At page 110: "...beginning and the end of the srings and..." it should say: "...beginning and the end of the strings and..."
• At page 112: "...comment delimited by "-" and the end of file" it should say: "...comment delimited by "-" and the end of line"
• At page 112: "...comment delimited by "//" and the end of file" it should say: "...comment delimited by "//" and the end of line"

(4) Perform the following formatting corrections:

• Bad format in page 22: 7.10.3.3 (see font of 7.10.3.2) in page 23: 7.10.3.4 (see font of 7.10.3.2)
• In figure 7.4 (page 26) the class Domain must be written in italic. The class Domain is abstract.
• In figure 7.4 (page 26) the class Rule must be written in italic. The class Rule is abstract.
• In page 49 at expression: name:=self.name;type:=getSqlType(self.type) missing a space between name and type.

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

In Figure 8.1 add the missing link
'OperationalTransformation:enforcedDirection : ModelParameter [0..1]'

Original file: ptc/07-07-08.zip
OMG Document Nmber: formal/2008-04-03
Standard document URL http://www.omg.org/spec/QVT/1.0/PDF

On Page 2 (Page 18 in PDF) there is a wrong reference in chapter 2.2 Language Dimension at 1. and 2.

"Core; The Core language is described in Chapter 11.."

"Relations: The Relations language is described in Chapter 9. ..."

It should be 9 and 7

The Chapter 10 reference is wrong too.
Further wrong Chapter 9/11 references exist in the main text.
The above references are manual text that do not use FrameMaker cross-reference facilities.
Loading the QVT 1.1 FrameMaker files reveals 6 unresolved cross-references.
OMG specifications have Clauses not Chapters.

Sections 8.3.4.7 and 8.3.4.9, page 110:

Operation signatures for 8.3.4.7 and 8.3.4.9 do not correspond with the title of sections.

Please update 8.3.4.7 from "Element::subobjects(OclType) : Set(Element)" to "Element::allSubobjectsOfType(OclType) : Set(Element)".

Please update 8.3.4.9 from "Element::subobjectsOfKind(OclType) : Set(Element)" to "Element::allSubobjectsOfKind(OclType) : Set(Element)"

yes

Section 8.2.2.7, page 95:

The text "list[condition]; // same as list->xselect(i; condition)" should read "list[condition]; // same as list->xselect(i | condition)". Notation of imperative iterate expressions state that the condition section must be separated from prior artifacts (iterators or target initializations), where present, by a "|" character, not a semicolon ";".

Duplicates in part Issue 13282.
Disposition: See issue 13282 for disposition

Section '8.3.5.3 rootObjects' has a typo in the signature of the operation defined: Model::rootobjects() : Set(Element). In compliance with the surrounding definitions and with the title of the section itself, it should read 'Model::rootObjects() : Set(Element), that is, the first letter of 'Objects', capitalized.

Suggestion: Replace 'Model::rootobjects() : Set(Element)' by the new 'Model::rootObjects() : Set(Element)'

yes

Problem's text: // column := self.attribute->forEach new(a) Column(a.name,a.type.name);
discussion: the foreach exp is not well written:
suggestion: replace the text above by "// column := self.attribute->forEach(a)

;

yes

Problem's text: OperationCallExp
discussion: From figure 8.4 and 8.6, we can guess that LogExp should inherits from both, OperationCallExp and ImperativeExpression.
suggesition: add ImperativeExpression as a LogExp's superclass.

yes

Problem's text: part : DictLiteralPart [*]

discussion: Do the parts need to be ordered ?. The diagram doesn't show it.
suggestion: Remove ordered or update the diagram.

Yes. A dictionary does not need go be ordered.
Already correct in the QVT 1.1 models

Problem's text: (see DictLiteralValue).
discussion: DictLiteralValue deosn't exist. It must be DictLiteralExp.
suggestion: Replace "DictLiteralValue" by "DictLiteralExp".

yes

Section 8.3.4.11, page 110:

The operaton "Element::deepclone()" should read "Element::deepClone()". I understand that "Subobjects" do not capitalize the leading 'o' for the word "objects", but in all other cases it seems consistent to use capitals for words' leading letters. Both the title and the operation signature should be updated accordingly. This issue is similar to 13913.

The same applies to Section 8.3.7.3 (page 113), "defaultget", which would read "defaultGet", and 8.3.8.4 (page 114), "joinfields", which would read "joinFields". Again both the titles and the operation signatures should be updated accordingly.

No Data Available

Problem's text: The OCL standard library is an instance of the Library metaclass.
discussion: It should obviously refer to the QVT Operational Mapppings standard library.
suggestion: replace "OCL" by "QVT Operational Mappings".

yes

Problem: There are two figures to represent the type extensions.
suggestion: Remove the first figure and name the sencond one as Figure 8.7 - Imperative OCL Package - Type extensions

There are actually 5 sub-diagrams of which the first two are duplicated by the third and fourth;
presumably an editing artefact when the fifth was introduced for ListLiteralExp.

Problem's text: elsePart : OclExpresion

" and "[0..1].

Yes, and correct spelling of OclExpression too.

Problem's text: condition: OclExpression [1]

discussion: the condition is optional.
suggestion: Replace "[1]" by "[0..1]".

Yes.
Already correct in the QVT 1.1 models

Problem's text: compute (x:MyClass := self.getFirstItem()) while (x<>null)

discussion: the compute expression's body requires the enclosing braces
Suggestion: replace the text above by "compute (x:MyClass := self.getFirstItem()) { while (x<>null) { … }}"

• Page 92: Semantics Section 8.2.2.4 ForExp
  Problems text:
  Collection(T)::forEach(source, iterator, condition,body) =
  do
  Unknown macro: { count }

  ;

Collection(T)::forOne(source, iterator, condition,body) =
forEach (i | condition)

Yes.
Yes.

Problem's text:
1.ReturnExp::value association my have multiplicity [0..1] in the diagram
2.TryExp::catchClause association should be called exceptClause
Discussion:
1. It seems that the returned value of a return expression might be optional.
2. Since the diagram and textual descriptioon are different, I'm not sure which was the original intention of the name of this reference. Reading the description's text
and the opposite role name (exceptOwner), I guees that the name must be "exceptClause".
suggestion:
1.In ReturnExp::value association replace mutiplicity 1 by multiplicity [0..1]. In the text is well described.
2.In TryExp class change change the "catchClause" by "exceptClause"

• Page 90: Section 8.2.2.3 ComputeExp
  Problem's text: body : OclExpression [1] {composes, ordered}

  Discussion: Ordered doesn't make sense in a univalued reference.
  Suggestion: remove "ordered".

Yes.
Yes.
Yes.
Already correct in the QVT 1.1 models

Problem's text: list[condition]; // same as list->xselect(i; condition)
discussion: From the specified notation, the xselect expression is not well written.
suggestion: replace ';' by '|'

yes

Problem's text: target : Variable [0..1]
discussion: composes is missed. In the diagram is correctly represented the association's feature.
suggestion: add the following text to end of the line "

Yes.
Already correct in the QVT 1.1 models.

Problem's text: // shorthand for list->xcollect object X

);

yes

Problem's text: "When an object expression is the body of an imperative collect expression (see xcollect in ImperativeLoopExp)"
discussion: the text should point ImperativeIterateExp instead.
suggestion: replace ImperativeLoopExp by ImperativeIterateExp.

yes

Problem's text: /instantiatedClass: Class [0..1](from InstanciationExp)
discussion: wrong description.
Suggestion: replace the text above by "/instantiatedClass: Class [1](from InstantiationExp)"
note that in /extent reference, "(from InstanciationExp)" must be also replaced by (from instantiationExp)"

Yes and correct the erroneous bounds change on the spurious redefinition.

On Page 130 there is written:

"The dottet arrows in the picture below sho the dependencies between the patterns, with the following interpretatoin: ..."

But there is no picture

No Data Available

The OCL 2.0 spec has a 32 page section on concrete semantics.
QVTr has 1.5 pages of BNF but no explanation.

In particular:
What are the semantics of 'import' which has no abstract counterpart?
Where is the explanation of the role of [ '

' ] in a <domain>?
Where is the instruction on how to treat the "_" identifier?

No Data Available

The concrete syntax does not specify a parsing goal.
If the first element (Transformation) is taken to be the goal, most of the rest
of the grammar is orphaned.

Suggest:

TopLevel ::= (Transformation | Mapping)*

simple change

A Direction defines the packages used by each direction domain.

Nothing defines the (additional) packages used by the middle area. For instance
there is no place to specify the trace class model generated by the RelationToCore
transformation. With many transformations and mappings in a QVTcore it does not
seem appropriate to overload TransformationName or MappingName as a hook to
reference the appropriate middle meta-models; different Mappings may have distinct
middle meta-models; multiple transformations may share the same middle meta-model.
(Core should be a first class programming language, not just one that supports
the eccentricities of a RelationToCore conversion.)

Suggest: a DirectionName between "where" and "(" in Mapping.

This reads very naturally:

map ...
check left (...
enforce right (...
where middle (...

But we also need to fix the Abstract Syntax. As a minimum a Mapping needs a
middle-typed-model property to capture the missing information. With this addition
a Mapping duplicates so much of a CoreDomain/Area, that it is more appropriate
to eliminate Area altogether, merging it into CoreDomain. Area is eliminated
from Mapping, and added as an additional CoreDomain referenced by the middleDomain
property.

So:

CoreDomain extends Domain
CoreDomain.variables : RealizedVariable [0..*] composed
CoreDomain.bottomPattern : BottomPattern [1] composed
CoreDomain.guardPattern : GuardPattern [1] composed

Mapping extends Rule
Rule.domain : Domain [0..*] composed (must be at least CoreDomain[3])
Mapping.specification - no change
Mapping.local - no change
Mapping.context - no change
Mapping.middle : CoreDomain [1] (must be in Rule.domain)

The suggested changes may be convenient but they are not necessary:

• the middle model can be anonymous
• the middle area can be merged with the overall mapping.
  What is needed is a way to bind a middle metamodel to its TypedModel. This can be achieved by an
  anonymus direction bindng

For uniformity, collectselect should be renamed xcollectselect following the distinction
between collect and xcollect (imperative version).

This is an unpleasant but worthwhile change. Implementations may choose to provide both spellings
for transitional compatibility.
If collectselect changes, so too should collectselectOne, collectOne and selectOne, since their
computation is imperative too.

Style. Use same font and presentation as 7.12.3, 8.4.

Typo. Remove '(' preceding '","' in BottomPattern.

Typo. Remove 'e' in 'Assignement'.

Some aspects of the presentation are easily resolved, but replacing e.g. DirectionName to
<directionName> is not worthwhile. These will all change to e.g. DirectionNameCS once OCL 2.5
aligned grammars are provided.
The '(' is needed as part of an 'optional' for which the prevailing BNF is [].
Assignement is a simple typo.

GuardPatterns and BottomPatterns with Variables but without Constraints must end with a '|'.
This is inelegant. Better to only require '|' as prefix to constraints (or to require it always).

Suggest:

GuardPattern ::= Variable ("," Variable)* ["|" (Constraint ";")+]

similarly BottomPattern

Simple change.

Issue 9379 made Pattern.bindsTo a non-composition.

This deprives Core of any parent for its non-realized variables.

Suggest: move BottomPattern.realizedVariables to CorePattern.variables.

CorePattern.variables then composes all variables declared for the pattern. A class-type
check of RealizedVariable/Variable derives the 'isRealized' property.

It is convenient to keep realized and unrealized variables separate to avoid unnecessary isRealized
tests.
Just add CorePattern.variables to compose the unrealized variables.

9.3 Assignment.slotExpression should be PropertyAssignment.slotExpression (VariableAssignments have no slot)

Simple move already in QVTcore.xml

Consider using asTuple instead of tuple keyword for TupleExp since asX() is usually
used for conversions.

There is no TupleExp or asTuple() in QVT 1.0 or 1.1 but there is an asOrderedTuple() with the
resolved description. So it appears that a variant of the suggested resolution made it into QVT 1.0.
Disposition: Closed, No Change

The concrete syntax defines 'realized', but section 10 consistently uses 'realize'.

Suggest: 'realize'

The concrete syntax defines 'realized' for a single element of a comma-separated list.
Section 10 appears to expect that 'realized' is a prefix to a comma-separated list.

Suggest: 'realize' is a comma-separated list prefix.

(semi-colon separation is available for distinct realize/not-realize.)

Use 'realize' as a keyword in the concrete syntax.
Use 'realized' as an adjective in editorial text, model names; e.g. RealizedVariable

Section 10 uses anonymous maps for composed mappings. The Concrete Syntax
does not allow this. Similarly, an 'in' is not appropriate for a composed mapping.

Suggest:

ComposedMapping ::= "map" [MappingName] ["refines" MappingName] MappingPatterns

where MappingPatterns is the common part of Mapping.

simple change

There is no concrete syntax for enforcement operations.

Suggest: a BottomPattern Constraint may also be
'create' OperationCallExpCS
'delete' OperationCallExpCS

simple change

The concrete sysntax allows guard patterns to have assignments. The abstract syntax does not.

Suggest: GuardPattern uses Predicate rather than Constraint

Simple change

• • QVTo Standard Library. Clarification of the side-effect operations is needed. I would explicity clarify which operations may modify the object source on which the operations are called. All the stdlib operations must clarify: 1. if the operation acts on the own object or on a copy of the object. 2. which object(s) is(are) exactly returned (the own object, a (collection of) new object(s), a (collection of) referenced object(s)) For example: String::trim operation clearly says that creates a new object copy of itself which is modified and returned. However, String::firstToUpper operation may have several interpretations.

Issue 19146 resolution makes the behaviour of List clear.
Dict clarified below and a typo
String clarified below.

• • QVTo Standard Library: Some operation's signatures seem to be erroneous. ** - the name in the signature of the operation allSubojectsOfType (8.3.4.7) has a typo. Rename correctly - the returned value in the signature of the operation raisedException (8.3.6.4) should better be Exception. - the asList (8.3.8.5) operation's signature is not correct for the types OrderedSet(T), Sequence(T), Bag(T). They shouldn't have any parameter. P.S: Why is this operation included in section 8.3.8 Operations List. I would recomend the creation of new sections for each collection type, instead. - OCLStdlib already defines toLower and toUpper operations. Since these operations may be considered as side-effects operations. I should clarify one of the possible situations: 1. toLower and toUpper are not intended to be side-effect operations. Remove them from the section. 2. toLower and toUpper are always intended to be side-effect operations, so that OCL Operations are discarded. This must be clarified. 3. both (side-effect and free side-effect) operations, are available in QVTtransformations. In this case I would change the name of QVTo std lib operations to distinguish. - In section (8.3.9) lastToUpper must be renamed as lastToLower. P.S: Why all the QVTo Std Lib operations have a subsection number, excepting String's operations?

allSubojectsOfType – see Issue 13989 resolution.
raisedException – Yes. But the Status operations are misleadingly under Transformation. Add a
missing section heading.
asList(T) – Yes, supersedes Issue 19146 resolution.
PS – see Issue 19146 resolution.
toLower – Yes. Make it clear that all String operations are immutable. Redirect OCL 2.4 synonyms to
OCL 2.4 deprecating the synonyms. We can also fix some bad typos, Boolean rather than
Integer/Real returns, references to the non-existent Float type and spurious matchXXX arguments.
lastToUpper – this seems to be a major bloat. Either name or description could change. Since the
name exists with an obvious functionality, correct the description.
PS Yes

Problem's text: "/body: BlockExp [0..1]

(from ImperativeOperation)
The operation body of the constructor. It should necessarily be
a ConstructorBody instance.

Yes. But we can go all the way by modeling the ConstructorBody constraint

Problem's text: "the invocation of the operation returns a tuple"
discussion: it could be understood as an OCL Tuple, which doesn't apply.
suggestion: Replace "a tuple" by "an ordered tuple".

The usage or OrderedTuple seems misguided since an ordinary OCL Tuple does very similar things
without a positional hazard and without noticeable lexical overhead.
Only the case of TupleLiteralEx/UnpackExp is plausibly defined in QVT 1.1 and neither of the QVT
implementations (SmartQVT or Eclipse QVT) support OrderedTuple.
Therefore eliminate TupleLiteralExp, UnpackExp and OrderedTupleType and
OrderedTupleLiteralPart.
Note that there are no editing instructions for the grammar. It is not clear that OrderedTuples were
really supported at all.

In the spirit of issue #13228, and in conversation with Mariano Belaunde, we think it is worth considering also adding the following operations to mutable lists. As specific usages of 'removeAt()': 'removeFirst()' and 'removeLast()'. And also: 'removeAll(Collection(T))'. Notice that this one includes the case of removing values specified inside mutable lists as long as ListType inherits CollectionType. Suggestion: Add the following text to section 8.3.8: - List(T)::removeFirst() : T Removes the first value of the mutable list. The return value is the value removed. - List(T)::removeLast() : T Removes the last value of the mutable list. The return value is the value removed. - List(T)::removeAll(Collection(T)) : Void Removes from the mutable list all the values that are also present in the specified collection.

And remove() from Issue 13228. A List is not a Collection so we need two removeAll's.
Additional operations in Issue 19146.
Disposition: See issue 19146 for disposition

For 'removeAt' I specify 'one' as the starting index value. Suggestion: - List(T)::remove(T) : T Removes a value from the list. - List(T)::removeAt(int) : T Removes a value from the mutable list at the given position. The index starts at one (in compliance with OCL convention). The return value is the value removed from the mutable list. - List(T)::clear() : Void Removes all values in the mutable list.

Yes. Revised wording in 132 is explicitly one-based.
Disposition: See issue 19146 for disposition

There is no support for transformation extension in the QVT Core concrete syntax.

Suggest: re-use the concrete syntax of QVT Relation, allowing "extends x" to follow
a transformation declaration.

example:

transformation yy::umlRdbms

extends base1, xx::base2, base3

Simple change. Names are left vague pending resolution of Issue 10935.

The QVT Relation Concrete Syntax makes no provision for organisation of transformations
in a package hierarchy; all transformations are presumed to be in root packages.

Suggest: change <identifier> to <transformationId> in both definition and reference
of the <transformation> production, and define <transformationId> as <pathNameCS>.

simple change

Problem's text: in MappingParameter class: "refiningParameter" and "refinedDomain".
discussion: while a mappingOperation refines a Relation, a mappingParamer should "refer" a RelationDomain. In the text of MappingParameter section, the concept of "refers" is used several time instead of "refines".
suggestion: replace "refiningParameter" and "refinedDomain" by "referringParameter" and "referredDomain".

Duplicates in part Issue 12527.
Disposition: See issue 12527 for disposition

Problem's text: "configuration property UML::Attribute::MAX_SIXE: String
discussion: providing a context to a configuration property doesn't seem to make sense.
suggestion remove "UML::Attribute::"

It's not obviously sensible, but is it actually wrong?
If there are many configuration properties, it may be convenient to partition them hierarchically. cf.
java.vm.specification.vendor.
The punctuation is however confusing; add a space.

Suggestion: Change original explanation text: "Removes an object of the model extent. All links that the object have with other objects in the extent are deleted." by something similar to the following one: "Removes an object from the model extent. The object is considered removed from the extent if it is not a root object of the extent, and is not contained by any other object of the extent."

simple change

The explanation of the operation: 'List(T)::insertAt(T,int) : Void' in Section 8.3.8.3 has a mistake concerning the index associated with the first element for OCL collections. The index starts at one, '1', not zero, '0'. Suggestion: Substitute the word 'zero' by the word 'one', so that the text reads: "The index starts at one (in compliance with OCL convention)."

Yes. Improved wording in Issue 19146.
Disposition: See issue 19146 for disposition

Problem's text: "overriden: Operation [0..1]"
discussion: the overriden operation should be an ImperativeOperation. This is correctly showd in the diagram.
suggestion: Replace "Operation" by "ImperativeOperation".

Yes.
Already correct in the QVT 1.1 models

Problem's text: "isubclass of Module (see: ImperativeOCL package)"
Discussion: Module doesn't belong to ImperativeOCL package.
Suggestion: remove "(see: ImperativeOCL package)"

simple change

Use of automated tooling to support comparison of the models developed
initially as part of the Eclipse GMT/UMLX project and being transferred to the
Eclipse QVT Declarative/QVT Operational Mappings Projects reveals the following
errors and anomalies in emof.ecore in the 07-07-08 ZIP.

Note that these errors and anomalies are not the same as those separately reported
for the QVT_1.0.mdl from which the Ecore was notionally auto-generated.

An Ecore file resolving these anomalies is attached

These changes mostly affect non-normative files which were corrected when QVT 1.1 issued revised
files based on Eclipse QVT contributions. However a few changes remain to be resolved in the main
text.
ContextualProperty .initExpression is Issue 13270
ObjectExp.instantiatedClass is Issue 13276
ObjectExp. initializationOperation is Issue 19021
ObjectExp. body is Issue 19022

Use of automated tooling to support comparison of the models developed
initially as part of the Eclipse GMT/UMLX project and being transferred to the
Eclipse QVT Declarative/QVT Operational Mappings Projects reveals the following
errors and anomalies in emof.ecore in the 07-07-08 ZIP.

Note that these errors and anomalies are not the same as those separately reported
for the QVT_1.0.mdl from which the Ecore was notionally auto-generated.

An Ecore file resolving these anomalies is attached.

These changes mostly affect non-normative files which were corrected when QVT 1.1 issued revised
files based on Eclipse QVT contributions. However a few changes remain to be resolved in the main
text.
CatchExp.exceptionVariable/CatchExp.exception changes are Issue 15997
Remove UnpackExp is Issue 13268
Remove OrderedTupleType is Issue 13268
Remove OrderedTupleLiteralExp is Issue 13268
Remove OrderedTupleLiteralPart is Issue 13268
Add InstantiationExp.initializationOperation is Issue 19021

QVT Operational Mappings claims in the overview section, the use of ListLiteralExpression (for instance to initialize a list), as in the section 8.1.14 (Pag 55) is shown. However, there is no way to represent this literal expression in the abstract syntax, due to: 1. There is no ListLiteralExp in the imperativeOCL package. 2. CollectionLiteralExp (from EssentialOCL) can't be used. There is a way to initialize lists, making use of the asList operator which appears in the Standard Library section (8.3.85 / Pag 112), however this should be clarified. Therefore, two possible solutions could be taken: Suggestion 1: Create a ListLiteralExp which should extend CollectionLiteralExp (From EssentialOCL). Suggestion 2: Update the overview examples, to properly ilustrate how to initialize lists. Besides, the grammar ( Pag 124) )should be consequently changed as well. (List

literal expressions wouldn't be supported).

No Data Available

Section 8.2.2.22 provides no guidance on the meaning of:

var x:X;
var y:Y;
var z:Z;
...
var (x:X,y,z) := self.foo();

[If one of the variables in the left hand side, does exist ...]

Possible interpretations

a) x:X is always a syntactical shorthand.

Therefore the above is a shorthand for:

var x:X;
var y:Y;
var z:Z;
...
var x:X; var (x,y,z) := self.foo();

and consequently there is duplicate variable definition to be
reported as a semantic error.

b) x:X is a convenience type check assertion

Therefore the above is a shorthand for:

var x:X;
var y:Y;
var z:Z;
...
var (x,y,z) := self.foo();

with a successful validation of type consistency.

c) x:X is not available as a shorthand

Therefore the above is a syntax error.

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

Interpretations b) and c) require semantic knowledge to resolve syntactic
sugar.

Interpretation a) is an unambiguous syntax shorthand that could be more
clearly
described by:

"The following example demonstrates a shorthand in which variables are both
declared
and assigned.

var (x:X,y:Y,z) := self.foo();

Any variable name qualified by a type name is both a declaration and an
assignment,
with all declarations proceding the unapack assignment.
The above example should therefore be analyzed as:

var x:X; var y:Y; var (x,y,z) := self.foo();"

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

Recommend interpretation a) with the above textual clarification.

No Data Available

Use of automated tooling to support comparison of the models developed
initially as part of the Eclipse GMT/UMLX project and being transferred to the
Eclipse QVT Declarative/QVT Operational Mappings Projects reveals the following
errors and anomalies in emof.ecore in the 07-07-08 ZIP.

Note that these errors and anomalies are not the same as those separately reported
for the QVT_1.0.mdl from which the Ecore was notionally auto-generated.

An Ecore file resolving these anomalies is attached.

'nsURI' for 'EMOF' should be 'http://schema.omg.org/spec/MOF/2.0/emof.xml' rather than 'http:///emof.ecore'
'name' for 'EMOF' should be 'EMOF' rather than 'emof'
'name' for 'Property.isID' should be 'isID' rather than 'isId'
'Factory' should be defined
'ReflectiveCollection' should be defined
'ReflectiveSequence' should be defined
'Comment.body' should be defined
'Factory.package' should be defined
'Element.tag' should be undefined
'eOpposite' for 'Tag.element' should be undefined
'lowerBound' for 'Operation.class' should be '0' rather than '1'
'lowerBound' for 'Type.package' should be '0' rather than '1'
'lowerBound' for 'Property.class' should be '0' rather than '1'
'ordered' for 'Class.superClass' should be 'false' rather than 'true'
'ordered' for 'Comment.annotatedElement' should be 'false' rather than 'true'
'ordered' for 'Element.ownedComment' should be 'false' rather than 'true'
'ordered' for 'Operation.raisedException' should be 'false' rather than 'true'
'ordered' for 'Package.nestedPackage' should be 'false' rather than 'true'
'ordered' for 'Package.ownedType' should be 'false' rather than 'true'
'ordered' for 'Tag.element' should be 'false' rather than 'true'
'defaultValueLiteral' for 'Class.isAbstract' should be 'false' rather than undefined
'defaultValueLiteral' for 'MultiplicityElement.isOrdered' should be 'false' rather than undefined
'defaultValueLiteral' for 'MultiplicityElement.isUnique' should be 'true' rather than undefined
'defaultValueLiteral' for 'MultiplicityElement.lower' should be '1' rather than undefined
'defaultValueLiteral' for 'MultiplicityElement.upper' should be '1' rather than undefined
'defaultValueLiteral' for 'Property.isComposite' should be 'false' rather than undefined
'defaultValueLiteral' for 'Property.isDerived' should be 'false' rather than undefined
'defaultValueLiteral' for 'Property.isReadOnly' should be 'false' rather than undefined
'Element.container()' should be defined
'Element.equals(object)' should be defined
'Element.get(property)' should be defined
'Element.getMetaClass()' should be defined
'Element.isSet(property)' should be defined
'Element.set(property,object)' should be defined
'Element.unset(property)' should be defined
'Extent.elements()' should be defined
'Extent.useContainment()' should be defined
'Factory.convertToString(dataType,object)' should be defined
'Factory.create(metaClass)' should be defined
'Factory.createFromString(dataType,string)' should be defined
'ReflectiveCollection.add(object)' should be defined
'ReflectiveCollection.addAll(objects)' should be defined
'ReflectiveCollection.clear()' should be defined
'ReflectiveCollection.remove(object)' should be defined
'ReflectiveCollection.size()' should be defined
'ReflectiveSequence.add(index,object)' should be defined
'ReflectiveSequence.get(index)' should be defined
'ReflectiveSequence.remove(index)' should be defined
'ReflectiveSequence.set(index,object)' should be defined
'Type.isInstance(object)' should be defined
'URIExtent.contextURI()' should be defined
'URIExtent.element(uri)' should be defined
'URIExtent.uri(element)' should be defined
Unnavigable 'opposite' of 'Class.superClass' should be modelled
Unnavigable 'opposite' of 'Element.ownedComment' should be modelled
Unnavigable 'opposite' of 'Package.nestedPackage' should be modelled
Unnavigable 'opposite' of 'Property.opposite' should be modelled

No Data Available

Use of automated tooling to support comparison of the models developed
initially as part of the Eclipse GMT/UMLX project and being transferred to the
Eclipse QVT Declarative/QVT Operational Mappings Projects reveals the following
errors and anomalies in qvt_metamodel.emof.xml in the 07-07-08 ZIP.

Note that these errors and anomalies are not the same as those separately reported
for the QVT_1.0.mdl from which the EMOF was notionally auto-generated.

EMOF files resolving these anomalies are attached.

No Data Available

Use of automated tooling to support comparison of the models developed
initially as part of the Eclipse GMT/UMLX project and being transferred to the
Eclipse QVT Declarative/QVT Operational Mappings Projects reveals the following
errors and anomalies in QVT_1.0.mdl in the 07-07-08 ZIP.

Since the diagrams are printed from QVT_1.0.mdl all the QVT problems also
occur in 08-04-03.

Textual errors in 08-04-03 cannot be analyzed automatically. There are
so many that a thorough proof read is required combined with a statement
that the diagrams only are normative

The QVT 1.0 diagrams and models were originally from the models in the QVT_1.0.mdl file. The
diagrams rely on proprietary tooling. Unfortunately some independent evolution occurred and so there
were many inconsistencies.
Consistent Ecore/EMOF files from Eclipse were endorsed as the QVT 1.1 non-normative files.
For QVT 1.2, the primary non-normative files are UML models derived from the QVT 1.1 Ecore files.
The diagrams are redrawn from the UML using the Open Source Papyrus tool. The diagrams are
drawn to assist understanding rather than to squeeze as much as possible into the useable area. The
redrawn diagrams are therefore larger/more numerous. (Unfortunately Papyrus does not support

text is added manually.) In all other respects diagrams and UML non-normative
files should be consistent.
The multiplicity of unnavigable opposites was not present in the Ecore files and so is set to 0..1 for
compositions, and 0..* for non-compositions by the Ecore2UML conversion. This causes a few 1
multiplicities to change to 0..1. The 1 multiplicities were needlessly restrictive prohibiting re-use of
classes, so the 0..1 seems better. Perhaps we should have an issue to change navigable containers
too.
TemplateParameterType is missing from the diagrams since it is not preset in the non-normative files.
TemplateParameterType has no practical utility implementations are required to work magic for
templates types which may or may not involve the TemplateParameterType class.
I find that when I consult the specification, I want to see all the diagrams, which is hard when they are
spread thoughout the AS section. All diagrams are therefore brought to the start of their AS section.

Use of automated tooling to support comparison of the models developed
initially as part of the Eclipse GMT/UMLX project and being transferred to the
Eclipse QVT Declarative/QVT Operational Mappings Projects reveals the following
errors and anomalies in emof.ecore in the 07-07-08 ZIP.

Note that these errors and anomalies are not the same as those separately reported
for the QVT_1.0.mdl from which the Ecore was notionally auto-generated.

An Ecore file resolving these anomalies is attached

These changes mostly affect non-normative files which were corrected when QVT 1.1 issued revised
files based on Eclipse QVT contributions. However a few changes remain to be resolved in the main
text. CorePattern.variable is Issue 10938
Assignment.slotExpression is Issue 11108

Use of automated tooling to support comparison of the models developed
initially as part of the Eclipse GMT/UMLX project and being transferred to the
Eclipse QVT Declarative/QVT Operational Mappings Projects reveals the following
errors and anomalies in emof.ecore in the 07-07-08 ZIP.

Note that these errors and anomalies are not the same as those separately reported
for the QVT_1.0.mdl from which the Ecore was notionally auto-generated.

An Ecore file resolving these anomalies is attached

These changes mostly affect non-normative files which were corrected when QVT 1.1 issued revised
files based on Eclipse QVT contributions. However a few changes remain to be resolved in the main
text.

Use of automated tooling to support comparison of the models developed
initially as part of the Eclipse GMT/UMLX project and being transferred to the
Eclipse QVT Declarative/QVT Operational Mappings Projects reveals the following
errors and anomalies in emof.ecore in the 07-07-08 ZIP.

Note that these errors and anomalies are not the same as those separately reported
for the QVT_1.0.mdl from which the Ecore was notionally auto-generated.

An Ecore file resolving these anomalies is attached.

These changes mostly affect non-normative files which were corrected when QVT 1.1 issued revised
files based on Eclipse QVT contributions. However a few changes remain to be resolved in the main
text.
No: Domain.typedModel lowerbound of 0 is correct; primitive domains have no TypedModel
Rule.transformation lowerbound change is Issue 11825.

Use of automated tooling to support comparison of the models developed
initially as part of the Eclipse GMT/UMLX project and being transferred to the
Eclipse QVT Declarative/QVT Operational Mappings Projects reveals the following
errors and anomalies in emof.ecore in the 07-07-08 ZIP.

Note that these errors and anomalies are not the same as those separately reported
for the QVT_1.0.mdl from which the Ecore was notionally auto-generated.

An Ecore file resolving these anomalies is attached.

No Data Available

Use of automated tooling to support comparison of the models developed
initially as part of the Eclipse GMT/UMLX project and being transferred to the
Eclipse QVT Declarative/QVT Operational Mappings Projects reveals the following
errors and anomalies in emof.ecore in the 07-07-08 ZIP.

Note that these errors and anomalies are not the same as those separately reported
for the QVT_1.0.mdl from which the Ecore was notionally auto-generated.

An Ecore file resolving these anomalies is attached.

These changes mostly affect non-normative files which were corrected when QVT 1.1 issued revised
files based on Eclipse QVT contributions. However a few changes remain to be resolved in the main
text.
CollectionTemplateExp.rest/member lowerBound is Issue 11826.
PropertyTemplateItem.value multiplicity is right in diagram not text

UnpackExp should not compose targetVariable There are a lot of issues in this section: 1. name of Variable association was not updated to targetVariable. 2.

is missed. 3. variable should not compose. They should refer for instance a previously defined VarInitExp::referredVariable. 4. Parenthesis are missed in the first example (notation section). 5. Remember to update the diagram in figure 8.6 (pag 86). Note: These proposed changes are needed if you want to allow unpacking OrderedTuples using previously defined variables (which makes sense). Another (worst) alternative is forcing to declare new variables . In this case, the notation section should be changed.

No Data Available

There is no support for queries in the QVT Core concrete syntax.

Suggest: re-use the concrete syntax of QVT Relation, except that the query
is defined at global scope and so must be qualified by the name of a
transformation defined in the same source unit.

example:

query txName::getStringSize (someString:String): Integer

Simple change. Names are left vague pending resolution of Issue 10935.

Problem's text: // shorthand for mylist->forEach i.late resolve(Table)
discussion: EBNF and forExp suggest using always braces to enclose the forExp body.
Suggestion: Enclose the forEach's body with '

'.

yes

Problem's text: ->forEach (cl) cleaningTransf.map removeDups(cl);
discussion: EBNF and forExp suggest using always braces to enclose the forExp body.
Suggestion: Enclose the forEach's body with '

'. Note that there are two forExps in this section

yes

Problem's text: This is called the “collect” shorthand
discussion: Since OCL provides a "collect" shorthand (f.i. doing aCollection.anOperationCall()), I would rather call "xcollect" shortand to avoid confusions.
suggestion: Replate "collect" by "xcollect".

OCL provides an 'implicit collect' shorthand, so 'imperative collect' is a better contrast

Problem's text: Superclasses OperationCallExp
discussion: It should extend ImperativeCallExp instead. The diagram is well showed.
suggestion: Replate "OperationCallExp" by "ImperativeCallExp".

Duplicates in part Issue 12527.
Disposition: See issue 12527 for disposition

missed text: there is a missed text related to the initExpression association.
discussion: If we have a look to the diagram in figure 8.2, we may realize that a description of the initExpression association is missed.
suggestion: include the following text in the association's description:
initExpression: OclExpression [0..1]

An optional OCL Expression to initialize the contextual property.

Yes.
Already correct in the QVT 1.1 models

Problem's text: // shorthand of self.ownedElement->xcollect i.map class2table();
discussion: It seems that the imperativeIteratExp has not been correctly notated.
suggestion: replace the text above by: // shorthand of self.ownedElement->xcollect(i | i.map class2table());

yes

Issue : QVT 1.0 Section 7,8,9,10 : Navigating non-navigable opposite roles

UML models drawn with Rose allow an opposite role to be defined for a
uni-directional role. This practice is common but haphazard in UML Infrastructure,
EMOF, OCL and QVT specification diagrams.

However EMOF provides only the (run-time) usage of the model and so any
EMOF (or Ecore) model generator must strip non-navigable opposite roles.

QVT matches models at compile-time and matching has no inherent need to
observe navigation constraints. This is amply demonstrated by the Rel2Core
transformation that makes extensive use of, for instance, the inverse Key to Class
relationship.

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

Problem: some QVT transformations require names for non-navigable opposite roles,
but those names cannot be present in layered multi-package EMOF meta-models.

The Rel2Core transformation of Section 10.3 cannot be implemented with QVT 1.0.

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

Abandoning EMOF (or Ecore) compliance in favour of perhaps CMOF seems unacceptable.

Changing EMOF (or Ecore) to incorporate opposite roles is not possible because
an EMOF specification cannot be extended to include the opposite role of every
meta-model that will ever exist.

Even if it was, there would be a substantial delay until meta-modelling tools
adopted the change and a problem with poor standardisation and global
non-interference of opposite rolenames.

QVT must therefore support definition of non-navigable role names as part of a
transformation. ModelMorf provided a very practical concrete syntax solution,
whereby the reserved operation opposite(qualified-role-name) could be used as
the missing opposite role-name wherever a forward role-name could be used.

An upward compatible abstract syntax requires an additional is-opposite qualifier
for each referred property.

So for

QVTCore::PropertyAssignment add isOpposite:Boolean[0..1] default false.

QVTTemplate::PropertyTemplateItem add isOpposite:Boolean[0..1] default false.

QVTRelation::Key add oppositeParts:Property[0..*]

with the constraint that parts.size() + oppositeParts.size() > 0

Perhaps QVTOperational::Module needs an additional oppositeConfigProperty and
QVTOperational::ContextualProperty needs an additional isOpposite too.

No Data Available

7.11.2.3 and Figure 7.6 both impose a lowerBound of 1 on CollectionTemplateExp.member and CollectionTemplateExp.rest.

However, the concrete syntax permits an empty match. This empty match is exploited in the
UnsharedWhenVarsToMgVars relation in Section 10.

Suggest:

Change CollectionTemplateExp.member to [0..*]
Change CollectionTemplateExp.rest to [0..1]

Add a sentence to clarify the empty match semantics.

yes

Mapping is a Rule and Rule.transformation has unit multiplicity and is a container.
Therefore Rule.context can never be a container.

This could be fixed in a number of ways:

Fix 1: Change Rule.transformation to 0..1
--> allow hierarchical Rule containment
--> all Transformation rules are distinctly named
– no representation change
– minor semantic relaxation for QVTr/QVTo
– minor semantic surprise for QVTc - composed mapping has null Mapping.transformation.

Fix 2: Change Rule.context to not composes
--> require flat Rule containment
--> Transformation can have multiple unnamed rules
– no change for QVTc/QVTo
– representation change for QVTc

Fix 3: Change opposite of Transformation.rule from Rule.transformation[1] to Rule.context[1]
Redefine Rule.transformation[1] as a derived property
Remove mapping.context (inherited from Rule)
– Doesn't work: context needs to be NamedElement to be either Rule or Transformation

Fix 4: Change opposite of Transformation.rule from Rule.transformation[1] to Rule.owningTransformation[0..1]
Redefine Rule.transformation[1] as a derived property
Rule.transformation := owningTransformation
Mapping.transformation := if context then context.transformation else owningTransformation endif
– no representation change
– minor semantic relaxation for QVTr/QVTo

Recommend 4.

Rule.transformation changed to 0..1 in QVTCore.xml for QVT 1.1.
Fix 4 doesn't seem that wonderful, so go with the obvious Fix 1. And why prohibit all reuse of Rule
outside a Transformation?

Text of Clause 7.2.3 is unclear:

Suggested rewrite:

(1) Add the following as the first two sentences of the first
paragraph.

"In the evaluation of a Transformation, one or more domains are
specified as target. The phrase 'executing in the direction of [some
domain]' refers to these domains."

Then change a few words in the paragraph as suggest by the text in []
below:

"Whether or not the [change "the" to "a"] relationship maybe [should
be "is"] enforced is determined by the target domain, which may be
marked as checkonly or enforced. When a transformation
[change "transformation" to "relation"] is enforced
[change "enforced" to "evaluated"] in the direction of a checkonly
domain, it is simply checked to see if [change "if" to "whether"]
there exists a valid match in the relevant model that satisfies the
relationship. When a transformation executes in the direction of the
model of an enforced domain, if checking fails, the target model is
modified so as to satisfy the relationship, i.e. a
check-before-enforce semantics."

[Strike the words beginning with "i.e." "check-before-enforce" is new
terminology that is neither defined nor helpful.]

Yes, we can certainly try to be clearer.

Section 7.13.5 Relation BNF

The grammar rule for template is incorrect (It does not allow a
template to have embedded within it another template. The example in
Appendix A will not compile with such a grammar.)

It says:

<propertyTemplate> ::= <identifier> '=' <OclExpressionCS>

It should says:
<propertyTemplate> ::= <identifier> '=' ( <template> |
<oclExpressionCS

No Data Available

It is not clear when and how you choose a top-level and not-top-level relation. Primitive domains, the reason for them and the use of them, are not explained although they are used in the Relation language example A1.1.1

'top' is explained clearly in Section 7.2.2 Top-level Relations.
'primitive' is a bit of a secret

have built a transformation engine based on QVT relations. The QVT relations example in Annex A contains a 'function' PrimitiveTypeToSqlType at the end of the example in textual syntax. This example is the only relations example in the whole spec. Nowhere is the semantics of 'function' defined nor contains the grammar of the concrete syntax a function keyword. However, 'query' is defined. Is 'function' another name for 'query'?

QVT Base has a Function.queryExpression.
QVT 1.1 added the mapping from queryCS to Function.
Not 'nowhere' but we can do better

9.17.12 EnforcementOperation, Figure 9.3
----------------------------------------

The definition: "operationCallExp : OperationCallExp[1]"
and the corresponding "*" enforcementOperation multiplicity in
Figure 9.3 provides a consistent definition of a shared reference
to a Call expression. There is no indication of where this
expression might be contained. It is unlikely that such
expressions can usefully be shared since they must refer to
invocation-site-specific variables.

Therefore:

Change the definition to:

operationCallExp : OperationCallExp[1]

and draw the composition with 0..1 parent multiplicity.

Simple change already in QVTcore.xml

The specification introduces comments by concrete syntax. Comments within the abstract syntax are not considered. This is i.e. undesirable for automated analysis of software product quality to which transformations are subject. One would again need to analyze the AST instead of the transformation metamodel. So I propose to introduce comments for transformations.

No Data Available

There is a reference to a figure that does not exist : figure 1.

No Data Available

The grammar rule used to produce a forExp doesn't coincide with the notation specified in the abstract syntax section for it (Pag 89, Section 8.2.2.6). The rule production in the grammar is wrong. Suggestion: Change the production rule: <for_exp> ::= ('forEach' | 'forOne') '(' <iter_declarator_list> ('|' <expression> )? ')' <expression_block>

No Data Available

A clarification is needed in the text because it says "A variable parameter is an abstract concept..." and it can lead to confussion. A variable parameter can not be abstract because we could not create VarParameters for Helpers or Constructors (We could just create ModelParameters or MappingParameters). Suggestion: Remove the word "abstract".

No Data Available

The extraCondition association needs revision: 1. The name does match with the diagram. 2. The cardinality is incorrect. Suggestion: Change the text with the following line: additionalCondition: OclExpression [*]

No Data Available