${taskforce.name} Avatar
  1. OMG Task Force

QVT RTF 1.1 — Closed Issues

  • Key: QVT11
  • Issues Count: 113
Open Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
QVT11-113 QVTo Standard Lybrary and typedefs Issue. Extending OCL predefined types QVT 1.0 QVT 1.1 Duplicate or Merged closed
QVT11-112 7.13.1 Qualified query name QVT 1.0 QVT 1.1 Resolved closed
QVT11-111 7.13.1 Multiple transformation extension QVT 1.0 QVT 1.1 Resolved closed
QVT11-110 Section: 9/17 page 134 QVT 1.0 QVT 1.1 Resolved closed
QVT11-109 Section: 9/17 page 132 QVT 1.0 QVT 1.1 Resolved closed
QVT11-108 Section: 8/2 page 102 QVT 1.0 QVT 1.1 Resolved closed
QVT11-107 Section: 8/2 page 101 QVT 1.0 QVT 1.1 Resolved closed
QVT11-106 Section: 8/2 page 99 QVT 1.0 QVT 1.1 Resolved closed
QVT11-105 Section: 8/2 page 98 QVT 1.0 QVT 1.1 Resolved closed
QVT11-104 Section: 8/2 page 97 QVT 1.0 QVT 1.1 Resolved closed
QVT11-103 Section: 8/2 QVT 1.0 QVT 1.1 Resolved closed
QVT11-102 Section: 8/2 page 95 QVT 1.0 QVT 1.1 Resolved closed
QVT11-101 Section: 8/2 page 94 QVT 1.0 QVT 1.1 Resolved closed
QVT11-100 Section: 8/2 page 93 QVT 1.0 QVT 1.1 Resolved closed
QVT11-99 Section: 8/2 page 92 QVT 1.0 QVT 1.1 Resolved closed
QVT11-96 Section: 8/2 page 79 QVT 1.0 QVT 1.1 Resolved closed
QVT11-95 Section: 8/2 page 70 QVT 1.0 QVT 1.1 Resolved closed
QVT11-94 Section: A.2.2 QVT 1.0 QVT 1.1 Resolved closed
QVT11-98 Section: 8/2 page 91 QVT 1.0 QVT 1.1 Resolved closed
QVT11-97 Section: 8/2 page 86 QVT 1.0 QVT 1.1 Resolved closed
QVT11-93 Section: 8/3 page 110 (03) QVT 1.0 QVT 1.1 Resolved closed
QVT11-92 Section: 8/3 page 110 (02) QVT 1.0 QVT 1.1 Resolved closed
QVT11-91 Section: 8/3 page 110 QVT 1.0 QVT 1.1 Resolved closed
QVT11-90 Section: 8/2 page 99 QVT 1.0 QVT 1.1 Resolved closed
QVT11-89 Section: 8/2 page 95 QVT 1.0 QVT 1.1 Resolved closed
QVT11-88 Section: 8/2 page 88 QVT 1.0 QVT 1.1 Resolved closed
QVT11-87 Section: 8/1 QVT 1.0 QVT 1.1 Resolved closed
QVT11-86 Section: 7/13 QVT 1.0 QVT 1.1 Resolved closed
QVT11-85 Section: 8/2 page 79 QVT 1.0 QVT 1.1 Resolved closed
QVT11-83 Section: 7/11 QVT 1.0 QVT 1.1 Resolved closed
QVT11-82 Section: 8/2 QVT 1.0 QVT 1.1 Resolved closed
QVT11-84 Section: 8/2 QVT 1.0 QVT 1.1 Resolved closed
QVT11-80 Wrong Chapter reference on Page 2 Language Dimension QVT 1.0 QVT 1.1 Resolved closed
QVT11-79 Typos in signatures of "allSubobjectsOfType" and "allSubobjectsOfKind" QVT 1.0 QVT 1.1 Resolved closed
QVT11-77 Minor typographical error in ImperativeIterateExp notation QVT 1.0 QVT 1.1 Resolved closed
QVT11-76 Typo in 'Model::rootObjects' signature QVT 1.0 QVT 1.1 Resolved closed
QVT11-70 Page 103: Associations Section 8.2.2.23 InstantiationExp QVT 1.0 QVT 1.1 Resolved closed
QVT11-69 Page 100: Superclasses Section 8.2.2.8 LogExp QVT 1.0 QVT 1.1 Resolved closed
QVT11-74 Page 106: Associations Section 8.2.2.29 DictLiteralExp QVT 1.0 QVT 1.1 Resolved closed
QVT11-73 Page 105: Associations Section 8.2.2.26 DictionaryType QVT 1.0 QVT 1.1 Resolved closed
QVT11-78 Capitalization of leading characters in multiword operation names QVT 1.0 QVT 1.1 Resolved closed
QVT11-75 Page 108: Section 8.3 Standard Library QVT 1.0 QVT 1.1 Resolved closed
QVT11-71 Page 103: Figure 8.7 QVT 1.0 QVT 1.1 Resolved closed
QVT11-68 Page 95: Associations Section 8.2.2.8 SwitchExp QVT 1.0 QVT 1.1 Resolved closed
QVT11-72 Page 105: Associations Section 8.2.2.24 Typedef QVT 1.0 QVT 1.1 Resolved closed
QVT11-65 Page 90: Notation Section 8.2.2.4 WhileExp QVT 1.0 QVT 1.1 Resolved closed
QVT11-64 Page 89: Figure 8.6 QVT 1.0 QVT 1.1 Resolved closed
QVT11-67 Page 95: Notation Section 8.2.2.7 ImperativeIterateExp QVT 1.0 QVT 1.1 Resolved closed
QVT11-66 Page 93: Associations Section 8.2.2.7 ImperativeIterateExp QVT 1.0 QVT 1.1 Resolved closed
QVT11-63 Page 87: Notation Section 8.2.1.24 ObjectExp (03) QVT 1.0 QVT 1.1 Resolved closed
QVT11-62 Page 87: Section 8.2.1.24 ObjectExp QVT 1.0 QVT 1.1 Resolved closed
QVT11-61 Page 87: Section 8.2.1.24 ObjectExp QVT 1.0 QVT 1.1 Resolved closed
QVT11-81 A referenced picture is missing QVT 1.0 QVT 1.1 Resolved closed
QVT11-1 Missing explanations in BNF QVT 1.0 QVT 1.1 Resolved closed
QVT11-7 9.18 Top-level syntax QVT 1.0 QVT 1.1 Resolved closed
QVT11-6 9.18 The middle direction packages QVT 1.0 QVT 1.1 Resolved closed
QVT11-11 Consider renaming collectselect as xcollectselect QVT 1.0 QVT 1.1 Resolved closed
QVT11-10 9.18 Typographics Issues QVT 1.0 QVT 1.1 Resolved closed
QVT11-4 9.18 Trailing | QVT 1.0 QVT 1.1 Resolved closed
QVT11-3 9.17 Variable composition QVT 1.0 QVT 1.1 Resolved closed
QVT11-13 Assignment.slotExpression QVT 1.0 QVT 1.1 Resolved closed
QVT11-12 Consider using asTuple instead of tuple keyword for TupleExp QVT 1.0 QVT 1.1 Resolved closed
QVT11-2 9.18: Realized QVT 1.0 QVT 1.1 Resolved closed
QVT11-8 9.18 Anonymous Maps QVT 1.0 QVT 1.1 Resolved closed
QVT11-9 9.18 EnforcementOperation QVT 1.0 QVT 1.1 Resolved closed
QVT11-5 9.18 GuardPattern assignments QVT 1.0 QVT 1.1 Resolved closed
QVT11-44 QVTo Standard Library. Clarification of the side-effect operations is needed. QVT 1.0 QVT 1.1 Resolved closed
QVT11-43 QVTo Standard Library: Some operation's signatures seem to be erroneous. QVT 1.0 QVT 1.1 Resolved closed
QVT11-54 Page 75: Section 8.2.1.13 Constructor QVT 1.0 QVT 1.1 Resolved closed
QVT11-53 Page 73: Section 8.2.1.11 Helper QVT 1.0 QVT 1.1 Resolved closed
QVT11-48 add the following operations to mutable lists QVT 1.0 QVT 1.1 Resolved closed
QVT11-47 Missing operations on Lists QVT 1.0 QVT 1.1 Resolved closed
QVT11-42 QVT 1.0 9.18 Missing transformation extension concrete syntax QVT 1.0 QVT 1.1 Resolved closed
QVT11-41 QVT 1.0 7.13.5 Transformation hierarchy QVT 1.0 QVT 1.1 Resolved closed
QVT11-51 Page 72, Figure 8-2 QVT 1.0 QVT 1.1 Resolved closed
QVT11-50 Page 65, Notation Section 8.2.1.3 Module QVT 1.0 QVT 1.1 Resolved closed
QVT11-45 Explanation of the 'Model::removeElement' operation needs clarification QVT 1.0 QVT 1.1 Resolved closed
QVT11-46 explanation of the operation: 'List(T)::insertAt(T,int) QVT 1.0 QVT 1.1 Resolved closed
QVT11-52 Page 73, Section 8.2.1.10 OperationalTransformation QVT 1.0 QVT 1.1 Resolved closed
QVT11-49 Pag 63, Section 8.2.1.1 OperationalTransformation QVT 1.0 QVT 1.1 Resolved closed
QVT11-39 Errors and anomalies in QVT 1.0 07-07-08 ZIP qvtoperational.ecore QVT 1.0 QVT 1.1 Resolved closed
QVT11-38 Errors and anomalies in QVT 1.0 07-07-08 ZIP imperativeocl.ecore QVT 1.0 QVT 1.1 Resolved closed
QVT11-29 Section: 8.1.14 QVT 1.0 QVT 1.1 Resolved closed
QVT11-28 MOF QVT 1.0, 8.2.2.22, Unclear specification of Unpack notation shorthand QVT 1.0 QVT 1.1 Resolved closed
QVT11-32 Errors and anomalies in QVT 1.0 07-07-08 ZIP emof.ecore QVT 1.0 QVT 1.1 Resolved closed
QVT11-31 Errors and anomalies in QVT 1.0 07-07-08 ZIP qvt_metamodel.emof.xml QVT 1.0 QVT 1.1 Resolved closed
QVT11-30 errors and anomalies in QVT_1.0.mdl in the 07-07-08 ZIP QVT 1.0 QVT 1.1 Resolved closed
QVT11-37 Errors and anomalies in QVT 1.0 07-07-08 ZIP qvtcore.ecore QVT 1.0 QVT 1.1 Resolved closed
QVT11-36 Errors and anomalies in QVT 1.0 07-07-08 ZIP qvtrelation.ecore QVT 1.0 QVT 1.1 Resolved closed
QVT11-34 Errors and anomalies in QVT 1.0 07-07-08 ZIP qvtbase.ecore QVT 1.0 QVT 1.1 Resolved closed
QVT11-33 Errors and anomalies in QVT 1.0 07-07-08 ZIP essentialocl.ecore QVT 1.0 QVT 1.1 Resolved closed
QVT11-35 Errors and anomalies in QVT 1.0 07-07-08 ZIP qvttemplate.ecore QVT 1.0 QVT 1.1 Resolved closed
QVT11-27 Section: 8.2.2.22 QVT 1.0 QVT 1.1 Resolved closed
QVT11-40 QVT 1.0 9.* Missing query concrete syntax QVT 1.0 QVT 1.1 Resolved closed
QVT11-60 Page 86: Notation Section 8.2.1.23 ResolveExp QVT 1.0 QVT 1.1 Resolved closed
QVT11-59 Page 84: Notation Section 8.2.1.22 MappingCallExp QVT 1.0 QVT 1.1 Resolved closed
QVT11-57 Page 83: Notation Section 8.2.1.22 MappingCallExp QVT 1.0 QVT 1.1 Resolved closed
QVT11-56 Page 83: Section 8.2.1.22 MappingCallExp QVT 1.0 QVT 1.1 Resolved closed
QVT11-55 Page 75: Section 8.2.1.14 ContextualProperty QVT 1.0 QVT 1.1 Resolved closed
QVT11-58 Page 83: Notation Section 8.2.1.22 MappingCallExp QVT 1.0 QVT 1.1 Resolved closed
QVT11-14 QVT 1.0 Section 7,8,9,10 : Navigating non-navigable opposite roles QVT 1.0 QVT 1.1 Resolved closed
QVT11-19 Section 7.11.2.3: Empty CollectionTemplateExp is useful QVT 1.0 QVT 1.1 Resolved closed
QVT11-18 Inconsistent Rule.transformation multiplicity/composes for Mapping QVT 1.0 QVT 1.1 Resolved closed
QVT11-26 Issue against QVT ptc/07-07-07 : clause 7.2.3 QVT 1.0 QVT 1.1 Resolved closed
QVT11-25 Issue against QVT ptc/07-07-07 : relational grammar QVT 1.0 QVT 1.1 Resolved closed
QVT11-16 Section: 7.11.3 QVT 1.0 QVT 1.1 Resolved closed
QVT11-15 Section: 7.13 QVT 1.0 QVT 1.1 Resolved closed
QVT11-17 9.17.12, EnforcementOperation.operationCallExp should be composes QVT 1.0 QVT 1.1 Resolved closed
QVT11-23 Section: 7.13.3 / 8.4.2 QVT 1.0 QVT 1.1 Resolved closed
QVT11-22 There is a reference to a figure that does not exist : figure 1. QVT 1.0 QVT 1.1 Resolved closed
QVT11-24 Section: 8.4.7 QVT 1.0 QVT 1.1 Resolved closed
QVT11-21 Section: 8.2.1.7 QVT 1.0 QVT 1.1 Resolved closed
QVT11-20 Section: 8.2.1.6 QVT 1.0 QVT 1.1 Resolved closed

Issues Descriptions

QVTo Standard Lybrary and typedefs Issue. Extending OCL predefined types

  • Key: QVT11-113
  • Legacy Issue Number: 13331
  • Status: closed  
  • Source: Open Canarias, SL ( Adolfo Sanchez-Barbudo Herrera [X] (Inactive))
  • Summary:

    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.

  • Reported: QVT 1.0 — Mon, 22 Dec 2008 05:00 GMT
  • Disposition: Duplicate or Merged — QVT 1.1
  • Disposition Summary:

    issue closed, duplicate of issue # 13252

  • Updated: Fri, 6 Mar 2015 22:56 GMT

7.13.1 Qualified query name

  • Key: QVT11-112
  • Legacy Issue Number: 10948
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    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 ?

  • Reported: QVT 1.0 — Mon, 26 Mar 2007 04:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

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

    {' <OclExpressionCS> '}

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

  • Updated: Fri, 6 Mar 2015 22:55 GMT

7.13.1 Multiple transformation extension

  • Key: QVT11-111
  • Legacy Issue Number: 10947
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

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

    Suggest: change the concrete syntax.

  • Reported: QVT 1.0 — Mon, 26 Mar 2007 04:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

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

    {' <keyDecl>* ( <relation> | <query> )* '}

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

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Section: 9/17 page 134

  • Key: QVT11-110
  • Legacy Issue Number: 9443
  • Status: closed  
  • Source: Universidad Politécnica de Madrid ( Jorge Enrique Pérez-Martínez)
  • Summary:

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

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

  • Reported: QVT 1.0 — Tue, 14 Mar 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    In Section 9.17.8 (Assignment)

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

      "

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Section: 9/17 page 132

  • Key: QVT11-109
  • Legacy Issue Number: 9442
  • Status: closed  
  • Source: Universidad Politécnica de Madrid ( Jorge Enrique Pérez-Martínez)
  • Summary:

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

  • Reported: QVT 1.0 — Tue, 14 Mar 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Section: 8/2 page 102

  • Key: QVT11-108
  • Legacy Issue Number: 9441
  • Status: closed  
  • Source: Universidad Politécnica de Madrid ( Jorge Enrique Pérez-Martínez)
  • Summary:

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

    {composes, ordered}
  • Reported: QVT 1.0 — Tue, 14 Mar 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    In Section 8.2.2.31 (AnonymousTupleLiteralExp)

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

      "
      by "part: AnonymousTupleLiteralPart [*]

      {composes, ordered}

      "

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Section: 8/2 page 101

  • Key: QVT11-107
  • Legacy Issue Number: 9440
  • Status: closed  
  • Source: Universidad Politécnica de Madrid ( Jorge Enrique Pérez-Martínez)
  • Summary:

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

    {composes}
  • Reported: QVT 1.0 — Tue, 14 Mar 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    (1) In Figure 8.7, add the

    {ordered}

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

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

      "

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Section: 8/2 page 99

  • Key: QVT11-106
  • Legacy Issue Number: 9439
  • Status: closed  
  • Source: Universidad Politécnica de Madrid ( Jorge Enrique Pérez-Martínez)
  • Summary:

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

    {composes}
  • Reported: QVT 1.0 — Tue, 14 Mar 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    In Section 8.2.2.24 (Typedef)

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

      "

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Section: 8/2 page 98

  • Key: QVT11-105
  • Legacy Issue Number: 9438
  • Status: closed  
  • Source: Universidad Politécnica de Madrid ( Jorge Enrique Pérez-Martínez)
  • Summary:

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

    {composes}
  • Reported: QVT 1.0 — Tue, 14 Mar 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    In Section 8.2.2.22 (UnpackExp)

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

      "

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Section: 8/2 page 97

  • Key: QVT11-104
  • Legacy Issue Number: 9437
  • Status: closed  
  • Source: Universidad Politécnica de Madrid ( Jorge Enrique Pérez-Martínez)
  • Summary:

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

    {composes} Association variable of the UnpackExp class should be (see figure 8.6) variable: Variable [1..*] {composes}
  • Reported: QVT 1.0 — Tue, 14 Mar 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Section: 8/2

  • Key: QVT11-103
  • Legacy Issue Number: 9436
  • Status: closed  
  • Source: Universidad Politécnica de Madrid ( Jorge Enrique Pérez-Martínez)
  • Summary:

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

    {composes} Association log of the AssertExp class should be (see figure 8.6) log: LogExp [0..1] {composes}
  • Reported: QVT 1.0 — Tue, 14 Mar 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    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}

      "

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Section: 8/2 page 95

  • Key: QVT11-102
  • Legacy Issue Number: 9435
  • Status: closed  
  • Source: Universidad Politécnica de Madrid ( Jorge Enrique Pérez-Martínez)
  • Summary:

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

    {composes}
  • Reported: QVT 1.0 — Tue, 14 Mar 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    In Section 8.2.2.15 (ReturnExp)

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

      "

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Section: 8/2 page 94

  • Key: QVT11-101
  • Legacy Issue Number: 9434
  • Status: closed  
  • Source: Universidad Politécnica de Madrid ( Jorge Enrique Pérez-Martínez)
  • Summary:

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

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

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

    {composes}
  • Reported: QVT 1.0 — Tue, 14 Mar 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    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}

      "

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Section: 8/2 page 93

  • Key: QVT11-100
  • Legacy Issue Number: 9433
  • Status: closed  
  • Source: Universidad Politécnica de Madrid ( Jorge Enrique Pérez-Martínez)
  • Summary:

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

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

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

    {composes} Association item of the UnlinkExp class should be (see figure 8.6) item: OclExpression [1] {composes}
  • Reported: QVT 1.0 — Tue, 14 Mar 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    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}

      "

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Section: 8/2 page 92

  • Key: QVT11-99
  • Legacy Issue Number: 9432
  • Status: closed  
  • Source: Universidad Politécnica de Madrid ( Jorge Enrique Pérez-Martínez)
  • Summary:

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

  • Reported: QVT 1.0 — Tue, 14 Mar 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Section: 8/2 page 79

  • Key: QVT11-96
  • Legacy Issue Number: 9429
  • Status: closed  
  • Source: Universidad Politécnica de Madrid ( Jorge Enrique Pérez-Martínez)
  • Summary:

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

  • Reported: QVT 1.0 — Tue, 14 Mar 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Section: 8/2 page 70

  • Key: QVT11-95
  • Legacy Issue Number: 9428
  • Status: closed  
  • Source: Universidad Politécnica de Madrid ( Jorge Enrique Pérez-Martínez)
  • Summary:

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

    {composes, ordered}

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

    {composes}
  • Reported: QVT 1.0 — Tue, 14 Mar 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

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

    {composes}"
    by "result: VarParameter [*] {composes, ordered}"
    and replace "body: OperationBody [0..1] {composes, ordered}"
    by "body: OperationBody [0..1] {composes}

    "

    NOTE (FIXES after AB Review)
    Additional omissions concerning the

    {composes} and {ordered} indications in property definitions where detected (when comparing to diagrams). The following resolutions should also be applied
    - Add the missing {composes}

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

    • Add the missing {ordered}

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

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Section: A.2.2

  • Key: QVT11-94
  • Legacy Issue Number: 9427
  • Status: closed  
  • Source: Universidad Politécnica de Madrid ( Jorge Enrique Pérez-Martínez)
  • Summary:

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

  • Reported: QVT 1.0 — Tue, 14 Mar 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Section: 8/2 page 91

  • Key: QVT11-98
  • Legacy Issue Number: 9431
  • Status: closed  
  • Source: Universidad Politécnica de Madrid ( Jorge Enrique Pérez-Martínez)
  • Summary:

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

  • Reported: QVT 1.0 — Tue, 14 Mar 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Section: 8/2 page 86

  • Key: QVT11-97
  • Legacy Issue Number: 9430
  • Status: closed  
  • Source: Universidad Politécnica de Madrid ( Jorge Enrique Pérez-Martínez)
  • Summary:

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

  • Reported: QVT 1.0 — Tue, 14 Mar 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Section: 8/3 page 110 (03)

  • Key: QVT11-93
  • Legacy Issue Number: 9426
  • Status: closed  
  • Source: Universidad Politécnica de Madrid ( Jorge Enrique Pérez-Martínez)
  • Summary:

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

  • Reported: QVT 1.0 — Tue, 14 Mar 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Section: 8/3 page 110 (02)

  • Key: QVT11-92
  • Legacy Issue Number: 9425
  • Status: closed  
  • Source: Universidad Politécnica de Madrid ( Jorge Enrique Pérez-Martínez)
  • Summary:

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

  • Reported: QVT 1.0 — Tue, 14 Mar 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Section: 8/3 page 110

  • Key: QVT11-91
  • Legacy Issue Number: 9424
  • Status: closed  
  • Source: Universidad Politécnica de Madrid ( Jorge Enrique Pérez-Martínez)
  • Summary:

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

  • Reported: QVT 1.0 — Tue, 14 Mar 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    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"

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Section: 8/2 page 99

  • Key: QVT11-90
  • Legacy Issue Number: 9423
  • Status: closed  
  • Source: Universidad Politécnica de Madrid ( Jorge Enrique Pérez-Martínez)
  • Summary:

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

    {composes, ordered}

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

  • Reported: QVT 1.0 — Tue, 14 Mar 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

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

    {composes, ordered}


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

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Section: 8/2 page 95

  • Key: QVT11-89
  • Legacy Issue Number: 9422
  • Status: closed  
  • Source: Universidad Politécnica de Madrid ( Jorge Enrique Pérez-Martínez)
  • Summary:

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

  • Reported: QVT 1.0 — Tue, 14 Mar 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    close, no change

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Section: 8/2 page 88

  • Key: QVT11-88
  • Legacy Issue Number: 9421
  • Status: closed  
  • Source: Universidad Politécnica de Madrid ( Jorge Enrique Pérez-Martínez)
  • Summary:

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

  • Reported: QVT 1.0 — Tue, 14 Mar 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    Duplicate of issue 9254

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Section: 8/1

  • Key: QVT11-87
  • Legacy Issue Number: 9420
  • Status: closed  
  • Source: Universidad Politécnica de Madrid ( Jorge Enrique Pérez-Martínez)
  • Summary:

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

  • Reported: QVT 1.0 — Tue, 14 Mar 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Section: 7/13

  • Key: QVT11-86
  • Legacy Issue Number: 9419
  • Status: closed  
  • Source: Universidad Politécnica de Madrid ( Jorge Enrique Pérez-Martínez)
  • Summary:

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

  • Reported: QVT 1.0 — Tue, 14 Mar 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Section: 8/2 page 79

  • Key: QVT11-85
  • Legacy Issue Number: 9418
  • Status: closed  
  • Source: Universidad Politécnica de Madrid ( Jorge Enrique Pérez-Martínez)
  • Summary:

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

  • Reported: QVT 1.0 — Tue, 14 Mar 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Section: 7/11

  • Key: QVT11-83
  • Legacy Issue Number: 9415
  • Status: closed  
  • Source: Universidad Politécnica de Madrid ( Jorge Enrique Pérez-Martínez)
  • Summary:

    CollectionKind not defined in this document in kind: CollectionKind

  • Reported: QVT 1.0 — Sat, 11 Mar 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Section: 8/2

  • Key: QVT11-82
  • Legacy Issue Number: 9414
  • Status: closed  
  • Source: Universidad Politécnica de Madrid ( Jorge Enrique Pérez-Martínez)
  • Summary:

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

    {...}

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

  • Reported: QVT 1.0 — Sat, 11 Mar 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    (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.
  • Updated: Fri, 6 Mar 2015 22:55 GMT

Section: 8/2

  • Key: QVT11-84
  • Legacy Issue Number: 9417
  • Status: closed  
  • Source: Universidad Politécnica de Madrid ( Jorge Enrique Pérez-Martínez)
  • Summary:

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

  • Reported: QVT 1.0 — Tue, 14 Mar 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Wrong Chapter reference on Page 2 Language Dimension

  • Key: QVT11-80
  • Legacy Issue Number: 14549
  • Status: closed  
  • Source: InterComponentWare AG ( Markus von Rüden)
  • Summary:

    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

  • Reported: QVT 1.0 — Fri, 9 Oct 2009 04:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typos in signatures of "allSubobjectsOfType" and "allSubobjectsOfKind"

  • Key: QVT11-79
  • Legacy Issue Number: 13989
  • Status: closed  
  • Source: Open Canarias, SL ( Victor Sanchez)
  • Summary:

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

  • Reported: QVT 1.0 — Sun, 14 Jun 2009 04:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    yes

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Minor typographical error in ImperativeIterateExp notation

  • Key: QVT11-77
  • Legacy Issue Number: 13987
  • Status: closed  
  • Source: Open Canarias, SL ( Victor Sanchez)
  • Summary:

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

  • Reported: QVT 1.0 — Sun, 14 Jun 2009 04:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typo in 'Model::rootObjects' signature

  • Key: QVT11-76
  • Legacy Issue Number: 13913
  • Status: closed  
  • Source: Open Canarias, SL ( Victor Sanchez)
  • Summary:

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

  • Reported: QVT 1.0 — Thu, 30 Apr 2009 04:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    yes

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 103: Associations Section 8.2.2.23 InstantiationExp

  • Key: QVT11-70
  • Legacy Issue Number: 13285
  • Status: closed  
  • Source: Open Canarias, SL ( Adolfo Sanchez-Barbudo Herrera [X] (Inactive))
  • Summary:

    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)

    { new Column(a.name,a.type.name) }

    ;

  • Reported: QVT 1.0 — Thu, 15 Jan 2009 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    yes

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 100: Superclasses Section 8.2.2.8 LogExp

  • Key: QVT11-69
  • Legacy Issue Number: 13284
  • Status: closed  
  • Source: Open Canarias, SL ( Adolfo Sanchez-Barbudo Herrera [X] (Inactive))
  • Summary:

    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.

  • Reported: QVT 1.0 — Thu, 15 Jan 2009 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    yes

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 106: Associations Section 8.2.2.29 DictLiteralExp

  • Key: QVT11-74
  • Legacy Issue Number: 13289
  • Status: closed  
  • Source: Open Canarias, SL ( Adolfo Sanchez-Barbudo Herrera [X] (Inactive))
  • Summary:

    Problem's text: part : DictLiteralPart [*]

    {composes,ordered}

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

  • Reported: QVT 1.0 — Thu, 15 Jan 2009 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 105: Associations Section 8.2.2.26 DictionaryType

  • Key: QVT11-73
  • Legacy Issue Number: 13288
  • Status: closed  
  • Source: Open Canarias, SL ( Adolfo Sanchez-Barbudo Herrera [X] (Inactive))
  • Summary:

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

  • Reported: QVT 1.0 — Thu, 15 Jan 2009 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    yes

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Capitalization of leading characters in multiword operation names

  • Key: QVT11-78
  • Legacy Issue Number: 13988
  • Status: closed  
  • Source: Open Canarias, SL ( Victor Sanchez)
  • Summary:

    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.

  • Reported: QVT 1.0 — Sun, 14 Jun 2009 04:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 108: Section 8.3 Standard Library

  • Key: QVT11-75
  • Legacy Issue Number: 13290
  • Status: closed  
  • Source: Open Canarias, SL ( Adolfo Sanchez-Barbudo Herrera [X] (Inactive))
  • Summary:

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

  • Reported: QVT 1.0 — Thu, 15 Jan 2009 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    yes

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 103: Figure 8.7

  • Key: QVT11-71
  • Legacy Issue Number: 13286
  • Status: closed  
  • Source: Open Canarias, SL ( Adolfo Sanchez-Barbudo Herrera [X] (Inactive))
  • Summary:

    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

  • Reported: QVT 1.0 — Thu, 15 Jan 2009 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 95: Associations Section 8.2.2.8 SwitchExp

  • Key: QVT11-68
  • Legacy Issue Number: 13283
  • Status: closed  
  • Source: Open Canarias, SL ( Adolfo Sanchez-Barbudo Herrera [X] (Inactive))
  • Summary:

    Problem's text: elsePart : OclExpresion

    {composes} [0..1]
    discussion: For uniformity, the multiplicty should appear after the type of the association.
    suggestion: change positions between "{composes}

    " and "[0..1].

  • Reported: QVT 1.0 — Thu, 15 Jan 2009 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    Yes, and correct spelling of OclExpression too.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 105: Associations Section 8.2.2.24 Typedef

  • Key: QVT11-72
  • Legacy Issue Number: 13287
  • Status: closed  
  • Source: Open Canarias, SL ( Adolfo Sanchez-Barbudo Herrera [X] (Inactive))
  • Summary:

    Problem's text: condition: OclExpression [1]

    {composes}

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

  • Reported: QVT 1.0 — Thu, 15 Jan 2009 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    Yes.
    Already correct in the QVT 1.1 models

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 90: Notation Section 8.2.2.4 WhileExp

  • Key: QVT11-65
  • Legacy Issue Number: 13280
  • Status: closed  
  • Source: Open Canarias, SL ( Adolfo Sanchez-Barbudo Herrera [X] (Inactive))
  • Summary:

    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)

    { body; break; }

    Discussion: It seems that ForEach and forOne expression are not correctly expressed in QVTo terms.
    Suggestion: Change the text above by:
    Collection(T)::forEach(source, iterator, condition,body) =
    do {
    count : Integer := 1;
    while (count <= source->size()) { var iterator := source->at(count); if (condition) body; count += 1; };
    };

    Collection(T)::forOne(source, iterator, condition,body) =
    forEach (iterator | condition) { body; break; }
  • Reported: QVT 1.0 — Thu, 15 Jan 2009 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    Yes.
    Yes.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 89: Figure 8.6

  • Key: QVT11-64
  • Legacy Issue Number: 13279
  • Status: closed  
  • Source: Open Canarias, SL ( Adolfo Sanchez-Barbudo Herrera [X] (Inactive))
  • Summary:

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

  • Reported: QVT 1.0 — Thu, 15 Jan 2009 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 95: Notation Section 8.2.2.7 ImperativeIterateExp

  • Key: QVT11-67
  • Legacy Issue Number: 13282
  • Status: closed  
  • Source: Open Canarias, SL ( Adolfo Sanchez-Barbudo Herrera [X] (Inactive))
  • Summary:

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

  • Reported: QVT 1.0 — Thu, 15 Jan 2009 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    yes

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 93: Associations Section 8.2.2.7 ImperativeIterateExp

  • Key: QVT11-66
  • Legacy Issue Number: 13281
  • Status: closed  
  • Source: Open Canarias, SL ( Adolfo Sanchez-Barbudo Herrera [X] (Inactive))
  • Summary:

    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 "

    {composes}
  • Reported: QVT 1.0 — Thu, 15 Jan 2009 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    Yes.
    Already correct in the QVT 1.1 models.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 87: Notation Section 8.2.1.24 ObjectExp (03)

  • Key: QVT11-63
  • Legacy Issue Number: 13278
  • Status: closed  
  • Source: Open Canarias, SL ( Adolfo Sanchez-Barbudo Herrera [X] (Inactive))
  • Summary:

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

    { … }
    discussion: It seems that the imperativeIteratExp has not been correctly notated.
    suggestion: replace the text above by: // shorthand for list->xcollect(x | object X{ … }

    );

  • Reported: QVT 1.0 — Thu, 15 Jan 2009 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    yes

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 87: Section 8.2.1.24 ObjectExp

  • Key: QVT11-62
  • Legacy Issue Number: 13277
  • Status: closed  
  • Source: Open Canarias, SL ( Adolfo Sanchez-Barbudo Herrera [X] (Inactive))
  • Summary:

    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.

  • Reported: QVT 1.0 — Thu, 15 Jan 2009 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    yes

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 87: Section 8.2.1.24 ObjectExp

  • Key: QVT11-61
  • Legacy Issue Number: 13276
  • Status: closed  
  • Source: Open Canarias, SL ( Adolfo Sanchez-Barbudo Herrera [X] (Inactive))
  • Summary:

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

  • Reported: QVT 1.0 — Thu, 15 Jan 2009 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

A referenced picture is missing

  • Key: QVT11-81
  • Legacy Issue Number: 14573
  • Status: closed  
  • Source: InterComponentWare AG ( Markus von Rüden)
  • Summary:

    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

  • Reported: QVT 1.0 — Tue, 20 Oct 2009 04:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing explanations in BNF

  • Key: QVT11-1
  • Legacy Issue Number: 10646
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

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

    {' <oclExpressionCS> '}

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

  • Reported: QVT 1.0 — Tue, 6 Feb 2007 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

9.18 Top-level syntax

  • Key: QVT11-7
  • Legacy Issue Number: 10942
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

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

  • Reported: QVT 1.0 — Sun, 25 Mar 2007 04:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    simple change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

9.18 The middle direction packages

  • Key: QVT11-6
  • Legacy Issue Number: 10941
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    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)

  • Reported: QVT 1.0 — Sun, 25 Mar 2007 04:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    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
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Consider renaming collectselect as xcollectselect

  • Key: QVT11-11
  • Legacy Issue Number: 11058
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

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

  • Reported: QVT 1.0 — Thu, 24 May 2007 04:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

9.18 Typographics Issues

  • Key: QVT11-10
  • Legacy Issue Number: 10945
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

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

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

    Typo. Remove 'e' in 'Assignement'.

  • Reported: QVT 1.0 — Sun, 25 Mar 2007 04:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

9.18 Trailing |

  • Key: QVT11-4
  • Legacy Issue Number: 10939
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    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

  • Reported: QVT 1.0 — Sun, 25 Mar 2007 04:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    Simple change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

9.17 Variable composition

  • Key: QVT11-3
  • Legacy Issue Number: 10938
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    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.

  • Reported: QVT 1.0 — Sun, 25 Mar 2007 04:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Assignment.slotExpression

  • Key: QVT11-13
  • Legacy Issue Number: 11108
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

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

  • Reported: QVT 1.0 — Fri, 1 Jun 2007 04:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    Simple move already in QVTcore.xml

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Consider using asTuple instead of tuple keyword for TupleExp

  • Key: QVT11-12
  • Legacy Issue Number: 11061
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

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

  • Reported: QVT 1.0 — Thu, 24 May 2007 04:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

9.18: Realized

  • Key: QVT11-2
  • Legacy Issue Number: 10937
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

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

  • Reported: QVT 1.0 — Sun, 25 Mar 2007 04:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

9.18 Anonymous Maps

  • Key: QVT11-8
  • Legacy Issue Number: 10943
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    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.

  • Reported: QVT 1.0 — Sun, 25 Mar 2007 04:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    simple change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

9.18 EnforcementOperation

  • Key: QVT11-9
  • Legacy Issue Number: 10944
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    There is no concrete syntax for enforcement operations.

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

  • Reported: QVT 1.0 — Sun, 25 Mar 2007 04:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    simple change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

9.18 GuardPattern assignments

  • Key: QVT11-5
  • Legacy Issue Number: 10940
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

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

    Suggest: GuardPattern uses Predicate rather than Constraint

  • Reported: QVT 1.0 — Sun, 25 Mar 2007 04:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    Simple change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

QVTo Standard Library. Clarification of the side-effect operations is needed.

  • Key: QVT11-44
  • Legacy Issue Number: 13183
  • Status: closed  
  • Source: Open Canarias, SL ( Adolfo Sanchez-Barbudo Herrera [X] (Inactive))
  • Summary:
      • 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.
  • Reported: QVT 1.0 — Fri, 19 Dec 2008 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

QVTo Standard Library: Some operation's signatures seem to be erroneous.

  • Key: QVT11-43
  • Legacy Issue Number: 13182
  • Status: closed  
  • Source: Open Canarias, SL ( Adolfo Sanchez-Barbudo Herrera [X] (Inactive))
  • Summary:
      • 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?
  • Reported: QVT 1.0 — Fri, 19 Dec 2008 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 75: Section 8.2.1.13 Constructor

  • Key: QVT11-54
  • Legacy Issue Number: 13269
  • Status: closed  
  • Source: Open Canarias, SL ( Adolfo Sanchez-Barbudo Herrera [X] (Inactive))
  • Summary:

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

    {composes} (from ImperativeOperation)
    The expression serving to populate the object using the given parameters. This expression should necessarily be
    an ObjectExp instance.
    discussion: This is not coherent with the ImperativeOperation definition. Body is an OperationBody, specifically a ConstructorBody.
    Suggestion: Replace the text above by the following:
    "/body: OperationBody [0..1] {composes}

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

  • Reported: QVT 1.0 — Thu, 15 Jan 2009 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 73: Section 8.2.1.11 Helper

  • Key: QVT11-53
  • Legacy Issue Number: 13268
  • Status: closed  
  • Source: Open Canarias, SL ( Adolfo Sanchez-Barbudo Herrera [X] (Inactive))
  • Summary:

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

  • Reported: QVT 1.0 — Thu, 15 Jan 2009 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

add the following operations to mutable lists

  • Key: QVT11-48
  • Legacy Issue Number: 13251
  • Status: closed  
  • Source: Open Canarias, SL ( Victor Sanchez)
  • Summary:

    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.

  • Reported: QVT 1.0 — Tue, 13 Jan 2009 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing operations on Lists

  • Key: QVT11-47
  • Legacy Issue Number: 13228
  • Status: closed  
  • Source: Open Canarias, SL ( Victor Sanchez)
  • Summary:

    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.

  • Reported: QVT 1.0 — Tue, 13 Jan 2009 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

QVT 1.0 9.18 Missing transformation extension concrete syntax

  • Key: QVT11-42
  • Legacy Issue Number: 12573
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    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

    { middle imports tuml2rdbms; uml imports umlMM; rdbms imports rdbmsMM; }

    extends base1, xx::base2, base3

  • Reported: QVT 1.0 — Fri, 11 Jul 2008 04:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

QVT 1.0 7.13.5 Transformation hierarchy

  • Key: QVT11-41
  • Legacy Issue Number: 12572
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

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

  • Reported: QVT 1.0 — Fri, 11 Jul 2008 04:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    simple change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 72, Figure 8-2

  • Key: QVT11-51
  • Legacy Issue Number: 13266
  • Status: closed  
  • Source: Open Canarias, SL ( Adolfo Sanchez-Barbudo Herrera [X] (Inactive))
  • Summary:

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

  • Reported: QVT 1.0 — Thu, 15 Jan 2009 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 65, Notation Section 8.2.1.3 Module

  • Key: QVT11-50
  • Legacy Issue Number: 13265
  • Status: closed  
  • Source: Open Canarias, SL ( Adolfo Sanchez-Barbudo Herrera [X] (Inactive))
  • Summary:

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

  • Reported: QVT 1.0 — Thu, 15 Jan 2009 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Explanation of the 'Model::removeElement' operation needs clarification

  • Key: QVT11-45
  • Legacy Issue Number: 13222
  • Status: closed  
  • Source: Open Canarias, SL ( Victor Sanchez)
  • Summary:

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

  • Reported: QVT 1.0 — Tue, 13 Jan 2009 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    simple change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

explanation of the operation: 'List(T)::insertAt(T,int)

  • Key: QVT11-46
  • Legacy Issue Number: 13223
  • Status: closed  
  • Source: Open Canarias, SL ( Victor Sanchez)
  • Summary:

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

  • Reported: QVT 1.0 — Tue, 13 Jan 2009 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 73, Section 8.2.1.10 OperationalTransformation

  • Key: QVT11-52
  • Legacy Issue Number: 13267
  • Status: closed  
  • Source: Open Canarias, SL ( Adolfo Sanchez-Barbudo Herrera [X] (Inactive))
  • Summary:

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

  • Reported: QVT 1.0 — Thu, 15 Jan 2009 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    Yes.
    Already correct in the QVT 1.1 models

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pag 63, Section 8.2.1.1 OperationalTransformation

  • Key: QVT11-49
  • Legacy Issue Number: 13264
  • Status: closed  
  • Source: Open Canarias, SL ( Adolfo Sanchez-Barbudo Herrera [X] (Inactive))
  • Summary:

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

  • Reported: QVT 1.0 — Thu, 15 Jan 2009 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    simple change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Errors and anomalies in QVT 1.0 07-07-08 ZIP qvtoperational.ecore

  • Key: QVT11-39
  • Legacy Issue Number: 12527
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    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

  • Reported: QVT 1.0 — Fri, 6 Jun 2008 04:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Errors and anomalies in QVT 1.0 07-07-08 ZIP imperativeocl.ecore

  • Key: QVT11-38
  • Legacy Issue Number: 12526
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    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.

  • Reported: QVT 1.0 — Fri, 6 Jun 2008 04:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.1.14

  • Key: QVT11-29
  • Legacy Issue Number: 12375
  • Status: closed  
  • Source: Open Canarias, SL ( Adolfo Sanchez-Barbudo Herrera [X] (Inactive))
  • Summary:

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

    { 1, 2, 3, }

    literal expressions wouldn't be supported).

  • Reported: QVT 1.0 — Tue, 8 Apr 2008 04:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF QVT 1.0, 8.2.2.22, Unclear specification of Unpack notation shorthand

  • Key: QVT11-28
  • Legacy Issue Number: 12374
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Section 8.2.2.22 provides no guidance on the meaning of:

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

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

    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.

  • Reported: QVT 1.0 — Tue, 8 Apr 2008 04:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Errors and anomalies in QVT 1.0 07-07-08 ZIP emof.ecore

  • Key: QVT11-32
  • Legacy Issue Number: 12520
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    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

  • Reported: QVT 1.0 — Fri, 6 Jun 2008 04:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Errors and anomalies in QVT 1.0 07-07-08 ZIP qvt_metamodel.emof.xml

  • Key: QVT11-31
  • Legacy Issue Number: 12519
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    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.

  • Reported: QVT 1.0 — Fri, 6 Jun 2008 04:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

errors and anomalies in QVT_1.0.mdl in the 07-07-08 ZIP

  • Key: QVT11-30
  • Legacy Issue Number: 12518
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    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

  • Reported: QVT 1.0 — Fri, 6 Jun 2008 04:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    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

    {ordered} so {ordered}

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Errors and anomalies in QVT 1.0 07-07-08 ZIP qvtcore.ecore

  • Key: QVT11-37
  • Legacy Issue Number: 12525
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    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

  • Reported: QVT 1.0 — Fri, 6 Jun 2008 04:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Errors and anomalies in QVT 1.0 07-07-08 ZIP qvtrelation.ecore

  • Key: QVT11-36
  • Legacy Issue Number: 12524
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    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

  • Reported: QVT 1.0 — Fri, 6 Jun 2008 04:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Errors and anomalies in QVT 1.0 07-07-08 ZIP qvtbase.ecore

  • Key: QVT11-34
  • Legacy Issue Number: 12522
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    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.

  • Reported: QVT 1.0 — Fri, 6 Jun 2008 04:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Errors and anomalies in QVT 1.0 07-07-08 ZIP essentialocl.ecore

  • Key: QVT11-33
  • Legacy Issue Number: 12521
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    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.

  • Reported: QVT 1.0 — Fri, 6 Jun 2008 04:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Errors and anomalies in QVT 1.0 07-07-08 ZIP qvttemplate.ecore

  • Key: QVT11-35
  • Legacy Issue Number: 12523
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    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.

  • Reported: QVT 1.0 — Fri, 6 Jun 2008 04:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.2.2.22

  • Key: QVT11-27
  • Legacy Issue Number: 12373
  • Status: closed  
  • Source: Open Canarias, SL ( Adolfo Sanchez-Barbudo Herrera [X] (Inactive))
  • Summary:

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

    {ordered}

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

  • Reported: QVT 1.0 — Mon, 7 Apr 2008 04:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

QVT 1.0 9.* Missing query concrete syntax

  • Key: QVT11-40
  • Legacy Issue Number: 12571
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    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

    { someString -> size() }
  • Reported: QVT 1.0 — Fri, 11 Jul 2008 04:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 86: Notation Section 8.2.1.23 ResolveExp

  • Key: QVT11-60
  • Legacy Issue Number: 13275
  • Status: closed  
  • Source: Open Canarias, SL ( Adolfo Sanchez-Barbudo Herrera [X] (Inactive))
  • Summary:

    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 '

    {' and '}

    '.

  • Reported: QVT 1.0 — Thu, 15 Jan 2009 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    yes

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 84: Notation Section 8.2.1.22 MappingCallExp

  • Key: QVT11-59
  • Legacy Issue Number: 13274
  • Status: closed  
  • Source: Open Canarias, SL ( Adolfo Sanchez-Barbudo Herrera [X] (Inactive))
  • Summary:

    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 '

    {' and '}

    '. Note that there are two forExps in this section

  • Reported: QVT 1.0 — Thu, 15 Jan 2009 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    yes

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 83: Notation Section 8.2.1.22 MappingCallExp

  • Key: QVT11-57
  • Legacy Issue Number: 13272
  • Status: closed  
  • Source: Open Canarias, SL ( Adolfo Sanchez-Barbudo Herrera [X] (Inactive))
  • Summary:

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

  • Reported: QVT 1.0 — Thu, 15 Jan 2009 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 83: Section 8.2.1.22 MappingCallExp

  • Key: QVT11-56
  • Legacy Issue Number: 13271
  • Status: closed  
  • Source: Open Canarias, SL ( Adolfo Sanchez-Barbudo Herrera [X] (Inactive))
  • Summary:

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

  • Reported: QVT 1.0 — Thu, 15 Jan 2009 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 75: Section 8.2.1.14 ContextualProperty

  • Key: QVT11-55
  • Legacy Issue Number: 13270
  • Status: closed  
  • Source: Open Canarias, SL ( Adolfo Sanchez-Barbudo Herrera [X] (Inactive))
  • Summary:

    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]

    {composes}

    An optional OCL Expression to initialize the contextual property.

  • Reported: QVT 1.0 — Thu, 15 Jan 2009 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    Yes.
    Already correct in the QVT 1.1 models

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 83: Notation Section 8.2.1.22 MappingCallExp

  • Key: QVT11-58
  • Legacy Issue Number: 13273
  • Status: closed  
  • Source: Open Canarias, SL ( Adolfo Sanchez-Barbudo Herrera [X] (Inactive))
  • Summary:

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

  • Reported: QVT 1.0 — Thu, 15 Jan 2009 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    yes

  • Updated: Fri, 6 Mar 2015 20:58 GMT

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

  • Key: QVT11-14
  • Legacy Issue Number: 11341
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

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

    { composed }
    and possibly relax the lower bound for
    QVTRelation::Key add parts:Property[0..*] { composed }

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

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

  • Reported: QVT 1.0 — Mon, 10 Sep 2007 04:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.11.2.3: Empty CollectionTemplateExp is useful

  • Key: QVT11-19
  • Legacy Issue Number: 11826
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    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.

  • Reported: QVT 1.0 — Mon, 17 Dec 2007 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    yes

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistent Rule.transformation multiplicity/composes for Mapping

  • Key: QVT11-18
  • Legacy Issue Number: 11825
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    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.

  • Reported: QVT 1.0 — Mon, 17 Dec 2007 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    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?

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue against QVT ptc/07-07-07 : clause 7.2.3

  • Key: QVT11-26
  • Legacy Issue Number: 12368
  • Status: closed  
  • Source: NIST ( Mr. Peter Denno)
  • Summary:

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

  • Reported: QVT 1.0 — Thu, 3 Apr 2008 04:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    Yes, we can certainly try to be clearer.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue against QVT ptc/07-07-07 : relational grammar

  • Key: QVT11-25
  • Legacy Issue Number: 12367
  • Status: closed  
  • Source: NIST ( Mr. Peter Denno)
  • Summary:

    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

  • Reported: QVT 1.0 — Thu, 3 Apr 2008 04:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.11.3

  • Key: QVT11-16
  • Legacy Issue Number: 11685
  • Status: closed  
  • Source: Siegfried Nolte ( Siegfried Nolte)
  • Summary:

    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

  • Reported: QVT 1.0 — Mon, 26 Nov 2007 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.13

  • Key: QVT11-15
  • Legacy Issue Number: 11602
  • Status: closed  
  • Source: Vienna University of Technology ( Johann Oberleitner)
  • Summary:

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

  • Reported: QVT 1.0 — Wed, 10 Oct 2007 04:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

9.17.12, EnforcementOperation.operationCallExp should be composes

  • Key: QVT11-17
  • Legacy Issue Number: 11708
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    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]

    {composes}

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

  • Reported: QVT 1.0 — Mon, 3 Dec 2007 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    Simple change already in QVTcore.xml

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.13.3 / 8.4.2

  • Key: QVT11-23
  • Legacy Issue Number: 12260
  • Status: closed  
  • Source: Forschungszentrum Karlsruhe ( Jens Kübler)
  • Summary:

    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.

  • Reported: QVT 1.0 — Tue, 4 Mar 2008 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

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

  • Key: QVT11-22
  • Legacy Issue Number: 12200
  • Status: closed  
  • Source: THALES ( Eric Maes)
  • Summary:

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

  • Reported: QVT 1.0 — Fri, 25 Jan 2008 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.4.7

  • Key: QVT11-24
  • Legacy Issue Number: 12362
  • Status: closed  
  • Source: Open Canarias, SL ( Adolfo Sanchez-Barbudo Herrera [X] (Inactive))
  • Summary:

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

  • Reported: QVT 1.0 — Tue, 1 Apr 2008 04:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.2.1.7

  • Key: QVT11-21
  • Legacy Issue Number: 12198
  • Status: closed  
  • Source: Open Canarias, SL ( Adolfo Sanchez-Barbudo Herrera [X] (Inactive))
  • Summary:

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

  • Reported: QVT 1.0 — Fri, 25 Jan 2008 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.2.1.6

  • Key: QVT11-20
  • Legacy Issue Number: 12173
  • Status: closed  
  • Source: Open Canarias, SL ( Adolfo Sanchez-Barbudo Herrera [X] (Inactive))
  • Summary:

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

    {composes, ordered}

  • Reported: QVT 1.0 — Mon, 14 Jan 2008 05:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT