MOF Query/View/Transformation Avatar
  1. OMG Specification

MOF Query/View/Transformation — Closed Issues

  • Acronym: QVT
  • Issues Count: 286
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
QVT13-99 QVTo: Mapping Overloading MOF 1.2 QVT 1.3 Resolved closed
QVT13-97 QVTo: xselectOne, xcollectselectOne is Sequence of One not One MOF 1.2 QVT 1.3 Duplicate or Merged closed
QVT13-93 QVTo: Mapping and other Identifiers MOF 1.2 QVT 1.3 Resolved closed
QVT13-78 QVTo: VariableInitExp wording for missing initializer MOF 1.2 QVT 1.3 Resolved closed
QVT13-58 QVTo: access/extension default for ImportKind MOF 1.2 QVT 1.3 Resolved closed
QVT13-56 QVTo: List navigation operator example problems QVT 1.2 QVT 1.3 Resolved closed
QVT13-61 QVTo: Calling the super implementation of an overriding operation MOF 1.2 QVT 1.3 Duplicate or Merged closed
QVT13-60 QVTo: non-mutating List operation example problem MOF 1.2 QVT 1.3 Resolved closed
QVT13-59 QVTc/QVTr: Imports QVT 1.0 QVT 1.3 Duplicate or Merged closed
QVT13-51 QVTo: null and AssignExp QVT 1.2 QVT 1.3 Resolved closed
QVT13-120 QVTo: object creation in helpers MOF 1.2 QVT 1.3 Duplicate or Merged closed
QVT13-53 QVTo: Standard Library return types QVT 1.2 QVT 1.3 Resolved closed
QVT13-47 QVTo: Per-transformation ModelTypes QVT 1.1 QVT 1.3 Closed; No Change closed
QVT13-48 allInstances() QVT 1.2 QVT 1.3 Resolved closed
QVT13-46 QVTo: multi-valued initialisation from single value QVT 1.2 QVT 1.3 Duplicate or Merged closed
QVT13-41 QVTr: Exact Collection match QVT 1.2 QVT 1.3 Resolved closed
QVT13-43 QVTr: Variable Initialization QVT 1.2 QVT 1.3 Resolved closed
QVT13-40 QVTc/QVTr: abstract mappings/relations QVT 1.1 QVT 1.3 Resolved closed
QVT13-39 QVTo: Redundant argument on matchIdentifier QVT 1.1 QVT 1.3 Resolved closed
QVT13-37 QVTo: deepclone on Collections QVT 1.1 QVT 1.3 Resolved closed
QVT13-38 QVTo: AssignExp unclear for OrderedSet QVT 1.1 QVT 1.3 Duplicate or Merged closed
QVT13-36 QVTo: Extents, Models and Model Parameters QVT 1.1 QVT 1.3 Resolved closed
QVT13-35 QVTo: Incorrect ModelType.additionalCondition multiplicity QVT 1.1 QVT 1.3 Closed; No Change closed
QVT13-50 QVTc: initialized variables QVT 1.2 QVT 1.3 Resolved closed
QVT13-42 QVTr: Multi-root match QVT 1.2 QVT 1.3 Resolved closed
QVT13-34 QVTo: xcollect is ambiguously flattened QVT 1.1 QVT 1.3 Resolved closed
QVT13-33 QVTo: Passing DataTypes 'by-reference' QVT 1.1 QVT 1.3 Resolved closed
QVT13-28 QVTo: 'result' for Tuple returns QVT 1.2 QVT 1.3 Resolved closed
QVT13-29 QVTo: invalid in ImperativeOCL QVT 1.2 QVT 1.3 Resolved closed
QVT13-30 QVTo: Inadequate helper/query distinction QVT 1.2 QVT 1.3 Duplicate or Merged closed
QVT13-26 Multiple input models QVT 1.1 QVT 1.3 Resolved closed
QVT13-24 QVTo: when and where as assertions QVT 1.1 QVT 1.3 Resolved closed
QVT13-20 QVTc/QVTr: Queries and their contexts QVT 1.1 QVT 1.3 Resolved closed
QVT13-22 QVTo: Trace data for an 'accessed' transformation QVT 1.1 QVT 1.3 Duplicate or Merged closed
QVT13-23 QVTo: Tracing and Resolving QVT 1.1 QVT 1.3 Resolved closed
QVT13-14 QVTo: ListLiteralExp inheritance QVT 1.1 QVT 1.3 Resolved closed
QVT13-16 QVTo: Introductory Examples Problems QVT 1.1 QVT 1.3 Resolved closed
QVT13-13 QVTo: Typedef for Standard Library predefined types QVT 1.0 QVT 1.3 Resolved closed
QVT13-6 QVTc/QVTr: Imports QVT 1.0 QVT 1.3 Resolved closed
QVT13-4 QVTr: UML to RDBMS Example Problems QVT 1.0 QVT 1.3 Resolved closed
QVT13-2 Missing Identifier Syntax QVT 1.0 QVT 1.3 Resolved closed
QVT13-101 QVTc/QVTo/QVTr acronyms MOF 1.2 QVT 1.3 Resolved closed
QVT13-45 QVTc/QVTr: Pattern.bindsTo composition QVT 1.2 QVT 1.3 Deferred closed
QVT13-32 Inconsistent multiple inheritance QVT 1.1 QVT 1.3 Deferred closed
QVT13-31 QVTr: working with stereotypes: QVT 1.0 QVT 1.3 Deferred closed
QVT13-21 QVTr: Deletion semantics QVT 1.1 QVT 1.3 Deferred closed
QVT13-19 QVTr: Rule Overriding semantics QVT 1.1 QVT 1.3 Deferred closed
QVT13-18 QVTc/QVTr: View/Transformation discrepancy QVT 1.1 QVT 1.3 Deferred closed
QVT13-17 QVTo: Relationship between QVTo Mapping and QVTr Relation QVT 1.1 QVT 1.3 Deferred closed
QVT13-15 QVTr: syntax mapping (correction to Issue 10646 resolution) QVT 1.1 QVT 1.3 Deferred closed
QVT13-11 QVTo: synonyms QVT 1.0 QVT 1.3 Resolved closed
QVT13-12 QVTo: Standard Library return types QVT 1.0 QVT 1.3 Duplicate or Merged closed
QVT13-9 QVTo: element creation and element attachment/detachment to/from an extent QVT 1.0 QVT 1.3 Duplicate or Merged closed
QVT13-10 QVTo: Typedef QVT 1.0 QVT 1.3 Resolved closed
QVT13-7 QVTr: BlackBox operation signature difficulties QVT 1.0 QVT 1.3 Deferred closed
QVT13-8 QVTo: ImperativeOCL conflicts with EssentialOCL semantics QVT 1.0 QVT 1.3 Resolved closed
QVT13-3 QVTr: Undefined semantics QVT 1.0 QVT 1.3 Deferred closed
QVT13-1 QVTr: Missing Name and Expression syntax QVT 1.0 QVT 1.3 Duplicate or Merged closed
QVT13-52 QVTo: Standard Library mode and namespace QVT 1.2 QVT 1.3 Deferred closed
QVT13-27 QVTo: Inadequate definition of "late" semantics QVT 1.2 QVT 1.3 Deferred closed
QVT13-25 QVTo: Enhance ObjectExp to allow constructors invocation QVT 1.1 QVT 1.3 Deferred closed
QVT13-134 QVTo: How can an UnlinkExp.target be a Property QVT 1.2 QVT 1.3 Deferred closed
QVT-90 Pre-ballot 2 FTF Appendix A: Erroneous memberSelection grammar QVT 1.0b1 QVT 1.0 Resolved closed
QVT-89 Chapter 7 QVTrelation Standard Library QVT 1.0b1 QVT 1.0 Resolved closed
QVT-88 RelationalTransformation as a subclass of Transformation QVT 1.0b1 QVT 1.0 Resolved closed
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
QVT-86 Top-levelness in QVT relations need to be enforced by a constraint QVT 1.0b1 QVT 1.0 Resolved closed
QVT-87 Rules for infering an extent QVT 1.0b1 QVT 1.0 Resolved closed
QVT-85 Escape characters in string literals QVT 1.0b1 QVT 1.0 Resolved closed
QVT-84 Kind of expressions in collection patterns QVT 1.0b1 QVT 1.0 Resolved closed
QVT-83 Relation To Core Transformation QVT 1.0b1 QVT 1.0 Resolved closed
QVT-82 Formatting QVT 1.0b1 QVT 1.0 Resolved closed
QVT-79 Member selection operator QVT 1.0b1 QVT 1.0 Resolved closed
QVT-80 Ambiguity QVT 1.0b1 QVT 1.0 Resolved closed
QVT-81 Typos QVT 1.0b1 QVT 1.0 Resolved closed
QVT-78 Filename QVT 1.0b1 QVT 1.0 Resolved closed
QVT-76 Missing paramDeclaration QVT 1.0b1 QVT 1.0 Resolved closed
QVT-75 Member selection as domain body QVT 1.0b1 QVT 1.0 Resolved closed
QVT-77 Missing oclExpressionCSList QVT 1.0b1 QVT 1.0 Resolved closed
QVT-74 Unsafe oclExpressionCS QVT 1.0b1 QVT 1.0 Resolved closed
QVT-73 Over-enthusiastic semicolon QVT 1.0b1 QVT 1.0 Resolved closed
QVT-70 Comments QVT 1.0b1 QVT 1.0 Resolved closed
QVT-71 Unquoted commas QVT 1.0b1 QVT 1.0 Resolved closed
QVT-72 Missing commas QVT 1.0b1 QVT 1.0 Resolved closed
QVT-69 OCL extensions QVT 1.0b1 QVT 1.0 Resolved closed
QVT-68 QVTrelation to QVTcore transformation QVT 1.0b1 QVT 1.0 Resolved closed
QVT11-110 Section: 9/17 page 134 QVT 1.0 QVT 1.1 Resolved closed
QVT-67 variable-assignment isn't defined in Core language QVT 1.0b1 QVT 1.0 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-106 Section: 8/2 page 99 QVT 1.0 QVT 1.1 Resolved closed
QVT11-107 Section: 8/2 page 101 QVT 1.0 QVT 1.1 Resolved closed
QVT11-104 Section: 8/2 page 97 QVT 1.0 QVT 1.1 Resolved closed
QVT11-105 Section: 8/2 page 98 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-99 Section: 8/2 page 92 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-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-96 Section: 8/2 page 79 QVT 1.0 QVT 1.1 Resolved closed
QVT11-94 Section: A.2.2 QVT 1.0 QVT 1.1 Resolved closed
QVT11-95 Section: 8/2 page 70 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-89 Section: 8/2 page 95 QVT 1.0 QVT 1.1 Resolved closed
QVT11-90 Section: 8/2 page 99 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-85 Section: 8/2 page 79 QVT 1.0 QVT 1.1 Resolved closed
QVT11-86 Section: 7/13 QVT 1.0 QVT 1.1 Resolved closed
QVT11-84 Section: 8/2 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
QVT-66 QVT Issue: Support for CMOF metamodels QVT 1.0b1 QVT 1.0 Resolved closed
QVT-63 When and where clause for mapping operations QVT 1.0b1 QVT 1.0 Resolved closed
QVT-65 Logging textual messages that depend on variables QVT 1.0b1 QVT 1.0 Resolved closed
QVT-64 Inconsistency of multiplicity of ImperativeIterateExp::target QVT 1.0b1 QVT 1.0 Resolved closed
QVT-62 Missing multiplicity of AnonymousLiteralPart::value QVT 1.0b1 QVT 1.0 Resolved closed
QVT-61 Missing iterator variable in resolve expressions QVT 1.0b1 QVT 1.0 Resolved closed
QVT-59 Missing association from MappingParameter to a ModelParameter QVT 1.0b1 QVT 1.0 Resolved closed
QVT-60 Missing variable references within inlined object expressions QVT 1.0b1 QVT 1.0 Resolved closed
QVT-58 Typo error ImperativeIteratorExp expected in diagram QVT 1.0b1 QVT 1.0 Resolved closed
QVT-57 Entry operations in operational definitions QVT 1.0b1 QVT 1.0 Resolved closed
QVT-56 isTopLevel should not be a derived property QVT 1.0b1 QVT 1.0 Resolved closed
QVT-55 RelationalTransformation as a subclass of Transformation QVT 1.0b1 QVT 1.0 Resolved closed
QVT-54 Typo error for properties whenOwner and whereOwner QVT 1.0b1 QVT 1.0 Resolved closed
QVT-53 Bad navigability in cross-package links QVT 1.0b1 QVT 1.0 Resolved closed
QVT-52 Revise the encoding of primitive domains QVT 1.0b1 QVT 1.0 Resolved closed
QVT-50 Page 131 QVT 1.0b1 QVT 1.0 Resolved closed
QVT-51 Incorrect composition of variables in patterns QVT 1.0b1 QVT 1.0 Resolved closed
QVT-48 Page 117 QVT 1.0b1 QVT 1.0 Resolved closed
QVT-47 Page 45 and 165 QVT 1.0b1 QVT 1.0 Resolved closed
QVT-49 Page 118 QVT 1.0b1 QVT 1.0 Resolved closed
QVT-46 Page 30 QVT 1.0b1 QVT 1.0 Resolved closed
QVT-45 Page 28 QVT 1.0b1 QVT 1.0 Resolved closed
QVT11-81 A referenced picture is missing 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-80 Wrong Chapter reference on Page 2 Language Dimension 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-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-75 Page 108: Section 8.3 Standard Library 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-72 Page 105: Associations Section 8.2.2.24 Typedef QVT 1.0 QVT 1.1 Resolved closed
QVT11-71 Page 103: Figure 8.7 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-65 Page 90: Notation Section 8.2.2.4 WhileExp 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-68 Page 95: Associations Section 8.2.2.8 SwitchExp 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-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-64 Page 89: Figure 8.6 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
QVT12-15 Not possible to remove from a mutable List QVT 1.1 QVT 1.2 Resolved closed
QVT12-18 Specify List::reject and other iterations QVT 1.1 QVT 1.2 Resolved closed
QVT12-9 clause 8.3.1.4 Exception needs to document the taxonomy of Exception types in QVT1.1 QVT 1.1 QVT 1.2 Resolved closed
QVT12-10 Consider submitting the QVTO profile out of UML Profile for NIEM, section 9-2 to QVT 1.2 QVT 1.1 QVT 1.2 Resolved closed
QVT12-16 Resolve expressions without source variable QVT 1.1 QVT 1.2 Resolved closed
QVT12-12 QVT atomicity QVT 1.1 QVT 1.2 Resolved closed
QVT12-14 ObjectExp Abstract Syntax misses a ConstructorBody QVT 1.1 QVT 1.2 Resolved closed
QVT12-17 Imprecise result types of resolveIn expressions QVT 1.1 QVT 1.2 Resolved closed
QVT12-13 Inconsistent description about constructor names QVT 1.1 QVT 1.2 Resolved closed
QVT12-11 Intermediate data not allowed for libraries QVT 1.1 QVT 1.2 Resolved closed
QVT12-6 Rule Overriding in QVTr QVT 1.1 QVT 1.2 Resolved closed
QVT12-5 Figure 7.3 QVT 1.1 QVT 1.2 Resolved closed
QVT12-8 abstract/concrete syntax for try/catch in clauses 8.2.2.13 & 8.2.2.14 lacks support for retrieving the exception caught QVT 1.1 QVT 1.2 Resolved closed
QVT12-2 Please provide a non-null text in the Scope section of documents ptc/09-12-06 and ptc/09-12-05 QVT 1.1 QVT 1.2 Resolved closed
QVT12-7 bug in the uml to rdbms transformation example QVT 1.1 QVT 1.2 Resolved closed
QVT12-4 Derived properties in QVTr QVT 1.1 QVT 1.2 Resolved closed
QVT12-3 QVT1.1: Add an operation Model::getURI() QVT 1.1 QVT 1.2 Resolved closed
QVT12-1 QVT 1.1 Opposite navigation scoping operator (Correction to Issue 11341 resolution) QVT 1.1 QVT 1.2 Resolved closed
QVT12-19 List does not support asList() QVT 1.1 QVT 1.2 Resolved closed
QVT12-20 What happens when an exception is thrown by an exception handler QVT 1.1 QVT 1.2 Resolved closed
QVT12-21 Issue 19178 resolution is rubbish QVT 1.1 QVT 1.2 Resolved closed
QVT11-59 Page 84: 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-57 Page 83: Notation Section 8.2.1.22 MappingCallExp 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-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-53 Page 73: Section 8.2.1.11 Helper 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-54 Page 75: Section 8.2.1.13 Constructor 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-51 Page 72, Figure 8-2 QVT 1.0 QVT 1.1 Resolved closed
QVT11-47 Missing operations on Lists 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-48 add the following operations to mutable lists 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-46 explanation of the operation: 'List(T)::insertAt(T,int) 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-44 QVTo Standard Library. Clarification of the side-effect operations is needed. 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-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-36 Errors and anomalies in QVT 1.0 07-07-08 ZIP qvtrelation.ecore 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-35 Errors and anomalies in QVT 1.0 07-07-08 ZIP qvttemplate.ecore 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-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-32 Errors and anomalies in QVT 1.0 07-07-08 ZIP emof.ecore 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-28 MOF QVT 1.0, 8.2.2.22, Unclear specification of Unpack notation shorthand 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-25 Issue against QVT ptc/07-07-07 : relational grammar QVT 1.0 QVT 1.1 Resolved closed
QVT11-27 Section: 8.2.2.22 QVT 1.0 QVT 1.1 Resolved closed
QVT11-29 Section: 8.1.14 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-24 Section: 8.4.7 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-21 Section: 8.2.1.7 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-20 Section: 8.2.1.6 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-19 Section 7.11.2.3: Empty CollectionTemplateExp is useful 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-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-14 QVT 1.0 Section 7,8,9,10 : Navigating non-navigable opposite roles 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-10 9.18 Typographics Issues QVT 1.0 QVT 1.1 Resolved closed
QVT11-8 9.18 Anonymous Maps QVT 1.0 QVT 1.1 Resolved closed
QVT11-11 Consider renaming collectselect as xcollectselect QVT 1.0 QVT 1.1 Resolved closed
QVT11-9 9.18 EnforcementOperation 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-5 9.18 GuardPattern assignments 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-2 9.18: Realized QVT 1.0 QVT 1.1 Resolved closed
QVT11-1 Missing explanations in BNF QVT 1.0 QVT 1.1 Resolved closed
QVT-44 Consider using the package keyword instead of metamodel QVT 1.0b1 QVT 1.0 Resolved closed
QVT-43 Consider using the case keyword within swith expression QVT 1.0b1 QVT 1.0 Resolved closed
QVT-42 Argument list missing in raise expression QVT 1.0b1 QVT 1.0 Resolved closed
QVT-38 Some errors in BNF grammar of the operational part QVT 1.0b1 QVT 1.0 Resolved closed
QVT-41 Consider adjusting the notation for unpack QVT 1.0b1 QVT 1.0 Resolved closed
QVT-39 Missing notation to indicate the enforced direction in mapping operations QVT 1.0b1 QVT 1.0 Resolved closed
QVT-40 Inconsistency in definition of TryExp with figure QVT 1.0b1 QVT 1.0 Resolved closed
QVT-35 Typos and omissions in the QVT operational Part QVT 1.0b1 QVT 1.0 Resolved closed
QVT-37 Missing text for notation for class properties in Section 8.4.6 QVT 1.0b1 QVT 1.0 Resolved closed
QVT-36 Any used instead of MOF::Object in operational type extensions QVT 1.0b1 QVT 1.0 Resolved closed
QVT-34 Top-level constraint too restrictive QVT 1.0b1 QVT 1.0 Resolved closed
QVT-33 8.4.3.5 != and <> QVT 1.0b1 QVT 1.0 Resolved closed
QVT-32 8.4.3.5 = and == QVT 1.0b1 QVT 1.0 Resolved closed
QVT-30 Chapter 7,8,9 EssentialOCL usage QVT 1.0b1 QVT 1.0 Resolved closed
QVT-31 Pre-ballot 2 FTF Appendix A: Erroneous collectionTemplate grammar QVT 1.0b1 QVT 1.0 Resolved closed
QVT-29 Chapter 7 Collection::=() QVT 1.0b1 QVT 1.0 Resolved closed
QVT-27 Consider renaming 'AnonymousTuple' as 'OrderedTuple' QVT 1.0b1 QVT 1.0 Resolved closed
QVT-26 QVTOperational examples have some errors and need to be inline with grammar QVT 1.0b1 QVT 1.0 Resolved closed
QVT-28 7.11.3.1 Relation.operationalImpl QVT 1.0b1 QVT 1.0 Resolved closed
QVT-25 Find better notation for explicit extent indication in op mapping parameter QVT 1.0b1 QVT 1.0 Resolved closed
QVT-24 8.4.6.2 QVToperational is not a syntax extension of OCL QVT 1.0b1 QVT 1.0 Resolved closed
QVT-23 7.13 Implicit Variable Declarations QVT 1.0b1 QVT 1.0 Resolved closed
QVT-22 7.13 Comments QVT 1.0b1 QVT 1.0 Resolved closed
QVT-21 7.11.2.3 CollectionTemplateExp.referredCollectionType QVT 1.0b1 QVT 1.0 Resolved closed
QVT-19 7.11.1.2 Meta-model Id persistence QVT 1.0b1 QVT 1.0 Resolved closed
QVT-20 7.11.2.3 CollectionTemplateExp QVT 1.0b1 QVT 1.0 Resolved closed
QVT-18 7.13.1 Collection conversions QVT 1.0b1 QVT 1.0 Resolved closed
QVT-17 7.13.1 Model class name semantics QVT 1.0b1 QVT 1.0 Resolved closed
QVT-16 7.13.1 Scoped transformation name QVT 1.0b1 QVT 1.0 Resolved closed
QVT-15 Distinguishing pure syntactic tags from other tags in QVTOperational QVT 1.0b1 QVT 1.0 Resolved closed
QVT-14 Extent of intermediate classes in QVT Operational QVT 1.0b1 QVT 1.0 Resolved closed
QVT-13 The QVT Operational StdLib has various mispellings and copy-paste errors QVT 1.0b1 QVT 1.0 Resolved closed
QVT-11 Incomplete specification for the resolution operation ResolveExp QVT 1.0b1 QVT 1.0 Resolved closed
QVT-12 Clarify the return type of xselect operator QVT 1.0b1 QVT 1.0 Resolved closed
QVT-9 The BNF syntax of QVTOperational is not complete QVT 1.0b1 QVT 1.0 Resolved closed
QVT-10 The representation and the containment of 'this' variable is missing QVT 1.0b1 QVT 1.0 Resolved closed
QVT-8 rules for solving type identifiers are missing in the QVTOperational syntax QVT 1.0b1 QVT 1.0 Resolved closed
QVT-7 Relations language should support "default assignments" QVT 1.0b1 QVT 1.0 Resolved closed
QVT-4 Collection Type syntax ambiguities QVT 1.0b1 QVT 1.0 Resolved closed
QVT-6 Relations language QVT 1.0b1 QVT 1.0 Resolved closed
QVT-5 Identifiers syntax to avoid reserved keywords QVT 1.0b1 QVT 1.0 Resolved closed
QVT-3 Problem with Domain syntax QVT 1.0b1 QVT 1.0 Resolved closed
QVT-1 Query result syntax QVT 1.0b1 QVT 1.0 Resolved closed
QVT-2 RelationalCallExp missing QVT 1.0b1 QVT 1.0 Resolved closed

Issues Descriptions

QVTo: Mapping Overloading

  • Key: QVT13-99
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    QVTo has one form of mapping overloading provided by disjuncts. This is poorly specified.

    It probably has another provided by name collision. This is unspecified.

  • Reported: MOF 1.2 — Tue, 6 Oct 2015 19:34 GMT
  • Disposition: Resolved — QVT 1.3
  • Disposition Summary:

    What are the QVTo mapping overloading semantics?

    QVTo has one form of mapping overloading provided by disjuncts. This is poorly specified.

    It probably has another provided by name collision. This is unspecified.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: xselectOne, xcollectselectOne is Sequence of One not One

  • Key: QVT13-97
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The return type of xselectOne, xcollectselectOne returns a SEquence rather than an optional value.

  • Reported: MOF 1.2 — Tue, 6 Oct 2015 18:42 GMT
  • Disposition: Duplicate or Merged — QVT 1.3
  • Disposition Summary:

    xselectOne, xcollectselectOne is Sequence of One not One

    The return type of xselectOne, xcollectselectOne returns a Sequence rather than an optional value.

    Discussion

    QVT13-34 revealed numerous errors in the pseudocode. This error is just one of many fixed by its resolution.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: Mapping and other Identifiers

  • Key: QVT13-93
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The <rulerefs> between mappings has no defined semantics.

    Presumably:

    <package-name>*::<transformation-name>::<context-type>::<mapping-name>

    allowing <package-name>*::<transformation-name> to be omitted defauklting to the current transdformation, and, preserving the current example semantics, resolving an omitted <context-type> by serching all mapping names in the transformation.

  • Reported: MOF 1.2 — Tue, 6 Oct 2015 12:29 GMT
  • Disposition: Resolved — QVT 1.3
  • Disposition Summary:

    Undefined rulerefs

    The <rulerefs> between mappings has no defined semantics.

    Presumably:

    <package-name>*::<transformation-name>::<context-type>::<mapping-name>

    allowing <package-name>*::<transformation-name> to be omitted defauklting to the current transdformation, and, preserving the current example semantics, resolving an omitted <context-type> by serching all mapping names in the transformation.

    Issue Links

    Discussion

    Since <mapping_id> needs definition, we can take the opportunity to rename the strange <rulerefs>.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: VariableInitExp wording for missing initializer

  • Key: QVT13-78
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    8.2.2.10 VariableInitExp says

    A variable may not declare an initialization value.

    when surely it means

    A variable may omit an initialization value.

  • Reported: MOF 1.2 — Mon, 5 Oct 2015 11:32 GMT
  • Disposition: Resolved — QVT 1.3
  • Disposition Summary:

    Unfortunate VariableInitExp wording for missing initializer

    8.2.2.10 VariableInitExp says

    A variable may not declare an initialization value.

    when surely it means

    A variable may omit an initialization value.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: access/extension default for ImportKind

  • Key: QVT13-58
  • Legacy Issue Number: 19816
  • Status: closed  
  • Source: Heinz Nixdorf Institute, University of Paderborn ( Christopher Gerking)
  • Summary:

    For imported compilation units, the specification should clearly state what happens if there is no corresponding ModuleImport for any of the modules included inside the imported unit.

    The Eclipse QVTo implementation applies extends semantics by default. A very bad idea, because it leads to undesired extensions and overridings (especially in case of multiple modules per unit).

    Using access as a default is a much better idea, but maybe clutters the namespaces at AST level with needless module imports.

    Therefore applying neither access nor extends could be another good idea, but lacks a helpful default behavior.

  • Reported: MOF 1.2 — Thu, 9 Jul 2015 04:00 GMT
  • Disposition: Resolved — QVT 1.3
  • Disposition Summary:

    Unspecified handling of imports without access/extends

    For imported compilation units, the specification should clearly state what happens if there is no corresponding ModuleImport for any of the modules included inside the imported unit.

    The Eclipse QVTo implementation applies extends semantics by default. A very bad idea, because it leads to undesired extensions and overridings (especially in case of multiple modules per unit).

    Using access as a default is a much better idea, but maybe clutters the namespaces at AST level with needless module imports.

    Therefore applying neither access nor extends could be another good idea, but lacks a helpful default behavior.

    Discussion

    Following some off-JIRA correspondence, the original issue is clearer and simpler.

    The 8.2.1.4 words say that ImportKind has only two possibilities. But the words and model omit a [1] multiplicity or defaultValue so that null is a third possibility. The grammar also permits a missing ImportKind.

    So as suggested we could introduce a third null semantics, or define one of access/extends as the default.

    I see no benefit in a third semantics.

    "extends" is a very serious mutating activity, not a default.

    "access" is harmless and non-mutating. Hardly AST clutter. If the user didn't want the names the user should not have specified an import.

    Let "access" be the default.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: List navigation operator example problems

  • Key: QVT13-56
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Clause 8.1.14 uses "mylist.add(5);" rather than "mylist->add(5);

    and "mydict.put"

  • Reported: QVT 1.2 — Mon, 13 Jul 2015 12:40 GMT
  • Disposition: Resolved — QVT 1.3
  • Disposition Summary:

    Incorrect navigation operator for LIst operations

    Clause 8.1.14 uses "mylist.add(5);" rather than "mylist->add(5); and "mydict.put"

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: Calling the super implementation of an overriding operation

  • Key: QVT13-61
  • Legacy Issue Number: 19823
  • Status: closed  
  • Source: Heinz Nixdorf Institute, University of Paderborn ( Christopher Gerking)
  • Summary:

    There is currently no way for an overriding operation to call its overridden super implementation. ImperativeOCL should provide something similar to the 'super' reference which is available in Java.

  • Reported: MOF 1.2 — Mon, 3 Aug 2015 04:00 GMT
  • Disposition: Duplicate or Merged — QVT 1.3
  • Disposition Summary:

    Calling the super implementation of an overriding operation

    There is currently no way for an overriding operation to call its overridden super implementation. ImperativeOCL should provide something similar to the 'super' reference which is available in Java.

    Discussion

    QVT13-93 clarifies the concept of a mapping identifier. An arbitrary mapping may therefore be called:

    self.map My::Tx::Your::Type::doIt(withSomething);

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: non-mutating List operation example problem

  • Key: QVT13-60
  • Legacy Issue Number: 19810
  • Status: closed  
  • Source: Heinz Nixdorf Institute, University of Paderborn ( Christopher Gerking)
  • Summary:

    The following helper from the specification is a NOP, because List::append has no side effect in QVT 1.2.

    helper Package::computeCandidates(inout list:List) : List

    { if (self.nothingToAdd()) return list; list.append(self.retrieveCandidates()); return list; }

    Therefore the snippet should rather use List::add.

  • Reported: MOF 1.2 — Thu, 25 Jun 2015 04:00 GMT
  • Disposition: Resolved — QVT 1.3
  • Disposition Summary:

    Incorrect use of side-effect free append in example

    The following helper from the specification is a NOP, because List::append has no side effect in QVT 1.2.

    helper Package::computeCandidates(inout list:List) : List

    { if (self.nothingToAdd()) return list; list.append(self.retrieveCandidates()); return list; }

    Therefore the snippet should rather use List::add.

    Discussion

    Yes

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTc/QVTr: Imports

  • Key: QVT13-59
  • Legacy Issue Number: 11690
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The "import" feature of Relations Language is not yet explained. And there is no example for it, too. For instance what does the "unit" in "import <unit>;" mean ?

  • Reported: QVT 1.0 — Tue, 27 Nov 2007 05:00 GMT
  • Disposition: Duplicate or Merged — QVT 1.3
  • Disposition Summary:

    Section: 7.13.5

    The "import" feature of Relations Language is not yet explained. And there is no example for it, too. For instance what does the "unit" in "import <unit>;" mean ?

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: null and AssignExp

  • Key: QVT13-51
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    "A compound assignment is equivalent to perform as much simple assignments as there are expressions. Null values are skipped."

    This is poor English and it conflicts with the OCL specification.

    Pedantically it only skips "Null" values so "null values" are allowed anyway.

    "An assignment may receive a future variable produced by a deferred resolve expression (see ResolveExp). The effect is equivalent to receive a null value except that a side-effect action occurs in order to allow re-executing the assignment at the end of the transformation.
    An assignment expression returns the assigned value unless it is a future value, in which case null is returned."

    This is barely intelligible and presumably related to the SmartQVT implementation. It certainly has confusion about nulls.

    I recommend following OCL and allowing null values. ->excluding(null) is easily added.

  • Reported: QVT 1.2 — Tue, 31 Mar 2015 16:15 GMT
  • Disposition: Resolved — QVT 1.3
  • Disposition Summary:

    Conflicting exclusion of null during assign

    "A compound assignment is equivalent to perform as much simple assignments as there are expressions. Null values are skipped."

    This is poor English and it conflicts with the OCL specification.

    Pedantically it only skips "Null" values so "null values" are allowed anyway.

    "An assignment may receive a future variable produced by a deferred resolve expression (see ResolveExp). The effect is equivalent to receive a null value except that a side-effect action occurs in order to allow re-executing the assignment at the end of the transformation.
    An assignment expression returns the assigned value unless it is a future value, in which case null is returned."

    This is barely intelligible and presumably related to the SmartQVT implementation. It certainly has confusion about nulls.

    I recommend following OCL and allowing null values. ->excluding(null) is easily added.

    Issue 19238

    AssignExp to an Collection should make clear that the results is

    target->including(source)->excluding(null)

    Issue 19687

    The two examples

    mymultivaluedproperty += object Node

    {…}; // additive semantics
    mymultivaluedproperty := object Node {…}

    ; // the list is reset and re-assigned

    are simple assignments from single valued RHS. These are not covered in the preceding description.

    I consider both to be errors since the RHS is unsuitable for assignment to the LHS. In both cases an asSet() or whatever should be appended.

    More generally, the library operation that exhibits the "additive semantics" should be clearly identified.

    Since addition to OCL collections is not permissible, it may be necessary to define constructors, so that

    var c : Set(String) := Set

    {"a"}

    ;

    invokes the Set(T)(Set(T)) constructor.

    This would allow initialization for a Sequence from a List and vice-versa that is otherwise magic.

    which should exploit an OCL definition of OrderedSet::including to be add at end if necessary.

    Discussion - nulls

    UML does not allow nulls in multi-values, therefore nulls must be excluded during assignments to properties.

    OCL does allow nulls, and even though this may appear to be a mistake, QVTo must support nulls in OCL collections until OCL is changed.

    Discussion - multiple values

    The current wording leaves open the design choice between:

    a) perfect fidelity of nested types, i.e. addition of a Collection of Collections adds the one Collection of Collection element

    b) perfect flattening, i.e. addition of a Collection of Collections adds all the elements in the nested collections.

    c) something in between, perhaps behaving differently depending whether the LHS is a nested collection or not,

    OCL unfortunately started without nested collections so that imploicit-collect flattens requiring the explicit collectNested for perfect Collection type fidelity. a) is not really an option. c) risks a confusing anarchy. b) is what is often wanted. If users want nested collections they can use more explicit operations.

    Discussion - future values

    Premature access to yet-to-be initialized values is obviously bad. Making this an error is an option, but it would be a breaking change; there may be users who poll the variable awaiting initialization. Simplest to just clarify the words to indicate that the value of any yet-to-be-initialized value is null, even when null is not assignable to the value. It is not initialized to null; it is null until initialized.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: object creation in helpers

  • Key: QVT13-120
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The prohibition on creation or update of instances in helpers has no justification. Why?

  • Reported: MOF 1.2 — Tue, 13 Oct 2015 09:58 GMT
  • Disposition: Duplicate or Merged — QVT 1.3
  • Disposition Summary:

    Allow object creation in helpers

    The prohibition on creation or update of instances in helpers has no justification. Why?

    Discussion

    This came up while clarifying wording for QVT13-33.

    The prohibition is presumably intended to ensure that all object creation has a corresponding trace record. A good idea but beyond the pragmatic integrity of QVTo. Untraced objects can be created in mappings anyway, so prohibiting their creation in helpers is just an unhelpful restriction on programming flexibility.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: Standard Library return types

  • Key: QVT13-53
  • Legacy Issue Number: 19760
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The objectsOf...(T) family of operations (e.g. Element::subobjectsOfKind(T), or Element::allSubobjectsOfType(T), or Model::objectsOfType(T)) returns a set of Elements.

    It should be possible to infer the precise return type from the given T, i.e., return a Set(T) instead of Set(Element).

    BTW, why is there no Model::objectsOfKind(T) ?

  • Reported: QVT 1.2 — Tue, 19 May 2015 04:00 GMT
  • Disposition: Resolved — QVT 1.3
  • Disposition Summary:

    Define return type for objectsOf...(T) operations more precisely

    The objectsOf...(T) family of operations (e.g. Element::subobjectsOfKind(T), or Element::allSubobjectsOfType(T), or Model::objectsOfType(T)) returns a set of Elements.

    It should be possible to infer the precise return type from the given T, i.e., return a Set(T) instead of Set(Element).

    BTW, why is there no Model::objectsOfKind(T) ?

    Discussion

    We can make the declaraions using the same approximation to a rigorous declaration as used by selectByKind in OCL 2.4.

    Omission of objectsOfKInd is an easily corrected oversight.

    The incorrect objectsOfKind usage by the current objectsOfType is a confusing error that gets worse when the correct operation is provided. Better to correct it.

    clone and deepClone from QVT13-12 can similarly exploit a T.

    The confusing wording of Model::createEmptyModel can be clarified,

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: Per-transformation ModelTypes

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

    a production rule seems to be missing: <module_element> ::= <modeltype> Since, a transformation file can define several transformations and libraries (modules), it is desirable having the possibility of defining modeltypes exclusively to a module. These "local" modelTypes should belong to the scope of a module, and it shouldn't be accessible to the remaining defined modules (unless the use of extension mechanisms is specified).

  • Reported: QVT 1.1 — Fri, 4 Apr 2008 04:00 GMT
  • Disposition: Closed; No Change — QVT 1.3
  • Disposition Summary:

    Section 8.7.1a production rule seems to be missing

    a production rule seems to be missing: <module_element> ::= <modeltype> Since, a transformation file can define several transformations and libraries (modules), it is desirable having the possibility of defining modeltypes exclusively to a module. These "local" modelTypes should belong to the scope of a module, and it shouldn't be accessible to the remaining defined modules (unless the use of extension mechanisms is specified).

    Discussion

    A transformation is a major programming element so multiple transformations per file seems as unusual as multiple Java classes per file.

    But we do already support

    transformation X(...) {...}
    transformation Y(...) {...}

    so perhaps we need per transformation modeltypes.

    But if we provided them as suggested: we would have

    transformation X(in q : Q) {
    modeltype Q uses ....;
    }

    allowing an outer declaration to depend on an inner.

    If a user really wants many transformations per file with many distinct conflicting modeltypes, then the user has the option to use distinctive names for each modeltype.

    Much more sensible to use multiple files in the first place.

    Similarly we don't want or support per-transformation imports.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

allInstances()

  • Key: QVT13-48
  • Legacy Issue Number: 19621
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    OCL's allInstances() applies to the one and only immutable model extent.

    The meaning of this in QVT with multiple, some mutable, extents/domains/typedModels is unclear.

    Suggest that allInstances applies to all the input and original inout extents only.

    Obtaining instances from other domains is available through alternate library operations such as objectsOfType in QVTo.

  • Reported: QVT 1.2 — Thu, 25 Sep 2014 04:00 GMT
  • Disposition: Resolved — QVT 1.3
  • Disposition Summary:

    allInstances() needs clarification

    OCL's allInstances() applies to the one and only immutable model extent.

    The meaning of this in QVT with multiple, some mutable, extents/domains/typedModels is unclear.

    Suggest that allInstances applies to all the input and original inout extents only.

    Obtaining instances from other domains is available through alternate library operations such as objectsOfType in QVTo.

    Discussion - QVTo

    allInstances() could be defined to apply to the initial, prevailing or final state. Since a QVTo execution proceeds through a predictable sequence of states limiting allInstances() to the initial state is unhelpful. A limitation to the final state is almost unuseable and may require a tool to introduce another form of late processing. Therefore the prevailing state is most appropriate for a QVTo allInstances().The returned instances are the mutable instances since any form of caching would impose an unjustified overhead.

    Discussion - QVTr/QVTc

    allInstances() could be defined to apply to the initial, prevailing or final state. The initial state is easy. The prevailing state does not exist declaratively. The final state is harder but may be useful for computing derived output values based on the outputs.

    However consider a cascade of endogeneous transformations A2B, B2C, C2D in which B2C performs an allInstances(). If we now compose the trio into A2B2C2D, the functionality of the allInstances() must not change. Therefore neither initial nor final state will do, since the initial state changes from B to A and the final state from C to D. We must use a prevailing state, which we can define as the final state of the domain in which the invocation of allInstances() occurs. For our example this is one of B or C and does not change as a consequence of the cascade.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: multi-valued initialisation from single value

  • Key: QVT13-46
  • Legacy Issue Number: 19687
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The two examples

    mymultivaluedproperty += object Node

    {…}; // additive semantics
    mymultivaluedproperty := object Node {…}

    ; // the list is reset and re-assigned

    are simple assignments from single valued RHS. These are not covered in the preceding description.

    I consider both to be errors since the RHS is unsuitable for assignment to the LHS. In both cases an asSet() or whatever should be appended.

    More generally, the library operation that exhibits the "additive semantics" should be clearly identified.

    Since addition to OCL collections is not permissible, it may be necessary to define constructors, so that

    var c : Set(String) := Set

    {"a"}

    ;

    invokes the Set(T)(Set(T)) constructor.

    This would allow initialization for a Sequence from a List and vice-versa that is otherwise magic.

  • Reported: QVT 1.2 — Mon, 15 Dec 2014 05:00 GMT
  • Disposition: Duplicate or Merged — QVT 1.3
  • Disposition Summary:

    Unclear multi-valued initialisation from single value

    The two examples

    mymultivaluedproperty += object Node

    {…}; // additive semantics
    mymultivaluedproperty := object Node {…}

    ; // the list is reset and re-assigned

    are simple assignments from single valued RHS. These are not covered in the preceding description.

    I consider both to be errors since the RHS is unsuitable for assignment to the LHS. In both cases an asSet() or whatever should be appended.

    More generally, the library operation that exhibits the "additive semantics" should be clearly identified.

    Since addition to OCL collections is not permissible, it may be necessary to define constructors, so that

    var c : Set(String) := Set

    {"a"}

    ;

    invokes the Set(T)(Set(T)) constructor.

    This would allow initialization for a Sequence from a List and vice-versa that is otherwise magic.

    Issue Links

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTr: Exact Collection match

  • Key: QVT13-41
  • Legacy Issue Number: 19663
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The QVTr AS allows CollectionTemplateExp::rest to be null corresponding to a precisely enumerated list of collection members to be matched.

    The QVTr CS does not support this.

    Suggest changing the

    '++' (restIdentifier=[pivot::Variable|UnrestrictedName] | '_')

    sub-parsing rule to

    ('++' (restIdentifier=[pivot::Variable|UnrestrictedName] | '_'))?

  • Reported: QVT 1.2 — Fri, 28 Nov 2014 05:00 GMT
  • Disposition: Resolved — QVT 1.3
  • Disposition Summary:

    Exact QVTr Collection match

    The QVTr AS allows CollectionTemplateExp::rest to be null corresponding to a precisely enumerated list of collection members to be matched.

    The QVTr CS does not support this.

    Suggest changing the

    '++' (restIdentifier=[pivot::Variable|UnrestrictedName] | '_')

    sub-parsing rule to

    ('++' (restIdentifier=[pivot::Variable|UnrestrictedName] | '_'))?

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTr: Variable Initialization

  • Key: QVT13-43
  • Legacy Issue Number: 19665
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    QVTr does not allow variables to be initialized at the point of declaration. This is a rather prehistoric limitation that significantly degrades readability.

    a) it requires separate declaration and assignment lines
    b) it inhibits inference of the variable type from the initializer
    c) it obfuscates the variable assignment

    The latter is a particular problem in QVTr where the assignment may a consequence of a pattern match;

    Suggest allowing an initializer on a VarDeclarationCS and allowing the type to be inferred from the initializer.

  • Reported: QVT 1.2 — Fri, 28 Nov 2014 05:00 GMT
  • Disposition: Resolved — QVT 1.3
  • Disposition Summary:

    QVTr Variable Initialization

    QVTr does not allow variables to be initialized at the point of declaration. This is a rather prehistoric limitation that significantly degrades readability.

    a) it requires separate declaration and assignment lines
    b) it inhibits inference of the variable type from the initializer
    c) it obfuscates the variable assignment

    The latter is a particular problem in QVTr where the assignment may a consequence of a pattern match;

    Suggest allowing an initializer on a VarDeclarationCS and allowing the type to be inferred from the initializer.

    Discussion

    The underlying Abstract Syntax supports an initializer.

    Prototyping in Eclipse QVTr demonstrated a useful reduction in line count and increase in clarity of the RelToCore transformation.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTc/QVTr: abstract mappings/relations

  • Key: QVT13-40
  • Legacy Issue Number: 19275
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    When mapping/relation refinement is used, it should be possible to specify via the abstract keyword that a mapping/relation is only intended for use in a refined form.

    Thus in A.3.1, declaring classAttributes abstract could determine whether the execution needs to consider matches not covered by the classPrimitiveAttributes and classComplexAttributes refinements.

  • Reported: QVT 1.1 — Thu, 27 Feb 2014 05:00 GMT
  • Disposition: Resolved — QVT 1.3
  • Disposition Summary:

    Support abstract mappings/relations

    When mapping/relation refinement is used, it should be possible to specify via the abstract keyword that a mapping/relation is only intended for use in a refined form.

    Thus in A.3.1, declaring classAttributes abstract could determine whether the execution needs to consider matches not covered by the classPrimitiveAttributes and classComplexAttributes refinements.

    Discussion

    A simple enhancement

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: Redundant argument on matchIdentifier

  • Key: QVT13-39
  • Legacy Issue Number: 19252
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Issue 19146 removed most of the erroneous matchXXX arguments but omitted to do so for String:: matchIndentifier

  • Reported: QVT 1.1 — Fri, 21 Feb 2014 05:00 GMT
  • Disposition: Resolved — QVT 1.3
  • Disposition Summary:

    Redundant argument on matchIdentifier

    Issue 19146 removed most of the erroneous matchXXX arguments but omitted to do so for String:: matchIdentifier

    Discussion

    Yes

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: deepclone on Collections

  • Key: QVT13-37
  • Legacy Issue Number: 19205
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The Issue 19146 resolution is not sufficiently clear for Collection::deepclone.

    Any nested mutables must be deepcloned, so the specification should require a recursive deepclone that the return decides between self or the clone according to whether any elements need to change

  • Reported: QVT 1.1 — Wed, 5 Feb 2014 05:00 GMT
  • Disposition: Resolved — QVT 1.3
  • Disposition Summary:

    Clarify deepclone on Collections

    The Issue 19146 resolution is not sufficiently clear for Collection::deepclone.

    Any nested mutables must be deepcloned, so the specification should require a recursive deepclone that the return decides between self or the clone according to whether any elements need to change

    Discussion

    Yes

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: AssignExp unclear for OrderedSet

  • Key: QVT13-38
  • Legacy Issue Number: 19238
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    AssignExp to an Collection should make clear that the results is

    target->including(source)->excluding(null)

    which should exploit an OCL definition of OrderedSet::including to be add at end if necessary.

  • Reported: QVT 1.1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Duplicate or Merged — QVT 1.3
  • Disposition Summary:

    AssignExp unclear for OrderedSet

    AssignExp to an Collection should make clear that the results is

    target->including(source)->excluding(null)

    which should exploit an OCL definition of OrderedSet::including to be add at end if necessary.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: Extents, Models and Model Parameters

  • Key: QVT13-36
  • Legacy Issue Number: 19204
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    There is no mention of extent in Section 8.1 where one might hope to find an overview of the utility.

    The proposed resolution of Issue 13103 clarifies the ability of ObjectExp to (re-)define the extent residence of a pre-existing object.

    MappingParameter has some contradictory indications that an extent is bound by the callee rather than the caller.

    Is this a consequence of the need for a MappingOperation to have a 1:1 correspondence to a QVTr Relation requiring the domain to be determined solely from the declaration? How is the inability of a Relation to have more than one parameter per domain accommodated when there can be more than one parameter per extent?

  • Reported: QVT 1.1 — Wed, 5 Feb 2014 05:00 GMT
  • Disposition: Resolved — QVT 1.3
  • Disposition Summary:

    Specify the utility of an extent

    There is no mention of extent in Section 8.1 where one might hope to find an overview of the utility.

    The proposed resolution of Issue 13103 clarifies the ability of ObjectExp to (re-)define the extent residence of a pre-existing object.

    MappingParameter has some contradictory indications that an extent is bound by the callee rather than the caller.

    Is this a consequence of the need for a MappingOperation to have a 1:1 correspondence to a QVTr Relation requiring the domain to be determined solely from the declaration? How is the inability of a Relation to have more than one parameter per domain accommodated when there can be more than one parameter per extent?

    Discussion

    A section on Extents is sadly lacking; write it.

    The confusing fiction that there is a correspondence between QVTo Model Parameters and QVTr Domains is best eliminated.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: Incorrect ModelType.additionalCondition multiplicity

  • Key: QVT13-35
  • Legacy Issue Number: 19201
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The EBNF:

    <modeltype> ::= 'modeltype' <identifier> <compliance_kind>?
    'uses' <packageref_list> <modeltype_where>? ';'
    <modeltype_where> ::= 'where' <expression_block>

    allows only a single where which may be a BlockExp, so ModelType.additionalCondition should be [0..1] rather than [*].

  • Reported: QVT 1.1 — Thu, 30 Jan 2014 05:00 GMT
  • Disposition: Closed; No Change — QVT 1.3
  • Disposition Summary:

    Incorrect ModelType.additionalCondition multiplicity

    The EBNF:

    <modeltype> ::= 'modeltype' <identifier> <compliance_kind>?
    'uses' <packageref_list> <modeltype_where>? ';'
    <modeltype_where> ::= 'where' <expression_block>

    allows only a single where which may be a BlockExp, so ModelType.additionalCondition should be [0..1] rather than [*].

    Discussion

    Yes, but

    <expression_block> ::= '{' <expression_list>? '}'

    which allows for the multiple expressions.

    The multiple expressions could be shown more clearly by flattening as:

    <modeltype> ::= 'modeltype' <identifier> <compliance_kind>?
    'uses' <packageref_list> ('where' '{' <expression_list>? '}')? ';'

    But in the absence of a CS2AS mapping, implementations are not obliged to create the inappropriate BlockExp.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTc: initialized variables

  • Key: QVT13-50
  • Legacy Issue Number: 19725
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Initializing variables at the point of declaration is generally recognized as good practice. QVTc does not support it.

    Suggest extend the (Realized) Variable syntax to support an initializer.

  • Reported: QVT 1.2 — Thu, 19 Feb 2015 05:00 GMT
  • Disposition: Resolved — QVT 1.3
  • Disposition Summary:

    Allow QVTc to use initialized variables

    Initializing variables at the point of declaration is generally recognized as good practice. QVTc does not support it.

    Suggest extend the (Realized) Variable syntax to support an initializer.

    Discussion

    Initializing RealizedVariables makes no sense, since a RealizedVariable is initialized by the new Type().

    Initializing (Unrealized)Variables is however useful and supported by the Abstract Syntax already; just need some Concrete Syntax re-using the := of an Assignment.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTr: Multi-root match

  • Key: QVT13-42
  • Legacy Issue Number: 19664
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The QVTr AS and CS permit only a single pattern to be matched in the input (and output) domains. QVTc permits multi-matches.

    This can be worked around with nested collections as demonstrated by RDomainToMBottomPredicateForEnforcement in RelToCore

    remainingUnBoundDomainVars: Set(essentialocl::Variable);
    predicatesWithVarBindings:Set(qvtbase::Predicate);

    domain relations rdtVarsSeq:Sequence(Set(Element)) {
    rdtSet:Set(Element) {
    r:Relation{},
    rd:RelationDomain{},
    te:ObjectTemplateExp {bindsTo = v:Variable {}}
    ++ _
    }
    ++ _
    };

    rdtVarsSeq->at(2) = predicatesWithoutVarBindings;
    rdtVarsSeq->at(3) = unboundDomainVars;

    The above is hard to read and uses nested collections in ways that are claimed to be unsupported. Much simpler to just write:

    domain relations
    r:Relation{},
    rd:RelationDomain{},
    te:ObjectTemplateExp {bindsTo = v:Variable {}},
    predicatesWithVarBindings:Set(qvtbase::Predicate) {},
    remainingUnBoundDomainVars: Set(essentialocl::Variable) {}
    ;

    Suggest in the AS, RelationDomain.pattern changes to RelationDomain.patterns, RelationDomain.rootVariable moves to DomainPattern.rootVariable.

    Suggest in the DomainCS CS, "pattern=DomainPatternCS" changes to "patterns+=DomainPatternCS (',' patterns+=DomainPatternCS)*"

    As a consequence additional variables may be passed in a RelationCallExp. These can still be in rootVariable order.

  • Reported: QVT 1.2 — Fri, 28 Nov 2014 05:00 GMT
  • Disposition: Resolved — QVT 1.3
  • Disposition Summary:

    QVTr Multi-root match

    The QVTr AS and CS permit only a single pattern to be matched in the input (and output) domains. QVTc permits multi-matches.

    This can be worked around with nested collections as demonstrated by RDomainToMBottomPredicateForEnforcement in RelToCore

    remainingUnBoundDomainVars: Set(essentialocl::Variable);
    predicatesWithVarBindings:Set(qvtbase::Predicate);

    domain relations rdtVarsSeq:Sequence(Set(Element)) {
    rdtSet:Set(Element) {
    r:Relation{},
    rd:RelationDomain{},
    te:ObjectTemplateExp {bindsTo = v:Variable {}}
    ++ _
    }
    ++ _
    };

    rdtVarsSeq->at(2) = predicatesWithoutVarBindings;
    rdtVarsSeq->at(3) = unboundDomainVars;

    The above is hard to read and uses nested collections in ways that are claimed to be unsupported. Much simpler to just write:

    domain relations
    r:Relation{},
    rd:RelationDomain{},
    te:ObjectTemplateExp {bindsTo = v:Variable {}},
    predicatesWithVarBindings:Set(qvtbase::Predicate) {},
    remainingUnBoundDomainVars: Set(essentialocl::Variable) {}
    ;

    Suggest in the AS, RelationDomain.pattern changes to RelationDomain.patterns, RelationDomain.rootVariable moves to DomainPattern.rootVariable.

    Suggest in the DomainCS CS, "pattern=DomainPatternCS" changes to "patterns+=DomainPatternCS (',' patterns+=DomainPatternCS)*"

    As a consequence additional variables may be passed in a RelationCallExp. These can still be in rootVariable order.

    Discussion

    This seems to be a completely unnecessary restriction that caused the author of relToCore significant difficulties.

    The only downside seems to be a slight increase in complexity of a RelationCallExp. No longer exactly one argument per domain, but linearizing the roots per domain is not exactly hard.

    (The spelling in the discussion is that of the Eclipse QVTr prototype. Changing pattern to patterns is not appropriate for QVT1.x where property names tend to be simple-singulars. Perhaps a change to owned-plurals and so ownedPatterns may be appropriate for QVT 2.0.)

    Exploiting this in relToCore should wait until an executable version has been debugged.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: xcollect is ambiguously flattened

  • Key: QVT13-34
  • Legacy Issue Number: 19177
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    xcolect is specified to like collect, which flattens, however the xcollect pseudocode does not flatten.

  • Reported: QVT 1.1 — Thu, 9 Jan 2014 05:00 GMT
  • Disposition: Resolved — QVT 1.3
  • Disposition Summary:

    xcollect is ambiguously flattened

    xcollect is specified to like collect, which flattens, however the xcollect pseudocode does not flatten.

    Discussion

    Ditto xcollectselect, xcollectselectOne

    Once an attempt is made to put the pseudo-code through Eclipse QVTo, it is quite amazing how many different errors there are.

    • spurious source/iterator arguments
    • missing compute open {
    • increarect non-collection returns
    • incorrect accommodation of ordered collections
    • no flattening
    • no single values
    • use of mutable Sequence rather than List
  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: Passing DataTypes 'by-reference'

  • Key: QVT13-33
  • Legacy Issue Number: 19019
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Intuitively List and Dict are objects, so if you pass them to a mapping/query/helper as an inout parameter, the object in the caller may be updated by the call.

    This is the behaviour of a Class Instance not a DataType Value.

    Please use the open https://bugs.eclipse.org/bugs/show_bug.cgi?id=420150 to discuss this topic.

  • Reported: QVT 1.1 — Wed, 23 Oct 2013 04:00 GMT
  • Disposition: Resolved — QVT 1.3
  • Disposition Summary:

    List and Dict Class/DataType confusion

    Intuitively List and Dict are objects, so if you pass them to a mapping/query/helper as an inout parameter, the object in the caller may be updated by the call.

    This is the behaviour of a Class Instance not a DataType Value.

    Discussion

    Equally intuitively List (and Dict) are values. Two distinct 'occurrences' may be equal. This is the behavior of a DataType not a Class.

    List and Dict are specified as CollectionType (DataType) derivations so we just need to fix up indications that List and Dict are Classes.

    While clarifying wording, QVT13-120 is merged to remove the prohibition on object creation/update in helpers.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: 'result' for Tuple returns

  • Key: QVT13-28
  • Legacy Issue Number: 19505
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The current phrasing

    Within a contextual operation <it>result</it> represents the unique result parameter (if there is a unique declared result) or the
    tuple containing the list of declared result parameters.

    suggests that the synthetic Tuple return is accessible as result. This is not necessary and imposes considerable implementation difficulties since a new Tuple would need creation with each mutation.

    Sucggest the new wording.

    Within a contextual operation for which no name is specified for a single return parameter, <it>result</it> is the implicit name of the parameter. If the name is specified explicitly, as is necessary for multiple returns, no pre-defined <it>result</it> variable exists.

  • Reported: QVT 1.2 — Wed, 2 Jul 2014 04:00 GMT
  • Disposition: Resolved — QVT 1.3
  • Disposition Summary:

    Clarify availability of 'result' for Tuple returns

    The current phrasing

    Within a contextual operation result represents the unique result parameter (if there is a unique declared result) or the
    tuple containing the list of declared result parameters.

    suggests that the synthetic Tuple return is accessible as result. This is not necessary and imposes considerable implementation difficulties since a new Tuple would need creation with each mutation.

    Suggest the new wording.

    Within a contextual operation for which no name is specified for a single return parameter, result is the implicit name of the parameter. If the name is specified explicitly, as is necessary for multiple returns, no pre-defined result variable exists.

    Discussion

    Yes

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: invalid in ImperativeOCL

  • Key: QVT13-29
  • Legacy Issue Number: 19548
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    OCL defines invalid as the result of a failed evaluation. The QVT specification is almost totally silent on invalid, except for a few library operations that may generate it.

    Presumably an invalid not 'caught' by oclIsInvalid/oclIsUndefined in QVTo causes a to-be-specifued exception to be raised in the problem statement.

    Presumably an invalid not 'caught' by oclIsInvalid/oclIsUndefined in QVTc/QVTr inhibits the detection of matches.

  • Reported: QVT 1.2 — Mon, 28 Jul 2014 04:00 GMT
  • Disposition: Resolved — QVT 1.3
  • Disposition Summary:

    invalid in QVT

    OCL defines invalid as the result of a failed evaluation. The QVT specification is almost totally silent on invalid, except for a few library operations that may generate it.

    Presumably an invalid not 'caught' by oclIsInvalid/oclIsUndefined in QVTo causes a to-be-specifued exception to be raised in the problem statement.

    Presumably an invalid not 'caught' by oclIsInvalid/oclIsUndefined in QVTc/QVTr inhibits the detection of matches.

    Discussion

    But invalid may be temporarily caught by a let variable of QVTo var. It is the use that is a problem.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: Inadequate helper/query distinction

  • Key: QVT13-30
  • Legacy Issue Number: 19571
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The Helper class in the AS syntax supports both helpers and queries.

    These two concepts have important distinctions that are poorly differentiated in 8.2.1.12, where as a minimum the two italicized terms 'helper' and 'query' should be used when defining the semantics of each.

    Presumably a 'query' cannot modify anything (other than the log file) anywhere.

    Presumably a 'helper' can modify anything anywhere, except of course sets and tuples that are always immutable.

    The current wording suggests that a 'helper' can modify sets and tuples but cannot modify objects or create objects. Surely a 'helper' cannot modify sets or tuples but can create or update objects?

  • Reported: QVT 1.2 — Wed, 6 Aug 2014 04:00 GMT
  • Disposition: Duplicate or Merged — QVT 1.3
  • Disposition Summary:

    Inadequate helper/query distinction

    The Helper class in the AS syntax supports both helpers and queries.

    These two concepts have important distinctions that are poorly differentiated in 8.2.1.12, where as a minimum the two italicized terms 'helper' and 'query' should be used when defining the semantics of each.

    Presumably a 'query' cannot modify anything (other than the log file) anywhere.

    Presumably a 'helper' can modify anything anywhere, except of course sets and tuples that are always immutable.

    The current wording suggests that a 'helper' can modify sets and tuples but cannot modify objects or create objects. Surely a 'helper' cannot modify sets or tuples but can create or update objects?

  • Updated: Tue, 29 Mar 2016 15:09 GMT

Multiple input models

  • Key: QVT13-26
  • Legacy Issue Number: 19428
  • Status: closed  
  • Source: kustar.ac.ae ( Fatma Mohamed)
  • Summary:

    This is a suggestion:

    A developer may need to take a set of in models that may vary in size each time he runs the transformation.

    So, instead of hard-coding the input/out put models when defining the transformation like this:

    transformation Uml2Rdbms(in uml:UML,out rdbms:RDBMS)

    The developer should be able to define a dynamic set of input models. So that he will not be obligated to change the transformation definition if the number of input models change every time he runs the transformation.

    For example, I defined a transformation that takes multiple input models (conforming to the same meta-model) to merge them. Now, I got different number of in models every time I run the transformation. To make this more dynamic, I need to take an array of models as an input to my transformation without specifying their numbers in the transformation definition each time I run the transformation.

  • Reported: QVT 1.1 — Thu, 22 May 2014 04:00 GMT
  • Disposition: Resolved — QVT 1.3
  • Disposition Summary:

    Dynamic set of input models

    This is a suggestion:

    A developer may need to take a set of in models that may vary in size each time he runs the transformation.

    So, instead of hard-coding the input/out put models when defining the transformation like this:

    transformation Uml2Rdbms(in uml:UML,out rdbms:RDBMS)

    The developer should be able to define a dynamic set of input models. So that he will not be obligated to change the transformation definition if the number of input models change every time he runs the transformation.

    For example, I defined a transformation that takes multiple input models (conforming to the same meta-model) to merge them. Now, I got different number of in models every time I run the transformation. To make this more dynamic, I need to take an array of models as an input to my transformation without specifying their numbers in the transformation definition each time I run the transformation.

    Discussion - imperative

    This is already supported by the QVTo grammar. Just define a Collection of models as input or output.

    transformation Uml2Rdbms(in uml:Sequence(UML),out rdbms:Sequence(RDBMS))

    and use collection operations to access the individual models.

    Discussion - declarative

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: when and where as assertions

  • Key: QVT13-24
  • Legacy Issue Number: 18363
  • Status: closed  
  • Source: gmail.com ( Fáo Levy Siqueira)
  • Summary:

    In operational QVT, it is not clear what happens when the "when" or "where" clause of an inherited mapping does not hold.

    Suggestion:
    Considering inheritance is a type (or, maybe, a synonym) of generalization, it would be expected that the semantics of inheritance mimics the semantics of generalization in MOF. The UML, which defines generalization used by CMOF and EMOF, states: "... features specified for instances of the general classifier are implicitly specified for instances of the specific classifier. Any constraint applying to instances of the general classifier also applies to instances of the specific classifier." (UML Infrastructure 2.4.1, p.51). If the "when" and "where" clauses are considered as features of a mapping, the clauses of the inherited mapping should be implicitly specified. Similarly, if they are considered as constraints applying to a mapping, the clauses defined in the inherited mapping should apply to the inheriting mapping. Therefore, a possible solution in both situations is to consider that the "when" and "where" clauses must hold in the inheriting mapping.

    Commentary:
    An interesting discussion is if something similar to the Liskov substitution principle should be applied in this situation.

  • Reported: QVT 1.1 — Fri, 4 Jan 2013 05:00 GMT
  • Disposition: Resolved — QVT 1.3
  • Disposition Summary:

    Undefined semantics for unsatisfied "when" and "where" in inherited mapping

    In operational QVT, it is not clear what happens when the "when" or "where" clause of an inherited mapping does not hold.

    Suggestion:
    Considering inheritance is a type (or, maybe, a synonym) of generalization, it would be expected that the semantics of inheritance mimics the semantics of generalization in MOF. The UML, which defines generalization used by CMOF and EMOF, states: "... features specified for instances of the general classifier are implicitly specified for instances of the specific classifier. Any constraint applying to instances of the general classifier also applies to instances of the specific classifier." (UML Infrastructure 2.4.1, p.51). If the "when" and "where" clauses are considered as features of a mapping, the clauses of the inherited mapping should be implicitly specified. Similarly, if they are considered as constraints applying to a mapping, the clauses defined in the inherited mapping should apply to the inheriting mapping. Therefore, a possible solution in both situations is to consider that the "when" and "where" clauses must hold in the inheriting mapping.

    Commentary:
    An interesting discussion is if something similar to the Liskov substitution principle should be applied in this situation.

    Discussion

    The suggestions regarding constraint inheritance and LSP are appropriate for a declarative language; they are not appropriate for a pragmatic imperative language such as QVTo. Each mapping can be independently specified.

    It can be made clearer that pre and post conditions are assertions that fail accordingly.

    Comparison of QVTr/QVTo when and where highlights the fallacy that a QVTo mapping is a refinement of QVTr relation. In QVTo, failure of a where post-condition is a catastrophic assertion failure, whereas a QVTr where clause is a corrollary to be attempted afterwards and ignored if it fails/fails to match. The claim in 8.1.4 that the QVTo when and where clauses are owned by QVTr is untrue; QVTo owns its own when and where clauses and works very well without any QVTr objects.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTc/QVTr: Queries and their contexts

  • Key: QVT13-20
  • Legacy Issue Number: 15523
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    QVTr already has queries but they are much less user friendly than e.g. MOFM2T's equivelent for which the first parameter is a hidden self, or indeed QVTo.

    Perhaps something closer to Complete OCL would do, allowing def'd attributes or operations.

  • Reported: QVT 1.1 — Fri, 13 Aug 2010 04:00 GMT
  • Disposition: Resolved — QVT 1.3
  • Disposition Summary:

    QVTr already has queries but they are much less user friendly than e.g. MOFM2T's equivelent

    QVTr already has queries but they are much less user friendly than e.g. MOFM2T's equivelent for which the first parameter is a hidden self, or indeed QVTo.

    Perhaps something closer to Complete OCL would do, allowing def'd attributes or operations.

    Discussion

    QVTo has contextual helpers.

    Syntactically it is trivial for QVTc and QVTo to have contextual queries just by allowing a scoped rather than simple name for the query.

    Semantically to avoid duuplicating QVTo AS irregularities we can use the synonym package merges for Complete OCL to make the implementation easy.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: Trace data for an 'accessed' transformation

  • Key: QVT13-22
  • Legacy Issue Number: 18323
  • Status: closed  
  • Source: campus.upb.de ( Christopher Gerking)
  • Summary:

    The spec should clarify the interaction of
    1.) explicit instantiation + execution of 'accessed' transformations, and
    2.) trace records / resolving.

    The following questions are of interest:

    How does the initial trace for an 'accessed' transformation look like? Does it reuse the records previously created by the 'accessing' transformation, or does an 'accessed' transformation always start on an empty trace?

    How does an 'accessed' transformation affect the trace? Are the trace records post-visible that were created during execution of the 'accessed' transformation, or is the trace of the 'accessing' transformation unchanged?

    Both issues heavily affect the results of resolve-operations. Resolving object references after executing an 'accessed' transformation would be very practical.

  • Reported: QVT 1.1 — Thu, 27 Dec 2012 05:00 GMT
  • Disposition: Duplicate or Merged — QVT 1.3
  • Disposition Summary:

    Trace data for an 'accessed' transformation

    The spec should clarify the interaction of
    1.) explicit instantiation + execution of 'accessed' transformations, and
    2.) trace records / resolving.

    The following questions are of interest:

    How does the initial trace for an 'accessed' transformation look like? Does it reuse the records previously created by the 'accessing' transformation, or does an 'accessed' transformation always start on an empty trace?

    How does an 'accessed' transformation affect the trace? Are the trace records post-visible that were created during execution of the 'accessed' transformation, or is the trace of the 'accessing' transformation unchanged?

    Both issues heavily affect the results of resolve-operations. Resolving object references after executing an 'accessed' transformation would be very practical.

    Discussion

    The resolution of QVT13-23 makes clear that the trace data contains a trace record for every mapping.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: Tracing and Resolving

  • Key: QVT13-23
  • Legacy Issue Number: 18324
  • Status: closed  
  • Source: campus.upb.de ( Christopher Gerking)
  • Summary:

    Trace data creation is specified to happen "at the end of the initialization section".

    For disjuncting mappings, the initialization section is never executed, which prevents any trace data from being stored.

    As a consequence, no resolution via resolve-in-expressions is possible on the disjuncting mapping, due to the missing trace record. This is problematic, since disjunction should be transparent from a resolver's point of view, i.e. it should not make a difference for resolution whether a mapping disjuncts or not.

    Hence, some clarification is required whether trace records are deliberately avoided for disjuncting mappings (for whatever reason), or whether trace data must be created in another place than the init section in case of a disjuncting mapping.

  • Reported: QVT 1.1 — Thu, 27 Dec 2012 05:00 GMT
  • Disposition: Resolved — QVT 1.3
  • Disposition Summary:

    No trace data for disjuncting mapping

    Trace data creation is specified to happen "at the end of the initialization section".

    For disjuncting mappings, the initialization section is never executed, which prevents any trace data from being stored.

    As a consequence, no resolution via resolve-in-expressions is possible on the disjuncting mapping, due to the missing trace record. This is problematic, since disjunction should be transparent from a resolver's point of view, i.e. it should not make a difference for resolution whether a mapping disjuncts or not.

    Hence, some clarification is required whether trace records are deliberately avoided for disjuncting mappings (for whatever reason), or whether trace data must be created in another place than the init section in case of a disjuncting mapping.

    Discussion

    It seems the 8.1.x section on Tracing never got written. Time for a thorough review and clarification.

    Trace lookups by source objects treat context and all in/inout parameters as source objects.

    Trace lookups by target objects treat all out/inout and result parameters as target objects.

    Trace lookups by mapping allow either disjuncting mapping or candidate mapping to be used as the mapping selection.

    If re-execution is to be completely suppressed and fully re-use a previous execution, the output trace should be the final outputs, but the existing text is clear that it is the preliminary outputs at the end of the initialization section. The earlier trace gives a slightly different semantics that requires the population section to modify the created object after it is traced and allows the population section to use the trace. This is different but fine when explained clearly.

    References to 8.1.12 refer to the new text from the QVT13-99 resolution.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: ListLiteralExp inheritance

  • Key: QVT13-14
  • Legacy Issue Number: 14620
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The resolution for Issue 12375 specifies that ListLiteralExp has
    CollectionLiteralExp
    as a superclass.

    This leaves the behaviour of the inherited kind and part attributes
    unspecified and
    rather embarrassing.

    ListLiteralExp (like DictLiteralExp) should inherit directly from
    LiteralExp.

  • Reported: QVT 1.1 — Wed, 11 Nov 2009 05:00 GMT
  • Disposition: Resolved — QVT 1.3
  • Disposition Summary:

    Inappropriate ListLiteralExp inheritance (Correction to issue 12375 resolution)

    The resolution for Issue 12375 specifies that ListLiteralExp has CollectionLiteralExp as a superclass.

    This leaves the behaviour of the inherited kind and part attributes unspecified and rather embarrassing.

    ListLiteralExp (like DictLiteralExp) should inherit directly from LiteralExp.

    Discussion

    The lack of specification of ListLiteralExp::kind and ListLiteralExp::part is indeed a problem.

    CollectionLiteralExp::kind is inextensible bloat that OCL could usefully eliminate, so no ListLiteralExp::kind is needed in QVTo.

    ListLiteralExp::part is needed if QVTo is truly an extension of OCL. Unfortunately the QVTo BNF omits the ".." operator and support for CollectionRanges.

    Therefore we need to introduce the missing CollectionRange parsing. ListLiteralExp can inherit LiteralExp adding CollectionLiteralExp::part but not CollectionLiteralExp::kind. ListLiteralExp::element is misguided; ListLiteralExp::part replaces it.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: Introductory Examples Problems

  • Key: QVT13-16
  • Legacy Issue Number: 15376
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The second example contains

    "if result then return;"

    which has a non-boolean condition expression and a missing endif.

    In the first example, it is not clear that the revisit adds rather than overwrites.

    In the third and fourth examples it is not clear why the second pass reuses the context for the first rather than creates new objects.

  • Reported: QVT 1.1 — Sun, 18 Jul 2010 04:00 GMT
  • Disposition: Resolved — QVT 1.3
  • Disposition Summary:

    8.1.10 Errors in Examples

    The second example contains

    "if result then return;"

    which has a non-boolean condition expression and a missing endif.

    In the first example, it is not clear that the revisit adds rather than overwrites.

    In the third and fourth examples it is not clear why the second pass reuses the context for the first rather than creates new objects.

    Discussion

    The examples are much worse than suggested; verging on the diabolical.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: Typedef for Standard Library predefined types

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

    As interpretated 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:
    Suggestion c: Just having one type to refer.
    Suggestion a: Since the typedef "extends" the behaviour of the predefined type (adding new operations), the former must be the referred one.
    Suggestion b: The OCL predefined type is referenced, but we must take into account that the operations added to the typedef are also available.

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

    QVTo Standard Library and typedefs Issue. Extending OCL predefined types

    As interpretated 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:
    Suggestion c: Just having one type to refer.
    Suggestion a: Since the typedef "extends" the behaviour of the predefined type (adding new operations), the former must be the referred one.
    Suggestion b: The OCL predefined type is referenced, but we must take into account that the operations added to the typedef are also available.

    Discussion

    The offending sentence is:

    This is specifically used in the QVT standard library to attach operations to pre-defined primitive types, like String and Collections.

    This facility is not used anywhere in the specification and there is no grammar that facilitates it. No model of the QVTo library is provided that exploits it. The sentence is therefore just an observation on a particular implementation approach.

    The approach takes no account of the very similar requirement for Complete OCL to extend types. This is being resolved by work towards OCL 2.5 / 3.0 with which QVTo will almost certainly have to comply.

    Therefore, tomorrow this sentence will be embarassing and incompatible. Today it is just irrelevant and confusing.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTc/QVTr: Imports

  • Key: QVT13-6
  • Legacy Issue Number: 12213
  • Status: closed  
  • Source: Siegfried Nolte ( Siegfried Nolte)
  • Summary:

    Concerning to Relations Language, how will the metamodels get into a transformation script ? Is there a technique similar to Operational Mappings using metamodel declaration and modeltypes ? The RL sample transformation script in annex A.1 (pp 164) doesn't declare the metamodels. The OM sample (A.2.3) does. There is some syntax for declaring and using metamodels and modeltypes in OM (pp118), there isn't for RL (pp38).

  • Reported: QVT 1.0 — Wed, 6 Feb 2008 05:00 GMT
  • Disposition: Resolved — QVT 1.3
  • Disposition Summary:

    Relations Language: how will metamodels get into a transformation scrip

    Concerning to Relations Language, how will the metamodels get into a transformation script ? Is there a technique similar to Operational Mappings using metamodel declaration and modeltypes ? The RL sample transformation script in annex A.1 (pp 164) doesn't declare the metamodels. The OM sample (A.2.3) does. There is some syntax for declaring and using metamodels and modeltypes in OM (pp118), there isn't for RL (pp38).

    Discussion

    We needs to support definition of e.g. UML in

    transformation umlToRdbms(uml:UML, rdbms:RDBMS)
    

    But we actually may want to reference a document URI or namespace URI

    http://www.omg.org/spec/UML/20131001/UML.xmi
    http://www.omg.org/spec/UML/20131001
    

    But the current syntax is essentially a Java import without the trailing * option.

    import my.model.package;
    

    It cannot reference URIs and it has the wrong separator.

    Something similar to QVTo's ModelType is needed:

    modeltype UML uses SimpleUml ("http://omg.qvt-examples.SimpleUml");
    

    However ModelType has many problems that we do not need to replicate:

    • it is a Class; absolutely not
    • it supports strict/effective inside rather than outside the program
    • it has undefined URI usage
      
      

      Conversely Complrete OCL has a requirement for an import too, and here ModelType's are not appropriate at all.

    Let's fix up import.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTr: UML to RDBMS Example Problems

  • Key: QVT13-4
  • Legacy Issue Number: 11686
  • Status: closed  
  • Source: Siegfried Nolte ( Siegfried Nolte)
  • Summary:

    top relation AssocToFKey { pKey : Key; ... when

    { ...; pKey = destTbl.key; }

    ... } In my opinion that doesn't work. pKey is of type Key, destTbl.key is of type OrderedSet key, isn't it ?

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

    Section: A1.1.1

    top relation AssocToFKey { pKey : Key; ... when

    { ...; pKey = destTbl.key; }

    ... } In my opinion that doesn't work. pKey is of type Key, destTbl.key is of type OrderedSet key, isn't it ?

    Discussion

    Yes. Well at least it's a Collection; the diagram leaves an ambiguity.

    Comparison with the QVTc solution shows that the 'primary' key should be selected, and initialized on creation.

    Loading the example in the Eclipse QVTr editor reveals many more problems.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

Missing Identifier Syntax

  • Key: QVT13-2
  • Legacy Issue Number: 10935
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The syntax of identifiers is undefined.

    The syntax for mapping clearly prohibits the use of a direction named 'where'.

    Suggest: identifier is an OCL simpleName, less the new reserved words (check default enforce
    imports map realize refines transformation uses where)

    Suggest: a string-literal may be used as an identifier to support awkward identifiers such as 'where'.

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

    Identifiers

    The syntax of identifiers is undefined.

    The syntax for mapping clearly prohibits the use of a direction named 'where'.

    Suggest: identifier is an OCL simpleName, less the new reserved words (check default enforce
    imports map realize refines transformation uses where)

    Suggest: a string-literal may be used as an identifier to support awkward identifiers such as 'where'.

    Discussion

    OCL 2.3/2.4 clarified identifiers and strings so we can just exploit the OCL productions including it's underscore-prefixed-string identifier.

    OCL 2.3 also introduced String::_'+' so no special description is needed for a QVTr extension.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTc/QVTo/QVTr acronyms

  • Key: QVT13-101
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The full names of the QVT languages are a bit cumbersome and so QVTc/QVTo/QVTr are often found in non-OMG usage.

    Suggest that the QVT specification at least define them and perhaps use them a little too.

  • Reported: MOF 1.2 — Wed, 7 Oct 2015 11:51 GMT
  • Disposition: Resolved — QVT 1.3
  • Disposition Summary:

    QVTc/QVTo/QVTr acronyms

    The full names of the QVT languages are a bit cumbersome and so QVTc/QVTo/QVTr are often found in non-OMG usage.

    Suggest that the QVT specification at least define them and perhaps use them a little too.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTc/QVTr: Pattern.bindsTo composition

  • Key: QVT13-45
  • Legacy Issue Number: 19673
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The author of Issue 9379 misunderstood the poor description of Pattern::bindsTo and consequently removed the

    {composes} qualifier.

    Issue 10938 observed that this totally broke QVTc and introduced CorePattern::variables to compensate.

    The QVTr to QVTc transformation remains broken since it continues to assume that bindsTo {composes}

    .

    There was actually nothing wrong with bindsTo that could not have been fixed by clearer wording to the effect that bindsTo was a dustbin container for variables not contained elsewhere.

    The above kind of emphasises the benefits of an ownedPlurals naming policy. Therefore suggest that:

    a) the AST bloat from the redundant bindsTo be replaced by definition of a suitable derived property that satisfies the intent of all variables.

    b) that variables be renamed ownedVariables and used throughout the QVTr to QVTc transformation

  • Reported: QVT 1.2 — Tue, 9 Dec 2014 05:00 GMT
  • Disposition: Deferred — QVT 1.3
  • Disposition Summary:

    Rewind Issues 9379, 10938

    The author of Issue 9379 misunderstood the poor description of Pattern::bindsTo and consequently removed the

    {composes} qualifier.

    Issue 10938 observed that this totally broke QVTc and introduced CorePattern::variables to compensate.

    The QVTr to QVTc transformation remains broken since it continues to assume that bindsTo {composes}

    .

    There was actually nothing wrong with bindsTo that could not have been fixed by clearer wording to the effect that bindsTo was a dustbin container for variables not contained elsewhere.

    The above kind of emphasises the benefits of an ownedPlurals naming policy. Therefore suggest that:

    a) the AST bloat from the redundant bindsTo be replaced by definition of a suitable derived property that satisfies the intent of all variables.

    b) that variables be renamed ownedVariables and used throughout the QVTr to QVTc transformation

    Discussion

    The problem is genuine, but further Eclipse QVTr prototyping reveals two distinct cases, one requiring containment, another not. Further work is needed to specify these accurately.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

Inconsistent multiple inheritance

  • Key: QVT13-32
  • Legacy Issue Number: 18912
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The pragmatic decision to define Module/Transformation as inheriting both Package and Class violates UML inheritance.

    For a Package: self.nestingPackage.nestedPackages->includes(self)

    For a Class:
    self.package.ownedTypes->includes(self)

    But self cannot have two containers.

    The problem is easily resolved by extending only Package and adding those Class features that are actually required.

  • Reported: QVT 1.1 — Mon, 16 Sep 2013 04:00 GMT
  • Disposition: Deferred — QVT 1.3
  • Disposition Summary:

    Inconsistent multiple inheritance

    The pragmatic decision to define Module/Transformation as inheriting both Package and Class violates UML inheritance.

    For a Package: self.nestingPackage.nestedPackages->includes(self)

    For a Class:
    self.package.ownedTypes->includes(self)

    But self cannot have two containers.

    The problem is easily resolved by extending only Package and adding those Class features that are actually required.

    Discussion

    Transformation is mostly a Class that may have arbitrary Package scoping. This has been successfully prototyped by the Eclipse QVT projects, but not in sufficient detail to justify this slightly breaking change.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTr: working with stereotypes:

  • Key: QVT13-31
  • Legacy Issue Number: 13158
  • Status: closed  
  • Source: Siegfried Nolte ( Siegfried Nolte)
  • Summary:

    QVT Relations and working with stereotypes: Is there something like a QVT-R standard library with methods on stereotypes in it? There is none in the specification; compare QVT-R, there are some methods. Are there some else options for accessing stereotypes with QVT-R?

  • Reported: QVT 1.0 — Mon, 15 Dec 2008 05:00 GMT
  • Disposition: Deferred — QVT 1.3
  • Disposition Summary:

    QVT Relations and working with stereotypes:

    QVT Relations and working with stereotypes: Is there something like a QVT-R standard library with methods on stereotypes in it? There is none in the specification; compare QVT-R, there are some methods. Are there some else options for accessing stereotypes with QVT-R?

    Discussion

    Good question. Recent progress on ensuring that typesafe OCL navigation works for stereotypes may render the answer trivial, but until such time as a stereotyped QVTr transformation has been executed it is too soon to respond.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTr: Deletion semantics

  • Key: QVT13-21
  • Legacy Issue Number: 15886
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    I’m having trouble with the semantics of DELETE on p. 189 of the QVT Specification (v1.1). It reads in part:

    FORALL OBJVAR IN MAKESET(<DOMAIN_K_VARIABLE_SET>) (
    …
    AND BELONGSTO(OBJVAR, MAKESET(<DOMAIN_K_VARIABLE_SET>))

    I guess I don’t understand MAKESET and BELONGSTO. First of all, <DOMAIN_K_VARIABLE_SET> is already a set, so what’s the MAKESET function do? Second, the FORALL iterates OBJVAR over the results of the same MAKESET that BELONGSTO tests. So how can BELONGSTO be false? That is, I would assume BELONGSTO is defined as follows:

    BELONGSTO(e, S) º e ÎS

    except that under this definition the expression above is always satisfied.

    Any and all help appreciated. Thank you very much.

  • Reported: QVT 1.1 — Tue, 12 Oct 2010 04:00 GMT
  • Disposition: Deferred — QVT 1.3
  • Disposition Summary:

    Specification of deletion semantics

    I’m having trouble with the semantics of DELETE on p. 189 of the QVT Specification (v1.1). It reads in part:

    FORALL OBJVAR IN MAKESET(<DOMAIN_K_VARIABLE_SET>) (
    …
    AND BELONGSTO(OBJVAR, MAKESET(<DOMAIN_K_VARIABLE_SET>))

    I guess I don’t understand MAKESET and BELONGSTO. First of all, <DOMAIN_K_VARIABLE_SET> is already a set, so what’s the MAKESET function do? Second, the FORALL iterates OBJVAR over the results of the same MAKESET that BELONGSTO tests. So how can BELONGSTO be false? That is, I would assume BELONGSTO is defined as follows:

    BELONGSTO(e, S) º e ÎS

    except that under this definition the expression above is always satisfied.

    Any and all help appreciated. Thank you very much.

    Discussion

    Well this is very embarrassing. I don't understand it all either, and I certainly do not understand why it is not written using OCL.

    I'm not convinced that QVTr has any delete semantics since declaratively delete occurs as an absence of creation.

    Must await the Eclipse QVTr prototype.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTr: Rule Overriding semantics

  • Key: QVT13-19
  • Legacy Issue Number: 15417
  • Status: closed  
  • Source: NASA ( Maged Elaasar)
  • Summary:

    The abstract syntax of QVTr allows a rule to be an override of another rule.

    Rule::overrides: Rule [0..1]
    The rule that this rule overrides.

    The concrete syntax of QVT allows it too:

    <relation> ::= ['top'] 'relation' <identifier>
    ['overrides' <identifier>]
    '

    {' .... '}

    '

    However, the only semantics I can see for 'overrides' is in clause 7.11.1.4 that says:

    "A rule may conditionally override another rule. The overriding rule is executed in place of the overridden rule when the overriding conditions are satisfied. The exact semantics of overriding are subclass specific. "

    Questions:

    1- Whtat are the overriding conditions? are they implied or specified and if so how?

    2- I have not seen any other discussion of overrding in a subclass or Rule so not sure what is meant by "The exact semantics of overriding are subclass specific"?

    3- I have not seen any example of using 'overrides' what so ever in the spec, shouldn't there be one?

    4 - What is the semantics of overriding? is it related to inheritance in the OO sense ? I think QVTr needs a good "inheritance" model where you can relations can be called polymorphically.

  • Reported: QVT 1.1 — Fri, 13 Aug 2010 04:00 GMT
  • Disposition: Deferred — QVT 1.3
  • Disposition Summary:

    Rule Overriding in QVTr

    The abstract syntax of QVTr allows a rule to be an override of another rule.

    Rule::overrides: Rule [0..1]
    The rule that this rule overrides.

    The concrete syntax of QVT allows it too:

    <relation> ::= ['top'] 'relation' <identifier>
    ['overrides' <identifier>]
    '

    {' .... '}

    '

    However, the only semantics I can see for 'overrides' is in clause 7.11.1.4 that says:

    "A rule may conditionally override another rule. The overriding rule is executed in place of the overridden rule when the overriding conditions are satisfied. The exact semantics of overriding are subclass specific. "

    Questions:

    1- What are the overriding conditions? are they implied or specified and if so how?

    2- I have not seen any other discussion of overriding in a subclass or Rule so not sure what is meant by "The exact semantics of overriding are subclass specific"?

    3- I have not seen any example of using 'overrides' what so ever in the spec, shouldn't there be one?

    4 - What is the semantics of overriding? is it related to inheritance in the OO sense ? I think QVTr needs a good "inheritance" model where you can relations can be called polymorphically.

    Discussion

    This now a much better understood field:

    M. Wimmer, G. Kappel, A. Kusel, W. Retschitzegger, J. Schönböck, W. Schwinger, D. Kolovos, R. Paige, M. Lauder, A. Schürr, D. Wagelaar. Surveying Rule Inheritance in Model-to-Model Transformation Languages. In Journal of Object Technology, vol. 11, no. 2, 2012, pages 3:1–46. doi:10.5381/jot.2012.11.2.a3

    QVTBase currently imposes single overriding which is unnecessary, and causes a problem for an application that needs to extend when B1 overrides A and B2 overrides A. The extending mapping needs C to override both B1 and B2 to ensure that C occludes both B1 and B2. Therefore we need multi-overrides.

    Oops. A QVTc Mapping::refines is an alternative concept that competes without comment with the inherited Rule::overrides. relToCore completely ignores the semantics of overrides translation. Relation::overrides should probably map across unchanged to Mapping::overrides. QVTc and QVTr semantics are unchanged.

    Fixing this textually without a prototype is too much of change.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTc/QVTr: View/Transformation discrepancy

  • Key: QVT13-18
  • Legacy Issue Number: 15411
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    "The starting point is a major flaw in all three QVT languages at present and enabled Perdita Stevens to correctly conclude in http://www.springerlink.com/content/9x368617317l3q87/ that QVTr and QVTc are incompatible. QVT currently provides no way to distinguish whether for instance a check-mode transformation is a query of whether a transformed input pattern can be discovered in the output (e.g. a database lookup), or a validation that the transformed input exactly matches the output (e.g. an already transformed check). Both facilities are useful and so when a QVT transformation is invoked the invoker needs to specify what I call the 'rooting' condition in addition to the direction

  • Reported: QVT 1.1 — Tue, 10 Aug 2010 04:00 GMT
  • Disposition: Deferred — QVT 1.3
  • Disposition Summary:

    Unclear transformation rooting condition

    "The starting point is a major flaw in all three QVT languages at present and enabled Perdita Stevens to correctly conclude in http://www.springerlink.com/content/9x368617317l3q87/ that QVTr and QVTc are incompatible. QVT currently provides no way to distinguish whether for instance a check-mode transformation is a query of whether a transformed input pattern can be discovered in the output (e.g. a database lookup), or a validation that the transformed input exactly matches the output (e.g. an already transformed check). Both facilities are useful and so when a QVT transformation is invoked the invoker needs to specify what I call the 'rooting' condition in addition to the direction

    Discussion

    We need a much simpler principled exposition of the intent of QVTc/QVTr. Since Perdita has correctly come to such unwelcome conclusions, we clearly have a problem. The new statement should be uncontroversial and therefore provide a reference against which subsequent text can be assessed.

    The following is perhaps what is needed, but needs more discussion with QVTr users and prototyping of its implications.

    In Section 6.3 replace

    The semantics of the Core language (and hence the Relations language) allow for the following execution scenarios:
    • Check-only transformations to verify that models are related in a specified way.
    • Single direction transformations.
    • Bi-directional transformations. (In fact more than two directions are possible, but two is the most common case.)
    • The ability to establish relationships between pre-existing models, whether developed manually, or through some other
    tool or mechanism.
    • Incremental updates (in any direction) when one related model is changed after an initial execution.
    • The ability to create as well as delete objects and values, while also being able to specify which objects and values must
    not be modified.

    by

    A Declarative QVT transformation capability establishes a correspondence between source objects in one or more source models and transformed objects in one or more transformed models. The correspondence may be used to check or enforce a view of, or a transformation to, target objects in one or more target models.

    The correspondence takes the form of trace data comprising a set of trace records. Each trace record identifies a relationship to one or more transformed objects from, one or more, source or transformed, objects or values. The production of each transformed object is traced by exactly one trace record. The trace data includes relationships for all satisfied constraints imposed by the language constructs that express the transformation program. No relationships for satisfiable constraints are omitted from the trace data.

    In practice a Core language (and hence the Relations language) transformation is executed after a form, mode and direction have been selected.

    There are two main forms of QVT execution:

    • For a Transformation execution, there is an exactly 1:1 mapping between the transformed objects and the target objects.
    • For a View execution, there is an exactly 1:1 mapping between the transformed objects and the target objects in the view. There may be further target objects outside the view that are unaffected by the execution.

    Additionally, for a Query execution, an OCL query is executed on the trace data. No actual target models are required.

    There are three modes of execution:

    • An enforced View or Transformation execution coerces the target objects to correspond to the transformed objects. (This is most simply achieved by model replacement, but may be realized by executing a series of changes so that desirable extra-model considerations such as xmi:id preservation or minimal database activity are accommodated.)
    • A check execution is a degenerate Query execution that just returns true or false according to the existence of the trace data. (An optimized execution capability may bypass the creation of the transformed objects and look for correspondence between source and target objects directly.)
    • An update Query, View or Transformation execution compares an old correspondence between source objects and transformed objects with a new correspondence between changed source objects and correspondingly changed transformed objects. The correspondence changes may be used to enforce or check for corresponding creations, deletions and updates in the target objects.

    Additionally an in-place update View or Transformation execution shares source and target models and so each source object is coerced to correspond to its transformed equivalent. (This can be naively achieved by model copy. An optimized execution may bypass the creation of the transformed objects by performing each source read before any corrupting write.)

    The declarative transformation languages do not have fixed sources and targets, rather they have multiple domains some of which may be designated sources and others as targets. The direction of the transformation is chosen by selecting the domain to be used as a target.

    • A unidirectional transformation has just a single choice of direction since only one domain is able to be used as the target
    • For a bi-directional, and more generally a multi-directional transformation, the domain used as the target may be selected

    In practice it is often difficult to satisfy the bijective requirements of bidirectional execution and so many transformations are just unidirectional.

  • Updated: Tue, 29 Mar 2016 15:09 GMT
  • Attachments:

QVTo: Relationship between QVTo Mapping and QVTr Relation

  • Key: QVT13-17
  • Legacy Issue Number: 15390
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    8.1.4 states "a mapping operation is always a refinement of an implicit relation" but 8.2.15 defines "refinedRelation: Relation [0..1] The refined relation, if any." Clearly a contradiction.

    8.1.4. provides the REL_PackageToSchema example of how an implicit relation might be defined, but no other examples or synthesis rules are supplied.

    enforce and checkonly appear in the REL_PackageToSchema example indicating that these define execution mode of a QVTo trnasformation, but there does not appear to be any description of how a transformation might be executed to for instance update an output model. Perhaps the 'output' parameter is 'inout' for create/update but 'out' for create/overwrite.

  • Reported: QVT 1.1 — Fri, 30 Jul 2010 04:00 GMT
  • Disposition: Deferred — QVT 1.3
  • Disposition Summary:

    8 Unclear mapping operation characteristics

    8.1.4 states "a mapping operation is always a refinement of an implicit relation" but 8.2.15 defines "refinedRelation: Relation [0..1] The refined relation, if any." Clearly a contradiction.

    8.1.4. provides the REL_PackageToSchema example of how an implicit relation might be defined, but no other examples or synthesis rules are supplied.

    enforce and checkonly appear in the REL_PackageToSchema example indicating that these define execution mode of a QVTo trnasformation, but there does not appear to be any description of how a transformation might be executed to for instance update an output model. Perhaps the 'output' parameter is 'inout' for create/update but 'out' for create/overwrite.

    Discussion

    The aspiration that every QVTo mapping has an underlying QVTr relation is fairly dubious. But there is no point respecifying until some prototyping feedback is available.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTr: syntax mapping (correction to Issue 10646 resolution)

  • Key: QVT13-15
  • Legacy Issue Number: 14640
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The numerous problems identified in http://www.omg.org/archives/qvt-rtf/msg00094.html need to be addressed. Apologies too for the long email. This is a very difficult area where precision is important. Provision of
    this resolution demonstrates the need for the resolution, but unfortunately the resolution has an
    erroneous precision that will make QVTr 1.1 unimplementable whereas QVTr 1.0 is just mildly
    ambiguous and conflicting.
    Please do not include the resolution in QVT 1.1 without significantrework.
    I found the definition of the "checkonly"/"enforce" to isCheckable/isEnforceable helpful, although
    different to three of my own intuitive guesses based on attempts to avoid errors in ModelMorf and
    Rel2Core examples.
    The problems identified below are the result of a local review of the resolution. In the absence of a
    coherent Environment semantics it has not been possible to perform a global review. In particular, I
    was unable to review the specification for the arguably redundant bindsTo.
    [Incidentally, the same resolution approach is needed for QVTc and QVTo].
    Disambiguating rules
    --------------------
    The resolution uses a similar approach to the OCL 2.0 specification, but neglects to provide any
    disambiguating rules although many are needed.
    Environments
    ------------
    OCL and the resolution employ environments to carry definitions specific to particular CS constructs,
    so that a CS reference may be resolved with the aid of an environment or the AST.
    In EssentialOCL, all definitions are resolvable with in the immutable AST with the exception of let and
    iterator expressions for which a nestedEnvironment() is used to carry the extra variable declaration
    with the aid of addElement(). The nestedEnvironment supports name occlusion from outer scopes.
    In CompleteOCL, further definitions may be introduced by a definition constraint. The OCL
    specification provides no precise insight into how an environment changes to accommodate the
    definition. Should the name be added to the AST or to the environment? Is the name available for
    forward reference?
    Environment::addElement is defined as a query operation thereby inhibiting side effects. Consequently
    usage such as
    XX.env = YY.env.addElement(Z.name, Z.ast, false)
    leaves the environment of YY unchanged and creates an extended environment for XX.
    A series of such usages creates a series of progressively elaborated environments that support
    backward but not forward referencing. This was not a clear requirement of the QVT 1.0 specification
    and it prevents any variable declarations being introduced in an object template tree being resolved
    through environments in other object template trees or predicate expressions.
    QVT 1.2 RTF Report Page 173 of 190
    Object Management Group
    RTF/FTF Report
    Imposition of no forward referencing seems very undesirable, particularly since the order of domains is
    imposed by the model parameter order. Imagine a Java program in which all methods had to be
    defined in a no-forward reference order.
    As noted above, CompleteOCL neglected to define how AST definitions were added to the AST. QVTr
    must solve this problem since QVTr defines a hierarchically scoped AST rather than an annotation of
    a pre-existing AST.
    I recommend a two stage approach. The inherited attributes section should first compute an
    environment from the pushed-down parent environment augmented by pull-ups from child constructs
    so that a complete immutable and consequently unambiguous environment is associated with each
    construct and then pushed-down to the children. During the pull-up the environment acquires a
    mapping from name to future-AST. During the push-down residual future-AST attributes are populated
    to give a valid AST.
    Reference resolution
    --------------------
    OCL uses lookup functions to resolve variable references. It is necessary either to overload the lookup
    functions so that the the distinct QVTr variable definition sites can be located in the AST, or to use
    some form of Environment::addElement where each definition is defined so that resolution in the
    environment is possible.
    Details
    =======
    Throughout, many disambiguating rules are needed to define illegal semantics. For instance "any" is
    often used to select a syntactically valid value. Corresponding usage in the OCL specification has a
    disambiguating rule to clarify what the consequence of not "one" is.
    My current best attempt at Disambiguating Rules is attached.
    Environment::addElement takes three arguments, the third being a mayBeImplicit argument. This has
    been omitted throughout without explanation.
    identifierCS
    ------------
    OCL defines SimpleNameCS. A degenerate mapping from identifierCS to SimplenameCS is required.
    topLevelCS
    ----------
    The 'imported transformation' environment element is later referenced as 'imported transformations'.
    Typo: TransformationListCS for transformationListCS in Synthesized attributes.
    importListCS
    ------------
    Semantics of import conflicts must be defined.
    unitCS
    ------
    Typo: ast is not a Set.
    Surely the import is of packages (enumerations or operations)or at least transformations (QVTo
    implementations) rather than necessarily relational-transformations?
    transformationCS
    ----------------
    QVT 1.2 RTF Report Page 174 of 190
    Object Management Group
    RTF/FTF Report
    ownedTag is not synthesized.
    keyDeclListCS
    -------------
    Typo: wrong font in synthesized attributes
    modelDeclCS
    -----------
    The [B] grammar:
    modelDeclCS ::= modelIdCS ':' '

    {' metaModelIdListCS '}

    '
    is missing.
    keyDeclCS
    ---------
    Synthesized attributes appear to have experienced a copy and paste error while providing distinct part
    and oppositePart left hand sides.
    keyPropertyCS
    -------------
    The synthesized attributes poke the parent.
    Suggest: it would be clearer for the parent to gather and distribute children similar to the relation/query
    allocation by transformationCS.
    relationCS
    ----------
    Transformation.extends does not appear to be transitive.
    topQualifierCS
    --------------
    Suggest: a boolean or enumerated value rather than a string.
    domainListCS
    ------------
    Typo: missing indentation.
    primitiveTypeDomainCS
    ---------------------
    isCheckable, isEnforceable not synthesized.
    objectTemplateCS
    ----------------
    Variable needs to be added to relation to provide a container.
    Variable needs to be added to relation environment to provide visibility.
    collectionTemplateCS
    --------------------
    Variable needs to be added to relation to provide a container.
    Variable needs to be added to relation environment to provide visibility.
    Suggest: last two if guards are redundant.
    QVT 1.2 RTF Report Page 175 of 190
    Object Management Group
    RTF/FTF Report
    restCS
    ------
    Variable needs to be added to relation to provide a container.
    Non-_ named variable needs to be added to relation environment to provide visibility.
    memberCS
    --------
    Variable needs to be added to relation to provide a container.
    Non-_ named variable needs to be added to relation environment to provide visibility.
    whenCS
    ------
    predicateListCS should be optional.
    whereCS
    -------
    predicateListCS should be optional.
    ExtOclExpressionCS
    ------------------
    This is not present in the QVTr or OCL grammar.
    Presumably it represents the QVTr extension to OCL's OclExpressionCS.
    However it is an extension, since at least RelationCallExpCS can be used in an ordinary
    OclExpressionCS using "not" or "and".
    [A], [B], [C] should therefore follow on from OCL's
    [A], [B], [C]..., [I].
    RelationCallExpressionCS
    ------------------------
    How is a RelationCallExpressionCS distinguished from an OperationCallExpCS?

  • Reported: QVT 1.1 — Mon, 16 Nov 2009 05:00 GMT
  • Disposition: Deferred — QVT 1.3
  • Disposition Summary:

    QVTr syntax mapping (correction to Issue 10646 resolution)

    The numerous problems identified in http://www.omg.org/archives/qvt-rtf/msg00094.html need to be addressed. Apologies too for the long email. This is a very difficult area where precision is important. Provision of
    this resolution demonstrates the need for the resolution, but unfortunately the resolution has an
    erroneous precision that will make QVTr 1.1 unimplementable whereas QVTr 1.0 is just mildly
    ambiguous and conflicting.
    Please do not include the resolution in QVT 1.1 without significantrework.
    I found the definition of the "checkonly"/"enforce" to isCheckable/isEnforceable helpful, although
    different to three of my own intuitive guesses based on attempts to avoid errors in ModelMorf and
    Rel2Core examples.
    The problems identified below are the result of a local review of the resolution. In the absence of a
    coherent Environment semantics it has not been possible to perform a global review. In particular, I
    was unable to review the specification for the arguably redundant bindsTo.
    [Incidentally, the same resolution approach is needed for QVTc and QVTo].
    Disambiguating rules
    --------------------
    The resolution uses a similar approach to the OCL 2.0 specification, but neglects to provide any
    disambiguating rules although many are needed.
    Environments
    ------------
    OCL and the resolution employ environments to carry definitions specific to particular CS constructs,
    so that a CS reference may be resolved with the aid of an environment or the AST.
    In EssentialOCL, all definitions are resolvable with in the immutable AST with the exception of let and
    iterator expressions for which a nestedEnvironment() is used to carry the extra variable declaration
    with the aid of addElement(). The nestedEnvironment supports name occlusion from outer scopes.
    In CompleteOCL, further definitions may be introduced by a definition constraint. The OCL
    specification provides no precise insight into how an environment changes to accommodate the
    definition. Should the name be added to the AST or to the environment? Is the name available for
    forward reference?
    Environment::addElement is defined as a query operation thereby inhibiting side effects. Consequently
    usage such as
    XX.env = YY.env.addElement(Z.name, Z.ast, false)
    leaves the environment of YY unchanged and creates an extended environment for XX.
    A series of such usages creates a series of progressively elaborated environments that support
    backward but not forward referencing. This was not a clear requirement of the QVT 1.0 specification
    and it prevents any variable declarations being introduced in an object template tree being resolved
    through environments in other object template trees or predicate expressions.
    QVT 1.2 RTF Report Page 173 of 190
    Object Management Group
    RTF/FTF Report
    Imposition of no forward referencing seems very undesirable, particularly since the order of domains is
    imposed by the model parameter order. Imagine a Java program in which all methods had to be
    defined in a no-forward reference order.
    As noted above, CompleteOCL neglected to define how AST definitions were added to the AST. QVTr
    must solve this problem since QVTr defines a hierarchically scoped AST rather than an annotation of
    a pre-existing AST.
    I recommend a two stage approach. The inherited attributes section should first compute an
    environment from the pushed-down parent environment augmented by pull-ups from child constructs
    so that a complete immutable and consequently unambiguous environment is associated with each
    construct and then pushed-down to the children. During the pull-up the environment acquires a
    mapping from name to future-AST. During the push-down residual future-AST attributes are populated
    to give a valid AST.
    Reference resolution
    --------------------
    OCL uses lookup functions to resolve variable references. It is necessary either to overload the lookup
    functions so that the the distinct QVTr variable definition sites can be located in the AST, or to use
    some form of Environment::addElement where each definition is defined so that resolution in the
    environment is possible.
    Details
    =======
    Throughout, many disambiguating rules are needed to define illegal semantics. For instance "any" is
    often used to select a syntactically valid value. Corresponding usage in the OCL specification has a
    disambiguating rule to clarify what the consequence of not "one" is.
    My current best attempt at Disambiguating Rules is attached.
    Environment::addElement takes three arguments, the third being a mayBeImplicit argument. This has
    been omitted throughout without explanation.
    identifierCS
    ------------
    OCL defines SimpleNameCS. A degenerate mapping from identifierCS to SimplenameCS is required.
    topLevelCS
    ----------
    The 'imported transformation' environment element is later referenced as 'imported transformations'.
    Typo: TransformationListCS for transformationListCS in Synthesized attributes.
    importListCS
    ------------
    Semantics of import conflicts must be defined.
    unitCS
    ------
    Typo: ast is not a Set.
    Surely the import is of packages (enumerations or operations)or at least transformations (QVTo
    implementations) rather than necessarily relational-transformations?
    transformationCS
    ----------------
    QVT 1.2 RTF Report Page 174 of 190
    Object Management Group
    RTF/FTF Report
    ownedTag is not synthesized.
    keyDeclListCS
    -------------
    Typo: wrong font in synthesized attributes
    modelDeclCS
    -----------
    The [B] grammar:
    modelDeclCS ::= modelIdCS ':' '

    {' metaModelIdListCS '}

    '
    is missing.
    keyDeclCS
    ---------
    Synthesized attributes appear to have experienced a copy and paste error while providing distinct part
    and oppositePart left hand sides.
    keyPropertyCS
    -------------
    The synthesized attributes poke the parent.
    Suggest: it would be clearer for the parent to gather and distribute children similar to the relation/query
    allocation by transformationCS.
    relationCS
    ----------
    Transformation.extends does not appear to be transitive.
    topQualifierCS
    --------------
    Suggest: a boolean or enumerated value rather than a string.
    domainListCS
    ------------
    Typo: missing indentation.
    primitiveTypeDomainCS
    ---------------------
    isCheckable, isEnforceable not synthesized.
    objectTemplateCS
    ----------------
    Variable needs to be added to relation to provide a container.
    Variable needs to be added to relation environment to provide visibility.
    collectionTemplateCS
    --------------------
    Variable needs to be added to relation to provide a container.
    Variable needs to be added to relation environment to provide visibility.
    Suggest: last two if guards are redundant.
    QVT 1.2 RTF Report Page 175 of 190
    Object Management Group
    RTF/FTF Report
    restCS
    ------
    Variable needs to be added to relation to provide a container.
    Non-_ named variable needs to be added to relation environment to provide visibility.
    memberCS
    --------
    Variable needs to be added to relation to provide a container.
    Non-_ named variable needs to be added to relation environment to provide visibility.
    whenCS
    ------
    predicateListCS should be optional.
    whereCS
    -------
    predicateListCS should be optional.
    ExtOclExpressionCS
    ------------------
    This is not present in the QVTr or OCL grammar.
    Presumably it represents the QVTr extension to OCL's OclExpressionCS.
    However it is an extension, since at least RelationCallExpCS can be used in an ordinary
    OclExpressionCS using "not" or "and".
    [A], [B], [C] should therefore follow on from OCL's
    [A], [B], [C]..., [I].
    RelationCallExpressionCS
    ------------------------
    How is a RelationCallExpressionCS distinguished from an OperationCallExpCS?

    Discussion

    These issues cannot be sensibly addressed until the auto-generation being pioneered for OCL can be re-used.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: synonyms

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

    his section (8.3.2) is very confusing for the reader. What does synonym means ? - Is just like a shorthand of the concrete syntax ? - Is just a new operation included in the QVTo Standard Library semantically equivalent?. Ideally, just one type/operation must exist (the OCL predefined type and the operation of an OCL predefined type), so that, writing Void (a type) or asType (operation) should produce the same AST as if I write OclVoid or oclAsType. With this idea, I'm really puzzled with the third paragraph of the section. Please revise this section so that it is less confusing.

  • Reported: QVT 1.0 — Fri, 19 Dec 2008 05:00 GMT
  • Disposition: Resolved — QVT 1.3
  • Disposition Summary:

    section (8.3.2) is very confusing for the reader

    This section (8.3.2) is very confusing for the reader. What does synonym means ? - Is just like a shorthand of the concrete syntax ? - Is just a new operation included in the QVTo Standard Library semantically equivalent?. Ideally, just one type/operation must exist (the OCL predefined type and the operation of an OCL predefined type), so that, writing Void (a type) or asType (operation) should produce the same AST as if I write OclVoid or oclAsType. With this idea, I'm really puzzled with the third paragraph of the section. Please revise this section so that it is less confusing.

    Discussion - Ocl type prefixes

    As an OCL user, I find the attempt and recommendation to hide the underlying OCL functionality very confusing, particularly when it introduces potential collisions whose prevention is inaccurately described.

    Since the description of the M1 types does not enumerate them, I am not clear which types are intended. If Eclipse QVTo is any guide, it would be OclAny/Any, OclVoid/Void, but not OclElement, OclInvalid, OclMessage, OclState, OclType.

    If this policy is to remain recommended, it must also apply to all of the above. I find the injection of Element and Type into the user's namespace particularly offensive.

    I recommend that the recommendation be reversed, so that we just observe that QVTo implementations offering backward compatibility may permit the seven enumerated synonyms to be used as shortforms of the full spelling.

    Discussion - ocl operation prefixes

    The references to the "Ocl" prefix are inaccurate for operations where it is "ocl".

    As an OCL user, I find the attempt and recommendation to hide the underlying OCL functionality a bit confusing, particularly since the abbreviated forms are used very little used in the editorial text and have no definition.

    I recommend eliminating their editorial usage and defining them as synonyms that a QVTo implementation offering backward compatibility may support as an alternate spelling that is mapped to the full spelling when used within the abstract syntax

    Discussion - Operation name synonyms

    This section was written for OCL 2.0 which has no String::+ operator. String::+ is available in OCL 2.4 so there is no need for QVT 1.2 to define it as a synonym.The other mathematical operators have always been part of OCL, so the purpose of enumerating them is unclear and indeed confusing. Is there actually an operation with the spelling "operator+"? I see no need for one. In the concrete syntax, "+" is fully available. In UML and OCL "+" is a permissible internal spelling for an operation name. The _'+' escape enables its use in arbitrary name contexts.

    The only question is whether a particular implementation might choose to use "plus" as a spel;ling to avoid problems in languages that do not allow arbitrary spellings. But that is an implementation language-specific choice that does not affect QVT or OCL; perhaps relevant to the Java-binding for OCL specification if written. FWIW, Eclipse QVTo has no "operator+" operation.

    Conversely, is the specification actually saying that "plus" may be used rather than "+"? This might be a way of elevating an implementation language workaround into the source, which seems rather perverse. FWIW, Eclipse QVTo provides no "divide" operation.

    The operation synonym sentences can be eliminated without any loss.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: Standard Library return types

  • Key: QVT13-12
  • Legacy Issue Number: 13181
  • Status: closed  
  • Source: Open Canarias, SL ( Adolfo Sanchez-Barbudo Herrera [X] (Inactive))
  • Summary:
      • QVTo Standard Library. Some operation's returned values would better return the TemplateParameterType **
        Several stdlib operations would be better changed to avoid doing unnecessary castings on the returned value of the operation.

    For AnyType::oclAsType(oclType) operation I could write:

    var aClass : Class := anotherVar.oclAsType(Class);

    However, for Model::objectsOfType(OclType) operation I can't do:

    var aClassSet : Set(Class) := aModel.objectsOfType(Class);

    I have to do the following, instead:

    var aClassSet : Set(Class) := aModel.objectsOfType(Class).oclAsType(Set(Class));

    Therefore, for end-user usability, I propose exploiting TemplateParameterType and changing some QVTo Standard Library operations

    Element::subobjectsOfType(OclType) : Set(T)
    Element::allSubobjects(OclType) : Set(T)
    Element::subobjectsOfKind(OclType) : Set(T)
    Element::allSubobjectsOfKind(OclType) : Set(T)
    Element::clone() : T
    Element::deepclone() : T
    Model::objectsOfType(OclType) : Set(T)
    Model::copy() : T
    Model::createEmptyModel(): T

    Note: this approach is made in the Object::asOrderedTuple() : OrderedTuple(T) operation.

  • Reported: QVT 1.0 — Fri, 19 Dec 2008 05:00 GMT
  • Disposition: Duplicate or Merged — QVT 1.3
  • Disposition Summary:

    8.3.5.7 createEmptyModel static Model::createEmptyModel() : Model Creates and initializes a model of the given type. This operation is useful when creating intermediate models within a transformation.

    QVTo Standard Library. Some operation's returned values would better return the TemplateParameterType **
    Several stdlib operations would be better changed to avoid doing unnecessary castings on the returned value of the operation.

    For AnyType::oclAsType(oclType) operation I could write:

    var aClass : Class := anotherVar.oclAsType(Class);

    However, for Model::objectsOfType(OclType) operation I can't do:

    var aClassSet : Set(Class) := aModel.objectsOfType(Class);

    I have to do the following, instead:

    var aClassSet : Set(Class) := aModel.objectsOfType(Class).oclAsType(Set(Class));

    Therefore, for end-user usability, I propose exploiting TemplateParameterType and changing some QVTo Standard Library operations

    Element::subobjectsOfType(OclType) : Set(T)
    Element::allSubobjects(OclType) : Set(T)
    Element::subobjectsOfKind(OclType) : Set(T)
    Element::allSubobjectsOfKind(OclType) : Set(T)
    Element::clone() : T
    Element::deepclone() : T
    Model::objectsOfType(OclType) : Set(T)
    Model::copy() : T
    Model::createEmptyModel(): T

    Note: this approach is made in the Object::asOrderedTuple() : OrderedTuple(T) operation.

    Discussion

    subobjectsOfType etc duplicate QVT13-53

    clone/deepclone merged into QVT13-53

    Model::copy/createEmptyModel - NO. Model is the correct return type.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: element creation and element attachment/detachment to/from an extent

  • Key: QVT13-9
  • Legacy Issue Number: 13103
  • Status: closed  
  • Source: Open Canarias, SL ( Victor Sanchez)
  • Summary:

    Suggestion: In the Operational Mappings language, element creation and element attachment/detachment to/from an extent should be seen and treated as two different and independent activities. Once an element is created via an ObjectExp, this element is usually attached to another element immediately afterwards, which becomes its container, so the ObjectExp semantics of assigning it to an explicit or inferred extent becomes an unnecessary overhead. And also there are other times when we need to assign to an extent some model elements that may have been created at an unrelated time. They could even exist prior to the transformation execution. A case where this is relevant is with the result of a 'Element::clone()' or 'Element::deepclone()' operation execution. Is it expected that these model elements must belong by default to the same model as the original? How to clone parts of an extent with direction kind == 'in'? How to make them become part of the Set of root elements of another, different extent?

  • Reported: QVT 1.0 — Fri, 21 Nov 2008 05:00 GMT
  • Disposition: Duplicate or Merged — QVT 1.3
  • Disposition Summary:

    element creation and element attachment/detachment to/from an extent

    Suggestion: In the Operational Mappings language, element creation and element attachment/detachment to/from an extent should be seen and treated as two different and independent activities. Once an element is created via an ObjectExp, this element is usually attached to another element immediately afterwards, which becomes its container, so the ObjectExp semantics of assigning it to an explicit or inferred extent becomes an unnecessary overhead. And also there are other times when we need to assign to an extent some model elements that may have been created at an unrelated time. They could even exist prior to the transformation execution. A case where this is relevant is with the result of a 'Element::clone()' or 'Element::deepclone()' operation execution. Is it expected that these model elements must belong by default to the same model as the original? How to clone parts of an extent with direction kind == 'in'? How to make them become part of the Set of root elements of another, different extent?

    Discussion

    This seems to be a misunderstanding. ObjectExp does not require a created object to be attached to an inferred extent.
    This functionality seems to be present already.
    Creation without attachment requires a null or null-valued extent during creation.
    Attachment after creation can occur through an ObjectExp update to the required extent.
    Re-attachment presumably occurs through an ObjectExp update to the new extent.
    Detachment then naturally occurs through an ObjectExp update to a null-valued extent.

    This issue inspired the provision of a better desciption of extents. The resolution is therefore merged with that of QVT-36.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: Typedef

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

    Creating aliases seems to be a good idea specially when dealing with complex types. However, for that purpose, it is not clear to me that we need to create a (useless) typedef just to represent an alias in the concrete syntax. In practice aliases are very useful when writing transformations (in concrete syntax), but they are useless in the abstract syntax (extra unnecessary classes in modules). One may still think that a typedef as an alias (no extra condition) may be needed to add operations to existing types, as specification suggests doing in order to include new operations for the OCL standard library predefined types. However, this still can be done by means of helpers. Suggestions: - Remove the statements related to aliases in the section 8.2.2.24 - Make Typedef.condition reference be mandatory in Figure 8.7 since, now, Typedef in the abstract syntax will be used to constrain existing types. - Add statements in the concrete syntax section, to clarify the use of aliases to rename existing types. Maybe, a new keyword (like alias) could be included to avoid confusions with the typedef one. - Change the grammar to adapt it to these suggestions. - Clarify in the Standard Library section that helpers will be used to add new operations to the OCL Std Lib predefined type.

  • Reported: QVT 1.0 — Thu, 18 Dec 2008 05:00 GMT
  • Disposition: Resolved — QVT 1.3
  • Disposition Summary:

    Typedef aliases issue

    Creating aliases seems to be a good idea specially when dealing with complex types. However, for that purpose, it is not clear to me that we need to create a (useless) typedef just to represent an alias in the concrete syntax. In practice aliases are very useful when writing transformations (in concrete syntax), but they are useless in the abstract syntax (extra unnecessary classes in modules). One may still think that a typedef as an alias (no extra condition) may be needed to add operations to existing types, as specification suggests doing in order to include new operations for the OCL standard library predefined types. However, this still can be done by means of helpers. Suggestions: - Remove the statements related to aliases in the section 8.2.2.24 - Make Typedef.condition reference be mandatory in Figure 8.7 since, now, Typedef in the abstract syntax will be used to constrain existing types. - Add statements in the concrete syntax section, to clarify the use of aliases to rename existing types. Maybe, a new keyword (like alias) could be included to avoid confusions with the typedef one. - Change the grammar to adapt it to these suggestions. - Clarify in the Standard Library section that helpers will be used to add new operations to the OCL Std Lib predefined type.

    Discussion

    Ignoring the QVT Standard Library usage eliminated by the resolution of Issue 13252, http://solitaire.omg.org/browse/QVT13-13, there are two distinct usages of typedef.

    a) to create an alias
    b) to create a new constrained type

    Discussion - alias

    If an alias introduces a new type as the inheritance of Typedef from Type would suggest, we have semantic nightmares. Which type conforms to which? How do we ensure that all functionality understands the typedef equivalence? As observed, a typedef is a concrete syntax text macro that should be eliminated during conversion to the abstract syntax to avoid ambiguities. However an AS concept is needed to persist the macro. A Tag is sufficient.

    Discussion - constrained type

    The typedef syntax with a constraint introduces a new type. However all the important semantics of this type are unspecified. What are the superclasses of this type? What does it conform to? How do its operations and properties interact with the unconstrained type? Can a Constrained Integer be used as a Sequence index?

    The only example of a constrained type is:

    typedef TopLevelPackage = Package [container()=null];

    suggesting that perhaps self is to be interpreted as the type instance. If container() is the proposed oclContainer() then the example is particularly interesting. If a TopLevelPackage is assigned to a container, how does the type change? Are all assignments supposed to have a predicate evaluation to ensure that typedef constraints are not violated? Are assigned types to be changed by an assignment? Does an assignment that violates a constrained type constraint render a transformation invalid and require some form of failure?

    Look at it another way. Suppose we used bland UML. We can add an invariant to a class, which can inherit/aggregate another type to re-use it. We and general purpose tooling understand these semantics. What does a typedef constrained type offer that is new? just magic undefined semantics that cannot be used with any non-QVTo tool.

    The constrained typedef appears to be a clear case of misguided syntax sugar. If metamodeling syntax sugar is really needed, let it have a clear relationship to UML.

    Conclusion

    The alias usage is a concrete syntax synonym that has no need of a Typedef class; a Tag will do.

    The constrained type is underspecified syntax sugar. The Typedef class can be deprecated.

    FWIW: neither of these forms of typedef is implemented by Eclipse QVTo.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTr: BlackBox operation signature difficulties

  • Key: QVT13-7
  • Legacy Issue Number: 13054
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    In 7.11.3.6 (and 7.8) the ordering of parameters is implied but not explicit. Presumably the first is the output (enforced direction) so:

    package QVTBase

    context TypedModel
    def: allUsedPackage() : Set(EMOF::Package)
    = self.dependsOn.allUsedPackage()>asSet()>union(self.usedPackage)

    endpackage

    package QVTRelation

    context RelationImplementation
    inv RootNodeIsBoundToRootVariable : self.inDirectionOf.allUsedPackage()>includes(self.impl.ownedParameter>at(1).type._package)

    endpackage

    This is not satisfied by almost the last line of RelToCore in 10.3:

    enforce domain core me:OclExpression{} implementedby CopyOclExpession(re, me);

    which seems to have output second.

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

    More significantly CopyOclExpession(re, me) is not meaningful as a black box signature, since it is a static function and EMOF has no way to define static functions. Perhaps it is a query, for which the declaration was omitted from the example. If this is the case, it should be made clear that black box operations must be declared internally as queries and bound externally to static operations of the transformation.

    This semantic clumsiness could be resolved, if, within a transformation,
    relation, domain or query, self is bound to a transformation instance. Queries would then be normal non-static operations of the transformation (class) and the implementedBy operation call would be a normal implicit call via self of a non-static transformation operation or query. (A RelationCallExp would also deviate less from OCL than it currently does.) This would also allow a transformation to extend a Utility class that provided the required black box operations. Since queries and relations are declarative, it is not obvious that there need be any prohibition on the content of an extended Class; if the Class has properties, these cannot mutate during a query or relation match, so the properties are ok; they might even permit useful behavioural tailoring. For instance an 'inherited' Boolean mangledNames property could influence the mapping of names between input and output.

    The RelToCore example can then be mended by declaring that:

    RelToCore(...) extends utils::CopyUtilities

    and externally binding the utils model name to a package that has a CopyUtilities class with suitable a CopyOclExpession operation.

  • Reported: QVT 1.0 — Fri, 31 Oct 2008 04:00 GMT
  • Disposition: Deferred — QVT 1.3
  • Disposition Summary:

    7.11.3.6 (and 7.11.1.1) BlackBox operation signature difficulties

    In 7.11.3.6 (and 7.8) the ordering of parameters is implied but not explicit. Presumably the first is the output (enforced direction) so:

    package QVTBase
    
    context TypedModel
    def: allUsedPackage() : Set(EMOF::Package)
    = self.dependsOn.allUsedPackage()>asSet()>union(self.usedPackage)
    
    endpackage
    
    package QVTRelation
    
    context RelationImplementation
    inv RootNodeIsBoundToRootVariable : self.inDirectionOf.allUsedPackage()>includes(self.impl.ownedParameter>at(1).type._package)
    
    endpackage
    

    This is not satisfied by almost the last line of RelToCore in 10.3:

    enforce domain core me:OclExpression{} implementedby CopyOclExpession(re, me);
    

    which seems to have output second.

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

    More significantly CopyOclExpession(re, me) is not meaningful as a black box signature, since it is a static function and EMOF has no way to define static functions. Perhaps it is a query, for which the declaration was omitted from the example. If this is the case, it should be made clear that black box operations must be declared internally as queries and bound externally to static operations of the transformation.

    This semantic clumsiness could be resolved, if, within a transformation,relation, domain or query, self is bound to a transformation instance. Queries would then be normal non-static operations of the transformation (class) and the implementedBy operation call would be a normal implicit call via self of a non-static transformation operation or query. (A RelationCallExp would also deviate less from OCL than it currently does.) This would also allow a transformation to extend a Utility class that provided the required black box operations. Since queries and relations are declarative, it is not obvious that there need be any prohibition on the content of an extended Class; if the Class has properties, these cannot mutate during a query or relation match, so the properties are ok; they might even permit useful behavioural tailoring. For instance an 'inherited' Boolean mangledNames property could influence the mapping of names between input and output.

    The RelToCore example can then be mended by declaring that:

    RelToCore(...) extends utils::CopyUtilities
    

    and externally binding the utils model name to a package that has a CopyUtilities class with suitable a CopyOclExpession operation.

    Discussion

    Binding self to a Transformation instance may conflict with self as the context in a query. Much safer to bind this; just like QVTo.

    Using this as the source of an OperationCallExp of a query eliminates an incompatibility with OCL. But there is no need bloat every RelationCallExp with an extra VariableExp for this.

    Any enhancement here needs prototyping.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: ImperativeOCL conflicts with EssentialOCL semantics

  • Key: QVT13-8
  • Legacy Issue Number: 13082
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Major Problem:
    (1) The current abstract syntax of ImperativeOCL introduces a couple of
    unclear situations. This may lead to incompatible QVT implementations.
    Further Problems:
    (2) Control flow constructs introduced by ImperativeOCL are redundant
    compared with existing conventional OCL constructs.
    (3) Several OCL equivalence rules break when ImperativeOCL is present.
    Detailed problem description:
    (1) The current abstract syntax of ImperativeOCL introduces a couple of
    unclear situations. This may lead to incompatible QVT implementations.
    In the abstract syntax, ImperativeOCL expressions / statements are
    inherited from OclExpression. Therefore, conventional OCL
    expressions may (and will) contain sub-expressions that are
    actually ImperativeOCL expressions.
    In conventional OCL, the interpretation of an expression under a
    given environment is a value. In ImperativeOCL, the interpretation
    of an expression is a value and a new environment
    (state,variables). This extended interpretation is not given for
    conventional OCL expressions, leading to undefined operational
    semantics of those expressions.
    Example: Given the following compute expression:
    compute(z:Boolean) {
    var x : Boolean := true
    var y : Boolean := true
    if ((x:=false) and (y:=false))

    { ... }

    z := y
    }
    What is the value of this expression: is it true or false (It
    depends on whether the 'and' operator is evaluated short-circuit
    or strict). The situation is similar for the evaluation of the
    other logical connectives, forAll, and exists when these
    expressions contain imperative sub-expressions.
    (2) Control flow constructs introduced by ImperativeOCL are redundant
    compared with existing conventional OCL constructs.
    Some of the new language features in ImperativeOCL such as forEach
    and the imperative conditional are not really necessary. Their
    effect can already be achieved using conventional OCL expressions:
    For example:
    company.employees->forEach(c)

    { c.salary := c.salary * 1.1}

    has the same effect as
    company.employees->iterate(c; r:OclAny=Undefined |
    c.salary := c.salary * 1.1
    )
    and
    if ( x < 0 )

    { x := 0 }

    else

    { x := 1 }

    endif is the same as
    if x < 0 then x := 0 else x := 1 endif
    (3) Several OCL equivalence rules break when ImperativeOCL is present.
    In conventional OCL, several equivalence rules well known from
    logic hold. Allowing OCL expression to contain imperative
    sub-expressions breaks these equivalence rules.
    Examples:
    let x=e1 in e2 equiv. e2

    { all occurences of x replaced by e1 }

    e1 and e2 equiv. e2 and e1
    These equivalences do not necessarily hold if e1 or e2 are allowed
    to have side-effects.
    Proposed solution:
    (A) - (The cheap solution.) State textually that conventional OCL
    expressions (as described in the OMG OCL spec.) are not
    allowed to have side effects unless used as part of a top
    level ImperativeOCL expression. Therefore, even in a system
    supporting ImperativeOCL, class invariants, and pre- and
    postconditions (e.g.) will not be allowed to contain
    ImperativeOCL sub-expressions.
    State explicitly that the redundant flow control statements
    have been introduced (solely) to write concise imperative
    programs and that the side-effect free forms of conditional
    evaluation ( 'if-then-else-endif' and 'iterate' ) shall not be
    used to program side-effects (instead, the ImperativeOCL forms
    shall be used).
    (B) - (Major rework.) Rework the abstract syntax to reuse OCL
    expressions by composition rather than by inheritance.
    Imperative expressions ( => rename to 'statements' ) then may
    contain sub-statements and OCL expressions; OCL expressions
    are reused unchanged from the OCL spec (no imperative
    sub-expressions, no side-effects).
    These issues have been discussed on the MoDELS 2008 OCL Workshop,
    more details can be found at
    http://www.fots.ua.ac.be/events/ocl2008/PDF/OCL2008_9.pdf

  • Reported: QVT 1.0 — Sat, 15 Nov 2008 05:00 GMT
  • Disposition: Resolved — QVT 1.3
  • Disposition Summary:

    current abstract syntax of ImperativeOCL introduces a couple of unclear situations

    Major Problem:
    (1) The current abstract syntax of ImperativeOCL introduces a couple of unclear situations. This may lead to incompatible QVT implementations.
    Further Problems:
    (2) Control flow constructs introduced by ImperativeOCL are redundant compared with existing conventional OCL constructs.
    (3) Several OCL equivalence rules break when ImperativeOCL is present.
    Detailed problem description:
    (1) The current abstract syntax of ImperativeOCL introduces a couple of unclear situations. This may lead to incompatible QVT implementations.
    In the abstract syntax, ImperativeOCL expressions / statements are inherited from OclExpression. Therefore, conventional OCL expressions may (and will) contain sub-expressions that are actually ImperativeOCL expressions. In conventional OCL, the interpretation of an expression under a given environment is a value. In ImperativeOCL, the interpretation of an expression is a value and a new environment (state,variables). This extended interpretation is not given for conventional OCL expressions, leading to undefined operational semantics of those expressions.
    Example: Given the following compute expression:
    compute(z:Boolean) {
    var x : Boolean := true
    var y : Boolean := true
    if ((x:=false) and (y:=false))

    { ... }

    z := y
    }
    What is the value of this expression: is it true or false (It depends on whether the 'and' operator is evaluated short-circuit or strict). The situation is similar for the evaluation of the other logical connectives, forAll, and exists when these expressions contain imperative sub-expressions.

    (2) Control flow constructs introduced by ImperativeOCL are redundant compared with existing conventional OCL constructs.
    Some of the new language features in ImperativeOCL such as forEach and the imperative conditional are not really necessary. Their effect can already be achieved using conventional OCL expressions:
    For example:
    company.employees->forEach(c)

    { c.salary := c.salary * 1.1}

    has the same effect as
    company.employees->iterate(c; r:OclAny=Undefined |
    c.salary := c.salary * 1.1
    )
    and
    if ( x < 0 )

    { x := 0 }

    else

    { x := 1 }

    endif is the same as
    if x < 0 then x := 0 else x := 1 endif

    (3) Several OCL equivalence rules break when ImperativeOCL is present.
    In conventional OCL, several equivalence rules well known from logic hold. Allowing OCL expression to contain imperative sub-expressions breaks these equivalence rules.
    Examples:
    let x=e1 in e2 equiv. e2

    { all occurences of x replaced by e1 }

    e1 and e2 equiv. e2 and e1
    These equivalences do not necessarily hold if e1 or e2 are allowed to have side-effects.
    Proposed solution:
    (A) - (The cheap solution.) State textually that conventional OCL expressions (as described in the OMG OCL spec.) are not allowed to have side effects unless used as part of a top level ImperativeOCL expression. Therefore, even in a system supporting ImperativeOCL, class invariants, and pre- and postconditions (e.g.) will not be allowed to contain ImperativeOCL sub-expressions.
    State explicitly that the redundant flow control statements have been introduced (solely) to write concise imperative programs and that the side-effect free forms of conditional evaluation ( 'if-then-else-endif' and 'iterate' ) shall not be used to program side-effects (instead, the ImperativeOCL forms shall be used).
    (B) - (Major rework.) Rework the abstract syntax to reuse OCL expressions by composition rather than by inheritance.
    Imperative expressions ( => rename to 'statements' ) then may contain sub-statements and OCL expressions; OCL expressions are reused unchanged from the OCL spec (no imperative sub-expressions, no side-effects).
    These issues have been discussed on the MoDELS 2008 OCL Workshop, more details can be found at http://www.fots.ua.ac.be/events/ocl2008/PDF/OCL2008_9.pdf

    Discussion - 1 short circuit semantics

    It is possible to weasel out of this narrowly described problem by observing that OCL only supports short-circuit semantics once it is proven that no invalid lurks beyond the short-circuit. An extension to this could inhibit short-circuit semantics if any imperative expression is involved.

    Discussion - (2) redundant control flow

    The first suggestion is contradictory. The replacement for forEach is noticeably longer and uses a side effect within an iterate, which the author argues against elsewhere.

    The second suggestion incorrectly assumes that an else clause is present. The imperative if (SwitchExp) allows one-sided functionality including selective control flow adjustment.

    Discussion - (3) broken equivalence

    The example is unreadable, but the point is unarguable; imperative semantics within functional semantics subvert the functional.

    (A) - (The cheap solution.) is simple and adopted here.

    (B) - (Major rework.) is a breaking structural change and so forked off to http://solitaire.omg.org/browse/QVT13-87 for consideration by QVT 2.0.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTr: Undefined semantics

  • Key: QVT13-3
  • Legacy Issue Number: 10936
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The whole Concrete Syntax section deserves a much more substantial description.

    In particular...

    The mechanism by which a package name is located is unresolved, perhaps deliberately,
    but the omission should be explicit.

    What constraints exist on forward referencing of names?

    Transformations and mappings could be ordered so that forward references are avoided,
    but large modules benefit from an alphabetical ordering of elements, so requiring
    a parser friendly order is not user friendly.

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

    9.18 Undefined semantics

    The whole Concrete Syntax section deserves a much more substantial description.

    In particular...

    The mechanism by which a package name is located is unresolved, perhaps deliberately,
    but the omission should be explicit.

    What constraints exist on forward referencing of names?

    Transformations and mappings could be ordered so that forward references are avoided,
    but large modules benefit from an alphabetical ordering of elements, so requiring
    a parser friendly order is not user friendly.

    Discussion

    This isn't going to happen until a QVT 2.0 rewrite adopts the autogeneration approaches underway for OCL.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTr: Missing Name and Expression syntax

  • Key: QVT13-1
  • Legacy Issue Number: 10934
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    9.18 Undefined syntax
    ---------------------

    The syntax for TransformationName, DirectionName, MappingName, PropertyName and VariableName
    is undefined. Presumably each of these is an Identifier (below) when defining, but a PathNameCS
    when referencing.

    The syntax for PackageName is undefined. Presumably it is an OCL PathNameCS.

    The syntax for ValueOCLExpr is undefined. This is presumably an OclExpressionCS.

    The syntax for BooleanOCLExpr is undefined. This could be an OclExpressionCS of Boolean type but ...

    The syntax for SlotOwnerOCLExpr is undefined. This could be an OclExpressionCS of Class type but ...

    If BooleanOCLExpr and SlotOwnerOCLExpr are parsed as OclExpressionCS the 'default' prefix
    causes a major ambiguity for 'default(...).xx' as a parenthesised slot owner or function call.
    It is necessary to make 'default' a reserved word within OCL expressions.

    Suggest: define BooleanOCLExpr and SlotOwnerOCLExpr very narrowly.

    Predicate ::= SimpleNameCS ("." SimpleNameCS)* "=" OclExpressionCS
    Assignment ::= ["default"] SimpleNameCS ("." SimpleNameCS)* ":=" OclExpressionCS

  • Reported: QVT 1.0 — Sun, 25 Mar 2007 04:00 GMT
  • Disposition: Duplicate or Merged — QVT 1.3
  • Disposition Summary:

    Undefined syntax

    9.18 Undefined syntax
    ---------------------

    The syntax for TransformationName, DirectionName, MappingName, PropertyName and VariableName
    is undefined. Presumably each of these is an Identifier (below) when defining, but a PathNameCS
    when referencing.

    The syntax for PackageName is undefined. Presumably it is an OCL PathNameCS.

    The syntax for ValueOCLExpr is undefined. This is presumably an OclExpressionCS.

    The syntax for BooleanOCLExpr is undefined. This could be an OclExpressionCS of Boolean type but ...

    The syntax for SlotOwnerOCLExpr is undefined. This could be an OclExpressionCS of Class type but ...

    If BooleanOCLExpr and SlotOwnerOCLExpr are parsed as OclExpressionCS the 'default' prefix
    causes a major ambiguity for 'default(...).xx' as a parenthesised slot owner or function call.
    It is necessary to make 'default' a reserved word within OCL expressions.

    Suggest: define BooleanOCLExpr and SlotOwnerOCLExpr very narrowly.

    Predicate ::= SimpleNameCS ("." SimpleNameCS)* "=" OclExpressionCS
    Assignment ::= ["default"] SimpleNameCS ("." SimpleNameCS)* ":=" OclExpressionCS

    Discussion

    Merged with the inadequate definition of identifiers.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: Standard Library mode and namespace

  • Key: QVT13-52
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The QVTo Standard Library has no model and consequently no namespace.

    This encourages a major confusion:

    The QVToLib::Model and QVToLib::Transformation types used in the QVTo Standard Library are at a different meta-level to UML::Model and QVTbase::Transformation. We have the uncomfortable situation that a QVToLib::Model is an instance of a QVTbase::TypedModel and a QVToLib::Transformation is an instance of a QVTbase::Transformation.

    As a minimum the distinct namespaces should be identified and modeled.

    Possibly QVToLib::Model and QVToLib::Transformation should be renamed. Since they have no namespace they are currently unuseable in code; their sole purpose is for specification of implementation behavior.

  • Reported: QVT 1.2 — Thu, 30 Apr 2015 08:21 GMT
  • Disposition: Deferred — QVT 1.3
  • Disposition Summary:

    QVTo Standard Library mode and namespace

    The QVTo Standard Library has no model and consequently no namespace.

    This encourages a major confusion:

    The QVToLib::Model and QVToLib::Transformation types used in the QVTo Standard Library are at a different meta-level to UML::Model and QVTbase::Transformation. We have the uncomfortable situation that a QVToLib::Model is an instance of a QVTbase::TypedModel and a QVToLib::Transformation is an instance of a QVTbase::Transformation.

    As a minimum the distinct namespaces should be identified and modeled.

    Possibly QVToLib::Model and QVToLib::Transformation should be renamed. Since they have no namespace they are currently unuseable in code; their sole purpose is for specification of implementation behavior.

    Discussion

    It is difficult to make sensible progress until the OCL work in progress modeling libraries provides the solution.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: Inadequate definition of "late" semantics

  • Key: QVT13-27
  • Legacy Issue Number: 19429
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The specification of "late" semantics uses the "conceptually" word; a sure sign of missing semantics. It is followed by a magic null value that stores information for later use and with an unspecified trace interaction.

    The interaction of "late" and implicit collect is not handled so in

    generalizations := self.eSuperTypes->collect(t | t.late resolve(UML::Generalization))

    the direct association of "late" with asssignment is no longer direct; the "late"s must be aggregated. Potentuially this may occur in arbitrary complexd expressions including mapping calls!

    An alternate multi-pass interpretation of "late" is given.

    This seems like the correct approach; an MtoM transformation from a with-late to multi-pass without-late transformation.

  • Reported: QVT 1.2 — Thu, 22 May 2014 04:00 GMT
  • Disposition: Deferred — QVT 1.3
  • Disposition Summary:

    Inadequate definition of "late" semantics

    The specification of "late" semantics uses the "conceptually" word; a sure sign of missing semantics. It is followed by a magic null value that stores information for later use and with an unspecified trace interaction.

    The interaction of "late" and implicit collect is not handled so in

    generalizations := self.eSuperTypes->collect(t | t.late resolve(UML::Generalization))

    the direct association of "late" with asssignment is no longer direct; the "late"s must be aggregated. Potentially this may occur in arbitrary complex expressions including mapping calls!

    An alternate multi-pass interpretation of "late" is given.

    This seems like the correct approach; an MtoM transformation from a with-late to multi-pass without-late transformation.

    Discussion

    Yes, but such an MtoM is non-trivial. Needs development and testing before it can be included as part of the specification.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: Enhance ObjectExp to allow constructors invocation

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

    Problem:

    ObjectExp seems to be an enhancement to the InstantationExp due to the additional semantics, however it gets limited due to the fact that every time we need to use it we have to define the constructor body (in constrast to the instantiation expression usage). Although, ObjectExp was conceived to inline object instantiations, this limitation is not justified.

    However, this limitation could be removed by also allowing an ObjectExp-Constructor combination, in the same way we have for InstantiationExp. The problem relies on a flaky concrete syntax which we could enhance to exploit an ObjectExp with an already defined constructor operation:

    constructor Column::ColumnConstructor (n:String,t: String)

    { name:=n; type:=t; }

    object result1 : Column (“name”, “String”);
    object result2 : Column (“age”, “Integer”);

    Providing a constructor body (from ObjectExp) and a list of arguments (from InstantiationExp) should be prohibited in both, the concrete syntax and the abstract syntax. Regarding the abstract syntax this could be expression with a constraint.

    context ObjectExp
    inv : argument->size() > 0 implies body.oclIsUndefined()

    Discussion:
    This enhancement seems convenient with no apparent drawbacks, since the old ObjectExp usage remains valid.

    Proposed solution:

    In section 8.2.1.24 add the following subsection:

    Constraints

    If an object expression contains a constructor body, no arguments for a constructor are allowed (and vice versa):

    context ObjectExp
    inv: argument->notEmpty() > 0 implies body.oclIsUndefined() and
    not body.oclIsUndefined() implies argument->isEmpty()

    In section 8.2.1.24 add the following to the the end notation subsection:

    Similarly to InstantiationExp, an object expression could be used to invoke a constructor operation, rather than inlining a constructor body:

    object result1 : Column (“name”, “String”);
    object result2 : Column (“age”, “Integer”);

    Note that this notation allows us to use object expression to instantiate (or update) objects, while having a reusable constructor in order to initialize (or update) the properties of the object subject to be created (or updated).

    In section 8.4.7:

    Replace:

    <object_exp> ::= 'object' ('(' <iter_declarator> ')')? <object_declarator>
    <expression_block>

    By:

    <object_exp> ::= 'object' ('(' <iter_declarator> ')')? <object_declarator>
    (<expression_block> | '(' (<declarator_list>)? ')' )

  • Reported: QVT 1.1 — Wed, 23 Oct 2013 04:00 GMT
  • Disposition: Deferred — QVT 1.3
  • Disposition Summary:

    Enhance ObjectExp to allow constructors invocation

    Problem:

    ObjectExp seems to be an enhancement to the InstantationExp due to the additional semantics, however it gets limited due to the fact that every time we need to use it we have to define the constructor body (in constrast to the instantiation expression usage). Although, ObjectExp was conceived to inline object instantiations, this limitation is not justified.

    However, this limitation could be removed by also allowing an ObjectExp-Constructor combination, in the same way we have for InstantiationExp. The problem relies on a flaky concrete syntax which we could enhance to exploit an ObjectExp with an already defined constructor operation:

    constructor Column::ColumnConstructor (n:String,t: String)

    { name:=n; type:=t; }

    object result1 : Column (“name”, “String”);
    object result2 : Column (“age”, “Integer”);

    Providing a constructor body (from ObjectExp) and a list of arguments (from InstantiationExp) should be prohibited in both, the concrete syntax and the abstract syntax. Regarding the abstract syntax this could be expression with a constraint.

    context ObjectExp
    inv : argument->size() > 0 implies body.oclIsUndefined()

    Discussion:
    This enhancement seems convenient with no apparent drawbacks, since the old ObjectExp usage remains valid.

    Proposed solution:

    In section 8.2.1.24 add the following subsection:

    Constraints

    If an object expression contains a constructor body, no arguments for a constructor are allowed (and vice versa):

    context ObjectExp
    inv: argument->notEmpty() > 0 implies body.oclIsUndefined() and
    not body.oclIsUndefined() implies argument->isEmpty()

    In section 8.2.1.24 add the following to the the end notation subsection:

    Similarly to InstantiationExp, an object expression could be used to invoke a constructor operation, rather than inlining a constructor body:

    object result1 : Column (“name”, “String”);
    object result2 : Column (“age”, “Integer”);

    Note that this notation allows us to use object expression to instantiate (or update) objects, while having a reusable constructor in order to initialize (or update) the properties of the object subject to be created (or updated).

    In section 8.4.7:

    Replace:

    <object_exp> ::= 'object' ('(' <iter_declarator> ')')? <object_declarator>
    <expression_block>

    By:

    <object_exp> ::= 'object' ('(' <iter_declarator> ')')? <object_declarator>
    (<expression_block> | '(' (<declarator_list>)? ')' )

    Discussion

    This was extensively discussed on the Eclipse qvto-dev mailing list.

    The conclusion was that the inheritance of ObjectExp from InstantiationExp is pragmatic and causes more problems that it solves. It should be eliminated.

    Allowing objects to be constructed by a constructor expression rather field assignment is a nice syntax enhancement for significant utility classes.

    It is hoped that a resolution will be prototyped by:

    https://bugs.eclipse.org/bugs/show_bug.cgi?id=479657

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: How can an UnlinkExp.target be a Property

  • Key: QVT13-134
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The description of UnlinkExp.target specifies an OclExpression but describes a Property.

    Is this an error? Is it introducing a new PropertyLiteralExp?

  • Reported: QVT 1.2 — Wed, 21 Oct 2015 16:48 GMT
  • Disposition: Deferred — QVT 1.3
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Tue, 22 Dec 2015 15:31 GMT

Pre-ballot 2 FTF Appendix A: Erroneous memberSelection grammar

  • Key: QVT-90
  • Legacy Issue Number: 10989
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    memberSelection has missing , in list

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

  • Reported: QVT 1.0b1 — Mon, 30 Apr 2007 04:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    closed, no change

  • Updated: Sun, 8 Mar 2015 18:08 GMT

Chapter 7 QVTrelation Standard Library

  • Key: QVT-89
  • Legacy Issue Number: 10985
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

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

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

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

  • Reported: QVT 1.0b1 — Mon, 30 Apr 2007 04:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    Add the following subsection in the concrete syntax section 7.13:

    Shorthands used to invoke pre-defined operations
    The binary operator "+" can be used as shorthand for the string concat operation.

  • Updated: Sun, 8 Mar 2015 18:08 GMT

RelationalTransformation as a subclass of Transformation

  • Key: QVT-88
  • Legacy Issue Number: 9384
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

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

    Suggestion: Add a RelationalTransformation metaclass inheriting
    from Transformation and add the missing association:
    'RelationalTransformation::key : [*] Key

    {composes}

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

  • Reported: QVT 1.0b1 — Mon, 13 Feb 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    duplicate of issue 9383, close

  • Updated: Sun, 8 Mar 2015 18:08 GMT

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

Top-levelness in QVT relations need to be enforced by a constraint

  • Key: QVT-86
  • Legacy Issue Number: 10626
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

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

  • Reported: QVT 1.0b1 — Thu, 25 Jan 2007 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    Add a "Constraints" subsection with the following content:

    """
    A non top-level relation should be invoked from the where clause of some other relation.
    self.isTopLevel implies not Relation.allInstances()->exists(r |
    r.where.predicate.conditionExpression->exists(ce |
    ce.oclIsTypeOf(RelationCallExp) and
    ce.oclAsType(RelationCallExp).referredRelation = self
    )
    )
    """

    NOTE:
    This issue is superseded by issue 11022. The resolution should hence not be applied.

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

Rules for infering an extent

  • Key: QVT-87
  • Legacy Issue Number: 10627
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

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

  • Reported: QVT 1.0b1 — Thu, 25 Jan 2007 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    In relation with resolution 9388, replace the text describing the "modelParameter" role:

    The extent of the mapping parameter. Should be explicitly provided
    when there is an ambiguity on the extent that will own a potential
    created element corresponding to this parameter.

    By:

    """
    The extent of the mapping parameter. If not provided the extent is inferred by inspecting the model types of the transformation. See the inference rules below.
    """

    In addition, after the description of the metaclass properties, add the following paragraph:
    """
    Extent inference rule for mapping parameters:
    If the mapping parameter direction is "in", inspect the input model types of the transformation to find the one that contains the type of the parameter. A model type "contains" a type if the type is directly or indirectly contained by the package defining the model type.
    If the model parameter direction is "inout" or "out", inspect the inout or output model types of the transformation to find the one that contains the type of the parameter.
    In both cases there should be a unique model type found.
    """

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

Escape characters in string literals

  • Key: QVT-85
  • Legacy Issue Number: 10625
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

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

  • Reported: QVT 1.0b1 — Thu, 25 Jan 2007 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    In relation with resolution 9427, replace the sentence:

    "All the usual escape characters using backslash can be used including the '\n' return-line character."

    By
    """
    All the usual escape characters using backslash can be used including the '\n' return-line character. The list of available escape characters are those defined for the Java language.

    EscapeSequence:
    \ b /* \u0008: backspace BS */
    \ t /* \u0009: horizontal tab HT */
    \ n /* \u000a: linefeed LF */
    \ f /* \u000c: form feed FF */
    \ r /* \u000d: carriage return CR */
    \ " /* \u0022: double quote" */
    \ ' /* \u0027: single quote ' */
    \ \ /* \u005c: backslash \ */
    OctalEscape /* \u0000 to \u00ff: from octal value

    OctalEscape:
    \ OctalDigit
    \ OctalDigit OctalDigit
    \ ZeroToThree OctalDigit OctalDigit
    OctalDigit: one of
    0 1 2 3 4 5 6 7
    ZeroToThree: one of
    0 1 2 3
    """

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

Kind of expressions in collection patterns

  • Key: QVT-84
  • Legacy Issue Number: 10624
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

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

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

  • Reported: QVT 1.0b1 — Thu, 25 Jan 2007 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    The resolution of this issue is related to the resolution of issue 10784. Please refer to the resolution of issue 10784. There is no need to specify CollectionPatternKind in the new extended collection pattern suggested in 10784.

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

Relation To Core Transformation

  • Key: QVT-83
  • Legacy Issue Number: 10619
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

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

  • Reported: QVT 1.0b1 — Sun, 21 Jan 2007 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    The relations-to-core transformation spec was out of sync with the meta models. The new updated spec is given in appendix B of this report.
    Replace the content of sections 10.3 by the new content in Appendix B of this report.

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

Formatting

  • Key: QVT-82
  • Legacy Issue Number: 10618
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Inconsistent font for first line of 7.13.1.

  • Reported: QVT 1.0b1 — Sun, 21 Jan 2007 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    Font to be made consistent in 7.13.1.

    NOTE:
    This issue is superseded by issue 10616 which replaces all the content of the BNF section. Hence, the resolution should not be applied.

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

Member selection operator

  • Key: QVT-79
  • Legacy Issue Number: 10615
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

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

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

  • Reported: QVT 1.0b1 — Sun, 21 Jan 2007 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    Resolution: No change

    Remark:
    Which operator to use is a matter of taste. We checked with a few users and they preferred an operator over a keyword.

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

Ambiguity

  • Key: QVT-80
  • Legacy Issue Number: 10616
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

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

    excluding collectionType that is ambiguous wrt collectionTemplate syntax

  • Reported: QVT 1.0b1 — Sun, 21 Jan 2007 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    Replace the content of section 7.13.1 and 7.13.2 by the new content given in Appendix A of this report. This new content is the updated grammar correcting typos and other mistakes.

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

Typos

  • Key: QVT-81
  • Legacy Issue Number: 10617
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

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

  • Reported: QVT 1.0b1 — Sun, 21 Jan 2007 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    Resolution: No change

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

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

Filename

  • Key: QVT-78
  • Legacy Issue Number: 10614
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

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

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

  • Reported: QVT 1.0b1 — Sun, 21 Jan 2007 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    The <filename> element has been renamed <unit> to mean "compilation unit" and defined as a sequence of identifier separated by dots. It is now clear that arbitrary file names cannot be used in import statements.

    In order to apply the resolution: replace the content of section 7.13.1 and 7.13.2 by the new content given in Appendix A of this report. This new content is the updated grammar correcting typos and other mistakes.

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

Missing paramDeclaration

  • Key: QVT-76
  • Legacy Issue Number: 10612
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

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

  • Reported: QVT 1.0b1 — Sun, 21 Jan 2007 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    Replace the content of section 7.13.1 and 7.13.2 by the new content given in Appendix A of this report. This new content is the updated grammar correcting typos and other mistakes.

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

Member selection as domain body

  • Key: QVT-75
  • Legacy Issue Number: 10611
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Relations to Core uses a top of domain memberSelectionExprCS.

    In <dommain>
    Replace: '

    {' <propertyTemplate>* '}

    '
    By: '

    {' (<propertyTemplate>* | memberSelectionExprCS) '}

    '
    Or rather: '

    {' ((<propertyTemplate> (',' <propertyTemplate>)*) | memberSelectionExprCS) '}

    '

  • Reported: QVT 1.0b1 — Sun, 21 Jan 2007 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    Replace the content of section 7.13.1 and 7.13.2 by the new content given in Appendix A of this report. This new content is the updated grammar correcting typos and other mistakes.

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

Missing oclExpressionCSList

  • Key: QVT-77
  • Legacy Issue Number: 10613
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

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

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

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

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

  • Reported: QVT 1.0b1 — Sun, 21 Jan 2007 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    Replace the content of section 7.13.1 and 7.13.2 by the new content given in Appendix A of this report. This new content is the updated grammar correcting typos and other mistakes.

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

Unsafe oclExpressionCS

  • Key: QVT-74
  • Legacy Issue Number: 10610
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

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

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

    Replace: <oclExpressionCS> ::= <propertyCallExpCS>

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

    and use this new construct as:

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

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


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

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

    {' <oclStatementCS> '}'


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

    ' ]

    In <query>
    Replace: ';' | '

    {' <oclExpressionCS> '}

    '
    By: ';' | '

    {' <oclStatementCS> '}

    '

  • Reported: QVT 1.0b1 — Sun, 21 Jan 2007 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    Replace the content of section 7.13.1 and 7.13.2 by the new content given in Appendix A of this report. This new content is the updated grammar correcting typos and other mistakes.

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

Over-enthusiastic semicolon

  • Key: QVT-73
  • Legacy Issue Number: 10609
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

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

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

  • Reported: QVT 1.0b1 — Sun, 21 Jan 2007 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    Replace the content of section 7.13.1 and 7.13.2 by the new content given in Appendix A of this report. This new content is the updated grammar correcting typos and other mistakes.

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

Comments

  • Key: QVT-70
  • Legacy Issue Number: 10604
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

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

  • Reported: QVT 1.0b1 — Sun, 21 Jan 2007 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    Specify the comment convention in section 7.13 by adding, before sub-section 7.13.1 Relation Textual Syntax Grammar, a new sub-section named "Comments" with the following text:

    """
    The syntax supports two forms of comments, a line comment, and a paragraph comment.
    The line comment starts with the string '--' and ends with the next newline. The paragraph comment starts with the string '/' and ends with the string '/.' Paragraph comments may be nested.
    """

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

Unquoted commas

  • Key: QVT-71
  • Legacy Issue Number: 10605
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

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

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

    Replace: <keyDecl> ::= 'key' <classId> '

    {' <propertyId> (, <propertyId>)* '}

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

    {' <propertyId> (',' <propertyId>)* '}

    ' ';'

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

  • Reported: QVT 1.0b1 — Sun, 21 Jan 2007 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    Replace the content of section 7.13.1 and 7.13.2 by the new content given in Appendix A of this report. This new content is the updated grammar correcting typos and other mistakes.

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

Missing commas

  • Key: QVT-72
  • Legacy Issue Number: 10608
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

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

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

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

  • Reported: QVT 1.0b1 — Sun, 21 Jan 2007 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    Replace the content of section 7.13.1 and 7.13.2 by the new content given in Appendix A of this report. This new content is the updated grammar correcting typos and other mistakes.

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

OCL extensions

  • Key: QVT-69
  • Legacy Issue Number: 10603
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

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

    OCL extension
    -------------

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

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

  • Reported: QVT 1.0b1 — Sun, 21 Jan 2007 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    Insert a new sub-section named "Keywords" in 7.13 to list the keywords. This section is to be inserted before the "Relations textual Syntax Grammar" sub-section. The text of the section will be as follows:

    Keywords:
    checkonly, domain, enforce, extends, implementedby, import, key, overrides
    primitive, query, relation, top, transformation, when, where.

    All these keywords are reserved words, they cannot be used as identifiers.
    The "_" OCL prefix convention for escaping reserved words can be used to refer to conflicting properties or class names.

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

QVTrelation to QVTcore transformation

  • Key: QVT-68
  • Legacy Issue Number: 10077
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

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

    in RelationToTraceclass

    RelationDomain has a DomainPattern rather than an ObjectTemplateExp

    in SubTemplateToTraceClassProps

    ObjectTemplateExp has a PartTemplateItem rather than an ObjectTemplateExp

    These are easily fixed, but

    in TopLevelRelationToMappingForEnforcement

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

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

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

  • Reported: QVT 1.0b1 — Wed, 26 Jul 2006 04:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    The relations-to-core transformation spec was out of sync with the meta models. The new updated spec is given in appendix B of this report.
    Replace the content of sections 10.3 by the new content in Appendix B of this report.

  • 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

variable-assignment isn't defined in Core language

  • Key: QVT-67
  • Legacy Issue Number: 9463
  • Status: closed  
  • Source: Modeling Value Group ( Wim Bast)
  • Summary:

    There exist assignments to variables in the QVT examples.

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

    This should be fixed.

    Impact: only changes the QVT Core language definition.

  • Reported: QVT 1.0b1 — Mon, 20 Mar 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

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

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

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

  • 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

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

QVT Issue: Support for CMOF metamodels

  • Key: QVT-66
  • Legacy Issue Number: 9397
  • Status: closed  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    The QVT spec (ptc/05-11-01) is littered with references to EMOF but has not one reference to CMOF.
    Hence it's not clear whether QVT can be used to transform models that instantiate CMOF metamodels. This is a major requirement since UML2 is itself a CMOF metamodel.

    Note that it's not important here that the QVT metamodel itself is expressed only in EMOF: but that it can be applied to CMOF metamodels. This means that references such as ObjectTemplateExp::referredClass(from EMOF) (see Fig 7.6) should also support references to CMOF metaclasses. Though CMOF is a compatible extension of EMOF, it is important that the QVT specification makes it clear that references to CMOF classes must be supported and that compliant QVT engines should not lose information when they transform models for CMOF metamodels. This is also likely to requires changes to the specification logic that describes the execution of transformations - for example to fully support non-unique Associations.

  • Reported: QVT 1.0b1 — Fri, 24 Feb 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    (1) Add a new top-level section named "QVT for CMOF" with the following content:

    For the sake of simplicity all previous chapters assume QVT used in the context of EMOF conformant metamodels. However this specification is also applicable to CMOF metamodels with a few restrictions.

    11.1 The QVT metamodel for CMOF

    The QVT metamodel for CMOF is a CMOF metamodel that is obtained by executing the following steps:

    The EMOF package is replaced by the CMOF Package.
    All other packages - including the EssentialOCL - are cloned, with the exception that all references to the original EMOF metaclasses are replaced by references to the corresponding CMOF metaclass.

    11.2 Semantic specificities

    The semantics of CMOF concerning the access and the modification of properties replaces the semantics of EMOF. For instance, in CMOF, setting a property that is specified as an association end implies that the corresponding association link instance is created and that any related sub-setted association is updated accordingly.

    There are some limitations when using QVT on CMOF metamodels which comes from the fact that we are cloning EssentialOCL - at the time being, the OCL specification does not define an "OCL for CMOF metamodels".

    • It is not possible to refer directly to an association; instead an association has to be accessed as a property from one of the owning classes. However, this does not address the case where both the ends of an association are owned by the association itself.

    (2) In the Compliance section 2, add a sub-section named "EMOF and CMOF compliance" after Section 2.3 Interoperability Dimension with the following content:

    A QVT tool may declare to be EMOF-compliant or CMOF-compliant (possibly both) depending on the kind of models that it is capable of working with. The same dimensions serving to characterize QVT-EMOF compliant implementations (in Figure 2.1) are applicable to QVT CMOF-compliant implementations. Note however that the XMI for an EMOF-compliant QVT tool is not the same as the XMI for a CMOF-compliant QVT tool since the XMI generation rules for CMOF are distinct from the corresponding generation rules for EMOF.

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

When and where clause for mapping operations

  • Key: QVT-63
  • Legacy Issue Number: 9392
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

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

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

  • Reported: QVT 1.0b1 — Mon, 13 Feb 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

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

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

Logging textual messages that depend on variables

  • Key: QVT-65
  • Legacy Issue Number: 9394
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

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

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

  • Reported: QVT 1.0b1 — Thu, 23 Feb 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

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

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

Inconsistency of multiplicity of ImperativeIterateExp::target

  • Key: QVT-64
  • Legacy Issue Number: 9393
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

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

  • Reported: QVT 1.0b1 — Mon, 13 Feb 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

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

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

Missing multiplicity of AnonymousLiteralPart::value

  • Key: QVT-62
  • Legacy Issue Number: 9391
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

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

  • Reported: QVT 1.0b1 — Mon, 13 Feb 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

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

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

Missing iterator variable in resolve expressions

  • Key: QVT-61
  • Legacy Issue Number: 9390
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

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

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

  • Reported: QVT 1.0b1 — Mon, 13 Feb 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    NOTE: This resolution should not be applied since superseded by resolution 10925.

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

    RESOLUTION:
    (1) In Section 8.2.1.22 (ResolveExp), define ResolveExp as a subclass
    of ImperativeLoopExp by replacing "CallExp" by "ImperativeLoopExp".
    (2) In the same section 8.2.1.22, remove the association 'condition'
    (since already contained by ImperativeLoopExp)
    (3) In Figure 8.3, remove the link ResolveExp::condition and replaces
    inheritance of ResolveExp so that it inherits from "ImperativeLoopExp"

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

Missing association from MappingParameter to a ModelParameter

  • Key: QVT-59
  • Legacy Issue Number: 9388
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

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

  • Reported: QVT 1.0b1 — Mon, 13 Feb 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    (1) In Section 8.2.1.16 (MappingParameter) add the association:
    """
    extent : ModelParameter [0..1]
    The extent of the mapping parameter. Should be explicitly provided
    when there is an ambiguity on the extent that will own a potential
    created element corresponding to this parameter.
    """
    (2) In the same section 8.2.1.16, add the "Notation" subtitle
    as follows:
    """
    Notation
    The extent of a mapping parameter can be provided explicitly
    using its name as the scope prefix of its type, using the "::"
    symbol. The declarator has the form:
    mymappingparameter : myextent::MyType.
    It is not mandatory to provide the extent when it can be inferred
    from the type.
    Example:
    transformation T(in src:S, out dest1, out dest2);
    mapping X::foo(inout dest1::Y) : dest2:Y;
    // 'X' is a class of 'S' metamodel and 'Y' is a class of 'D' metamodel
    """
    Remark: No changes are needed in the grammar since the 'declarator' rule
    already supports this syntax.

    (3) In Figure 8.1, add the correspond link between MappingParameter
    and ModelParameter.

    (4) In Section 8.2.1 (ObjectExp), within the "Notation" subtitle,
    replace:
    """When provided the model parameter is notated within brackets
    after the object keyword.
    object[srcmodel] x:X

    { ... } // x is created within the 'srcmodel
    """
    by:
    """When an explicit extent is provided, the variable name
    prefixes the type of the object expression using the "::" symbol.
    object x: srcmodel::X { ... }

    // x is created within the 'srcmodel
    """
    (this change is required for consistency with mapping parameter notation).

    (5) In Section 8.2.2.23 (InstantiationExp), within the "Notation" subtitle,
    replace:
    """
    When provided the extent is notated by adding the variable name in brackets after the new keyword.
    column := new [mymodel] Column(n,t); // mymodel is the extent for the new instance.
    """

    by:
    """When an explicit extent is provided, the variable name
    prefixes the type of the instantiation expression using the "::" symbol.
    column := new mymodel::Column(n,t); // mymodel is the extent for the new instance.
    """

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

Missing variable references within inlined object expressions

  • Key: QVT-60
  • Legacy Issue Number: 9389
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

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

    Suggestion:
    Adding the association:
    OperationBody::variable : [*] Variable

    {composes}

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

  • Reported: QVT 1.0b1 — Mon, 13 Feb 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

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

    {composes}

    The variables defined implicitly within this operation body.
    This concerns implicit variables in object expressions (ObjectExp).
    """
    (2) In Section 8.2.1.24, replace "referredObject: Variable [0..1]"
    by "referredObject: Variable [1]"
    (3) In figure 8.2 add the "OperationBody::variable Variable" unidirectional
    link
    (4) In figure 8.3 change multiplicity of ObjectExp::referredObject to '1'.

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

Typo error ImperativeIteratorExp expected in diagram

  • Key: QVT-58
  • Legacy Issue Number: 9387
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

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

  • Reported: QVT 1.0b1 — Mon, 13 Feb 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    Duplicate of issue 9254, close

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

Entry operations in operational definitions

  • Key: QVT-57
  • Legacy Issue Number: 9386
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

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

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

  • Reported: QVT 1.0b1 — Mon, 13 Feb 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    In Section 8.2.1.1 (OperationalTransformation),
    remove the association "entry : EntryOperation [0..1]" and
    in Section 8.2.1.3 (Module) inserts the association "entry : Operation [0..1]".
    In Figure 8.1, make the corresponding move of the 'entry' link.

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

isTopLevel should not be a derived property

  • Key: QVT-56
  • Legacy Issue Number: 9385
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

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

  • Reported: QVT 1.0b1 — Mon, 13 Feb 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    (1) In 7.11.3.1, replace "/isTopLevel : Boolean" by "isTopLevel : Boolean".
    and remove the sentence "This is a derived attribute."
    (2) In Figure 7.7 replace "/isTopLevel" by "isTopLevel"

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

RelationalTransformation as a subclass of Transformation

  • Key: QVT-55
  • Legacy Issue Number: 9383
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

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

    Suggestion: Add a RelationalTransformation metaclass inheriting
    from Transformation and add the missing association:
    'RelationalTransformation::key : [*] Key

    {composes}

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

  • Reported: QVT 1.0b1 — Mon, 13 Feb 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    (1) In section 7.11.3 insert the definition of the "RelationTransformation"
    class with the following description:
    """
    A RelationalTransformation is a specialization of a Transformation
    representing a transformation definition that uses the QVT-Relation
    formalism.
    Superclasses
    Transformation (from BaseQVT)
    Associations
    key : [*] Key

    {composes}

    The keys defined within this transformation.
    """
    (2) In Figure 7.7 inserts the class "RelationTransformation" inheriting
    from "Transformation" and adds the link to the "Key" class

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

Typo error for properties whenOwner and whereOwner

  • Key: QVT-54
  • Legacy Issue Number: 9382
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

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

  • Reported: QVT 1.0b1 — Mon, 13 Feb 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

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

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

Bad navigability in cross-package links

  • Key: QVT-53
  • Legacy Issue Number: 9381
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

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

  • Reported: QVT 1.0b1 — Mon, 13 Feb 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    (1) In Figure 7.4 make unidirectional the link Transformation::ownedTag
    (2) In Figure 8.1
    make unidirectional the link Module::ownedTag
    make unidirectional the link Module::configProperty
    (3) In Figure 8.6
    make unidirectional the link TryExp::tryBody
    (4) In Figure 8.5
    make unidirectional the link ComputeExp::returnedElement

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

Revise the encoding of primitive domains

  • Key: QVT-52
  • Legacy Issue Number: 9380
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

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

  • Reported: QVT 1.0b1 — Mon, 13 Feb 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    (1) In Section 7.11.1.3, replace "typedModel: TypedModel [1]"
    by "typedModel: TypedModel [0..1]"
    In figure 7.4 change the corresponding multiplicity.

    (2) In 7.11.3.2, replace "/typedModel: TypedModel [1] (from Domain)"
    by "/typedModel: TypedModel [0..1] (from Domain)"
    and replace "pattern: DomainPattern [1]

    {composes}"
    by "pattern: DomainPattern [0..1] {composes}

    "
    Make the corresponding change in figure 7.7.

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

Page 131

  • Key: QVT-50
  • Legacy Issue Number: 9255
  • Status: closed  
  • Source: Hewlett Packard Enterprise ( Susan Entwisle)
  • Summary:

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

  • Reported: QVT 1.0b1 — Thu, 19 Jan 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

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

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

Incorrect composition of variables in patterns

  • Key: QVT-51
  • Legacy Issue Number: 9379
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

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

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

  • Reported: QVT 1.0b1 — Mon, 13 Feb 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

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

    {composes}"
    by "bindsTo: Variable [*]"
    and in Figure 7.5 removes the corresponding composition symbol

    (2) In 7.11.2.1 replaces "bindsTo: Variable [0..1] {composes}

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

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

Page 117

  • Key: QVT-48
  • Legacy Issue Number: 9253
  • Status: closed  
  • Source: Hewlett Packard Enterprise ( Susan Entwisle)
  • Summary:

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

  • Reported: QVT 1.0b1 — Thu, 19 Jan 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    closed no change

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

Page 45 and 165

  • Key: QVT-47
  • Legacy Issue Number: 9252
  • Status: closed  
  • Source: Hewlett Packard Enterprise ( Susan Entwisle)
  • Summary:

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

  • Reported: QVT 1.0b1 — Thu, 19 Jan 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    In the introductory text of section 7.11 and sections 9.7
    add the following paragraph (similar to paragraph found in 8.2):

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

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

Page 118

  • Key: QVT-49
  • Legacy Issue Number: 9254
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: QVT 1.0b1 — Thu, 19 Jan 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

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

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

Page 30

  • Key: QVT-46
  • Legacy Issue Number: 9251
  • Status: closed  
  • Source: Hewlett Packard Enterprise ( Susan Entwisle)
  • Summary:

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

  • Reported: QVT 1.0b1 — Thu, 19 Jan 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    closed no change

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

Page 28

  • Key: QVT-45
  • Legacy Issue Number: 9250
  • Status: closed  
  • Source: Hewlett Packard Enterprise ( Susan Entwisle)
  • Summary:

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

  • Reported: QVT 1.0b1 — Thu, 19 Jan 2006 05:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    In section 6.2, page 25, replaces the sentence
    "The plugin implementation has access to object references in models,
    and may do arbitrary things to those objects." by:

    "The plugin implementation has access to object references in models,
    and may do arbitrary things to those objects, possibly breaking
    encapsulation".

  • Updated: Fri, 6 Mar 2015 22:36 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

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

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

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

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

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

Not possible to remove from a mutable List

  • Key: QVT12-15
  • Legacy Issue Number: 19095
  • Status: closed  
  • Source: Heinz Nixdorf Institute, University of Paderborn ( Christopher Gerking)
  • Summary:

    A List is a mutable type. However, there is only an interface for adding to a List, not for removing from a List. Analogously to the operation

    List(T)::add(T) : Void

    there should be something like:

    List(T)::remove(T) : Void

  • Reported: QVT 1.1 — Tue, 19 Nov 2013 05:00 GMT
  • Disposition: Resolved — QVT 1.2
  • Disposition Summary:

    Duplicates in part Issue 13251.
    Disposition: See issue 19146 for disposition

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

Specify List::reject and other iterations

  • Key: QVT12-18
  • Legacy Issue Number: 19146
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The current specification of List has a vague claim that all OCL Collection operations are available.

    Are iterations available?

    Are Sequence operations and iterations not available?

    Are return types adjusted to List?

    The specification needs to provide a clear model defining all the operations and iterations.

  • Reported: QVT 1.1 — Wed, 18 Dec 2013 05:00 GMT
  • Disposition: Resolved — QVT 1.2
  • Disposition Summary:

    Specifying the operations is straightforward, but highlights some nasty inconsistencies such as two
    versions of insertAt.
    The OCL 2.4 operations are included.
    From Issue 13223 clarify wording of insertAt:
    From Issue 13251 add remove operations.
    A model must wait till OCL 2.5 provides an extensible library model

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

clause 8.3.1.4 Exception needs to document the taxonomy of Exception types in QVT1.1

  • Key: QVT12-9
  • Legacy Issue Number: 15978
  • Status: closed  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    In particular, this taxonomy should explicitly include the AssertionFailed exception type that clause 8.2.2.20 refers to for an AssertExp.
    Suggest defining a String message attribute for Exception; this would facilitate retrieving the message from a raise expression (clause 8.2.2.15)
    Suggest defining AssertionFailed as a subtype of Exception.
    Suggest defining 2 attributes in AssertionFailed corresponding to the severity and log expressions of the AssertExp (clause 8.2.2.20)

  • Reported: QVT 1.1 — Fri, 21 Jan 2011 05:00 GMT
  • Disposition: Resolved — QVT 1.2
  • Disposition Summary:

    Yes. We need a toxonomy.
    At the root is clearly Exception and this needs no parameters.
    We need to introduce a derived StringException for the standard string-valued RaiseExp, and oops we
    need to modify the grammar to support this shorthand.
    The LogExp-valued AssertionFailed is another derivation of Exception; no severity since it is always
    fatal.

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

Consider submitting the QVTO profile out of UML Profile for NIEM, section 9-2 to QVT 1.2

  • Key: QVT12-10
  • Legacy Issue Number: 17538
  • Status: closed  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    Section 9-2 in the UML Profile for NIEM Beta2 document describes an interesting diagrammatic notation for describing the salient organization of a QVTO transformation.

    Based on the notation shown in figures 9-2, 9-3, 9-4 and others, this notation clearly involves some kind of UML profile for describing a QVTO transformation whose stereotypes
    include <<OperationalTransformation>>, <<MappingOperation>>, <<disjuncts>> and <<inherits>>. The figures in section 9 make a compelling illustration of the utility of a UML Profile for QVTO Transformation.
    I believe this UML profile for QVTO is a novel contribution of the UML Profile for NIEM FTF; unfortunately, the document does not describe it and this QVTO Transformation profile
    is not mentioned anywhere in the UML Profile for NIEM inventory or in any of the machine readable artifacts.

  • Reported: QVT 1.1 — Fri, 3 Aug 2012 04:00 GMT
  • Disposition: Resolved — QVT 1.2
  • Disposition Summary:

    No Data Available

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

Resolve expressions without source variable

  • Key: QVT12-16
  • Legacy Issue Number: 19096
  • Status: closed  
  • Source: Heinz Nixdorf Institute, University of Paderborn ( Christopher Gerking)
  • Summary:

    In contrast to 8.2.1.23 ResolveInExp, the prior section 8.2.1.22 ResolveExp does not explicitly state whether the source variable is optional for resolve expressions. For Eclipse QVTo, this leads to the situation the source variable is assumed to be mandatory. Consequently, the resolve expression in following snippet is invalid in Eclipse:

    var p : EPackage = resolveone(EPackage);

    I don't think that this restriction is desirable from the specification viewpoint.

    Eclipse bugzilla: https://bugs.eclipse.org/bugs/show_bug.cgi?id=392156

  • Reported: QVT 1.1 — Tue, 19 Nov 2013 05:00 GMT
  • Disposition: Resolved — QVT 1.2
  • Disposition Summary:

    The resolve needs a domain in which to search for target objects. For ResolveInExp this can be the
    traces of a designated mapping. For ResolveExp it would seem that some source objects must be
    supplied. However there seems no reason to prohibit a search everywhere and this could be achieved
    by specifying Element.allInstances(). Therefore an omitted ResolveExp sources can mean search all
    traces.

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

QVT atomicity

  • Key: QVT12-12
  • Legacy Issue Number: 18572
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Clause 7.7 mandates fixed-point semantics for in-place transformations.

    Please ask my bank to use a repeat-until-no-change in-place transformation for my next pay cheque:

    new-balance = old-balance + deposit.

    More seriously, the repeat is at the relation level, so if there are multiple applicable relations, the in-place result is specified to experience multiple updates in an indeterminate order. If relation A and then relation B are repeated to exhaustion, is relation A repeated again to accommodate relation B's changes?

    Start again. QVTr and QVTc are declarative, therefore they express a single complex truth about the final outputs with respect to the original inputs. There are no observable intermediate steps. It is the responsibility of the transformation engine to ensure that the multiple actual output changes are observed as a single atomic transaction. In particular for in-place transformations, the engine must ensure that no input value is accessed after it is updated for output.

    In regard to fixed-point semantics, repetition can only be determinate if it is the entire tranformation that is repeated, and whether to do so would seem to be a legitimate execution option. Therefore QVT should either not specify repetition at all, leaving it to the invoking engine, or specify it as an invocation option for a RelationCallExp.

    If an in-place transformation does perform fixed-point repetition at the transformation level, it would seem that the whole repetition should still be a single atomic transaction so that outputs are never observable in an inconsistent partially transformed state between iterations. The engine must therefore iterate over candidate outputs rather than actual outputs.

  • Reported: QVT 1.1 — Thu, 21 Mar 2013 04:00 GMT
  • Disposition: Resolved — QVT 1.2
  • Disposition Summary:

    Fixed point semantics can be achieved by a has-it-changed loop.

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

ObjectExp Abstract Syntax misses a ConstructorBody

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

    Problem:

    ObjectExp enhances an InstationExp with additional abstract syntax and semantics what respect to the association of the object to be created/updated to a variable.

    Likewise, the object expression provides concrete syntax to specify the set of expressions to be executed in order to intialize/update the properties of the object to be created. However this is not reflected in the abstract sytanx.

    Discussion:
    Indeed, ObjectExp should contain a containment reference to comprise the block of expressions used to initialize/update the object properties.

    The best AS candidate is ConstructorBody. Note that this is supported by the own description of the ConstructorBody (section 8.2.1.18):

    "A constructor body contains the implementation of a constructor operation or the implementation of an inline constructor
    (see ObjectExp)."

    This ConstructorBody should be optional, as a result of an enhancement I'll raise in a different issue.

    Proposed resolution:

    Add the following association to ObjectExp in section 8.2.1.24

    body: ConstructorBody [0..1]

    {composes}

    The object expression body comprising the expressions to initialize (or update) the properties of the object to be instantiated (or updated).

  • Reported: QVT 1.1 — Wed, 23 Oct 2013 04:00 GMT
  • Disposition: Resolved — QVT 1.2
  • Disposition Summary:

    The required association is already shown in Fig 8.3; just need to add the missing text

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

Imprecise result types of resolveIn expressions

  • Key: QVT12-17
  • Legacy Issue Number: 19121
  • Status: closed  
  • Source: Heinz Nixdorf Institute, University of Paderborn ( Christopher Gerking)
  • Summary:

    Section 8.2.1.22 ResolveExp states the following about the result type of a resolve expression:

    "If no target variable is provided, the type is either Object (the type representing all types, see Section 8.3.1) either a Sequence of Objects - depending on the multiplicity."

    On top of that, Section 8.2.1.23 ResolveInExp states:

    "The type of a ResolveInExp expression is computed using the same rules as for the type of a ResolveExp."

    In case of a ResolveInExp, why can't we obtain the result type from the respective mapping?

    Consider the following example

    mapping EClass :: EClass2EPackage() : EPackage

    The result of any resolveIn expression for that mapping is necessarily a subtype of EPackage. No need to cast this up to Object.

  • Reported: QVT 1.1 — Fri, 22 Nov 2013 05:00 GMT
  • Disposition: Resolved — QVT 1.2
  • Disposition Summary:

    OclAny rather Object is of course the top type

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

Inconsistent description about constructor names

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

    Problem:

    Specification first says in the Constructor concept description:

    "The name of the constructor is usually the name of the class to be
    instantiated. However this is not mandatory. Giving distinct names allows having more than one constructor."

    Later on in the Constructor notation:

    "The name of the constructor is necessarily the name of the context type"

    This is inconsistent.

    Discussion:
    Indeed, the notation section statement seems to be correct since:
    1. Looks like other programming languages, like Java.
    2. More importantly, the instantiation expression would not be so obvious when constructing new objects, and would required to be changed.

    Example:

    If we have the following constructors:

    constructor MyClass::MyClassConstructor(name : String)

    { name := name }

    constructor MyClass::MyClass(name : String)

    { name := name + "v2" }

    How can the instantiation expression refer the different constructor ?

    • new MyClass("abc")
    • new MyClassConstructor("abc")
    • new MyClass::Constructor("abc")

    The referred class in a InstantiationExp would not be enough. Changing instantiation expression to provide different name constructor doesn't seem sensible.

    Proposed solution:

    In section 8.2.1.13

    Replace:

    "A constructor does not declare result parameters. The name of the constructor is usually the name of the class to be
    instantiated. However this is not mandatory. Giving distinct names allows having more than one constructor."

    by

    "A constructor does not declare result parameters and its name must be the name of the class to be instantiated."

  • Reported: QVT 1.1 — Wed, 23 Oct 2013 04:00 GMT
  • Disposition: Resolved — QVT 1.2
  • Disposition Summary:

    This was discussed on https://bugs.eclipse.org/bugs/show_bug.cgi?id=421621.
    Unless we abandon constructor diversity completely, the current AS imposes a needless
    implementation difficulty by requiring dynamic resolution of a statically known constructor. This can be
    avoided by augmenting InstantiationExp.instantiatedClass with
    InstantiationExp.initializationOperation , which can refer to any statically determined constructor. We
    can therefore relax the contradictory restrictions on constructor name spelling.
    Unfortunately Constructor is not available in ImperativeOCL. Promoting Constructor to ImperativeOCL
    would appear easy, unfortunately its superclass ImperativeOperation is also not available. Promoting
    ImperativeOperation requires … too hard. So we must instead introduce InstantiationExp.
    initializationOperation and redefine it in ObjectExp.

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

Intermediate data not allowed for libraries

  • Key: QVT12-11
  • Legacy Issue Number: 18325
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The QVT spec says that "an operational transformation may use for its definition intermediate classes and intermediate properties."

    Is intermediate data actually restricted to plain transformations? In other words, is intermediate data unsupported for libraries? The eclipse QVTo implementation sticks to this interpretation and actually supports intermediate data only for plain transformations, which is a limitation I don't see a reason for.

  • Reported: QVT 1.1 — Thu, 27 Dec 2012 05:00 GMT
  • Disposition: Resolved — QVT 1.2
  • Disposition Summary:

    No Data Available

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

Rule Overriding in QVTr

  • Key: QVT12-6
  • Legacy Issue Number: 15524
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    You have reached the edge of the specification as written.

    1: Yes
    2: Yes
    3: Yes
    4: Yes

    I gave some consideration to this for UMLX.

    I felt that an abstract 'rule' could define a 'subrule' obligation, which would require an identical match signature, since if the override was narrower it would not fulfill the obligation and if it was wider the additional width would not be permitted by the invocation of the abstract 'rule'.

    I felt that all concrete rules should always be matched to ensure that addition of extended functionality did not change previous behaviour. This complies with UMLX's all maximal matches philosophy. Keys in QVTr, Evolution Ids in UMLX can ensure that derived rules reuse inherited matches.

    I think a transformation being both a package and a class introduces some difficult compatibility issues to be studied.

    Transformation extension is also poorly defined giving additional imprecision when considering the combination of transformation extension and rule override.

    My ideas for UMLX were not complete but I think that they may be sounder than QVTr's.

  • Reported: QVT 1.1 — Fri, 13 Aug 2010 04:00 GMT
  • Disposition: Resolved — QVT 1.2
  • Disposition Summary:

    This issue was inadvertently raised from Issue 15417 correspondence. Close it as merged even though
    Issue 15417 needs further work.
    Disposition: See issue 15417 for disposition

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

Figure 7.3

  • Key: QVT12-5
  • Legacy Issue Number: 15424
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    I am confused by something in the MOF QVT specification (version 1.1) and am not sure if it’s an error or my own misunderstanding. Figure 7.3 (p. 24) has links from two instances of ObjectTemplateExp to a single instance of PropertyTemplateItem (the one in the middle). Figure 7.6 (p. 30) shows a composite association between ObjectTemplateExp and PropertyTemplateItem. Why then are there two links to the instance in Figure 7.3? Doesn’t a composite association mean that a PropertyTemplateItem can be owned by only one ObjectTemplateExp?

  • Reported: QVT 1.1 — Tue, 3 Aug 2010 04:00 GMT
  • Disposition: Resolved — QVT 1.2
  • Disposition Summary:

    The problem is that UML Object diagrams omit the decorations from instantiated relationships. Shrt of
    moving to a non-standard UMLX diagram, we can perhaps get away with some explanations.

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

abstract/concrete syntax for try/catch in clauses 8.2.2.13 & 8.2.2.14 lacks support for retrieving the exception caught

  • Key: QVT12-8
  • Legacy Issue Number: 15977
  • Status: closed  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    Current abstract/concrete syntax for try/catch in clauses 8.2.2.13 & 8.2.2.14 lacks support for retrieving the exception caught.

    That is, QVT1.1 is currently limited to the following style of try/catch logic:

    try

    { // ... } except (Exception) { // there is no syntax to bind the actual exception caught to a variable or to retrieve it in an except expression. };


    One possibility would be to introduce a variable in the catch expression (clause 8.2.2.14), e.g.:


    try { // ... }

    except (Exception e)

    { // do something with the exception caught: e }

    ;

    or:

    try

    { // ... }

    except (Exception1 e1, Exception2 e2)

    { // do something with the exception caught: e1 or e2 }

    ;

  • Reported: QVT 1.1 — Fri, 21 Jan 2011 05:00 GMT
  • Disposition: Resolved — QVT 1.2
  • Disposition Summary:

    Yes. Unuseable caught exceptions are clearly of limited utility.
    There can only be one exception variable name for many exception types; what is its type? Cannot be
    any of the listed types so it will have to be the common super type. Introduce a new exceptionVariable.
    Of course the lower bound on the exception type should be 1. If a catch all is required then the type
    can be Exception. If a finally is required then we need a wrapper or specification enhancement.

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

Please provide a non-null text in the Scope section of documents ptc/09-12-06 and ptc/09-12-05

  • Key: QVT12-2
  • Legacy Issue Number: 14835
  • Status: closed  
  • Source: Thematix Partners LLC ( Doug Tolbert)
  • Summary:

    Please provide a non-null text in the Scope section of documents ptc/09-12-06 and ptc/09-12-05

  • Reported: QVT 1.1 — Mon, 7 Dec 2009 05:00 GMT
  • Disposition: Resolved — QVT 1.2
  • Disposition Summary:

    No Data Available

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

bug in the uml to rdbms transformation example

  • Key: QVT12-7
  • Legacy Issue Number: 15917
  • Status: closed  
  • Source: laposte.net ( Xavier Dolques)
  • Summary: