Issues for MOF QVT 1.3 Revision Task Force

To comment on any of these issues, send email to [email protected]. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to [email protected].

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Jira Issues

Issue 10646: Missing explanations in BNF (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The OCL 2.0 spec has a 32 page section on concrete semantics.  QVTr has 1.5 pages of BNF but no explanation.    In particular:  What are the semantics of 'import' which has no abstract counterpart?  Where is the explanation of the role of [ '{' <oclExpressionCS> '}' ] in a <domain>?  Where is the instruction on how to treat the "_" identifier?

Resolution:
Revised Text: Add a sub-section in section 7.13 with the following content: The mapping is specified using attribute grammar similar to how OCL' concrete to abstract syntax mapping is specified. topLevelCS topLevelCS ::= importListCS? transformationListCS? Abstract syntax mapping topLevelCS.ast : Set(RelationalTransformation) Synthesized attributes topLevelCS.ast = TransformationListCS.ast Inherited attributes transformationListCS.env = if (importListCS.ast.notEmpty()) then Environment.EMPTY_ENV.addElement('imported transformation', importListCS.ast) else Environment.EMPTY_ENV endif importListCS importListCS[1] ::= 'import' unitCS ';' importListCS[2]? Abstract syntax mapping importListCS[1].ast : Set(RelationalTransformation) Synthesized attributes importListCS[1].ast = unitCS.ast->union(importListCS[2].ast) unitCS unitCS ::= identifierCS ('.' identifierCS)* Abstract syntax mapping unitCS.ast : Set(RelationalTransformation) Synthesized attributes <left unspecified> The dot separated identifiers identify a compilation unit that is expected to contain transformation specifications. As explained in section 7.13.1 of the spec, how the dot separated identifiers are mapped to, say, a file system hierarchy is implementation specific. transformationListCS transformationListCS[1] ::= transformationCS transformationListCS[2]? Abstract syntax mapping transformationListCS[1].ast : Set(RelationalTransformation) Synthesized attributes transformationListCS[1].ast = Set{transformationCS.ast}->union(transformationListCS[2].ast) Inherited attributes transformationCS[1].env = transformationListCS[1].env transformationListCS[2].env = transformationListCS[1].env transformationCS transformationCS ::= 'transformation' identifierCS[1] '(' modelDeclListCS ')' ('extends' identifierCS[2])? '{' keyDeclListCS? relQueryListCS? '}' Abstract syntax mapping transformationCS.ast : RelationalTransformation Synthesized attributes transformationCS.ast.name = identifierCS[1].ast transformationCS.ast.modelParameter = modelDeclListCS.ast if (not identifierCS[2].ast.oclIsUndefined()) then transformationCS.ast.extends = let importedTransformationSet:Set(RelationalTransformation) = transformationCS.env.lookup('imported transformations').referredElement.oclAsType(SetType) in importedTransformationSet->any(t | t.name = identifierCS[2].ast) endif transformationCS.ast.rule = relQueryListCS->select(r | r.OclIsTypeOf(Relation)) transformationCS.ast.ownedOperation = relQueryListCS->select(r | r.OclIsTypeOf(Function)) transformationCS.ast.ownedKey = keyDeclListCS.ast Inherited attributes identifierCS[1].env = transformationCS.env modelDeclListCS.env = transformationCS.env identifierCS[2].env = transformationCS.env let env:Environment = transformationCS.env.addElement('context transformation', transformationCS.ast) in keyDeclListCS.env = env and relQueryListCS.env = env modelDeclListCS modelDeclListCS[1] ::= modelDeclCS (',' modelDeclListCS[2])? Abstract syntax mapping modelDeclListCS[1].ast : Sequence(TypedModel) Synthesized attributes modelDeclListCS[1].ast = Sequence{modelDeclCS.ast}->union(modelDeclListCS[2].ast) Inherited attributes modelDeclCS.env = modelDeclListCS[1].env modelDeclListCS[2].env = modelDeclListCS[1].env keyDeclListCS keyDeclListCS[1] ::= keyDeclCS keyDeclListCS[2]? Abstract syntax mapping keyDeclListCS[1].ast : Set(Key) Synthesized attributes keyDeclListCS[1].ast = Set{keyDeclCS.ast}->union(keyDeclListCS[2].ast) Inherited attributes keyDeclCS.env = keyDeclListCS[1].env keyDeclListCS[2].env = keyDeclListCS[1].env relQueryListCS relQueryListCS[1] ::= relQueryCS relQueryListCS[2]? Abstract syntax mapping relQueryListCS[1].ast : Set(ModelElement) Synthesized attributes relQueryListCS[1].ast = Set{relQueryCS.ast}->union(relQueryListCS[2].ast) Inherited attributes relQueryCS.env = relQueryListCS[1].env relQueryListCS[2].env = relQueryListCS[1].env relQueryCS [A] relQueryCS ::= relationCS [B] relQueryCS ::= queryCS Abstract syntax mapping relQueryCS.ast : ModelElement Synthesized attributes [A] relQueryCS.ast = relationCS.ast [B] relQueryCS.ast = queryCS.ast Inherited attributes [A] relationCS.env = relQueryCS.env [B] queryCS.env = relQueryCS.env modelDeclCS modelDeclCS ::= modelIdCS ':' metaModelIdCS Abstract syntax mapping modelDeclCS.ast : TypedModel Synthesized attributes modelDeclCS.ast.name = modelIdCS.ast modelDeclCS.ast.usedPackage = metaModelIdCS.ast Inherited attributes modelIdCS.env = modelDeclCS.env metaModelIdCS.env = modelDeclCS.env modelIdCS modelIdCS ::= identifierCS Abstract syntax mapping modelIdCS.ast : String Synthesized attributes modelIdCS.ast = identifierCS.ast metaModelIdCS metaModelIdCS ::= identifierCS Abstract syntax mapping metaModelIdCS.ast : Package Synthesized attributes metaModelIdCS.ast = loadMetaModelPackage(identifierCS.ast) // How the package is located and loaded is tool specific and so left unspecified. keyDeclCS keyDeclCS ::= 'key' classIdCS '{' keyPropertyListCS '}' ';' Abstract syntax mapping keyDeclCS.ast : Key Synthesized attributes keyDeclCS.ast.identifies = classIdCS.ast keyDeclCS.ast.part->union(keyDeclCS.ast.oppositePart) = keyPropertyListCS.ast Inherited attributes classIdCS.env = keyDeclCS.env keyPropertyListCS.env = keyDeclCS.env.addElement('context key', keyDeclCS.ast) keyPropertyListCS keyPropertyListCS[1] ::= keyPropertyCS (',' keyPropertyListCS[2])? Abstract syntax mapping keyPropertyListCS[1].ast : Set(Property) Synthesized attributes keyPropertyListCS[1].ast : Set{keyPropertyCS.ast}->union(keyPropertyListCS[2].ast) Inherited attributes keyPropertyCS.env = keyPropertyListCS[1].env keyPropertyListCS[2].env = keyPropertyListCS[1].env classIdCS classIdCS ::= pathNameCS Abstract syntax mapping classIdCS.ast : Class Synthesized attributes classIdCS.ast = let trans:RelationalTransformation = classIdCS.env.lookup('context transformation'). referredElement.oclAsType(RelationalTransformation) in trans.lookupClassName(pathNameCS.ast) keyPropertyCS [A] keyPropertyCS ::= identifierCS [B] keyPropertyCS ::= 'opposite' '(' classIdCS '.' identifierCS ')' Abstract syntax mapping: keyPropertyCS.ast : Property Synthesized attributes: [A] keyPropertyCS.ast = let cls:Class = keyPropertyCS.env.lookup('context key'). referredElement.oclAsType(Key).identifies in cls.lookupProperty(identifierCS.ast) keyPropertyCS.env.lookup('context key').referredElement.oclAsType(Key). part->includes(keyPropertyCS.ast) [B] keyPropertyCS.ast = classIdCS.ast.lookupProperty(identifierCS.ast) keyPropertyCS.env.lookup('context key').referredElement.oclAsType(Key). oppositePart->includes(keyPropertyCS.ast) Inherited attributes: [B] classIdCS.env = keyPropertyCS.env relationCS relationCS ::= topQualifierCS? 'relation' identifierCS[1] ('overrides' identifierCS[2])? '{' varDeclListCS? domainListCS whenCS? whereCS? '}' Abstract syntax mapping relationCS.ast : Relation Synthesized attributes relationCS.ast.isTopLevel = if (not topQualifierCS.ast.oclIsUndefined() and topQualifierCS.ast = 'top') then true else false endif relationCS.ast.name = identifierCS[1].ast if (not identifierCS[2].ast.oclIsUndefined()) then relationCS.ast.overrides = let currTrans:RelationTransformation = relationCS.env.lookup('context transformation'). referredElement.oclAsType(RelationalTransformation) in currTrans.extends.rule->any(r | r.name = identifierCS[2].ast) endif relationCS.ast.variable = varDeclListCS.ast->union( domainListCS->iterate(d:RelationDomain; domainVars:Set(Variable)={} | domainVars->including(d.rootVariable)) ) relationCS.ast.domain = domainListCS.ast relationCS.ast.when = whenCS.ast relationCS.ast.where = whereCS.ast Inherited attributes let env:Environment = relationCS.env.addElement('context relation', relationCS.ast) in varDeclListCS.env = env domainListCS.env = env whenCS.env = env whereCS.env = env topQualifierCS topQualifierCS ::= 'top' Abstract syntax mapping topQualifierCS.ast : String Synthesized attributes topQualifierCS.ast = 'top' varDeclListCS varDeclListCS[1] ::= varDeclarationCS varDeclListCS[2]? Abstract syntax mapping varDeclListCS[1].ast : Set(Variable) Synthesized attributes varDeclListCS[1].ast ::= varDeclarationCS.ast->union(varDeclListCS[2].ast) Inherited attributes varDeclarationCS.env = varDeclListCS[1].env varDeclListCS[2].env = varDeclListCS[1].env varDeclarationCS varDeclarationCS ::= varListCS ':' TypeCS ';' Abstract syntax mapping varDeclarationCS.ast : Set(Variable) Synthesized attributes varDeclarationCs.ast->size() = varListCS.ast->size() varListCS.ast->forAll(vn | varDeclarationCS.ast->exists(v | v.name = vn and v.type = TypeCS.ast) ) Inherited attributes TypeCS.env = varDeclarationCS.env varListCS varListCS[1] ::= identifierCS (',' varListCS[2])? Abstract syntax mapping varListCS[1].ast : Set(String) Synthesized attributes varListCS[1].ast : Set{identifierCS.ast}->union(varListCS[2].ast) domainListCS domainListCS[1] ::= domainCS domainListCS[2]? Abstract syntax mapping domainListCS[1].ast : Sequence(RelationDomain) Synthesized attributes domainListCS[1].ast = Sequence{domainCS.ast}->union(domainListCS[2].ast) Inherited attributes domainCS.env = domainListCS[1].env domainListCS[2].env = domainListCS[1].env domainCS domainCS[A] ::= modelDomainCS domainCS[B] ::= primitiveDomainCS Abstract syntax mapping domainCS.ast : RelationDomain Synthesized attributes [A] domainCS.ast = modelDomainCS.ast [B] domainCS.ast = primitiveDomainCS.ast Inherited attributes [A] modelDomainCS.env = domainCS.env [B] primitiveDomainCS.env = domainCS.env modelDomainCS modelDomainCS ::= checkEnforceQualifierCS? 'domain' modelIdCS templateCS ('implementedby' OperationCallExpCS)? ('default_values' '{' assignmentExpListCS '}')? ';' Abstract syntax mapping modelDomainCS.ast : RelationDomain Synthesized attributes if (checkEnforceQualifierCS.ast.oclIsUndefined()) then modelDomainCS.ast.isCheckable = false and modelDomainCS.ast.isEnforceable = false else if (checkEnforceQualifierCS.ast = 'checkonly') then modelDomainCS.ast.isCheckable = true and modelDomainCS.ast.isEnforceable = false else modelDomainCS.ast.isCheckable = true and modelDomainCS.ast.isEnforceable = true endif endif modelDomainCS.ast.typedModel = modelDomainCS.env.lookup('context transformation').modelParameter-> any(t | t.name = modelIdCS.ast) modelDomainCS.ast.pattern.templateExpression = templateCS.ast modelDomainCS.ast.rootVariable = templateCS.ast.bindsTo if (not OperationCallExpCS.ast.oclIsUndefined()) then let rel:Relation = modelDomainCS.env.lookup('context relation'). referredElement.oclAsType(Relation) in rel.operationalImpl.impl = OperationCallExpCS.ast.referredOperation and rel.operationalImpl.inDirectionOf = modelDomainCS.ast.typedModel endif if (assignmentExpListCS.ast.notEmpty()) then modelDomainCS.ast.defaultAssignment = assignmentExpListCS.ast endif Inherited attributes let env:Environment = modelDomainCS.env.addElement('context domain', modelDomainCS.ast) in templateCS.env = env OperationCallExpCS.env = env assignmentExpListCS.env = env primitiveTypeDomainCS primitiveTypeDomainCS ::= 'primitive' 'domain' identifierCS ':' TypeCS ';' Abstract syntax mapping primitiveTypeDomainCS.ast : RelationDomain Synthesized attributes primitiveTypeDomainCS.ast.rootVariable.name = identifierCS.ast primitiveTypeDomainCS.ast.rootVariable.type = TypeCS.ast Inherited attributes TypeCS.env = primitiveTypeDomainCS.env checkEnforceQualifierCS [A] checkEnforceQualifierCS ::= 'checkonly' [B] checkEnforceQualifierCS ::= 'enforce' Abstract syntax mapping checkEnforceQualifierCS.ast : String Synthesized attributes [A] checkEnforceQualifierCS.ast = 'checkonly' [B] checkEnforceQualifierCS.ast = 'enforce' templateCS [A] templateCS ::= objectTemplateCS ('{' OclExpressionCS '}')? [B] templateCS ::= collectionTemplateCS ('{' OclExpressionCS '}')? Abstract syntax mapping templateCS.ast : TemplateExp Synthesized attributes [A] templateCS.ast = objectTemplateCS.ast if (not OclExpressionCS.ast.oclIsUndefined()) then templateCS.ast.where = OclExpressionCS.ast endif [B] templateCS.ast = collectionTemplateCS.ast if (not OclExpressionCS.ast.oclIsUndefined()) then templateCS.ast.where = OclExpressionCS.ast endif Inherited attributes [A] objectTemplateCS.env = templateCS.env OclExpressionCS.env = templateCS.env [B] collectionTemplateCS.env = templateCS.env OclExpressionCS.env = templateCS.env objectTemplateCS objectTemplateCS ::= identifierCS? ':' pathNameCS '{' propertyTemplateListCS? '}' Abstract syntax mapping objectTemplateCS.ast : ObjectTemplateExp Synthesized attributes let cls:Class = objectTemplateCS.env.lookup('context domain'). referredElement.typedModel.usedPackage.getEnvironmentWithoutParents(). lookupPathName(pathNameCS.ast).referredElement.oclAsType(Class) in if (not identifierCS.ast.oclIsUndefined) then objectTemplateCS.ast.bindsTo.name = identifierCS.ast and objectTemplateCS.ast.bindsTo.type = cls and objectTemplateCS.env.lookup('context relation'). referredElement.oclAsType(Relation).variable-> exists(v | v = objectTemplateCS.ast.bindsTo) endif and objectTemplateCS.ast.referredClass = cls objectTemplateCS.ast.part = propertyTemplateListCS.ast Inherited attributes propertyTemplateListCS.env = objectTemplateCS.env.addElement('context template', objectTemplateCS.ast) propertyTemplateListCS propertyTemplateListCS[1] ::= propertyTemplateCS (',' propertyTemplateListCS[2])? Abstract syntax mapping propertyTemplateListCS[1].ast : Set(PropertyTemplateItem) Synthesized attributes propertyTemplateListCS[1].ast = Set{propertyTemplateCS.ast}-> union(propertyTemplateListCS[2].ast) Inherited attributes propertyTemplateCS.env = propertyTemplateListCS[1].env propertyTemplateListCS[2].env = propertyTemplateListCS[1].env propertyTemplateCS [A] propertyTemplateCS ::= identifierCS '=' ExtOclExpressionCS [B] propertyTemplateCS ::= 'opposite' '(' classIdCS '.' identifierCS ')' '=' ExtOclExpressionCS Abstract syntax mapping: propertyTemplateCS.ast : PropertyTemplateItem Synthesized attributes: [A] propertyTemplateCS.ast.referredProperty = propertyTemplateCS.env.lookup('context template'). referredElement.oclAsType(ObjectTemplateExp). referredClass.lookupProperty(identifierCS.ast) propertyTemplateCS.ast.isOpposite = false propertyTemplateCS.ast.value = ExtOclExpressionCS.ast [A] propertyTemplateCS.ast.referredProperty = classIdCS.ast.lookupProperty(identifierCS.ast) propertyTemplateCS.ast.isOpposite = true propertyTemplateCS.ast.value = ExtOclExpressionCS.ast Inherited attributes: [A] ExtOclExpressionCS.env = propertyTemplateCS.env [B] ExtOclExpressionCS.env = propertyTemplateCS.env classIdCS.env = propertyTemplateCS.env collectionTemplateCS collectionTemplateCS ::= identifierCS? ':' CollectionTypeIdentifierCS '(' TypeCS ')' '{' (memberListCS '++' restCS)? '}' Abstract syntax mapping collectionTemplateCS.ast : CollectionTemplateExp Synthesized attributes if (CollectionTypeIdentifierCS.ast = CollectionKind::Set) then collectionTemplateCS.ast.referredCollectionType.oclIsTypeOf(SetType) else if (CollectionTypeIdentifierCS.ast = CollectionKind::Sequence) then collectionTemplateCS.ast.referredCollectionType.oclIsTypeOf(SequenceType) else if (CollectionTypeIdentifierCS.ast = CollectionKind::Bag) then collectionTemplateCS.ast.referredCollectionType.oclIsTypeOf(BagType) else if (CollectionTypeIdentifierCS.ast = CollectionKind::OrderedSet) then collectionTemplateCS.ast.referredCollectionType. oclIsTypeOf(OrderedSetType) endif endif endif endif collectionTemplateCS.ast.referredCollectionType.elementType = TypeCS.ast if (not identifierCS.ast.oclIsUndefined) then collectionTemplateCS.ast.bindsTo.name = identifierCS.ast and collectionTemplateCS.ast.bindsTo.type = collectionTemplateCS.ast.referredCollectionType and collectionTemplateCS.env.lookup('context relation'). referredElement.oclAsType(Relation).variable-> exists(v | v = collectionTemplateCS.ast.bindsTo) endif if (memberListCS->notEmpty()) then collectionTemplateCS.ast.member = memberListCS.ast endif if (not restCS.oclIsUndefined()) then collectionTemplateCS.ast.rest = restCS.ast endif Inherited attributes TypeCS.env = collectionTemplateCS.env memberListCS.env = collectionTemplateCS.env restCS.env = collectionTemplateCS.env memberListCS memberListCS[1] ::= memberCS (',' memberListCS[2])? Abstract syntax mapping memberListCS[1].ast : Sequence(OclExpression) Synthesized attributes memberListCS[1].ast = Sequence{memberCS.ast}->union(memberListCS[2].ast) Inherited attributes memberCS.env = memberListCS[1].env memberListCS[2].env = memberListCS[1].env restCS [A] restCS ::= identifierCS [B] restCS ::= '_' Abstract syntax mapping restCS.ast : Variable Synthesized attributes [A] restCS.ast = restCS.env.lookup('context relation'). referredElement.oclAsType(Relation).variable->any(v | v.name = identifierCS.ast) [B] restCS.ast.name = '_' memberCS [A] memberCS ::= identifierCS [B] memberCS ::= templateCS [C] memberCS ::= '_' Abstract syntax mapping memberCS.ast : OclExpression Synthesized attributes [A] memberCS.ast = memberCS.env.lookup('context relation'). referredElement.oclAsType(Relation).variable->any(v | v.name = identifierCS.ast) [B] memberCS.ast = templateCS.ast [C] memberCS.ast.oclIsTypeOf(Variable) memberCS.ast.oclAsType(Variable).name = '_' Inherited attributes [B] templateCS.env = memberCS.env assignmentExpListCS assignmentExpListCS[1] ::= assignmentExpCS assignmentExpListCS[2]? Abstract syntax mapping assignmentExpListCS[1].ast : Set(RelationDomainAssignment) Synthesized attributes assignmentExpListCS[1].ast = Set{assignmentExpCS.ast}-> union(assignmentExpListCS[2].ast) Inherited attributes assignmentExpListCS[2].env = assignmentExpListCS[1].env assignmentExpCS.env = assignmentExpListCS[1].env assignmentExpCS assignmentExpCS ::= identifierCS '=' OclExpressionCS ';' Abstract syntax mapping assignmentExpCS.ast : RelationDomainAssignment Synthesized attributes assignmentExpCS.ast.variable = assignmentExpCS.env.lookup('context relation'). referredElement.oclAsType(Relation).variable-> any(v | v.name = identifierCS.ast) assignmentExpCS.ast.valueExp = OclExpressionCS.ast Inherited attributes OclExpressionCS.env = assignmentExpCS.env whenCS whenCS ::= 'when' '{' predicateListCS '}' Abstract syntax mapping whenCS.ast : Pattern Synthesized attributes whenCS.ast.predicate = predicateListCS.ast Inherited attributes predicateListCS.env = whenCS.env whereCS whereCS ::= 'where' '{' predicateListCS '}' Abstract syntax mapping whereCS.ast : Pattern Synthesized attributes whereCS.ast.predicate = predicateListCS.ast Inherited attributes predicateListCS.env = whereCS.env predicateListCS predicateListCS[1] ::= predicateCS ';' predicateListCS[2]? Abstract syntax mapping predicateListCS[1].ast : Set(Predicate) Synthesized attributes predicateListCS[1].ast = Set{predicateCS.ast}->union(predicateListCS[2].ast) Inherited attributes predicateCS.env = predicateListCS[1].env predicateListCS[2].env = predicateListCS[1].env predicateCS predicateCS ::= ExtOclExpressionCS Abstract syntax mapping predicateCS.ast : Predicate Synthesized attributes predicateCS.ast.conditionExpression = ExtOclExpressionCS.ast Inherited attributes ExtOclExpressionCS.env = predicateCS.env queryCS queryCS ::= 'query' identifierCS '(' paramDeclListCS? ')' ':' TypeCS queryBodyCS Abstract syntax mapping queryCS.ast : Function Synthesized attributes queryCS.ast.name = identifierCS.ast queryCS.ast.ownedParameter = paramDeclListCS.ast queryCS.ast.type = TypeCS.ast queryCS.ast.queryExpression = queryBodyCS.ast Inherited attributes paramDeclListCS.env = queryCS.env queryBodyCS.env = queryCS.env paramDeclListCS paramDeclListCS[1] ::= paramDeclarationCS (',' paramDeclListCS[2])? Abstract syntax mapping paramDeclListCS[1].ast : Sequence(Parameter) Synthesized attributes paramDeclListCS[1].ast = Sequence{paramDeclarationCS.ast}-> union(paramDeclListCS[2].ast) Inherited attributes paramDeclarationCS.env = paramDeclListCS[1].env paramDeclListCS[2].env = paramDeclListCS[1].env paramDeclarationCS paramDeclarationCS ::= identifierCS ':' TypeCS Abstract syntax mapping paramDeclarationCS.ast : Parameter Synthesized attributes paramDeclarationCS.ast.name = identifierCS.ast paramDeclarationCS.ast.type = typeCS.ast Inherited attributes typeCS.env = paramDeclarationCS.env queryBodyCS [A] queryBodyCS ::= ';' [B] queryBodyCS ::= '{' OclExpressionCS '}' Abstract syntax mapping queryBodyCS.ast : OclExpression Synthesized attributes [B] queryBodyCS.ast = OclExpressionCS.ast Inherited attributes [B] OclExpressionCS.env = queryBodyCS.env ExtOclExpressionCS [A] ExtOclExpressionCS ::= OclExpressionCS [B] ExtOclExpressionCS ::= templateCS [C] ExtOclExpressionCS ::= RelationCallExpCS Abstract syntax mapping ExtOclExpressionCS.ast : OclExpressionCS Synthesized attributes [A] ExtOclExpressionCS.ast = OclExpressionCS.ast [B] ExtOclExpressionCS.ast = templateCS.ast [C] ExtOclExpressionCS.ast = RelationCallExpCS.ast Inherited attributes [A] OclExpressionCS.env = ExtOclExpressionCS.env [B] templateCS.env = ExtOclExpressionCS.env [C] RelationCallExpCS.env = ExtOclExpressionCS.env RelationCallExpCS RelationCallExpCS ::= (identifierCS[1] '.')? identifierCS[2] '(' argumentsCS? ')' Abstract syntax mapping RelationCallExpCS.ast : RelationCallExp Synthesized attributes RelationCallExpCS.ast.referredRelation = let trans:RelationalTransformation = if (not identifierCS[1].ast.oclIsUndefined) then RelationCallExpCS.env.lookup('imported transformation'). referredElement.oclAsType(CollectionType)-> any(t | t.name = identifierCS[1].ast) else RelationCallExpCS.env.lookup('context transformation'). referredElement.oclAsType(RelationalTransformation) endif in trans.rule->any(r | r.name = identifierCS[2].ast). oclAsType(RelationalTransformation) RelationCallExpCS.ast.argument = argumentsCS.ast Inherited attributes argumentsCS.env = RelationCallExpCS.env argumentsCS argumentsCS[1] ::= OclExpressionCS (',' argumentsCS[2])? Abstract syntax mapping argumentsCS[1].ast : Sequence(OclExpression) Synthesized attributes argumentsCS[1].ast = Sequence{OclExpressionCS.ast}->union(argumentsCS[2].ast) Inherited attributes OclExpressionCS.env = argumentsCS[1].env argumentsCS[2].env = argumentsCS[1].env Operations context RelationalTransformation::lookupClassName(names: Sequence(String)) : Class post: result = let typesPackage:Package = self.modelParameter.usedPackage->any(p| not p.getEnvironmentWithoutParents().lookupPathName(names).oclIsUndefined()) in typesPackage.getEnvironmentWithoutParents().lookupPathName(names).oclAsType(Class)
Actions taken:
February 6, 2007: received issue
April 26, 2010: closed issue

Discussion:

Resolution: Deferred    Comment:   Specifying more formally the mapping between the concrete syntax and the metamodel - as it was achieved for the OCL language - could be interesting. However it is a very time expensive task. Also, may be difficult to maintain. We prefer defer such decision to a future RTF.

Issue 10934: 9.18 Undefined syntax (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
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

Resolution: 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.
Revised Text:
Actions taken:
March 25, 2007: received issue
December 22, 2015: Duplicate or Merged
March 29, 2016: closed issue

Discussion:

It is hard to tackle this properly until we have the model-driven specification generated technology and  clear OCL grammar that OCL 2.5 will pioneer.  Disposition: Deferred

Issue 10935: 9.18 Identifiers (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
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'.

Resolution: 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.
Revised Text: In 7.13.2 replace The "_" OCL prefix convention for escaping reserved words can be used to refer to conflicting properties or class names. by Reserved words and awkward characters may be used within identifiers using OCL's underscore-prefixed-string-literal escape. e.g _'key' _'new\nline' A simple underscore prefix may also be used but is now deprecated. Delete 7.13.4 Shorthands used to invoke pre-defined operations The binary operator ?+? can be used as shorthand for the string concat operation. In 7.13.5 add Production names ending CS are defined by OCL. <identifier> :: <simpleNameCS> replace all usages of <TypeCS> by <typeCS>. In 8.4.7 after keywords add <identifier> ::= <simpleNameCS> // from OCL<STRING> ::= (#x22 StringChar* #x22) | (#x27 StringChar* #x27) // from OCL StringLiteralExpCS In 9.18 add Production names ending CS are defined by OCL. DirectionName ::= simpleNameCS MappingName ::= pathNameCS PackageName ::= pathNameCS PropertyName ::= simpleNameCS QueryName ::= pathNameCS TransformationName ::= pathNameCS VariableName ::= simpleNameCS TypeDeclaration ::= typeCS BooleanOCLExpr ::= OclExpressionCS QueryOCLExpr ::= OclExpressionCS SlotOwnerOCLExpr ::= OclExpressionCS ValueOCLExpr ::= OclExpressionCS
Actions taken:
March 25, 2007: received issue
December 22, 2015: Resolved
March 29, 2016: closed issue

Discussion:

It is hard to tackle this properly until we have the model-driven specification generated technology and  clear OCL grammar that OCL 2.5 will pioneer.  Disposition: Deferred

Issue 10936: 9.18 Undefined semantics (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
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.

Resolution: 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.
Revised Text:
Actions taken:
March 25, 2007: received issue
December 22, 2015: Deferred
March 29, 2016: closed issue

Discussion:

It is hard to tackle this properly until we have the model-driven specification generated technology that  OCL 2.5 will pioneer.  Specifically the specification defines a fixed point truth with little regard as to how this may be  achieved. The direction of references is therefore irrelevant.  Disposition: Deferred

Issue 10937: 9.18: Realized (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The concrete syntax defines 'realized', but section 10 consistently uses 'realize'.      Suggest: 'realize'      The concrete syntax defines 'realized' for a single element of a comma-separated list.  Section 10 appears to expect that 'realized' is a prefix to a comma-separated list.      Suggest: 'realize' is a comma-separated list prefix.      (semi-colon separation is available for distinct realize/not-realize.)

Resolution: Use 'realize' as a keyword in the concrete syntax. Use 'realized' as an adjective in editorial text, model names; e.g. RealizedVariable
Revised Text: In 9.18 Concrete Syntax change RealizedVariable := �realized� VariableName �:� TypeDeclaration to RealizedVariable := �realize� VariableName �:� TypeDeclaration
Actions taken:
March 25, 2007: received issue
July 15, 2014: closed issue

Discussion:

Issue 10938: 9.17 Variable composition (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Issue 9379 made Pattern.bindsTo a non-composition.      This deprives Core of any parent for its non-realized variables.      Suggest: move BottomPattern.realizedVariables to CorePattern.variables.      CorePattern.variables then composes all variables declared for the pattern. A class-type  check of RealizedVariable/Variable derives the 'isRealized' property.

Resolution: It is convenient to keep realized and unrealized variables separate to avoid unnecessary isRealized tests. Just add CorePattern.variables to compose the unrealized variables.
Revised Text: In 9.17.1 CorePattern add variable: Variable [*] {composes} {opposite corePattern:CorePattern[?]} Unrealized guard pattern variables are the unbound variables of the pattern. Unrealized bottom pattern variables may be used to factor out common expressions. In Figure 9.2 add a CorePattern to Variable composition arc for CorePattern.variable Update QVTcore models accordingly.
Actions taken:
March 25, 2007: received issue
July 15, 2014: closed issue

Discussion:

Issue 10939: 9.18 Trailing | (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

GuardPatterns and BottomPatterns with Variables but without Constraints must end with a '|'.  This is inelegant. Better to only require '|' as prefix to constraints (or to require it always).      Suggest:      GuardPattern ::= Variable ("," Variable)* ["|" (Constraint ";")+]                        similarly BottomPattern

Resolution: Simple change.
Revised Text: From 9.18 Concrete Syntax change GuardPattern ::= [Variable(�,�Variable )* �|� ] ( Constraint �;� )* BottomPattern ::= [ (Variable | RealizedVariable) (�,� ( Variable | RealizedVariable)* �|� ] ( Constraint �;� )* to GuardPattern ::= [Variable(�,�Variable )* ] [�|� ( Constraint �;� )+] BottomPattern ::= [ (Variable | RealizedVariable) (�,� ( Variable | RealizedVariable)*] [�|� ( Constraint �;� )+]
Actions taken:
March 25, 2007: received issue
July 15, 2014: closed issue

Discussion:

Issue 10940: 9.18 GuardPattern assignments (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The concrete sysntax allows guard patterns to have assignments. The abstract syntax does not.      Suggest: GuardPattern uses Predicate rather than Constraint

Resolution: Simple change
Revised Text: From 9.18 Concrete Syntax change GuardPattern ::= [Variable(�,�Variable )* �|� ] ( Constraint �;� )* to GuardPattern ::= [Variable(�,�Variable )* �|� ] ( Predicate �;� )*
Actions taken:
March 25, 2007: received issue
July 15, 2014: closed issue

Discussion:

Issue 10941: 9.18 The middle direction packages (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

A Direction defines the packages used by each direction domain.      Nothing defines the (additional) packages used by the middle area. For instance  there is no place to specify the trace class model generated by the RelationToCore  transformation. With many transformations and mappings in a QVTcore it does not  seem appropriate to overload TransformationName or MappingName as a hook to  reference the appropriate middle meta-models; different Mappings may have distinct  middle meta-models; multiple transformations may share the same middle meta-model.  (Core should be a first class programming language, not just one that supports  the eccentricities of a RelationToCore conversion.)      Suggest: a DirectionName between "where" and "(" in Mapping.      This reads very naturally:      map ...          check left (...          enforce right (...          where middle (...      But we also need to fix the Abstract Syntax. As a minimum a Mapping needs a  middle-typed-model property to capture the missing information. With this addition  a Mapping duplicates so much of a CoreDomain/Area, that it is more appropriate  to eliminate Area altogether, merging it into CoreDomain. Area is eliminated  from Mapping, and added as an additional CoreDomain referenced by the middleDomain  property.      So:      CoreDomain extends Domain          CoreDomain.variables : RealizedVariable [0..*] composed          CoreDomain.bottomPattern : BottomPattern [1] composed          CoreDomain.guardPattern : GuardPattern [1] composed      Mapping extends Rule          Rule.domain : Domain [0..*] composed (must be at least CoreDomain[3])          Mapping.specification - no change          Mapping.local - no change          Mapping.context - no change          Mapping.middle : CoreDomain [1] (must be in Rule.domain)

Resolution: The suggested changes may be convenient but they are not necessary: - the middle model can be anonymous - the middle area can be merged with the overall mapping. What is needed is a way to bind a middle metamodel to its TypedModel. This can be achieved by an anonymus direction bindng
Revised Text: In 7.11.1.2 TypedModel change A typed model specifies a named, typed parameter of a transformation. to A typed model specifies a typed parameter of a transformation. Explicit external parameters have a non-null name. An implicit parameter such as the QVTc middle model may have a null name, In 9.18 Concrete Syntax change Direction ::= DirectionName [�imports� PackageName(�,� PackageName)*] [�uses� DirectionName(�,� DirectionName)*] to Direction ::= [DirectionName] [�imports� PackageName(�,� PackageName)*] [�uses� DirectionName(�,� DirectionName)*]
Actions taken:
March 25, 2007: received issue
July 15, 2014: closed issue

Discussion:

Issue 10942: 9.18 Top-level syntax (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The concrete syntax does not specify a parsing goal.  If the first element (Transformation) is taken to be the goal, most of the rest  of the grammar is orphaned.      Suggest:      TopLevel ::= (Transformation | Mapping)*

Resolution: simple change
Revised Text: In 9.18 Concrete Syntax add TopLevel ::= (Transformation | Mapping)*
Actions taken:
March 25, 2007: received issue
July 15, 2014: closed issue

Discussion:

Issue 10943: 9.18 Anonymous Maps (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Section 10 uses anonymous maps for composed mappings. The Concrete Syntax  does not allow this. Similarly, an 'in' is not appropriate for a composed mapping.      Suggest:       ComposedMapping ::= "map" [MappingName] ["refines" MappingName] MappingPatterns      where MappingPatterns is the common part of Mapping.

Resolution: simple change
Revised Text: In 9.18 Concrete Syntax change ComposedMapping ::= Mapping to ComposedMapping ::= �map� [MappingName] [�refines� MappingName] �{� ([�check�] [�enforce�] DirectionName �(�DomainGuardPattern�)� �{� DomainBottomPattern �}� )* �where� �(� MiddleGuardPattern �)� �{� MiddleBottomPattern �}� (ComposedMapping )* �}�
Actions taken:
March 25, 2007: received issue
July 15, 2014: closed issue

Discussion:

Issue 10944: 9.18 EnforcementOperation (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

There is no concrete syntax for enforcement operations.      Suggest: a BottomPattern Constraint may also be          'create' OperationCallExpCS          'delete' OperationCallExpCS

Resolution: simple change
Revised Text: In 9.18 Concrete Syntax change BottomPattern ::= [ (Variable | RealizedVariable) (�,� ( Variable | RealizedVariable)* �|� ] ( Constraint �;� )* to BottomPattern ::= [ (Variable | RealizedVariable) (�,� ( Variable | RealizedVariable)* �|� ] ( (Constraint | EnforcementOperation) �;� )* EnforcementOperation ::= (�create� | �delete�) OperationCallExpCS
Actions taken:
March 25, 2007: received issue
July 15, 2014: closed issue

Discussion:

Issue 10945: 9.18 Typographics Issues (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Style. Use same font and presentation as 7.12.3, 8.4.      Typo. Remove '(' preceding '","' in BottomPattern.      Typo. Remove 'e' in 'Assignement'.

Resolution: Some aspects of the presentation are easily resolved, but replacing e.g. DirectionName to <directionName> is not worthwhile. These will all change to e.g. DirectionNameCS once OCL 2.5 aligned grammars are provided. The '(' is needed as part of an 'optional' for which the prevailing BNF is []. Assignement is a simple typo.
Revised Text: Throughout 9.18 Change asymmetric double quotes �...� to single quotes '...' In 9.18 Concrete Syntax change BottomPattern ::= [ (Variable | RealizedVariable) (�,� ( Variable | RealizedVariable)* �|� ] ( Constraint �;� )* to BottomPattern ::= [ (Variable | RealizedVariable) [�,� ( Variable | RealizedVariable)*] �|� ] ( Constraint �;� )* In 9.18 Concrete Syntax change Assignement ::= to Assignment ::=
Actions taken:
March 25, 2007: received issue
July 15, 2014: closed issue

Discussion:

Issue 10947: 7.13.1 Multiple transformation extension (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The concrete syntax for transformation supports multiple extension.  The abstract syntax supports only single extension.      Suggest: change the concrete syntax.

Resolution: 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.
Revised Text:
Actions taken:
March 26, 2007: received issue
November 7, 2007: closed issue

Issue 10948: 7.13.1 Qualified query name (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
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 ?

Resolution: 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.
Revised Text:
Actions taken:
March 26, 2007: received issue
November 7, 2007: closed issue

Issue 11058: Consider renaming collectselect as xcollectselect (qvt-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: This is an unpleasant but worthwhile change. Implementations may choose to provide both spellings for transitional compatibility. If collectselect changes, so too should collectselectOne, collectOne and selectOne, since their computation is imperative too.
Revised Text: Change all 9 occurrences of 'collectselect' to 'xcollectselect'. Change all 7 occurrences of 'collectselectOne' to 'xcollectselectOne'. Change all 5 occurrences of 'selectOne' to 'xselectOne'. Change all 2 occurrences of 'collectOne' to 'xcollectOne'.
Actions taken:
May 24, 2007: received issue
July 15, 2014: closed issue

Discussion:

Issue 11061: Consider using asTuple instead of tuple keyword for TupleExp (qvt-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: There is no TupleExp or asTuple() in QVT 1.0 or 1.1 but there is an asOrderedTuple() with the resolved description. So it appears that a variant of the suggested resolution made it into QVT 1.0. Disposition: Closed, No Change
Revised Text:
Actions taken:
May 24, 2007: received issue
July 15, 2014: closed issue

Discussion:

Comment:  The TupleExp metaclass can in fact be replaced by a simple operation in the standard library.    Resolution  (1)	Remove the TupleExp metaclass section description 8.2.2.21  (2)	Within section 8.3.3 add the description of a new operation named asOrderedTuple defined as:        Object::asOrderedTuple : OrderedTuple(T).             Converts the object into an ordered tuple. If the object is a already an ordered type no change is done. If the object is a OCL Tuple, the list of attributes become the anonymous content of the ordered tuple. Otherwise, the operation creates a new tuple with a unique element being the object.  (3)	Apply diagram update described in Appendix D.

Issue 11108: Assignment.slotExpression (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Simple move already in QVTcore.xml
Revised Text: From 9.17.8 Assignment move slotExpression: OclExpression [1] {composes} An OCL expression identifying the object whose property value is to be assigned. to 9.17.9 PropertyAssignment slotExpression: OclExpression [1] {composes} An OCL expression identifying the object whose property value is to be assigned. In Figure 9.3 move the Assignment end of OclExpression.slotExpression to PropertyAssignment
Actions taken:
June 1, 2007: received issue
July 15, 2014: closed issue

Issue 11341: QVT 1.0 Section 7,8,9,10 : Navigating non-navigable opposite roles (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Issue : QVT 1.0 Section 7,8,9,10 : Navigating non-navigable opposite roles UML models drawn with Rose allow an opposite role to be defined for a uni-directional role. This practice is common but haphazard in UML Infrastructure, EMOF, OCL and QVT specification diagrams. However EMOF provides only the (run-time) usage of the model and so any EMOF (or Ecore) model generator must strip non-navigable opposite roles. QVT matches models at compile-time and matching has no inherent need to observe navigation constraints. This is amply demonstrated by the Rel2Core transformation that makes extensive use of, for instance, the inverse Key to Class relationship. ---------------------------------- Problem: some QVT transformations require names for non-navigable opposite roles, but those names cannot be present in layered multi-package EMOF meta-models. The Rel2Core transformation of Section 10.3 cannot be implemented with QVT 1.0. ---------------------------------- Abandoning EMOF (or Ecore) compliance in favour of perhaps CMOF seems unacceptable. Changing EMOF (or Ecore) to incorporate opposite roles is not possible because an EMOF specification cannot be extended to include the opposite role of every meta-model that will ever exist. Even if it was, there would be a substantial delay until meta-modelling tools adopted the change and a problem with poor standardisation and global non-interference of opposite rolenames. QVT must therefore support definition of non-navigable role names as part of a transformation. ModelMorf provided a very practical concrete syntax solution, whereby the reserved operation opposite(qualified-role-name) could be used as the missing opposite role-name wherever a forward role-name could be used. An upward compatible abstract syntax requires an additional is-opposite qualifier for each referred property. So for QVTCore::PropertyAssignment add isOpposite:Boolean[0..1] default false. QVTTemplate::PropertyTemplateItem add isOpposite:Boolean[0..1] default false. QVTRelation::Key add oppositeParts:Property[0..*] { composed } and possibly relax the lower bound for QVTRelation::Key add parts:Property[0..*] { composed } with the constraint that parts.size() + oppositeParts.size() > 0 Perhaps QVTOperational::Module needs an additional oppositeConfigProperty and QVTOperational::ContextualProperty needs an additional isOpposite too.

Resolution:
Revised Text: (1) Replace the definition of Key (Section 7.11.3.5) by the following text: 7.11.3.5 Key A key defines a set of properties of a class that uniquely identify an instance of the class in a model extent. A class may have multiple keys (as in relational databases). Sometimes it may be necessary to specify a key in terms of opposite properties that are not navigable from the class. Please refer to section 7.4 for a detailed description of the role played by keys in the enforcement semantics of relations. Superclasses Element Associations identifies: Class [1] The class that is identified by the key. part: Property [0..*] Properties of the class that make up the key. oppositePart: Property [0..*] Opposite properties of the class that make up the key. (2) In the definition of PropertyTemplateItem (Section 7.11.2.4), add the following attribute definition: Attributes isOpposite:Boolean Specifies whether the referred property is owned by the opposite end class. An opposite property template item selects an object of the opposite end class that has this object as the value of the specified property. The default value of this property is false. Please refer to section 7.3 for an example that uses an opposite property in template specification. (3) Modify the grammar rule <keyDecl>, <classId>, <keyproperty> and <propertyTemplate> in section 7.13.5 as follows: <keyDecl> ::= 'key' <classId> '{' <keyProperty> (, <keyProperty>)* '}' ';' <classId> ::= <pathNameCS> <keyProperty> ::= <identifier> | 'opposite' '(' <classId> '.' <identifier> ')' <propertyTemplate> ::= <identifier> '=' <OclExpressionCS> | 'opposite' '(' <classId> '.' <identifier> ')' '=' <OclExpressionCS> (4) At the end of section 7.4 describing keys add the following text: Sometimes it may be necessary to use a non-navigable opposite role in the specification of a key. For instance, an attribute is identified by a combination of its name and the owning class. Suppose we have a meta model in which the 'Class' to 'Attribute' association 'attribute' is only navigable from Class to Attribute. We should still be able to use this association in the key specification of Attribute. E.g. key Attribute {name, opposite(Class.attribute)}; This specifies that an attribute is uniquely identified by its name and the class it belongs to. (5) At the end of section 7.3, just before the last sentence, add the following text: Sometimes it may be necessary to use a non-navigable opposite role in the specification of object templates. E.g. domain myModel a:Attribute {name = n, opposite(Class.attribute) = c:Class{}}; This specifies that the pattern will only match if the class the attribute belongs to is equal to 'c'. This is equivalent to the following template definition with condition: domain myModel a:Attribute {name = n} {c.attribute.includes(a)}; But the 'opposite' notation allows this to be specified in the template itself, leading to more compact specifications (6) In figure 7.6, add the new 'isOpposite : Boolean' attribute to the PropertyTemplateItem metaclass. (7) In Figure 7.7, add the additional 'oppositePart: Property [0..*]' association from Key metaclass to the Property metaclass.
Actions taken:
September 10, 2007: received issue
April 26, 2010: closed issue

Discussion:

Agree with the suggested extensions to the key and property template parts of the relations language. As for a more general support in other expressions, we should perhaps wait until the next OCL revision.     Sometimes it may be necessary to use a non-navigable opposite role in the specification of a key. For instance, an attribute is identified by a combination of its name and the owning class. Suppose we have a meta model in which the 'Class' to 'Attribute' association 'attribute' is only navigable from Class to Attribute. We should still be able to use this association in the key specification of Attribute.  E.g.  	key Attribute {name, opposite(Class.attribute)};  This specifies that an attribute is uniquely identified by its name and the class it belongs to.    Similarly, it is useful to be able to specify object templates in terms of opposite properties.  E.g.  domain myModel a:Attribute {name = n, opposite(Class.attribute) = c:Class{}};  This specifies that the pattern will only match if the class the attribute belongs to is equal to 'c'. This is equivalent to the following template definition with condition:  domain myModel a:Attribute {name = n} {c.attribute.includes(a)};  But the 'opposite' notation allows this to be specified in the template itself, leading to more compact specifications.

Issue 11602: Section: 7.13 (qvt-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Critical
Summary:

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

Resolution: QVT Base has a Function.queryExpression. QVT 1.1 added the mapping from queryCS to Function. Not 'nowhere' but we can do better
Revised Text: In 7.11.1.5 Function change A function may be specified to Since a function is side effect free, it is often called a query. A function may be specified
Actions taken:
October 10, 2007: received issue
July 15, 2014: closed issue

Issue 11685: Section: 7.11.3 (qvt-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

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

Resolution: 'top' is explained clearly in Section 7.2.2 Top-level Relations. 'primitive' is a bit of a secret
Revised Text: Add 7.2.4 Primitive Domains Simple data such as configuration information or constants may be passed as parameters to a relation using primitive domains. A primitive domain is identified by primitive keyword and no domain name. A primitive domain is neither checkable nor enforceable. relation Outer { checkonly domain source s:Source {}; enforce domain target t:Target {}; where { Inner(s,t,'target'); } relation Inner { checkonly domain source s:Source {name=pn}; enforce domain target t:Target {name=separator + pn}; primitive domain separator:String; }
Actions taken:
November 26, 2007: received issue
July 15, 2014: closed issue

Issue 11686: Section: A1.1.1 (qvt-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
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 ?

Resolution: 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.
Revised Text: In A.1.1.1 Replace all usage of "//" by "--" Replace key Table (name, schema); key Column (name, owner); key Key (name, owner); by key Table {name, schema}; key Column {name, owner}; key Key {name, owner}; Replace key=k:Key {name=cn+'_pk', column=cl}}; by _'key'=k:Key {name=cn+'_pk', column=cl, kind='primary'}}; Replace srcTbl, destTbl: Table; pKey: Key; by srcTbl, destTbl: SimpleRDBMS::Table; pKey: SimpleRDBMS::Key; Replace pKey = destTbl.key; by pKey = destTbl._'key'->select(kind='primary'); Replace function PrimitiveTypeToSqlType(primitiveTpe:String):String by query PrimitiveTypeToSqlType(primitiveType:String):String Replace endif endif; by endif endif
Actions taken:
November 26, 2007: received issue
December 22, 2015: Resolved
March 29, 2016: closed issue

Discussion:

I think that the intention is for pKey to 'loop' over each destTbl.key, but I cannot see text to justify this.  Collection matching needs revision, in particular the untenable prohibition on nested collections.  Disposition: Deferred

Issue 11690: Section: 7.13.5 (qvt-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
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 ?

Resolution: 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 ?
Revised Text:
Actions taken:
November 27, 2007: received issue
December 22, 2015: Duplicate or Merged
March 29, 2016: closed issue

Discussion:

OCL 2.5 should resolve the semantics of an import for Complete OCL. The QVTr (and QVTc) at least  syntaxes should be compatible.  Disposition: Deferred

Issue 11708: 9.17.12, EnforcementOperation.operationCallExp should be composes (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Simple change already in QVTcore.xml
Revised Text: Simple change already in QVTcore.xml. Revised Text: From 9.17.12 EnforcementOperation change operationCallExp: OperationCallExp [1] to operationCallExp: OperationCallExp [1] {composes} In Figure 9.2 draw EnforcementOperation.operationCallExp as a 0..1 composition.
Actions taken:
December 3, 2007: received issue
July 15, 2014: closed issue

Discussion:

Issue 11825: Inconsistent Rule.transformation multiplicity/composes for Mapping (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Mapping is a Rule and Rule.transformation has unit multiplicity and is a container.  Therefore Rule.context can never be a container.      This could be fixed in a number of ways:      Fix 1: Change Rule.transformation to 0..1          --> allow hierarchical Rule containment          --> all Transformation rules are distinctly named          -- no representation change          -- minor semantic relaxation for QVTr/QVTo          -- minor semantic surprise for QVTc - composed mapping has null Mapping.transformation.      Fix 2: Change Rule.context to not composes          --> require flat Rule containment          --> Transformation can have multiple unnamed rules          -- no change for QVTc/QVTo          -- representation change for QVTc      Fix 3: Change opposite of Transformation.rule from Rule.transformation[1] to Rule.context[1]          Redefine Rule.transformation[1] as a derived property          Remove mapping.context (inherited from Rule)          -- Doesn't work: context needs to be NamedElement to be either Rule or Transformation      Fix 4: Change opposite of Transformation.rule from Rule.transformation[1] to Rule.owningTransformation[0..1]          Redefine Rule.transformation[1] as a derived property                  Rule.transformation := owningTransformation                  Mapping.transformation := if context then context.transformation else owningTransformation endif          -- no representation change          -- minor semantic relaxation for QVTr/QVTo      Recommend 4.

Resolution: Rule.transformation changed to 0..1 in QVTCore.xml for QVT 1.1. Fix 4 doesn't seem that wonderful, so go with the obvious Fix 1. And why prohibit all reuse of Rule outside a Transformation?
Revised Text: In Fig 7.4 change Rule.transformation multiplcity from '1' to '0..1'. In 7.11.1.4 Rule change transformation: Transformation[1] to transformation: Transformation[0..1]
Actions taken:
December 17, 2007: received issue
July 15, 2014: closed issue

Issue 11826: Section 7.11.2.3: Empty CollectionTemplateExp is useful (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

7.11.2.3 and Figure 7.6 both impose a lowerBound of 1 on CollectionTemplateExp.member and CollectionTemplateExp.rest.      However, the concrete syntax permits an empty match. This empty match is exploited in the  UnsharedWhenVarsToMgVars relation in Section 10.      Suggest:      Change CollectionTemplateExp.member to [0..*]  Change CollectionTemplateExp.rest to [0..1]      Add a sentence to clarify the empty match semantics.

Resolution: yes
Revised Text: In 7.11.2.3 CollectionTemplateExp change member : OclExpression [1..*] {composes} The expressions that the elements of the collection must have matches for. A special variable _ may be used to indicate that any arbitrary element may be matched and ignored. rest : Variable [1] The variable that the rest of the collection (i.e., excluding elements matched by member expressions) must match. A special variable _ may be used to indicate that any arbitrary collection may be matched and ignored. to member : OclExpression [*] {composes} The expressions that the elements of the collection must have matches for. A special variable _ may be used to indicate that any arbitrary element may be matched and ignored. The expression may be omitted to restrict a match to an empty collection. rest : Variable [0..1] The variable that the rest of the collection (i.e., excluding elements matched by member expressions) must match. A special variable _ may be used to indicate that any arbitrary collection may be matched and ignored. The variable may be omitted to restrict a match to a collection with no elements other than those matched by the member expressions.
Actions taken:
December 17, 2007: received issue
July 15, 2014: closed issue

Issue 12173: Section: 8.2.1.6 (qvt-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text: In Section 8.2.1.6, replace extraCondition: OclExpression [1..*] {composes, ordered} By: additionalCondition: OclExpression [*] {composes, ordered}
Actions taken:
January 14, 2008: received issue
April 26, 2010: closed issue

Discussion:

That's true. The class description is obsolete in respect with the role naming found in Figure 8.1.

Issue 12198: Section: 8.2.1.7 (qvt-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

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

Resolution:
Revised Text: In Section 8.2.1.7, replace "A variable parameter is an abstract concept�" By: "A variable parameter is a concept�"
Actions taken:
January 25, 2008: received issue
April 26, 2010: closed issue

Issue 12200: There is a reference to a figure that does not exist : figure 1. (qvt-rtf)

Click here for this issue's archive.
Source: THALES (Mr. Eric Maes, eric.maes(at)fr.thalesgroup.com)
Nature: Clarification
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
January 25, 2008: received issue
July 15, 2014: closed issue

Discussion:

Figure numbering was resolved in the QVT 1.0 FAS.  Disposition: Closed, No Change

Issue 12213: Relations Language: how will metamodels get into a transformation scrip (qvt-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
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).

Resolution: 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 https://www.omg.org/spec/UML/20131001/UML.xmihttps://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.
Revised Text: In 7.1 replace transformation umlRdbms (uml : SimpleUML, rdbms : SimpleRDBMS) { by import SimpleUML : 'https://www.omg.org/spec/UML/20131001/UML.xmi';transformation umlRdbms (uml : SimpleUML, rdbms : SimpleRDBMS) { Insert before 7.1.1 7.1.1 Import statements An import statement introduces definitions of unqualified, or first qualifier names for resolution as if defined at the root package of the transformation. The import of a document URI (such as [1]https://www.omg.org/spec/UML/20131001/UML.xmi) makes the root element (the UML Package) available to resolve references (to UML). Additionally, the optional alias (SimpleUML) also makes the root element available to resolve references to the alias name. Alternatively the import of a namespace URI (such as [2]https://www.omg.org/spec/UML/20131001) makes the referenced element available in a similar way. It is not specified how an implementation locates elements corresponding to namespace URIs or how it distinguishes namespace URI access from document URI access. (A plausible implementation maintains a catalog of known namespace URIs to support their resolution leaving everything else to be interpreted as a document URI.) The import may use further qualification such as 'https://www.omg.org/spec/UML/20131001'::Activities to provide a finer grained import. A trailing wildcard as in 'https://www.omg.org/spec/UML/20131001'::* imports all names defined by the reference preceding the wild card. For UML, this is the Packages Actions, Activities, Classification, ... . An alias and a wildcard cannot be used together. In 7.13.5 replace <topLevel> ::= ('import' <unit> ';' )* <transformation>* <unit> ::= <identifier> ('.' <identifier>)* by <topLevel> ::= <import>* <transformation>* <import> ::= 'import' [<identifier> ':'] <URI> ('::' <identifier>)* ['::*'] ';' <URI> ::= #x27 StringChar* #x27 //from OCL StringLiteralExpCS In 9.18 replace TopLevel ::= (Transformation | Mapping | Query)* by TopLevel ::= Import* (Transformation | Mapping | Query)* Import ::= 'import' [simpleNameCS ':'] <URI> ('::' simpleNameCS)* ['::*'] ';' <URI> ::= #x27 StringChar* #x27 //from OCL StringLiteralExpCS ---------------------------------------------------------------------------------------- [1] https://www.omg.org/spec/UML/20131001/UML.xmi [2] https://www.omg.org/spec/UML/20131001
Actions taken:
February 6, 2008: received issue
December 22, 2015: Resolved
March 29, 2016: closed issue

Discussion:

Initial Response  I don't think QVTo is any different to QVTr.  Although A.2.3 happens to provide syntax for metamodels these have names that are distinct from the  subsequent transformation and are separated by an explanatory paragraph.  How short names such as "UML" are resolved to a particular version, location and representation of a  meta-model is tool-specific.  http://www.eclipse.org/gmt/umlx/doc/EclipseAndOMG08/ModelRegistry.pdf  describes one re-usable solution to the problem. It is used by QVTr and QVTc editors.  Discussion:  I now consider the failure of QVTr, QVTc and Complete OCL to provide an ability to import a  Document URI is a language bug and should not depend on external implementation magic. As for  Issue 11690: OCL 2.5 should resolve the semantics of an import for Complete OCL. The QVTr (and  QVTc) at least syntaxes should be compatible.  Disposition: Deferred

Issue 12260: Section: 7.13.3 / 8.4.2 (qvt-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
March 4, 2008: received issue
July 15, 2014: closed issue

Discussion:

All Abstract Syntax elements extend EMOF::Element and so the Element::ownedComment property is  available for comments.  Disposition: Closed, No Change

Issue 12362: Section: 8.4.7 (qvt-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text: Revised Text: In Section 8.2.2.6, at the end of the "Notation" sub-section add the following text. """ When using a forEach expression in conjunction with a compute expression the following shorthand can be used: mylist->forEach(i;x:X=...|cond) { � } This is equivalent to: compute (x:X=...) mylist->forEach(i|cond) { � } This is similar to the shorthand notation for while expression (see 8.2.2.4). """
Actions taken:
April 1, 2008: received issue
April 26, 2010: closed issue

Discussion:

The intent of syntax rule:   <for_exp> ::= ('forEach' | 'forOne') '(' <iter_declarator_list> (';' <declarator>)? ('|' <expression>)? ')' <expression_block>   was to allow shorthand with the computeExp   compute (x:X) mylist->forEach(i|cond) { � }   <==> mylist->forEach(i;x|cond) { � }   Similarly with what happens with While expression.   However the explanation was missing in the notation sub-section.

Issue 12367: Issue against QVT ptc/07-07-07 : relational grammar (qvt-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Peter Denno, peter.denno(at)nist.gov)
Nature: Uncategorized Issue
Severity:
Summary:

Section 7.13.5 Relation BNF      The grammar rule for template is incorrect (It does not allow a   template to have embedded within it another template. The example in   Appendix A will not compile with such a grammar.)      It says:      <propertyTemplate> ::= <identifier> '=' <OclExpressionCS>      It should says:  <propertyTemplate> ::= <identifier> '=' ( <template> |   <oclExpressionCS

Resolution:
Revised Text:
Actions taken:
April 3, 2008: received issue
July 15, 2014: closed issue

Discussion:

No. The grammar also redefines:  <OclExpressionCS> ::= <PropertyCallExpCS> | <VariableExpCS> | <LiteralExpCS> |  <LetExpCS> | <IfExpCS> | '(' <OclExpressionCS> ')' | <template>  Disposition: Closed, No Change

Issue 12368: Issue against QVT ptc/07-07-07 : clause 7.2.3 (qvt-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Peter Denno, peter.denno(at)nist.gov)
Nature: Uncategorized Issue
Severity:
Summary:

Text of Clause 7.2.3 is unclear:      Suggested rewrite:       (1) Add the following as the first two sentences of the first   paragraph.      "In the evaluation of a Transformation, one or more domains are   specified as target. The phrase 'executing in the direction of [some   domain]' refers to these domains."      Then change a few words in the paragraph as suggest by the text in []   below:      "Whether or not the [change "the" to "a"] relationship maybe [should   be "is"] enforced is determined by the target domain, which may be   marked as checkonly or enforced. When a transformation   [change "transformation" to "relation"] is enforced   [change "enforced" to "evaluated"] in the direction of a checkonly   domain, it is simply checked to see if [change "if" to "whether"]   there exists a valid match in the relevant model that satisfies the   relationship. When a transformation executes in the direction of the   model of an enforced domain, if checking fails, the target model is   modified so as to satisfy the relationship, i.e. a   check-before-enforce semantics."       [Strike the words beginning with "i.e." "check-before-enforce" is new   terminology that is neither defined nor helpful.]

Resolution: Yes, we can certainly try to be clearer.
Revised Text: In 7.2.3 change Whether or not the relationship may be enforced is determined by the target domain, which may be marked as checkonly or enforced. When a transformation is enforced in the direction of a checkonly domain, it is simply checked to see if there exists a valid match in the relevant model that satisfies the relationship. When a transformation executes in the direction of the model of an enforced domain, if checking fails, the target model is modified so as to satisfy the relationship, i.e., a check-before-enforce semantics. to When a transformation is evaluated, the transformation executes in the direction of the domain specified as the target. Whether or not a relation is enforced is determined by the target domain, which may be marked as checkonly or enforced. When a relation executes in the direction of a checkonly domain, the domain is simply checked to see whether there exists a valid match in the relevant model that satisfies the relationship. When a relation executes in the direction of an enforced domain, if checking fails, the target model is modified so as to satisfy the relation.
Actions taken:
April 3, 2008: received issue
July 15, 2014: closed issue

Issue 12370: Section 8.7.1a production rule seems to be missing (qvt-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
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).

Resolution: 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.
Revised Text:
Actions taken:
April 4, 2008: received issue
December 22, 2015: Closed; No Change
March 29, 2016: closed issue

Discussion:

It is not clear whether this is necessary or just a convenience.  Disposition: Deferred

Issue 12373: Section: 8.2.2.22 (qvt-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Critical
Summary:

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

Resolution:
Revised Text: (1) Replace: variable : Variable [1..*] {composes} by targetVariable : Variable [1..*] {ordered} (2) Replace var x, y , z := self.foo(); // assuming foo returns a tuple of three elements. By var (x,y,z) := self.foo(); // assuming foo returns a tuple of three elements. (3) Update diagram 8.6 to reflect that targetVariable is not a composition
Actions taken:
April 7, 2008: received issue
April 26, 2010: closed issue

Issue 12374: MOF QVT 1.0, 8.2.2.22, Unclear specification of Unpack notation shorthand (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Section 8.2.2.22 provides no guidance on the meaning of:      var x:X;  var y:Y;  var z:Z;  ...  var (x:X,y,z) := self.foo();      [If one of the variables in the left hand side, does exist ...]      Possible interpretations      a) x:X is always a syntactical shorthand.      Therefore the above is a shorthand for:      var x:X;  var y:Y;  var z:Z;  ...  var x:X; var (x,y,z) := self.foo();      and consequently there is duplicate variable definition to be  reported as a semantic error.      b) x:X is a convenience type check assertion      Therefore the above is a shorthand for:      var x:X;  var y:Y;  var z:Z;  ...  var (x,y,z) := self.foo();      with a successful validation of type consistency.      c) x:X is not available as a shorthand      Therefore the above is a syntax error.      ------------------------------------      Interpretations b) and c) require semantic knowledge to resolve syntactic  sugar.      Interpretation a) is an unambiguous syntax shorthand that could be more  clearly  described by:      "The following example demonstrates a shorthand in which variables are both  declared  and assigned.              var (x:X,y:Y,z) := self.foo();      Any variable name qualified by a type name is both a declaration and an  assignment,  with all declarations proceding the unapack assignment.   The above example should therefore be analyzed as:              var x:X; var y:Y; var (x,y,z) := self.foo();"      ---------------------------------------------------------------------      Recommend interpretation a) with the above textual clarification.

Resolution:
Revised Text: (1) Replace the text: """If one of the variables in the left hand side does not exist, the notation is a shorthand for declaring the missing variables prior to the unpack expression. In such case, the type of the variables can be given. For instance, in the example above, if 'x' and 'y' does not exist, the expression var (x:X,y:Y,z) := self.foo(); is equivalent to: var x:X; var y:Y; var (x,y,z) := foo(); """ By the following text: """The following example demonstrates a shorthand in which variables are both declared and assigned. var (x:X,y:Y,z) := self.foo(); Any variable name which specifies a type name is both a declaration and an assignment, with all declarations proceding the unpack assignment. The above example should therefore be analyzed as: var x:X; var y:Y; var (x,y,z) := self.foo();" """
Actions taken:
April 8, 2008: received issue
April 26, 2010: closed issue

Issue 12375: Section: 8.1.14 (qvt-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

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

Resolution:
Revised Text: (1) Add a new subsection 8.2.2.33 ListLiteralExp, with the following content: A list literal expression is a literal definition for a mutable list type (see 8.2.2.25) . Superclasses: CollectionLiteralExp (From EssentialOCL) Associations: element : OclExpression [*] {composes,ordered} The values of the literal list. (2) Update the Figure 8.7 with the ListLiteralExp definition (3) Add the 'List' keyword in 8.4.7.1.
Actions taken:
April 8, 2008: received issue
April 26, 2010: closed issue

Discussion:

Issue 12518: errors and anomalies in QVT_1.0.mdl in the 07-07-08 ZIP (qvt-rtf)

Click here for this issue's archive. Click here for this issue's attachments.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Use of automated tooling to support comparison of the models developed  initially as part of the Eclipse GMT/UMLX project and being transferred to the  Eclipse QVT Declarative/QVT Operational Mappings Projects reveals the following  errors and anomalies in QVT_1.0.mdl in the 07-07-08 ZIP.      Since the diagrams are printed from QVT_1.0.mdl all the QVT problems also  occur in 08-04-03.      Textual errors in 08-04-03 cannot be analyzed automatically. There are  so many that a thorough proof read is required combined with a statement  that the diagrams only are normative

Resolution: The QVT 1.0 diagrams and models were originally from the models in the QVT_1.0.mdl file. The diagrams rely on proprietary tooling. Unfortunately some independent evolution occurred and so there were many inconsistencies. Consistent Ecore/EMOF files from Eclipse were endorsed as the QVT 1.1 non-normative files. For QVT 1.2, the primary non-normative files are UML models derived from the QVT 1.1 Ecore files. The diagrams are redrawn from the UML using the Open Source Papyrus tool. The diagrams are drawn to assist understanding rather than to squeeze as much as possible into the useable area. The redrawn diagrams are therefore larger/more numerous. (Unfortunately Papyrus does not support {ordered} so {ordered} text is added manually.) In all other respects diagrams and UML non-normative files should be consistent. The multiplicity of unnavigable opposites was not present in the Ecore files and so is set to 0..1 for compositions, and 0..* for non-compositions by the Ecore2UML conversion. This causes a few 1 multiplicities to change to 0..1. The 1 multiplicities were needlessly restrictive prohibiting re-use of classes, so the 0..1 seems better. Perhaps we should have an issue to change navigable containers too. TemplateParameterType is missing from the diagrams since it is not preset in the non-normative files. TemplateParameterType has no practical utility implementations are required to work magic for templates types which may or may not involve the TemplateParameterType class. I find that when I consult the specification, I want to see all the diagrams, which is hard when they are spread thoughout the AS section. All diagrams are therefore brought to the start of their AS section.
Revised Text: see pages 32 - 44 of ptc/2014-03-36 for details
Actions taken:
June 6, 2008: received issue
July 15, 2014: closed issue

Issue 12519: Errors and anomalies in QVT 1.0 07-07-08 ZIP qvt_metamodel.emof.xml (qvt-rtf)

Use of automated tooling to support comparison of the models developed  initially as part of the Eclipse GMT/UMLX project and being transferred to the  Eclipse QVT Declarative/QVT Operational Mappings Projects reveals the following  errors and anomalies in qvt_metamodel.emof.xml in the 07-07-08 ZIP.      Note that these errors and anomalies are not the same as those separately reported  for the QVT_1.0.mdl from which the EMOF was notionally auto-generated.      EMOF files resolving these anomalies are attached.

Resolution:
Revised Text:
Actions taken:
June 6, 2008: received issue
July 15, 2014: closed issue

Discussion:

QVT 1.1 issued revised files based on Eclipse QVT contributions.  Issue 12518: QVT 1.2 is providing non-normative UML files.  Disposition: Closed, No Change

Issue 12520: Errors and anomalies in QVT 1.0 07-07-08 ZIP emof.ecore (qvt-rtf)

Use of automated tooling to support comparison of the models developed  initially as part of the Eclipse GMT/UMLX project and being transferred to the  Eclipse QVT Declarative/QVT Operational Mappings Projects reveals the following  errors and anomalies in emof.ecore in the 07-07-08 ZIP.      Note that these errors and anomalies are not the same as those separately reported  for the QVT_1.0.mdl from which the Ecore was notionally auto-generated.      An Ecore file resolving these anomalies is attached.      'nsURI' for 'EMOF' should be 'http://schema.omg.org/spec/MOF/2.0/emof.xml' rather than 'http:///emof.ecore'  'name' for 'EMOF' should be 'EMOF' rather than 'emof'  'name' for 'Property.isID' should be 'isID' rather than 'isId'  'Factory' should be defined  'ReflectiveCollection' should be defined  'ReflectiveSequence' should be defined  'Comment.body' should be defined  'Factory.package' should be defined  'Element.tag' should be undefined  'eOpposite' for 'Tag.element' should be undefined  'lowerBound' for 'Operation.class' should be '0' rather than '1'  'lowerBound' for 'Type.package' should be '0' rather than '1'  'lowerBound' for 'Property.class' should be '0' rather than '1'  'ordered' for 'Class.superClass' should be 'false' rather than 'true'  'ordered' for 'Comment.annotatedElement' should be 'false' rather than 'true'  'ordered' for 'Element.ownedComment' should be 'false' rather than 'true'  'ordered' for 'Operation.raisedException' should be 'false' rather than 'true'  'ordered' for 'Package.nestedPackage' should be 'false' rather than 'true'  'ordered' for 'Package.ownedType' should be 'false' rather than 'true'  'ordered' for 'Tag.element' should be 'false' rather than 'true'  'defaultValueLiteral' for 'Class.isAbstract' should be 'false' rather than undefined  'defaultValueLiteral' for 'MultiplicityElement.isOrdered' should be 'false' rather than undefined  'defaultValueLiteral' for 'MultiplicityElement.isUnique' should be 'true' rather than undefined  'defaultValueLiteral' for 'MultiplicityElement.lower' should be '1' rather than undefined  'defaultValueLiteral' for 'MultiplicityElement.upper' should be '1' rather than undefined  'defaultValueLiteral' for 'Property.isComposite' should be 'false' rather than undefined  'defaultValueLiteral' for 'Property.isDerived' should be 'false' rather than undefined  'defaultValueLiteral' for 'Property.isReadOnly' should be 'false' rather than undefined  'Element.container()' should be defined  'Element.equals(object)' should be defined  'Element.get(property)' should be defined  'Element.getMetaClass()' should be defined  'Element.isSet(property)' should be defined  'Element.set(property,object)' should be defined  'Element.unset(property)' should be defined  'Extent.elements()' should be defined  'Extent.useContainment()' should be defined  'Factory.convertToString(dataType,object)' should be defined  'Factory.create(metaClass)' should be defined  'Factory.createFromString(dataType,string)' should be defined  'ReflectiveCollection.add(object)' should be defined  'ReflectiveCollection.addAll(objects)' should be defined  'ReflectiveCollection.clear()' should be defined  'ReflectiveCollection.remove(object)' should be defined  'ReflectiveCollection.size()' should be defined  'ReflectiveSequence.add(index,object)' should be defined  'ReflectiveSequence.get(index)' should be defined  'ReflectiveSequence.remove(index)' should be defined  'ReflectiveSequence.set(index,object)' should be defined  'Type.isInstance(object)' should be defined  'URIExtent.contextURI()' should be defined  'URIExtent.element(uri)' should be defined  'URIExtent.uri(element)' should be defined  Unnavigable 'opposite' of 'Class.superClass' should be modelled  Unnavigable 'opposite' of 'Element.ownedComment' should be modelled  Unnavigable 'opposite' of 'Package.nestedPackage' should be modelled  Unnavigable 'opposite' of 'Property.opposite' should be modelled

Resolution:
Revised Text:
Actions taken:
June 6, 2008: received issue
June 6, 2008: received issue
July 15, 2014: closed issue

Discussion:

These changes affect non-normative EMOF files which were corrected when QVT 1.1 issued revised  files based on Eclipse QVT contributions.  Disposition: Closed, No Change

Issue 12521: Errors and anomalies in QVT 1.0 07-07-08 ZIP essentialocl.ecore (qvt-rtf)

Use of automated tooling to support comparison of the models developed  initially as part of the Eclipse GMT/UMLX project and being transferred to the  Eclipse QVT Declarative/QVT Operational Mappings Projects reveals the following  errors and anomalies in emof.ecore in the 07-07-08 ZIP.      Note that these errors and anomalies are not the same as those separately reported  for the QVT_1.0.mdl from which the Ecore was notionally auto-generated.      An Ecore file resolving these anomalies is attached.

Resolution:
Revised Text:
Actions taken:
June 6, 2008: received issue
July 15, 2014: closed issue

Discussion:

These changes affect non-normative EssentialOCL files which were corrected when QVT 1.1 issued  revised files based on Eclipse QVT contributions.  Disposition: Closed, No Change

Issue 12522: Errors and anomalies in QVT 1.0 07-07-08 ZIP qvtbase.ecore (qvt-rtf)

Use of automated tooling to support comparison of the models developed  initially as part of the Eclipse GMT/UMLX project and being transferred to the  Eclipse QVT Declarative/QVT Operational Mappings Projects reveals the following  errors and anomalies in emof.ecore in the 07-07-08 ZIP.      Note that these errors and anomalies are not the same as those separately reported  for the QVT_1.0.mdl from which the Ecore was notionally auto-generated.      An Ecore file resolving these anomalies is attached.

Resolution: These changes mostly affect non-normative files which were corrected when QVT 1.1 issued revised files based on Eclipse QVT contributions. However a few changes remain to be resolved in the main text. No: Domain.typedModel lowerbound of 0 is correct; primitive domains have no TypedModel Rule.transformation lowerbound change is Issue 11825.
Revised Text: In Fig 7.4 change Rule.transformation multiplicity from 1 to 0..1. � Transformation.modelParameter to not ordered. � Rule.overriden to overridden. In 7.11.1.1 Transformation change transformation: Transformation[1] to transformation: Transformation[0..1] In 7.11.1.4 Rule change transformation: Transformation[1] to transformation: Transformation[0..1] In the non-normative files change � Transformation.modelParameter to not ordered.
Actions taken:
June 6, 2008: received issue
July 15, 2014: closed issue

Issue 12523: Errors and anomalies in QVT 1.0 07-07-08 ZIP qvttemplate.ecore (qvt-rtf)

Use of automated tooling to support comparison of the models developed  initially as part of the Eclipse GMT/UMLX project and being transferred to the  Eclipse QVT Declarative/QVT Operational Mappings Projects reveals the following  errors and anomalies in emof.ecore in the 07-07-08 ZIP.      Note that these errors and anomalies are not the same as those separately reported  for the QVT_1.0.mdl from which the Ecore was notionally auto-generated.      An Ecore file resolving these anomalies is attached.

Resolution: These changes mostly affect non-normative files which were corrected when QVT 1.1 issued revised files based on Eclipse QVT contributions. However a few changes remain to be resolved in the main text. CollectionTemplateExp.rest/member lowerBound is Issue 11826. PropertyTemplateItem.value multiplicity is right in diagram not text
Revised Text: In Fig 7.6 change � Correct part/objContainer positions; should show ObjectTemplateExp.part � Correct CollectionTemplateExp.referredCollectionType to multiplicity 1. � Correct CollectionTemplateExp.member to multiplicity *. � Correct CollectionTemplateExp.rest to multiplicity 0..1. In 7.11.2.3 CollectionTemplateExp change member : OclExpression [1..*] {composes} ... rest : Variable [1] to member : OclExpression [*] {composes} ... rest : Variable [0..1] In 7.11.2.4 PropertyTemplateItem change value: OclExpression [0..1] {composes} to value: OclExpression [1] {composes}
Actions taken:
June 6, 2008: received issue
July 15, 2014: closed issue

Issue 12524: Errors and anomalies in QVT 1.0 07-07-08 ZIP qvtrelation.ecore (qvt-rtf)

Use of automated tooling to support comparison of the models developed  initially as part of the Eclipse GMT/UMLX project and being transferred to the  Eclipse QVT Declarative/QVT Operational Mappings Projects reveals the following  errors and anomalies in emof.ecore in the 07-07-08 ZIP.      Note that these errors and anomalies are not the same as those separately reported  for the QVT_1.0.mdl from which the Ecore was notionally auto-generated.      An Ecore file resolving these anomalies is attached

Resolution: These changes mostly affect non-normative files which were corrected when QVT 1.1 issued revised files based on Eclipse QVT contributions. However a few changes remain to be resolved in the main text.
Revised Text: In Fig 7.7 � Remove the partial diagram artifact at the bottom of the diagram � Correct the RelationImplementation.relation multiplicity to 1 � Correct the RelationCallExp.referredRelation multiplicity to 1 � Correct the RelationCallExp.argument multiplicity to 2..* In 7.11.3.1 RelationalTransformation change key: Key [*] {composes} to ownedKey: Key [*] {composes} In 7.11.3.2 Relation change /domain: Domain [*] {composes} (from Rule) to /domain: RelationDomain [*] {composes} (from Rule) In the non-normative files change � RelationImplementation.relation multiplicity to 1
Actions taken:
June 6, 2008: received issue
July 15, 2014: closed issue

Issue 12525: Errors and anomalies in QVT 1.0 07-07-08 ZIP qvtcore.ecore (qvt-rtf)

Use of automated tooling to support comparison of the models developed  initially as part of the Eclipse GMT/UMLX project and being transferred to the  Eclipse QVT Declarative/QVT Operational Mappings Projects reveals the following  errors and anomalies in emof.ecore in the 07-07-08 ZIP.      Note that these errors and anomalies are not the same as those separately reported  for the QVT_1.0.mdl from which the Ecore was notionally auto-generated.      An Ecore file resolving these anomalies is attached

Resolution: These changes mostly affect non-normative files which were corrected when QVT 1.1 issued revised files based on Eclipse QVT contributions. However a few changes remain to be resolved in the main text. CorePattern.variable is Issue 10938 Assignment.slotExpression is Issue 11108
Revised Text: In Fig 9.2 � add a CorePattern to Variable composition arc for CorePattern.variable In Figure 9.3 � move the Assignment end of OclExpression.slotExpression to PropertyAssignment. � Change the EnforcementOperation.bottomPattern multiplicity to 1. In 9.17.1 CorePattern add variable: Variable [*] {composes} In 9.17.6 Mapping change domain : Domain [*] {composes} (From QVTBase) to /domain : CoreDomain [*] {composes} (From QVTBase) In 9.17.7 RealizedVariable change bottomPattern : BottomPattern [*] {composes} to bottomPattern : BottomPattern [1] In 9.17.8 Assignment change bottomPattern: BottomPattern to bottomPattern : BottomPattern [1] From 9.17.8 Assignment move slotExpression: OclExpression [1] {composes} An OCL expression identifying the object whose property value is to be assigned. to 9.17.9 PropertyAssignment slotExpression: OclExpression [1] {composes} An OCL expression identifying the object whose property value is to be assigned. In the non-normative files change � EnforcementOperation.bottomPattern multiplicity to 1
Actions taken:
June 6, 2008: received issue
July 15, 2014: closed issue

Issue 12526: Errors and anomalies in QVT 1.0 07-07-08 ZIP imperativeocl.ecore (qvt-rtf)

Use of automated tooling to support comparison of the models developed  initially as part of the Eclipse GMT/UMLX project and being transferred to the  Eclipse QVT Declarative/QVT Operational Mappings Projects reveals the following  errors and anomalies in emof.ecore in the 07-07-08 ZIP.      Note that these errors and anomalies are not the same as those separately reported  for the QVT_1.0.mdl from which the Ecore was notionally auto-generated.      An Ecore file resolving these anomalies is attached.

Resolution: These changes mostly affect non-normative files which were corrected when QVT 1.1 issued revised files based on Eclipse QVT contributions. However a few changes remain to be resolved in the main text. CatchExp.exceptionVariable/CatchExp.exception changes are Issue 15997 Remove UnpackExp is Issue 13268 Remove OrderedTupleType is Issue 13268 Remove OrderedTupleLiteralExp is Issue 13268 Remove OrderedTupleLiteralPart is Issue 13268 Add InstantiationExp.initializationOperation is Issue 19021
Revised Text: In Fig 8.5 � Position * and {ordered} unambiguously for BlockExp.body � Add Operation � Add unidirectional reference from InstantiationExp to Operation forward role initializationOperation [0..1] reverse role instantiationExp [*] In Fig 8.6 � remove spurious artifact at RHS � add CatchExp.exceptionVariable � change CatchExp.exception multiplicity to + � change ReturnExp.value multiplicity to 0..1 � remove UnpackExp and its associations In Fig 8.7 � remove OrderedTupleType and its associations � remove OrderedTupleLiteralExp and its associations � remove OrderedTupleLiteralPart and its associations In 8.2.2.7 ImperativeIterateExp change target : Variable [0..1] to target : Variable [0..1] {composes} In 8.2.2.8 SwitchExp change elsePart : OclExpresion {composes} [0..1] to elsePart : OclExpression {composes} [0..1] In 8.2.2.14 CatchExp and the QVT 1.1 models add exceptionVariable : Variable [0..1] In 8.2.2.23 InstantiationExp add initializationOperation : Operation [0..1] The initialization operation that uses the arguments to initialize the object after creation. The initialization operation may be omitted when implicit initialization occurs with no arguments. In 8.2.2.24 Typedef change condition: OclExpression [1]{composes} to condition: OclExpression [0..1]{composes} In 8.2.2.29 DictLiteralExp change part : DictLiteralPart [*] {composes,ordered} to part : DictLiteralPart [*] {composes} In the non-normative models change � add CatchExp.exceptionVariable � change CatchExp.exception multiplicity to + � add InstantiationExp.initializationOperation � remove UnpackExp � remove OrderedTupleType � remove OrderedTupleLiteralExp � remove OrderedTupleLiteralPart
Actions taken:
June 6, 2008: received issue
July 15, 2014: closed issue

Issue 12527: Errors and anomalies in QVT 1.0 07-07-08 ZIP qvtoperational.ecore (qvt-rtf)

Use of automated tooling to support comparison of the models developed  initially as part of the Eclipse GMT/UMLX project and being transferred to the  Eclipse QVT Declarative/QVT Operational Mappings Projects reveals the following  errors and anomalies in emof.ecore in the 07-07-08 ZIP.      Note that these errors and anomalies are not the same as those separately reported  for the QVT_1.0.mdl from which the Ecore was notionally auto-generated.      An Ecore file resolving these anomalies is attached

Resolution: These changes mostly affect non-normative files which were corrected when QVT 1.1 issued revised files based on Eclipse QVT contributions. However a few changes remain to be resolved in the main text. ContextualProperty .initExpression is Issue 13270 ObjectExp.instantiatedClass is Issue 13276 ObjectExp. initializationOperation is Issue 19021 ObjectExp. body is Issue 19022
Revised Text: In Fig 8.1 � Replace Operation by EntryOperation as target of Module.entry � Change ModelType.metamodel multiplicity to 1..* In Fig 8.2 � Disentangle MappingBody.endSection/OperationBody.content and {ordered} � Add {ordered} to OperationBody.content Move from 8.2.1.1 OperationalTransformation to 8.2.1.3 Module ownedVariable : Variable [0..*] {composes} The list of variables owned by this module. In 8.2.1.14 ContextualProperty change overridden: Property [1] to overridden: Property [0..1] In 8.2.1.14 ContextualProperty add initExpression: OclExpression [0..1] {composes} In 8.2.1.15 MappingOperation change isBlackbox: Boolean to /isBlackbox: Boolean (from ImperativeOperation) In 8.2.1.21 MappingCallExp Superclasses change OperationCallExp to ImperativeCallExp In 8.2.1.24 ObjectExp change /instantiatedClass: Class [0..1](from InstanciationExp) to /instantiatedClass: Class [1](from InstantiationExp) In 8.2.1.24 ObjectExp add body: ConstructorBody[1] { composes } The constructor to execute. In 8.2.1.24 ObjectExp add /initializationOperation : Constructor [0..1] (from InstantiationExp) The constructor that uses the arguments to initialize the object after creation. The constructor may be omitted when implicit construction occurs with no arguments. In the non-normative files change � ObjectExp.referredObject multiplicity to 1
Actions taken:
June 6, 2008: received issue
July 15, 2014: closed issue

Discussion:

Issue 12571: QVT 1.0 9.* Missing query concrete syntax (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

There is no support for queries in the QVT Core concrete syntax.      Suggest: re-use the concrete syntax of QVT Relation, except that the query  is defined at global scope and so must be qualified by the name of a  transformation defined in the same source unit.      example:      query txName::getStringSize (someString:String): Integer {    someString -> size()  }

Resolution: Simple change. Names are left vague pending resolution of Issue 10935.
Revised Text: In 9.18 Concrete Syntax add (NB TopLevel introduced by Issue 10942) TopLevel ::= (Transformation | Mapping | Query)* Query ::= 'query' QueryName '(' [ ParamDeclaration (',' ParamDeclaration)*] ')' ':' TypeDeclaration (';' | '{' QueryOCLExpr '}') ParamDeclaration ::= ParameterName ':' TypeDeclaration
Actions taken:
July 11, 2008: received issue
July 15, 2014: closed issue

Issue 12572: QVT 1.0 7.13.5 Transformation hierarchy (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The QVT Relation Concrete Syntax makes no provision for organisation of transformations  in a package hierarchy; all transformations are presumed to be in root packages.      Suggest: change <identifier> to <transformationId> in both definition and reference  of the <transformation> production, and define <transformationId> as <pathNameCS>.

Resolution: simple change
Revised Text: In 7.13.5 Relations Textual Syntax Grammar change <transformation> ::= 'transformation' <identifier> '(' <modelDecl> (',' <modelDecl>)* ')' ['extends' <identifier>] '{' <keyDecl>* ( <relation> | <query> )* '}' to <transformation> ::= 'transformation' <transformationId> '(' <modelDecl> (',' <modelDecl>)* ')' ['extends' <transformationId>] '{' <keyDecl>* ( <relation> | <query> )* '}' <transformationId> ::= <pathNameCS>
Actions taken:
July 11, 2008: received issue
July 15, 2014: closed issue

Issue 12573: QVT 1.0 9.18 Missing transformation extension concrete syntax (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

There is no support for transformation extension in the QVT Core concrete syntax.      Suggest: re-use the concrete syntax of QVT Relation, allowing "extends x" to follow  a transformation declaration.      example:      transformation yy::umlRdbms {          middle imports tuml2rdbms;          uml imports umlMM;          rdbms imports rdbmsMM;  } extends base1, xx::base2, base3

Resolution: Simple change. Names are left vague pending resolution of Issue 10935.
Revised Text: In 9.18 Concrete Syntax change Transformation ::= �transformation� TransformationName �{� ( Direction�;� )* �}� to Transformation ::= �transformation� TransformationName �{� ( Direction�;� )* �}� [ �extends� TransformationName (�,� TransformationName)*]
Actions taken:
July 11, 2008: received issue
July 15, 2014: closed issue

Issue 13054: MOF-QVT 1.0: 7.11.3.6 (and 7.11.1.1) BlackBox operation signature difficulties (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
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.

Resolution: 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.
Revised Text:
Actions taken:
October 31, 2008: received issue
December 22, 2015: Deferred
March 29, 2016: closed issue

Discussion:

I would like to see a working implementation of this before resolving.  Disposition: Deferred

Issue 13082: current abstract syntax of ImperativeOCL introduces a couple of unclear situations (qvt-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
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

Resolution: 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 [1]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 [2]http://solitaire.omg.org/browse/QVT13-87 for consideration by QVT 2.0. ---------------------------------------------------------------------------------------- [1] http://www.fots.ua.ac.be/events/ocl2008/PDF/OCL2008_9.pdf [2] http://solitaire.omg.org/browse/QVT13-87
Revised Text: In 8.2.2.1 Add Note also that since an ImperativeExpression can introduce side effects, it may not be used in a side effect free OclExpression even though its inheritance from OclExpression might suggest that it can. When side effects are required, imperative constructs such as ImperativeLoopExp, SwitchExp or VariableInitExp should be used in place of LoopExp, IfExp or LetExp. Constraint Every containment ancestor of an ImperativeExpression that is an OclExpression must also be an ImperatveExpression. context ImperativeExpression inv IsInImperativeContext: let ancestors = self->closure(oclContainer()) in ancestors->forAll(oclIsKindOf(OclExpression) implies oclIsKindOf(ImperativeExpression))
Actions taken:
November 15, 2008: received issue
December 22, 2015: Resolved
March 29, 2016: closed issue

Discussion:

A rework may be necessary to clarify whether the claim that QVT (and consequently QVTo ) is an  extension of OCL needs to be amended.  Disposition: Deferred

Issue 13103: element creation and element attachment/detachment to/from an extent (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. E. Victor Sanchez, vsanchez(at)opencanarias.com)
Nature: Enhancement
Severity: Minor
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?

Resolution: 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 [1]QVT-36. ---------------------------------------------------------------------------------------- [1] http://issues.omg.org/browse/QVT-36
Revised Text:
Actions taken:
November 21, 2008: received issue
December 22, 2015: Duplicate or Merged
March 29, 2016: closed issue

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. Preview Revised Text: In 8.2.1.24 ObjectExp add after the first paragraph Object creation, initialisation and residence are separate activities. Object creation occurs when the referredObject has a null value; it is skipped if the referredObject variable references an existing object. Object initialization always occurs, but may be trivial if the body is empty. Object residence is left unchanged when the extent is omitted, so object creation will normally result in an object without any residence; the residence will be established as soon as the created object is put at the target end of some composition relationship. An explicit object residence may be established by specifying the model parameter for the required extent as the extent. Specifying an extent with a null value ensures that the created object has no residence; this may remove the residence of a pre-existing object. Discussion Discussion, primarily on Eclipse qvto-dev identified the lack of an overview of the intent of an Extent to motivate the detailed behaviours amended above in ObjectExp but not revised for InstantiationExp. Disposition: Deferred

Issue 13158: QVT Relations and working with stereotypes: (qvt-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
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?

Resolution: 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.
Revised Text:
Actions taken:
December 15, 2008: received issue
December 22, 2015: Deferred
March 29, 2016: closed issue

Discussion:

OCL 2.5 should provide stereotype support that can be extended if necessary by QVTr  Disposition: Deferred

Issue 13168: Typedef aliases issue (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody)
Nature: Enhancement
Severity: Significant
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.

Resolution: 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, [1]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. ---------------------------------------------------------------------------------------- [1] http://solitaire.omg.org/browse/QVT13-13
Revised Text: In 8.1.14 delete Another mechanism is defined to make the type system more flexible. The typedef mechanism allows attaching additional constraints to an existing type within a specific context. It also serves to define aliases to complex data types. When used in the signature of a mapping operation, the typedef constraints are added to the guard of the mapping operation. The condition is expressed within brackets after the type taken as reference. typedef TopLevelPackage = Package [container()=null]; typedef AttributeOrOperation = Any [#Attribute or #Operation]; typedef Activity = ActionState[stereotypedBy("Activity")]; The type defined by a typedef is considered to be in the scope of the model type of the type taken as reference. For instance, if Package exists in the context of a UML modeltype, the TopLevelPackage is also considered being defined in the context of the UML modeltype. The ?#Metaclass? notation - respectively '##Metaclass? - is a shorthand for isKindOf(Metaclass) - respectively isTypeOf(Metaclass). and replace A typedef can also be used to simply define an alias to a complex type, as for tuple types: by A typedef can be used to define an alias for a complex type such as a tuple type: In 8.2.2.22 replace Figure 8.11 depicts the four new types, which are: TemplateParameterType, Typedef, DictionaryType, and ListType. by Figure 8.11 depicts the four new types, which are: TemplateParameterType, Typedef (deprecated), DictionaryType, and ListType. Replace the whole of 8.2.2.23 Typedef by 8.2.2.23 Typedef (deprecated) The Typedef class was underspecified and unnecessary. A type alias may be defined by using a typedef construct. A Constrained Type may be defined by adding an invariant to a derived class. Superclasses Class Associations base : Type [1] condition : OclExpression [0..1] {composes} In 8.4.7 replace 8.4.7.1 Syntax for module definitions by // Syntax for module definitions Replace // typedefs <typedef> ::= 'typedef' <identifier> '=' <typespec> (typedef_condition)? ';' <typedef_condition> ::= '[' <expression> ']' by <typedef> ::= 'typedef' <identifier> '=' <typespec> ';' and add 8.4.7.1 Deprecated syntax The following alternative constructs may be provided by tools offering backward compatibility to earlier versions of the QVT specification. // typedefs <typedef> ::= 'typedef' <identifier> '=' <typespec> (typedef_condition)? ';' <typedef_condition> ::= '[' <expression> ']'
Actions taken:
December 18, 2008: received issue
December 22, 2015: Resolved
March 29, 2016: closed issue

Discussion:

It is hard to tackle this properly until the OCL type system is clearer. OCL 2.5 should define what it  means to prepare a loaded metamodel for OCL usage. This definition can form the basis of a QVT  clarification..  Disposition: Deferred

Issue 13180: section (8.3.2) is very confusing for the reader (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody)
Nature: Clarification
Severity: Minor
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.

Resolution: 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.
Revised Text: In 8.1.14, 8.1.15, 8.2.2.6, A.2.3 replace isKindOf by oclIsKindOf. In 8.1.14, 8.2.12, 8.2.13, 8.2.15 replace isTypeOf by oclIsTypeOf. In A.2.3 replace asType by oclAsType In 8.3.2. Replace All the OCL operations starting with ?Ocl? prefix have a synonym operation in the QVT library where the prefix is skipped. For instance: isKindOf is a synonym of oclIsKindOf. All the predefined OCL types M1 starting with ?Ocl? prefix have a synonym type in the QVT library where the prefix is skipped. The Ocl prefix in types and operations, can still be used but its usage is not recommended since name conflicts can be avoided by qualifying with the name of the library (StdLib). by QVT 1.0, 1.1 and 1.2 encouraged the use of the simpler "asType", "isKindOf" and "isTypeOf" synonyms for "ocl"-prefixed operation names such as "oclAsType", "oclisKindOf" and "oclIsTypeOf" . Use of "Any" and "Void" synonyms were similarly encouraged in preference to "Ocl"-prefix types such as "OclAny" and "OclVoid". Since these synonyms may introduce conflicts and since few QVTo users can avoid also being OCL users, the use of these synonyms is deprecated. A QVTo implementation may support these deprecated synonyms by translating them to their prefixed form before using them in any Abstract Syntax representation. Any conflicting usage of the synonyms must ignore the synonym in favor of the user declaration. Delete The following synonyms are defined for the following pre-defined OCL operations: String : operator+ -> concat Integer: operator+ -> plus, operator- (binary) -> minus, operator- (unary) -> unaryminus operator* -> multiply operator/ -> divide Real: operator+ -> plus, operator- (binary) -> minus, operator- (unary) -> unaryminus operator* -> multiply operator/ -> divide
Actions taken:
December 19, 2008: received issue
December 22, 2015: Resolved
March 29, 2016: closed issue

Discussion:

Once OCL 2.5 provides an extensible modeled OCL Standard Library, there will be no need for this to  be more than additional library definitions.  Disposition: Deferred

Issue 13181: ** QVTo Standard Library (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody)
Nature: Clarification
Severity: Minor
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.

Resolution: 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 [1]QVT13-53 clone/deepclone merged into [2]QVT13-53 Model::copy/createEmptyModel - NO. Model is the correct return type. ---------------------------------------------------------------------------------------- [1] http://issues.omg.org/browse/QVT13-53 [2] http://issues.omg.org/browse/QVT13-53
Revised Text:
Actions taken:
December 19, 2008: received issue
December 22, 2015: Duplicate or Merged
March 29, 2016: closed issue

Discussion:

This is the approach taken by the OCL Standard Library modeling in Eclipse OCL using the OclSelf  type, which has a well-defined meaning whereas TemplateParameterType is magic.  A proper QVT Library model should use the modeling capabilities to be provided by OCL 2.5.  Disposition: Deferred

Issue 13182: QVTo Standard Library: Some operation's signatures seem to be erroneous. (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody)
Nature: Clarification
Severity: Minor
Summary:

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

Resolution: allSubojectsOfType � see Issue 13989 resolution. raisedException � Yes. But the Status operations are misleadingly under Transformation. Add a missing section heading. asList(T) � Yes, supersedes Issue 19146 resolution. PS � see Issue 19146 resolution. toLower � Yes. Make it clear that all String operations are immutable. Redirect OCL 2.4 synonyms to OCL 2.4 deprecating the synonyms. We can also fix some bad typos, Boolean rather than Integer/Real returns, references to the non-existent Float type and spurious matchXXX arguments. lastToUpper � this seems to be a major bloat. Either name or description could change. Since the name exists with an obvious functionality, correct the description. PS Yes
Revised Text: After 8.3.6.3 Transformation wait insert <<new 8.3.7 number>> Status The following operations may be used to interrogate the Status object that synchronizes the end of a transformation. In 8.3.6.4 Transformation raisedException change Status::raisedException () : Class to Status::raisedException () : Exception In the Issue 19146 replacement text, replace the erroneous trailing (T) parameter by an empty () parameter list in the following signatures: List(T)::add(T) List(T)::asList(T) List(T)::clone(T) List(T)::deepclone(T) Collection(T)::asList(T) Collection(T)::clone(T) Collection(T)::deepclone(T) Bag(T)::asList(T) Bag(T)::clone(T) Bag(T)::deepclone(T) OrderedSet(T)::asList(T) OrderedSet(T)::clone(T) OrderedSet(T)::deepclone(T) Sequence(T)::asList(T) Sequence(T)::clone(T) Sequence(T)::deepclone(T) (Set needs no change.) In the body of 8.3.9 replace String::size () : Integer The size operation returns the length of the sequence of characters represented by the object at hand. Synonym operation: length() by String::length () : Integer The length operation returns the length of the sequence of characters represented by the object at hand. This is a synonym of the OCL String::size() operation. It is therefore deprecated. In the body of 8.3.9 replace String::toLower () : String Converts all of the characters in this string to lowercase characters. String::toUpper () : String Converts all of the characters in this string to uppercase characters. by String::toLower () : String Converts all of the characters in this string to lowercase characters. This is a synonym of the OCL String::toLowerCase() operation. It is therefore deprecated. String::toUpper () : String Converts all of the characters in this string to uppercase characters. This is a synonym of the OCL String::toUpperCase() operation. It is therefore deprecated. In the body of 8.3.9 replace String::lastToUpper () : String Converts the last character in the string to a lowercase character. by String::lastToUpper () : String Converts the last character in the string to an uppercase character. In the body of 8.3.9 replace String::matchBoolean (s:String) : Boolean � Returns true if the string is �true,� �false,� �0,� or �1.� The method is not case sensitive. String::matchInteger (i:Integer) : Boolean � Returns true if the string represents an integer. String::matchFloat (i:Integer) : Boolean Returns true if the string represents a float. by String::matchBoolean () : Boolean � Returns true if the string is �true,� �false,� �0,� or �1.� The method is not case sensitive. String::matchInteger () : Boolean � Returns true if the string represents an integer. String::matchFloat ) : Boolean Returns true if the string represents a real. This is a synonym of the matchReal() operation. It is therefore deprecated. String::matchReal () : Boolean Returns true if the string represents a real. In the body of 8.3.9 replace String::asInteger() : Boolean Returns a Integer value if the string can be interpreted as as integer. Null otherwise. String::asFloat() : Boolean Returns a Float value if the string can be interpreted as as float. Null otherwise. by String::asInteger() : Integer Returns a Integer value if the string can be interpreted as as integer. Null otherwise. String::asFloat() : Real Returns a Real value if the string can be interpreted as as real. Null otherwise. This is a synonym of the asReal() operation. It is therefore deprecated. String::asReal() : Real Returns a Real value if the string can be interpreted as as real. Null otherwise. In 8.3.9 give each operation a sub-sub-sub-section number as for other types
Actions taken:
December 19, 2008: received issue
July 15, 2014: closed issue

Issue 13183: QVTo Standard Library. Clarification of the side-effect operations is needed. (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody)
Nature: Clarification
Severity: Minor
Summary:

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

Resolution: Issue 19146 resolution makes the behaviour of List clear. Dict clarified below and a typo String clarified below.
Revised Text: In 8.3.7.1 Dictionary get change The null value is returned is not present. to The null value is returned if k is not present. Modifying the returned value modifies the value stored in the dictionary. In 8.3.7.4 Dictionary put change Assigns a value to a key. to Modifies the dictionary by assigning a value to a key. Modifying the value modifies the value stored in the dictionary. In 8.3.7.5 Dictionary clear change Removes all values in the dictionary to Modifies the dictionary by removing all values. In 8.3.7.7 Dictionary values change Returns the list of values in a list. The order is arbitrary. to Returns a new list of the values in the dictionary. The order is arbitrary. Modifying the returned list does not modify the contents of the dictionary. Modifying the values in the list modifies the values stored in the dictionary. In 8.3.7.8 Dictionary keys change Returns the list of keys in a list. The order is arbitrary. to Returns a new list of keys to the dictionary. Modifying the returned list does not modify the contents of the dictionary. Modifying the values in the list may modify the keys to the dictionary contents giving unpredictable behaviour. If mutable types such as List or Dictionary are used as Dictionary keys, applications should take care to create clones where appropriate. In 8.3.9 String change All string operations defined in OCL are available. to All string operations defined in OCL 2.4 are available. An OCL String is immutable and so there are no operations that modify strings.
Actions taken:
December 19, 2008: received issue
July 15, 2014: closed issue

Issue 13222: Explanation of the 'Model::removeElement' operation needs clarification (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. E. Victor Sanchez, vsanchez(at)opencanarias.com)
Nature: Clarification
Severity: Minor
Summary:

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

Resolution: simple change
Revised Text: In 8.3.5.4 Model::removeElement change Removes an object of the model extent. All links that the object have with other objects in the extent are deleted to Removes an object of the model extent. All links between the object and other objects in the extent are deleted. References from collections to the ends of deleted links are removed. References from noncollections are set to null.
Actions taken:
January 13, 2009: received issue
July 15, 2014: closed issue

Issue 13223: explanation of the operation: 'List(T)::insertAt(T,int) (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. E. Victor Sanchez, vsanchez(at)opencanarias.com)
Nature: Revision
Severity: Minor
Summary:

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

Resolution: Yes. Improved wording in Issue 19146. Disposition: See issue 19146 for disposition
Revised Text:
Actions taken:
January 13, 2009: received issue
July 15, 2014: closed issue

Issue 13228: Missing operations on Lists (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. E. Victor Sanchez, vsanchez(at)opencanarias.com)
Nature: Enhancement
Severity: Significant
Summary:

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

Resolution: Yes. Revised wording in 132 is explicitly one-based. Disposition: See issue 19146 for disposition
Revised Text:
Actions taken:
January 13, 2009: received issue
July 15, 2014: closed issue

Issue 13251: add the following operations to mutable lists (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. E. Victor Sanchez, vsanchez(at)opencanarias.com)
Nature: Enhancement
Severity: Minor
Summary:

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

Resolution: And remove() from Issue 13228. A List is not a Collection so we need two removeAll's. Additional operations in Issue 19146. Disposition: See issue 19146 for disposition
Revised Text:
Actions taken:
January 13, 2009: received issue
July 15, 2014: closed issue

Discussion:

Issue 13252: QVTo Standard Lybrary and typedefs Issue. Extending OCL predefined types (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody)
Nature: Uncategorized Issue
Severity:
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.

Resolution: 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.
Revised Text: In 8.2.2.24 Typedef delete This is specifically used in the QVT standard library to attach operations to pre-defined primitive types, like String and Collections.
Actions taken:
January 13, 2009: received issue
December 22, 2015: Resolved
March 29, 2016: closed issue

Discussion:

It is hard to tackle this properly until the OCL type system is clearer. OCL 2.5 should define what it  means to prepare a loaded metamodel for OCL usage. This definition can form the basis of a QVT  clarification..  Disposition: Deferred

Issue 13264: Pag 63, Section 8.2.1.1 OperationalTransformation (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody)
Nature: Revision
Severity: Minor
Summary:

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

Resolution: simple change
Revised Text: In the final editorial paragrpah of 8.2.1.1 OperationalTransformation change is a subclass of Module (see: ImperativeOCL package), to is a subclass of Module
Actions taken:
January 15, 2009: received issue
July 15, 2014: closed issue

Issue 13265: Page 65, Notation Section 8.2.1.3 Module (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody)
Nature: Revision
Severity: Minor
Summary:

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

Resolution: It's not obviously sensible, but is it actually wrong? If there are many configuration properties, it may be convenient to partition them hierarchically. cf. java.vm.specification.vendor. The punctuation is however confusing; add a space.
Revised Text: In 8.2.1.1 OperationalTransformation change Properties that are configuration properties are declared using the configuration qualifier keyword. configuration property UML::Attribute::MAX_SIZE: String; to Properties that are configuration properties may have hierarchical scope. They are declared using the configuration qualifier keyword. configuration property UML::Attribute::MAX_SIZE : String;
Actions taken:
January 15, 2009: received issue
July 15, 2014: closed issue

Issue 13266: Page 72, Figure 8-2 (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody)
Nature: Revision
Severity: Minor
Summary:

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

Resolution: Duplicates in part Issue 12527. Disposition: See issue 12527 for disposition
Revised Text:
Actions taken:
January 15, 2009: received issue
July 15, 2014: closed issue

Discussion:

Issue 13267: Page 73, Section 8.2.1.10 OperationalTransformation (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody)
Nature: Revision
Severity: Minor
Summary:

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

Resolution: Yes. Already correct in the QVT 1.1 models
Revised Text: In 8.2.1.10 ImperativeOperation change overridden: Operation [0..1] to overridden: ImperativeOperation [0..1]
Actions taken:
January 15, 2009: received issue
July 15, 2014: closed issue

Issue 13268: Page 73: Section 8.2.1.11 Helper (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody)
Nature: Revision
Severity: Minor
Summary:

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

Resolution: The usage or OrderedTuple seems misguided since an ordinary OCL Tuple does very similar things without a positional hazard and without noticeable lexical overhead. Only the case of TupleLiteralEx/UnpackExp is plausibly defined in QVT 1.1 and neither of the QVT implementations (SmartQVT or Eclipse QVT) support OrderedTuple. Therefore eliminate TupleLiteralExp, UnpackExp and OrderedTupleType and OrderedTupleLiteralPart. Note that there are no editing instructions for the grammar. It is not clear that OrderedTuples were really supported at all.
Revised Text: In 8.1.12 replace var f := lookForAFooInstance(); var (atom: Atom, bar: Bar) := f.foo2atombar(); by var f := lookForAFooInstance(); var t := f.foo2atombar(); � Tuple(atom: Atom, bar: Bar) var atom := t.atom; var bar := t.bar; In 8.1.14 replace These are mutable lists, dictionary types, and ordered tuples. by These are mutable lists and dictionary types. In 8.1.14 remove An ordered tuple is a tuple whose slots are unnamed. It can be manipulated in a more flexible way than tuples with named slots since it can be packed and unpacked more directly. var mytuple := Tuple{1,2,3}; // an ordered tuple literal var (x,y,z) := mytuple; // unpacking the tuple into three variables In Fig 8.4 remove UnpackExp In Fig 8.7 and accompanying explanatory text remove OrderedTupleType, OrderedTupleLiteralExp, OrderedTupleLiteralPart In 8.2.1.15 MappingOperation replace After call resolution, all the parameters of the mapping are passed as a tuple. The parameters include, in this order: the context parameter by After call resolution, the parameters of the mapping include: the context parameter In 8.2.2.16 ReturnExp replace If the operation declares more than one result parameter, the value is assigned to the tuple representing the collection of results. This requires that the type of the value passed to the result expressions is a tuple. by If the operation declares more than one return parameter, the result is a tuple with a tuple part for each return parameter. When the return expression value is omitted, this tuple is created automatically from the assignable result parameters. Alternatively the return expression value may be an explicitly constructed tuple with one part for each return parameter. Remove 8.2.2.22 UnpackExp Remove 8.2.2.27 OrderedTupleType Remove 8.2.2.31 OrderedTupleLiteralExp Remove 8.2.2.32 OrderedTupleLiteralPart In 8.3.3.1 repr remove Object::asOrderedTuple
Actions taken:
January 15, 2009: received issue
July 15, 2014: closed issue

Issue 13269: Page 75: Section 8.2.1.13 Constructor (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody)
Nature: Revision
Severity: Minor
Summary:

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

Resolution: Yes. But we can go all the way by modeling the ConstructorBody constraint
Revised Text: In 8.2.1.13 Constructor change /body: BlockExp [0..1]{composes}(from ImperativeOperation) The expression serving to populate the object using the given parameters. This expression should necessarily be an ObjectExp instance. to /body: ConstructorBody [0..1]{composes}(from ImperativeOperation) The imperative implementation for this constructor.
Actions taken:
January 15, 2009: received issue
July 15, 2014: closed issue

Issue 13270: Page 75: Section 8.2.1.14 ContextualProperty (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody)
Nature: Revision
Severity: Minor
Summary:

missed text: there is a missed text related to the initExpression association.  discussion: If we have a look to the diagram in figure 8.2, we may realize that a description of the initExpression association is missed.  suggestion: include the following text in the association's description:  initExpression: OclExpression [0..1] {composes}      An optional OCL Expression to initialize the contextual property.

Resolution: Yes. Already correct in the QVT 1.1 models
Revised Text: In 8.2.1.14 ContextualProperty add initExpression: OclExpression [0..1] {composes} An optional OCL Expression to initialize the contextual property
Actions taken:
January 15, 2009: received issue
July 15, 2014: closed issue

Issue 13271: Page 83: Section 8.2.1.22 MappingCallExp (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody)
Nature: Revision
Severity: Minor
Summary:

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

Resolution: Duplicates in part Issue 12527. Disposition: See issue 12527 for disposition
Revised Text:
Actions taken:
January 15, 2009: received issue
July 15, 2014: closed issue

Issue 13272: Page 83: Notation Section 8.2.1.22 MappingCallExp (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody)
Nature: Revision
Severity: Minor
Summary:

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

Resolution: OCL provides an 'implicit collect' shorthand, so 'imperative collect' is a better contrast
Revised Text: In 8.1.6 Inlining Mapping Operations replace the collect shorthand by the imperative collect shorthand In 8.2.1.21 MappingCallExp replace the �collect� shorthand by the �imperative collect� shorthand In 8.2.2.8 SwitchExp replace the �collect� shorthand by the �imperative collect� shorthand
Actions taken:
January 15, 2009: received issue
July 15, 2014: closed issue

Issue 13273: Page 83: Notation Section 8.2.1.22 MappingCallExp (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody)
Nature: Revision
Severity: Minor
Summary:

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

Resolution: yes
Revised Text: In 8.2.1.21 MappingCallExp replace self.ownedElement->map class2table(); // shorthand of self.ownedElement->xcollect(i) i.map class2table(); by self.ownedElement->map class2table(); // shorthand of self.ownedElement->xcollect(i | i.map class2table());
Actions taken:
January 15, 2009: received issue
July 15, 2014: closed issue

Issue 13274: Page 84: Notation Section 8.2.1.22 MappingCallExp (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody)
Nature: Revision
Severity: Minor
Summary:

Problem's text: ->forEach (cl) cleaningTransf.map removeDups(cl);  discussion: EBNF and forExp suggest using always braces to enclose the forExp body.  Suggestion: Enclose the forEach's body with '{' and '}'. Note that there are two forExps in this section

Resolution: yes
Revised Text: In 8.2.1.21 MappingCallExp replace // first pass: cleaning the UML classes uml->objectsOfType(Class) // invoking the imported transformation ->forEach (cl) cleaningTransf.map removeDups(cl); // second pass: transforming all UML classes uml ->objectsOfType(Class)->forEach (cl) cl.map umlclass2javaclass (); // equivalent to: this.map umlclass2javaclass(cl) by // first pass: cleaning the UML classes uml->objectsOfType(Class) // invoking the imported transformation ->forEach (cl) { cleaningTransf.map removeDups(cl); } // second pass: transforming all UML classes uml ->objectsOfType(Class)->forEach (cl) { cl.map umlclass2javaclass(); }// equivalent to: this.map umlclass2javaclass(cl)
Actions taken:
January 15, 2009: received issue
July 15, 2014: closed issue

Issue 13275: Page 86: Notation Section 8.2.1.23 ResolveExp (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody)
Nature: Revision
Severity: Minor
Summary:

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

Resolution: yes
Revised Text: In 8.2.1.22 ResolveExp replace myprop := mylist->late resolve(Table); // shorthand for mylist->forEach(i) i.late resolve(Table) by (and correct font size of) myprop := mylist->late resolve(Table); // shorthand for mylist->forEach(i) { i.late resolve(Table); }
Actions taken:
January 15, 2009: received issue
July 15, 2014: closed issue

Issue 13276: Page 87: Section 8.2.1.24 ObjectExp (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody)
Nature: Revision
Severity: Minor
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)"

Resolution: Yes and correct the erroneous bounds change on the spurious redefinition.
Revised Text: In 8.2.1.24 ObjectExp and the QVT 1.1 models replace /instantiatedClass: Class [0..1](from InstanciationExp) Indicates the class of the object to be created or populated. /extent: Variable [0..1](from InstanciationExp) by /instantiatedClass: Class [1](from InstantiationExp) Indicates the class of the object to be created or populated. /extent: Variable [0..1](from InstantiationExp)
Actions taken:
January 15, 2009: received issue
July 15, 2014: closed issue

Issue 13277: Page 87: Section 8.2.1.24 ObjectExp (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody)
Nature: Revision
Severity: Minor
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.

Resolution: yes
Revised Text: In 8.2.1.24 ObjectExp replace see xcollect in ImperativeLoopExp by see xcollect in ImperativeIterateExp
Actions taken:
January 15, 2009: received issue
July 15, 2014: closed issue

Issue 13278: Page 87: Notation Section 8.2.1.24 ObjectExp (03) (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody)
Nature: Revision
Severity: Minor
Summary:

Problem's text: // shorthand for list->xcollect(x) 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{ � });

Resolution: yes
Revised Text: In 8.2.1.24 ObjectExp replace // shorthand for list->xcollect(x) object X{ � } by // shorthand for list->xcollect(x | object X{ � })
Actions taken:
January 15, 2009: received issue
July 15, 2014: closed issue

Discussion:

Issue 13279: Page 89: Figure 8.6 (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody)
Nature: Revision
Severity: Minor
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".

Resolution: Yes. Yes. Yes. Already correct in the QVT 1.1 models
Revised Text: In Figure 8.6 replace the �catchClause� role from TryExp by �exceptClause�. In Figure 8.6 replace the �1� multiplicity on ReturnExp.value by �0..1�. In 8.2.2.3 ComputeExp replace body : OclExpression [1] {composes, ordered} by body : OclExpression [1] {composes}
Actions taken:
January 15, 2009: received issue
July 15, 2014: closed issue

Discussion:

Issue 13280: Page 90: Notation Section 8.2.2.4 WhileExp (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody)
Nature: Revision
Severity: Minor
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 {        count : Integer := 0;        while (count <= source->size()) {           var iterator := source->at(count+1);           if (condition) continue;           body;           count += 1;        };     };    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;     }

Resolution: Yes. Yes.
Revised Text: In 8.2.2.4 WhileExp replace compute (x:MyClass := self.getFirstItem()) while (x<>null) { � } by compute (x:MyClass := self.getFirstItem()) { while (x<>null) { � } } In 8.2.2.6 ForExp replace Collection(T)::forEach(source, iterator, condition,body) = do { count : Integer := 0; while (count <= source->size()) { var iterator := source->at(count+1); if (condition) continue; body; count += 1; }; }; 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; }; }; and Collection(T)::forOne(source, iterator, condition,body) = forEach (i | condition) { body; break; } by Collection(T)::forOne(source, iterator, condition,body) = forEach (iterator | condition) { body; break; }
Actions taken:
January 15, 2009: received issue
July 15, 2014: closed issue

Issue 13281: Page 93: Associations Section 8.2.2.7 ImperativeIterateExp (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody)
Nature: Revision
Severity: Minor
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}

Resolution: Yes. Already correct in the QVT 1.1 models.
Revised Text: In 8.2.2.7 ImperativeIterateExp replace target : Variable [0..1] by target : Variable [0..1] { composes }
Actions taken:
January 15, 2009: received issue
July 15, 2014: closed issue

Issue 13282: Page 95: Notation Section 8.2.2.7 ImperativeIterateExp (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody)
Nature: Revision
Severity: Minor
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 '|'

Resolution: yes
Revised Text: In 8.2.2.7 ImperativeIterateExp replace list[condition]; // same as list->xselect(i; condition) by list[condition]; // same as list->xselect(i | condition)
Actions taken:
January 15, 2009: received issue
July 15, 2014: closed issue

Issue 13283: Page 95: Associations Section 8.2.2.8 SwitchExp (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody)
Nature: Revision
Severity: Minor
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].

Resolution: Yes, and correct spelling of OclExpression too.
Revised Text: In 8.2.2.8 SwitchExp replace elsePart : OclExpresion {composes} [0..1] by elsePart : OclExpression [0..1] {composes}
Actions taken:
January 15, 2009: received issue
July 15, 2014: closed issue

Issue 13284: Page 100: Superclasses Section 8.2.2.8 LogExp (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody)
Nature: Revision
Severity: Minor
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.

Resolution: yes
Revised Text: In 8.2.2.19 LogExp replace Superclasses OperationCallExp by Superclasses OperationCallExp, ImperativeExpression
Actions taken:
January 15, 2009: received issue
July 15, 2014: closed issue

Issue 13285: Page 103: Associations Section 8.2.2.23 InstantiationExp (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody)
Nature: Revision
Severity: Minor
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) };

Resolution: yes
Revised Text: In 8.2.2. 23 InstantiationExp replace // column := self.attribute->forEach new(a) Column(a.name,a.type.name); by // column := self.attribute->forEach(a) { new Column(a.name,a.type.name); }
Actions taken:
January 15, 2009: received issue
July 15, 2014: closed issue

Issue 13286: Page 103: Figure 8.7 (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody)
Nature: Revision
Severity: Minor
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

Resolution: 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.
Revised Text: In Figure 8.7 remove the first two sub-diagrams.
Actions taken:
January 15, 2009: received issue
July 15, 2014: closed issue

Discussion:

Issue 13287: Page 105: Associations Section 8.2.2.24 Typedef (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody)
Nature: Revision
Severity: Minor
Summary:

Problem's text: condition: OclExpression [1]{composes}  discussion: the condition is optional.  suggestion: Replace "[1]" by "[0..1]".

Resolution: Yes. Already correct in the QVT 1.1 models
Revised Text: In 8.2.2.24 Typedef replace condition: OclExpression [1]{composes} by condition: OclExpression [0..1]{composes}
Actions taken:
January 15, 2009: received issue
July 15, 2014: closed issue

Issue 13288: Page 105: Associations Section 8.2.2.26 DictionaryType (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody)
Nature: Revision
Severity: Minor
Summary:

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

Resolution: yes
Revised Text: In 8.2.2.26 DictionaryType replace (see DictLiteralValue) by (see DictLiteralExp)
Actions taken:
January 15, 2009: received issue
July 15, 2014: closed issue

Issue 13289: Page 106: Associations Section 8.2.2.29 DictLiteralExp (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody)
Nature: Revision
Severity: Minor
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.

Resolution: Yes. A dictionary does not need go be ordered. Already correct in the QVT 1.1 models
Revised Text: In 8.2.2.29 DictLiteralExp replace part : DictLiteralPart [*] {composes,ordered} The list of parts contained by this dictionary. by part : DictLiteralPart [*] {composes} The parts contained by this dictionary.
Actions taken:
January 15, 2009: received issue
July 15, 2014: closed issue

Issue 13290: Page 108: Section 8.3 Standard Library (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody)
Nature: Revision
Severity: Minor
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".

Resolution: yes
Revised Text: In 8.3 Standard Library replace This section describes the additions to the OCL standard library. The OCL standard library is an instance of the Library metaclass. by This section describes the additions to the OCL standard library to form the QVT Operational Mappings Library, which is an instance of the Library metaclass.
Actions taken:
January 15, 2009: received issue
July 15, 2014: closed issue

Issue 13331: QVTo Standard Lybrary and typedefs Issue. Extending OCL predefined types (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody)
Nature: Uncategorized Issue
Severity:
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.

Resolution: issue closed, duplicate of issue # 13252
Revised Text:
Actions taken:
December 22, 2008: received issue
January 26, 2009: issue closed, duplicate of issue # 13252

Issue 13913: Typo in 'Model::rootObjects' signature (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. E. Victor Sanchez, vsanchez(at)opencanarias.com)
Nature: Revision
Severity: Minor
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)'

Resolution: yes
Revised Text: In 8.3.5.3 rootObjects change Model::rootobjects(): Set(Element) to Model::rootObjects(): Set(Element)
Actions taken:
April 30, 2009: received issue
July 15, 2014: closed issue

Issue 13987: Minor typographical error in ImperativeIterateExp notation (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. E. Victor Sanchez, vsanchez(at)opencanarias.com)
Nature: Revision
Severity: Minor
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 ";".

Resolution: Duplicates in part Issue 13282. Disposition: See issue 13282 for disposition
Revised Text:
Actions taken:
June 14, 2009: received issue
July 15, 2014: closed issue

Issue 13988: Capitalization of leading characters in multiword operation names (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. E. Victor Sanchez, vsanchez(at)opencanarias.com)
Nature: Revision
Severity: Significant
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.

Resolution:
Revised Text:
Actions taken:
June 14, 2009: received issue
July 15, 2014: closed issue

Discussion:

The suggested spellings are better but the existing spellings are established. It does not seem worth  changing.  Disposition: Closed, No Change

Issue 13989: Typos in signatures of "allSubobjectsOfType" and "allSubobjectsOfKind" (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. E. Victor Sanchez, vsanchez(at)opencanarias.com)
Nature: Revision
Severity: Minor
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)"

Resolution: yes
Revised Text: In 8.3.4.7 allSubobjectsOfType change Element::subobjects(OclType) : Set(Element) to Element::allSubobjectsOfType(OclType) : Set(Element) In 8.3.4.9 allSubobjectsOfKind change Element::subobjectsOfKind(OclType) : Set(Element) to Element::allSubobjectsOfKind(OclType) : Set(Element)
Actions taken:
June 14, 2009: received issue
July 15, 2014: closed issue

Issue 14549: Wrong Chapter reference on Page 2 Language Dimension (qvt-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Original file: ptc/07-07-08.zip  OMG Document Nmber: formal/2008-04-03  Standard document URL https://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 ;)

Resolution: 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.
Revised Text: <Review all cross-references and correct stale definitions> <Replace all usage of Chapter by a cross reference to the corresponding clause>
Actions taken:
October 9, 2009: received issue
July 15, 2014: closed issue

Issue 14573: A referenced picture is missing (qvt-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
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 :(

Resolution:
Revised Text:
Actions taken:
October 20, 2009: received issue
July 15, 2014: closed issue

Discussion:

The figure numbering was resolved in QVT 1.1.  Disposition: Closed, No Change

Issue 14619: QVT 1.1 Opposite navigation scoping operator (Correction to Issue 11341 resolution) (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The resolution for Issue 11341 uses '.' as a property scoping operator.      This is inconsistent with OCL for which class scoping always uses '::' e.g  enumeration is class::literal operation call is class::operation.      Note the clarifying discussion in OCL, justifying Class.allInstances,  explains  that dot is only for operations on instances.

Resolution: Simple correction of '.' to '::' in the grammar.
Revised Text: In 7.13.5 change <keyProperty> ::= <identifier> | 'opposite' '(' <classId> '.' <identifier> ')' to <keyProperty> ::= <identifier> | 'opposite' '(' <classId> '::' <identifier> ')' and <propertyTemplate> ::= <identifier> '=' <OclExpressionCS> | 'opposite' '(' <classId> '.' <identifier> ')' '=' <OclExpressionCS> to <propertyTemplate> ::= <identifier> '=' <OclExpressionCS> | 'opposite' '(' <classId> '::' <identifier> ')' '=' <OclExpressionCS>
Actions taken:
November 11, 2009: received issue
July 15, 2014: closed issue

Discussion:

Issue 14620: QVT 1.1 Inappropriate ListLiteralExp inheritance (Correction to issue 12375 resolution) (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
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.

Resolution: 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.
Revised Text: In the QVTo model and Fig 8.11, where ListLiteralExp already inherits directly from LiteralExp, replace element:OclExpression[*]{composes,ordered} by part:CollectionLiteralPart[*]{composes,ordered} In 8.2.2.29 ListLiteralExp replace the CollectionLiteralExp superclass by LiteralExp, and replace element:OclExpression[*]{composes,ordered} by part:CollectionLiteralPart[*]{composes,ordered} In 8.4.7 BNF replace <collection_item_list> ::= <expression_comma_list> by <collection_item> ::= <expression> ('..' <expression>)? <collection_item_list> ::= <collection_item> (',' <collection_item>)* Add to 8.2.2.24 ListType: Notation An initialized list literal may be created in the same way as an initialized sequence literal. List{1,2,3} List{1..10,12,14..16} Implementation Note ListLiteralExp will become obsolete once OCL eliminates the prohibition on extension of CollectionLiteralExp imposed by the redundant CollectionLiteralExp::kind attribute.
Actions taken:
November 11, 2009: received issue
December 22, 2015: Resolved
March 29, 2016: closed issue

Discussion:

Issue 14640: QVT 1.1 QVTr syntax mapping (correction to Issue 10646 resolution) (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The numerous problems identified in https://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?

Resolution: QVTr syntax mapping (correction to Issue 10646 resolution) The numerous problems identified in [1]https://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. ---------------------------------------------------------------------------------------- [1] https://www.omg.org/archives/qvt-rtf/msg00094.html
Revised Text:
Actions taken:
November 16, 2009: received issue
December 22, 2015: Deferred
March 29, 2016: closed issue

Discussion:

It is hard to tackle this properly until we have the model-driven specification generated technology that  OCL 2.5 will pioneer.  Disposition: Deferred

Issue 14835: Please provide a non-null text in the Scope section of documents ptc/09-12-06 and ptc/09-12-05 (qvt-rtf)

Click here for this issue's archive.
Source: Thematix Partners LLC (Dr. Doug Tolbert, dtolbert(at)bluwale.com)
Nature: Uncategorized Issue
Severity:
Summary:

Please provide a non-null text in the Scope section of documents ptc/09-12-06 and ptc/09-12-05

Resolution:
Revised Text:
Actions taken:
December 7, 2009: received issue
July 15, 2014: closed issue

Discussion:

The QVT 1.0 scope text was restored for the QVT 1.0 FAS.  Disposition: Closed, No Change

Issue 15215: QVT1.1: Add an operation Model::getURI() (qvt-rtf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

Sometimes, it is useful to get the URI corresponding to the resource of a given transformation input model parameter.      I suggest adding an operation for this purpose in clause 8.3.5 Operations on models.      Model::getURI() : String      Returns the string of the URI corresponding to the model's resource. This operation produces an empty string for a model corresponding to an output parameter       For what it's worth, below is a patch for the Eclipse M2M implementation of QVTOperational where I prototyped such an operation.

Resolution:
Revised Text:
Actions taken:
April 20, 2010: received issue
July 15, 2014: closed issue

Discussion:

This seems reasonable but:  UML already provides an inherited Package::URI field so Model::getURI() would be confusing.  Perhaps getExternalURI() or getDocumentURI(). However this is not a QVT issue; if there is a  requirement for contextual knowledge of a Model, surely UML should provide it?  A QVT transformation hides its context and for a transformation realized by a cascade communicating  through memories or pipes, what would the URI be?  Users who understand and control the context can pass the context as a parameter/control model.  More generally there is a problem in defining the URI of a transformation that generates a datadependent  number of output models. Any get context solution would address this.  Disposition: Closed, No Change

Issue 15376: QVT 1.1 8.1.10 Errors in Examples (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
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.

Resolution: 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.
Revised Text: In 8.1.10 Replace The example below illustrates its usage: given a list of java classes (JClass instances) that have a packageName field indicating the name of the owning Package, the JClass2JPackage transformation creates a Java Package (JPackage) for each package name found in the list of java classes. transformation JClass2JPackage(inout javamodel:JAVA); main () { javamodel->objectsOfType(JClass)->jclass2jpackage();} mapping Class::jclass2jpackage() : JPackage () { init { result := resolveIn(jclass2jpackage,true) ->select(p|self.package=p.name)->first(); if result then return; } name := self.package; } In the example above, return is used to avoid creating more than two packages having the same name. by:JClass2JPackage.qvto modeltype JAVA uses 'https://www.omg.org/qvt/examples/javamodel'; transformation JClass2JPackage(inout javamodel : JAVA); main () { javamodel.objectsOfType(JClass)->jclass2jpackage(); } mapping JClass::jclass2jpackage() : JPackage { init { result := resolveoneIn(JClass::jclass2jpackage, p : JPackage | self.packageName = p.name); } if (name = null) { name := self.packageName; } } In the example above, the JClass::jclass2jpackage mapping is invoked for each JClass. Within the mapping, resolveoneIn, without a source expression, is used to examine all JPackage's created by the JClass::jclass2jpackage mapping. The p iterator traverses the JPackage's and the condition selects only those whose name matches the JClass's packageName. Using resolveoneIn rather than resolveIn ensures that at most one match is returned. The match is assigned to result for re-use avoiding the creation associated with a null result. A redundant re-assignment of name in the re-used JPackage is avoided by testing whether it has already been assigned. Replace The example below treats potential cyclic due to class inheritance dependencies. transformation Uml2Java(in uml:UML,out java:JAVA) main() : JAVA::Interface { uml->objectsOfType(Class)->map transformClass(); } mapping UML::transformClass() : JAVA::Interface () { name := "Ifce".concat(self.name); base := self.superClass->late resolve(JAVA::Interface); } byUML2JavaLate.qvto modeltype JAVA uses 'https://www.omg.org/qvt/examples/javamodel';modeltype UML uses 'https://www.omg.org/qvt/examples/umlmodel'; transformation Uml2Java(in uml:UML,out java:JAVA); main() { uml.objectsOfType(Class)->map transformClass(); } mapping UML::Class::transformClass() : JAVA::Interface { name := "Ifce" + self.name; base := self.superClass->late resolve(JAVA::Interface); } In the example above, the UML::Class::transformClass() mapping is invoked for each Class in the uml model. The mapping causes a corresponding JAVA::Interface to be created with name and base property initialization. The name is initialized by a simple String concatenation. The base requires the JAVA::Interface's corresponding to each self.superClass to be resolved and referenced. The resolve, with a source expression, locates the JAVA::Interface created by any mapping from the object referenced by the source expression. Application of this on a collection resolves all creations from each of the collection elements. Since it is awkward to ensure that the order of mapping execution is shallowest-superClass-first, a late resolve is used thereby deferring the assignment of the base property until all possible superClass'es have been created by all possible UML::Class::transformClass() executions. A late resolve expression is always executed in conjunction with an assignment. The assignment initially returns null, and the context that is required to execute the assignment later is stored as part of the trace state. Replace transformation Uml2Java(in uml:UML,out java:JAVA) main() : JAVA::Interface { uml->objectsOfType(Class)->map transformClass(); uml->objectsOfType(Class)->map transformClassInheritance(); } mapping UML::transformClass() : JAVA::Interface { name := "Ifce".concat(self.name); } mapping UML::transformClassInheritance() : JAVA:Interface { base := self.superClass->resolveIn(transformClass,JAVA::Interface); } In terms of execution, the ?late resolve? expression is always related to an assignment. Conceptually it returns null but in the meantime it stores all the information that is required to re-execute later the trace inspection and the assignment. byUML2JavaTwoPass.qvto modeltype JAVA uses 'https://www.omg.org/qvt/examples/javamodel';modeltype UML uses 'https://www.omg.org/qvt/examples/umlmodel'; transformation Uml2Java(in uml:UML,out java:JAVA); main() { uml.objectsOfType(Class)->map transformClass(); uml.objectsOfType(Class)->map transformClassInheritance(); } mapping UML::Class::transformClass() : JAVA::Interface { name := "Ifce" + self.name; } mapping UML::Class::transformClassInheritance() : JAVA::Interface { init { result := self.resolveoneIn(UML::Class::transformClass); } base := self.superClass->resolveIn(UML::Class::transformClass); } The main program now invokes the UML::Class::transformClass() mapping for each Class in the uml model to perform the first pass, then it invokes the UML::Class::transformClassInheritance() mapping for each Class to perform the second pass. The first mapping just creates a corresponding JAVA::Interface with a name initialized by a simple String concatenation. The second mapping relocates the JAVA::Interface created by the first mapping using an init section within which resolveoneIn, with self as a source expression, locates the result of the UML::Class::transformClass() mapping when applied to self. base is initialized by assigning the results of each of the superClass resolutions.. At the end of 8.2.1.22 ResolveExp Notation add See also the third and fourth examples of Section 8.1.10. At the end of 8.2.1.23 ResolveInExp Notation add See also the second and fourth examples of Section 8.1.10.
Actions taken:
July 18, 2010: received issue
December 22, 2015: Resolved
March 29, 2016: closed issue

Discussion:

Help wanted.  Disposition: Deferred

Issue 15390: QVT 1.1 8 Unclear mapping operation characteristics (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
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.

Resolution: 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.
Revised Text:
Actions taken:
July 30, 2010: received issue
December 22, 2015: Deferred
March 29, 2016: closed issue

Discussion:

Help wanted.  Disposition: Deferred

Issue 15411: Unclear transformation rooting condition (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
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

Resolution: 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 [1]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. ---------------------------------------------------------------------------------------- [1] http://www.springerlink.com/content/9x368617317l3q87/
Revised Text:
Actions taken:
August 10, 2010: received issue
December 22, 2015: Deferred
March 29, 2016: closed issue

Discussion:

This requires some research work.  Disposition: Deferred

Issue 15416: Derived properties in QVTr (qvt-rtf)

Click here for this issue's archive.
Source: NASA (Dr. Maged Elaasar, Maged.E.Elaasar(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

If I want to specify a uni-directional transformation using QVTr, is it ok to use "derived" properties in source domains' object templates? I guess since the transform is not meant to be run in the opposite direction, this will not create a problem?    If that is allowed, it would be a good additional feature of QVTr to allow the definition of new derived properties right in the transform, instead of having them only in the source metamodel.    For example    transform A (...) {    property Class::allSuperClass : Class {  self->closure(self.superClass) // closure might not be standard collection op but I used it just to demonstrate the point  }    relation B {  checkonly domain source c:Class {  allSuperClass = super:Class {...}  }  }    }    does this make sense?

Resolution:
Revised Text:
Actions taken:
August 13, 2010: received issue
July 15, 2014: closed issue

Discussion:

Use of derived properties while checking should pose no problem. The existing text on values is  sound.  Use of derived properties while enforcing is highly suspect. Derived properties are often readonly. If  changeable then the derived interrelationships are an issue for the metamodel not for QVTr.  When QVTr acquires well-formedness rules, an enforeable readonly property could be diagnosed.  QVTr supports queries that can be used to emulate custom derived properties.  Disposition: Closed, No Change

Issue 15417: Rule Overriding in QVTr (qvt-rtf)

Click here for this issue's archive.
Source: NASA (Dr. Maged Elaasar, Maged.E.Elaasar(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
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.

Resolution: 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.
Revised Text:
Actions taken:
August 13, 2010: received issue
December 22, 2015: Deferred
March 29, 2016: closed issue

Discussion:

[Comments from inadvertently raised Issue 15524]  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.  QVT 1.2 RTF Report Page 180 of 190  Object Management Group  RTF/FTF Report  My ideas for UMLX were not complete but I think that they may be sounder than QVTr's.  [If Transformation is just a Class, one area for study vanishes.]  Disposition: Deferred

Issue 15424: Figure 7.3 (qvt-rtf)

Click here for this issue's archive.
Source: Institute for Defense Analyses (Dr. Steven Wartik, swartik(at)ida.org)
Nature: Uncategorized Issue
Severity:
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?

Resolution: 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.
Revised Text: Above Figure 7.3 add Instance diagrams omit the usual UML decorations, so the reader should note that a top to bottom composition layout is used in Figure 7.3. Thus the PropertyTempateItem for 'attribute' is composed by the ObjectTemplateItem for 'Class' and composes the ObjectTemplateItem for 'Attribute'.
Actions taken:
August 3, 2010: received issue
July 15, 2014: closed issue

Issue 15523: QVTr already has queries but they are much less user friendly than e.g. MOFM2T's equivelent (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
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.

Resolution: 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.
Revised Text: In 7.13.5 replace <query> ::= 'query' <identifier> by <query> ::= 'query' <queryId> and add <queryId> ::= <PathNameCS> In 9.18 replace Query ::= 'query' QueryName '(' by Query ::= 'query' QueryId '(' and add QueryId ::= PathNameCS
Actions taken:
August 13, 2010: received issue
December 22, 2015: Resolved
March 29, 2016: closed issue

Discussion:

Perhaps it is sufficient to allow a QVTr query to be invoked with its first argument as a syntactical  source rather than argument.  Disposition: Deferred

Issue 15524: Rule Overriding in QVTr (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
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.

Resolution: 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
Revised Text:
Actions taken:
August 13, 2010: received issue
July 15, 2014: closed issue

Issue 15886: Specification of deletion semantics (qvt-rtf)

Click here for this issue's archive.
Source: Institute for Defense Analyses (Dr. Steven Wartik, swartik(at)ida.org)
Nature: Uncategorized Issue
Severity:
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.

Resolution: 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.
Revised Text:
Actions taken:
October 12, 2010: received issue
December 22, 2015: Deferred
March 29, 2016: closed issue

Discussion:

I see no justification for not using OCL to express the Annex B semantic. The OCL could then form  part of real tests.  I see little prospect of progress here till we have a conformant working QVTr implementation.  Disposition: Deferred

Issue 15917: bug in the uml to rdbms transformation example (qvt-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

In the UML to rdbms transformation code given in section A.2.3 :      -- mapping to update a Table with new columns of foreign keys  mapping Association::asso2table() : Table  when {self.isPersistent();}  {  init {result := self.destination.resolveone(Table);}  foreignKey := self.map asso2ForeignKey();  column := result.foreignKey->column ;  }      The mapping asso2table is supposed to update a table by adding new columns, but with the last line of the mapping, the existing columns are all replaced by the new ones. I suggest to replace the last line with :    column += result.foreignKey->column ;

Resolution: yes
Revised Text: In A.2.3 mapping Association::asso2table() change column := result.foreignKey->column ; to column += result.foreignKey->column ;
Actions taken:
January 7, 2011: received issue
July 15, 2014: closed issue

Discussion:

Issue 15977: abstract/concrete syntax for try/catch in clauses 8.2.2.13 & 8.2.2.14 lacks support for retrieving the exception caught (qvt-rtf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
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  };

Resolution: 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.
Revised Text: In 8.2.2.13 TryExp add The exceptClauses are searched in order to select the first exceptClause that provides an exception type to which the raised exception conforms. If an exceptClause is selected, its body is executed. In 8.2.2.14 CatchExp add The caught expression may be accessed in the body expression using the exceptionVariable whose apparent (static) type is the most derived common super type of all catchable exception types. In 8.2.2.14 CatchExp and the QVT 1.1 models add exceptionVariable : String [0..1] The variable through which the caught exception may be accessed. In 8.2.2.14 CatchExp and the QVT 1.1 models change exception: Type [*] {ordered} to exception: Type [+] {ordered} In 8.4.7 change <except> ::= 'except' '(' <scoped_identifier_list> ')' <expression_block> to <except> ::= 'except' '(' [<identifier> ':'] <scoped_identifier> [',' <scoped_identifier>]* ')' <expression_block>
Actions taken:
January 21, 2011: received issue
July 15, 2014: closed issue

Issue 15978: clause 8.3.1.4 Exception needs to document the taxonomy of Exception types in QVT1.1 (qvt-rtf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
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)

Resolution: 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.
Revised Text: In 8.2.2.15 RaiseExp change The notation uses the raise keyword with the exception name as body. The exceptions can be provided as simple strings. In that case the implicit referred exception is the user Exception defined in the QVT standard library and the string is the argument of the raise expression. myproperty := self.something default raise "ProblemHere"; to The notation uses the raise keyword followed by the exception type name and arguments for one of the expression type name constructors. myproperty := self.something default raise StringException("ProblemHere"); The exceptions can be provided as simple strings. This is a shorthand for raising a StringException with the string as the constructor argument myproperty := self.something default raise "ProblemHere"; Following 8.3.1.4 Exception add additional sub-sub-sub-sections <new sub-sub-sub-section> StringException The StringException supports the simple string-valued shorthand of a RaiseExp. Superclasses Exception Constructor StringException(reason : String) reason : String [1] The reason provided on construction. <new sub-sub-sub-section> AssertionFailed The AssertionFailed exception supports a fatal AssertExp. Superclasses Exception Constructor AssertionFailed(reason : LogExp) Attributes reason : LogExp [1] The reason provided on construction. In 8.4.7 change <raise_exp> ::= 'raise' <scoped_identifier> ('(' <arg_list>? ')')? to <raise_exp> ::= 'raise' <scoped_identifier> ('(' <arg_list>? ')')? | 'raise' <STRING>
Actions taken:
January 21, 2011: received issue
July 15, 2014: closed issue

Discussion:

Issue 17538: Consider submitting the QVTO profile out of UML Profile for NIEM, section 9-2 to QVT 1.2 (qvt-rtf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
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.

Resolution:
Revised Text:
Actions taken:
August 3, 2012: received issue
July 15, 2014: closed issue

Discussion:

This would be an interesting enhancement and could perhaps form an Annex. However it is beyond  the scope for the active members of this RTF. There has been no response from other RTF members  to a couple of help-wanted requests, so this enhancement can be closed for lack of interest.  Disposition: Closed, No Change

Issue 18323: Trace data for an 'accessed' transformation (qvt-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
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.

Resolution: 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 [1]QVT13-23 makes clear that the trace data contains a trace record for every mapping. ---------------------------------------------------------------------------------------- [1] http://issues.omg.org/browse/QVT13-23
Revised Text:
Actions taken:
December 27, 2012: received issue
December 22, 2015: Duplicate or Merged
March 29, 2016: closed issue

Discussion:

Help wanted.  Disposition: Deferred

Issue 18324: No trace data for disjuncting mapping (qvt-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
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.

Resolution: 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 [1]QVT13-99 resolution. ---------------------------------------------------------------------------------------- [1] http://issues.omg.org/browse/QVT13-99
Revised Text: In 8.1.4 change { init { ? } population { ? } end { ? } } to { // inhibition section - see Section 8.1.10.2init { ? } // instantiation section - see Section 8.1.10.2population { ? } end { ? } } In 8.1.4 replace Between the initialization and the population sections, there is an implicit section, named the instantiation section, which creates all output parameters that have a null value at the end of the initialization section. This means that, in order to return an existing object rather than creating a new one, one simply needs to assign the result parameter within the initialization section. by Before the init, there is an implicit section, named the inhibition section, which suppresses redundant re-execution of a mapping. Following the init and before the population sections, there is an implicit section, named the instantiation section, which creates all output parameters that have a null value at the end of the initialization section. The null value tests mean that, in order to return an existing object rather than creating a new one, one simply needs to assign the result parameter within the init section.The instantiation section also creates the trace record of the execution. In 8.1 before 8.1.10 Add a new section 8.1.x Tracing and Resolving Execution of a mapping establishes a trace record to maintain the relationship between its context object and the result object or objects. This relationship can be queried using one of the eight resolve expressions. 8.1.x.1 Trace Records Execution of a transformation builds the overall trace-data which comprises a sequence of trace-records; one for each mapping execution in execution order. This includes every mapping executed by, accessed or extended, transformations or libraries, but not those by transformation invocations. Each trace-record comprises: *context-parameter - the context parameter object *in-parameters - the in and inout parameter objects or values *invoked-mapping - the invoked mapping operation *executed-mapping - the executed mapping operation *out-parameters - the out parameter objects or values *result-parameters - the result parameter object or objects The invoked-mapping and executed-mapping operations may differ when a disjuncting mapping is executed. The invoked-mapping is the disjuncting mapping. The executed-mapping is the successfully selected candidate mapping or null. inout parameters are traced once as in-parameters; they cannot change during production of the trace-record. The trace-record is created during the instantiation section of the selected candidate mapping, which is after the initialization section and before the population section. A trace-record is created by every mapping execution, unless predicates or initialization section fail. A trace-record is created or re-used by every mapping invocation, unless predicates or initialization section fail. In the case of a standard mode execution for which no candidate mapping is selected, the executed-mapping, out-parameters and result-parameters are null. The following example mapping declarations mapping X::disjunctingMapping(in p1:P1, inout p2:P2, out p3:P3) : r1:R1, r2:R2 disjuncts mappingName, ... {} mapping X::mappingName(in p1:P1, inout p2:P2, out p3:P3) : r1:R1, r2:R2 ..{...} may be invoked as var t := anX.map disjunctingMapping(aP1, aP2, aP3); var anR1 := t.r1; var anR2 := t.r2; to create the following trace-record. (Hyphens are used in names that are helpful for exposition, but which are not accessible to program code.) object Trace-Record { context-parameter := anX; in-parameters := Sequence{aP1, aP2}; invoked-mapping := X::disjunctingMapping; executed-mapping := X::mappingName; out-parameters := Sequence{aP3}; result-parameters := Sequence{anR1, anR2}; } The trace-record traces the relationship between mapping inputs and outputs; between the inputs {anX, aP1, aP2} and the outputs {aP3, anR1, anR2}. Note that there is no trace for object construction in helpers or for nested object construction in mappings. If a trace of all objects is needed, a mapping must be used to create each object as a mapping output. 8.1.x.2 The inhibition and instantiation sections The auto-generated inhibition and instantiation sections surround the initialization section of a mapping, whose general structure is: mapping X::mappingName(in p1:P1, inout p2:P2, out p3:P3) : r1:R1, r2:R2 when { ? } where { ? } { // inhibition sectionvar trace-records := trace-data ->select(executed-mapping=X::mappingName) ->select(context-parameter=self) ->select(in-parameters->at(1)=p1) ->select(in-parameters->at(2)=p2); if (trace-records->notEmpty()) { var trace-record := trace-records->at(1); p3 := trace-record.out-parameters->at(1); r1 := trace-record.result-parameters->at(1); r2 := trace-record.result-parameters->at(2); return; }; init { ? } // instantiation sectionif (p3 == null) p3 := object P3{}; if (r1 == null) r1 := object R1{}; if (r2 == null) r2 := object R2{}; trace-data += object Trace-Record{ context-parameter:=self, in-parameters:=Sequence{p1, p2}, invoked-mapping:=X::dislunctingName, executed-mapping:=X::mappingName, out-parameters:=Sequence{p3}, result-parameters:=Sequence{r1,r2} }; population { ? } end { ? } } In the inhibition section, the trace-data is consulted to locate all trace-records whose executed-mapping, context-parameter and in-parameters match the new candidate mapping invocation. If a match is found, the previous out-parameters and result-parameters are used as the mapping return values and the mapping re-execution is suppressed. Then the initialization section provides an opportunity for the default null values of outputs to be replaced by something more useful. If the null values are unchanged, the instantiation section constructs an object for each object. inout parameters may not be changed during the initialization section. Finally the execution of the mapping is recorded by adding a trace-record to the trace-data. A candidate mapping execution is suppressed to avoid creating a trace-record whose context-parameter, in-parameters, invoked-mapping and executed-mapping fields duplicate another trace-record already in the trace-data. When comparing trace-record fields, Class instances are compared as objects without regard for their content, and DataType values are compared by deep value equality. Traced object instances may therefore be modified between mapping executions without inhibiting detection of re-execution since only the object references are traced. However any modification of a traced DataType value such as a List inhibits detection of a re-execution since the entire value is traced. When a re-execution attempt is detected, the re-execution is suppressed without any additional trace-record being created. Note that traced Class instances are mutable and so the re-used value may have changed in the interim. 8.1.x.3 resolve() - Resolution of target objects by Type The trace data may be queried to identify all target objects using the resolve operation without a context object or argument. resolve() The query may be restricted to identifying all target objects conforming to a given type by adding a type argument. resolve(Table) The returned target objects may be restricted to those mapped from a particular source object by supplying the source object as the context object. source.resolve() Additionally, or alternatively, the returned target objects may be restricted by an OCL condition. source.resolve(t : Table | t.name.startsWith('_')) These queries return a sequence of target objects in mapping invocation order. An equivalent OCL-like query for SOURCE.resolve(T : TYPE | CONDITION) is let selectedRecords = trace-data->select(in-parameters->including(context-parameter)->includes(SOURCE)) in let selectedTargets = selectedRecords->collect(out-parameters->union(result-parameters)) in selectedTargets->selectByKind(TYPE)->select(T | CONDITION) 8.1.x.4 resolveIn() - Resolution of target objects by Mapping The trace data may be queried to identify all target objects produced by a given invoked disjuncting mapping or executed candidate mapping using the resolveIn expression. resolveIn(Class2Table) The returned target objects may be restricted to those mapped from a particular source object by supplying the source object as the context object. source.resolveIn(Class2Table) Additionally, or alternatively, the returned target objects may be restricted by an OCL condition. source.resolveIn(Class2Table, t : Table | t.name.startsWith('_')) These queries return a sequence of target objects in mapping invocation order. An equivalent OCL-like query for SOURCE.resolveIn(MAPPING, T : TYPE | CONDITION) is let selectedRecords1 = trace-data->select(in-parameters->including(context-parameter)->includes(SOURCE)) in let selectedRecords2 = selectedRecords1->select((invoked-mapping = MAPPING) or (executed-mapping = MAPPING)) in let selectedTargets = selectedRecords2->collect(out-parameters->union(result-parameters)) in selectedTargets->selectByKind(TYPE)->select(T | CONDITION) 8.1.x.5 invresolve() - Resolution of source objects by Type or Mapping The corresponding inverse queries are available using the invresolve or invresolveIn expressions. These identify source objects mapped to a given type or by a given mapping. invresolve() // all sources invresolve(Class) // all sources of kind Class target.invresolve() // all sources mapped to target target.invresolve(c : Class | c.name.startsWith('_')) invresolveIn(Class2Table) // all sources for Class2Table mappings target.invresolveIn(Class2Table) // all sources mapped to target by a Class2Table mapping target.invresolveIn(Class2Table, c : Class | c.name.startsWith('_')) 8.1.x.6 resolveone() - Resolution of a single source or target object by Type or Mapping The four resolveone variants of the four resolve expressions modify the return to suit the common case where only a single object is expected. The return is therefore the first resolved object or null. resolveone() // the first target resolveone(Table) // the first target of kind Table source.resolveone() // the first target mapped from source source.resolveone(t : Table | t.name.startsWith('_')) resolveoneIn(Class2Table) // the first target of a Class2Table mapping source.resolveoneIn(Class2Table) // the first target mapped from source by a Class2Table mapping source.resolveoneIn(Class2Table, t : Table | t.name.startsWith('_')) invresolveone() // the first source invresolveone(Class) // the first source of kind Class target.invresolveone() // the first source mapped to target target.invresolveone(c : Class | c.name.startsWith('_')) invresolveoneIn(Class2Table) // the first source for a Class2Table mapping target.invresolveoneIn(Class2Table) // the first source mapped to target by a Class2Table mapping target.invresolveoneIn(Class2Table, c : Class | c.name.startsWith('_')) 8.1.x.7 Late resolution The resolve expressions query the prevailing state of the trace data. resolve cannot of course return results from mappings that have yet to execute and so careful programming of mapping invocations may be required to ensure that required results are available when needed. Alternatively a late keyword may prefix resolve when the resolution occurs within an assignment. This defers the execution of the assignment and the partial computation involving late resolve's until all mapping executions have completed. The deferred assignment cannot return the future value; it therefore returns a null value. More precisely, mappings execute, assignment right hand sides involving late resolutions are computed, then finally deferred assignments are made. The ordering in which late resolutions occur does not matter, since each late resolution can influence only its own deferred assignment. myprop := mylist->late resolve(Table); // shorthand for mylist->xcollect(late resolve(Table)) This last example also demonstrates that an implicit imperative xcollect of resolutions may be performed, in this case requiring the collection to be performed after all mappings have executed. 8.1.x.8 Persisted Trace Data The trace data may be persisted and reloaded to support a re-execution. However the trace record does not trace configuration data, transformation properties or intermediate data, and does not involve a deep clone of every traced object. It is therefore not possible to use a persisted form of the trace data to support incremental re-execution of an arbitrary QVTo transformation since the required object state may not be present in persisted trace. A well-behaved transformation that avoids dependence on mutable object properties or other untraced facilities may be re-executable. In 8.2.1.15 Correct A mapping operation is an operation implementing a mapping between one or more source model elements- intoand one or more target model elements. In 8.2.1.15 Replace The when clause acts either as a pre-condition or as a guard, depending on the invocation mode of the mapping operation. by The when clause acts either as a pre-condition when invoked with strict semantics, or as a guard, when invoked using standard semantics. In 8.2.1.15 Replace The initialization section is used for computation prior to the effective instantiation of the outputs. The population section is used to populate the outputs and the finalization section is used to define termination computations that take place before exiting the body. by The init (initialization) section is used for computation prior to the effective instantiation of the outputs. The population section is used to populate the outputs and the end (finalization) section is used to define termination computations that take place before exiting the body. In 8.2.1.15 Replace There are three reuse and composition facilities associated to mapping operations: by A mapping operation may be explicitly defined as a disjunction of candidate mapping operations. Every mapping operation is also an implicit disjunction of all mappings that are overloads as a consequence of matching name and argument count. Execution of a disjunction involves selecting the first candidate mapping whose when clause and other predicates are satisfied and then invoking it. This is described in Section 8.1.12. The empty body of the disjuncting mapping is not executed. Additionally, there are two extension mechanisms associated to mapping operations: In 8.2.1.15 Replace 3. A mapping operation may be defined as a disjunction of other mapping operations. This means selecting, among the set of disjuncted mappings, the first that satisfies the when clause and then invoking it. The execution semantics subsection below provides the details of these reuse facilities. by The execution semantics subsection below provides the details of these mapping extension mechanisms. In 8.2.1.15 Constraints add The body of a disjuncting mapping must be empty. disjunct->notEmpty() implies body = null In 8.2.1.15 Replace We first define the semantic of the execution of a mapping operation in absence of any reuse facility (inheritance, merge, and disjunction), then we describe the effect of using these facilities. by We firstly define the semantic of the execution of a mapping operation in the absence of any inheritance or merge reuse facility. In 8.2.1.21 Replace Indicates the mode of the mapping invocation. by Indicates whether the mapping invocation mode is strict or standard. In 8.2.1.21 Replace In strict mode the when clause is evaluated as a pre-condition. In contrast, when the mapping is invoked in standard mode, the execution of the mapping body is skipped and the null value is returned to the caller. by In strict mode, failure to evaluate the when clause as a pre-condition causes the mapping execution to fail. In contrast in standard mode, failure to evaluate the when clause as a guard causes execution of the mapping body to be skipped and null to be returned to the caller. In 8.2.1.21 Correct The map and xmap keywords may be called on a listcollection as source In 8.2.1.22 Correct where the <resolve_op> is one of the following: resolve, resolveone, invresolve, and invresolveone. In 8.2.1.22 Correct When isDeferred is true the latelate keyword is used before the operation name<resolve_op>. In 8.2.1.22 Correct The resolution operator may be called on a listcollection. This is a shorthand for invoking it in the body of a ForExpan xcollect ImperativeIterateExp expression. In 8.2.1.22 Replace // shorthand for mylist->forEach(i) { i.late resolve(Table); } by // shorthand for mylist->xcollect(late resolve(Table))
Actions taken:
December 27, 2012: received issue
December 22, 2015: Resolved
March 29, 2016: closed issue

Discussion:

Help wanted.  Disposition: Deferred

Issue 18325: Intermediate data not allowed for libraries (qvt-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
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.

Resolution:
Revised Text:
Actions taken:
December 27, 2012: received issue
July 15, 2014: closed issue

Discussion:

The metamodels are very clear; no intermediate classes/properties in a Module.  Today: 8.1.3 A library contains definitions that can be reused by transformations. Intermediate data  are not inherently re-useable, but could be formulated as a metamodel if required.  Future: if the dual Package/Class inheritance of Module is resolved to make Library Package-like and  OperationalTransformation Class-like, promoting intermediates to Module will create more problems to  solve.  Disposition: Closed, No Change

Issue 18363: Undefined semantics for unsatisfied "when" and "where" in inherited mapping (qvt-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
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.

Resolution: 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.
Revised Text: In 8.1.4 correct A mapping operation is syntactically described by a signature, a guard (a when clause) or precondition, a mapping body, and a postcondition (a where clause). Even if it is not explicitly notated in the concrete syntax, a mapping operation is always a refinement of an implicit relation that is the owner of the when and where clauses. in 8.1.4 append In strict invocation mode, a precondition (a when clause) is executed as an assertion before any other execution. Failure of the assertion causes a fatal execution failure. A postcondition (a where clause) is similarly executed as an assertion after all other execution has completed. In 8.2.1.15 following The when clause acts either as a pre-condition or as a guard, depending on the invocation mode of the mapping operation. The where clause always acts as a post-condition for the mapping operation. append pre-conditions and post-conditions are assertions; any execution failure is fatal.
Actions taken:
January 4, 2013: received issue
December 22, 2015: Resolved
March 29, 2016: closed issue

Discussion:

Yes. This is a very fundamental principle that should form part of the philosophical underpining in the  first couple of paragraphs of the QVTo language exposition. (ditto QVTc, QVTr).  It is disgraceful that the specification of transformation extension and rule refinement is so poor.  For QVTc and QVTr I favour a principle that extension provides extension not replacement. But that  may be too restricting.  QVTo is more permissive and practical so a pure principle may be inappropriate.  Research needed.  Disposition: Deferred

Issue 18572: QVT atomicity (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
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.

Resolution: Fixed point semantics can be achieved by a has-it-changed loop.
Revised Text: In 7.7 In-place Transformations replace A transformation may be considered in-place when its source and target candidate models are both bound to the same model at runtime. The following additional comments apply to the enforcement semantics of an inplace transformation: � A relation is re-evaluated after each enforcement-induced modification to a target pattern instance of the model. � A relation�s evaluation stops when all the pattern instances satisfy the relationship. by A transformation may be considered in-place when one or more source models are bound to one or more target models at runtime. Execution proceeds as if the source and target models are distinct with an atomic update of non-distinct models occurring on completion of the transformation. This implies that an implementation that operates in-place must take copies of the old state to avoid confusion with updated new state. Execution of a transformation should return a Boolean status to indicate whether any changes were made to target models. This status enables transformation applications to repeat execution until no changes occur where that is appropriate for the application.
Actions taken:
March 21, 2013: received issue
July 15, 2014: closed issue

Issue 18912: Inconsistent multiple inheritance (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
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.

Resolution: 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.
Revised Text:
Actions taken:
September 16, 2013: received issue
December 22, 2015: Deferred
March 29, 2016: closed issue

Discussion:

A quick experiment suggests that Class features are important but Package features are incidental, so  making Transformation extend just Class and requiring a containing Package to provide context could  be a good solution. Further investigation is required.  (Similar problem for FunctionParameter).  Disposition: Deferred

Issue 19019: List and Dict are Classes rather than DataTypes (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Significant
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.

Resolution: 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, [1]QVT13-120 is merged to remove the prohibition on object creation/update in helpers. ---------------------------------------------------------------------------------------- [1] http://issues.omg.org/browse/QVT13-120
Revised Text: In 8.2.1.15 MappingOperation Executing a mapping operation replace: All out parameters, including result parameters, have their value initialized to null. All in or inout non null values, except for the primitive types are passed by reference. However it is not legal to change the value when an object is declared with in direction kind. by: All Class parameters are passed or returned by reference. An in Class parameter may not be modified. in DataType parameters are passed by value and may be modified by the mapping without affecting the caller. result DataType parameters are returned by value. inout and out DataType parameters are passed by reference-to-variable, that is the caller passes a reference to a variable whose value may be updated zero or more times by the mapping. These updates are visible to the caller. The initial value of each out and result parameter is null. The value of out, inout and result parameters may be updated many times by assignments. The final value of each out, inout and result parameter is returned to the caller. in 8.2.1.12 Helper replace: A helper is an operation that performs a computation on one or more source objects and provides a result. The body of a helper is an ordered list of expressions that is executed in sequence. When more than one result is declared in the signature of the helper operation, the invocation of the operation returns a tuple. Unless the isQuery property is true, a helper may have side-effects on the parameters; for instance, a list may be passed and changed within the body and its effect is visible after the operation call termination. However it is illegal to create or update object instances within a helper operation except for pre-defined types like sets, tuples, and for intermediate properties. by Helpers and queries are operations that perform a computation on one or more source objects and provide a result. The body is an ordered list of expressions that are executed in sequence. A query has no side-effects. The isQuery property is true. All parameters are implicitly in. A helper may have side-effects; for instance, a list may be passed and changed within the body and its effect is visible after the operation call termination. The isQuery property is false. Parameters may be in, inout or out. A helper may create or modify Class instances or mutable DataType values such as List or Dict. A helper or query may create mutable DataType values such as List or Dict or immutable DataType values such as Tuple, Set or String. When more than one result is declared in the signature of a helper operation, the invocation of the operation returns a tuple. All Class parameters are passed or returned by reference. An in Class parameter may not be modified. in DataType parameters are passed by value and may be modified by a helper without affecting the caller. result DataType parameters are returned by value. inout and out DataType parameters are passed by reference-to-variable, that is the caller passes a reference to a variable whose value may be updated zero or more times by the helper. These updates are visible to the caller. The initial value of each out and result parameter is null. The value of out, inout and result parameters may be updated many times by assignments. The final value of each out, inout and result parameter is returned to the caller.
Actions taken:
October 23, 2013: received issue
December 22, 2015: Resolved
March 29, 2016: closed issue

Discussion:

It would be nice to clean this up, but very dangerous to do so without evaluating the consequences for  a real implementation and typical transformations.  Disposition: Deferred

Issue 19021: Inconsistent description about constructor names (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody)
Nature: Clarification
Severity: Minor
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."

Resolution: 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.
Revised Text: In 8.2.1.13 Constructor notation change The name of the constructor is necessarily the name of the context type to The name of the constructor is usually the name of the context type In 8.2.1.24 ObjectExp add /initializationOperation : Constructor [0..1] (from InstantiationExp) The constructor that uses the arguments to initialize the object after creation. The constructor may be omitted when implicit construction occurs with no arguments. In 8.2.2.23 InstantiationExp add initializationOperation : Operation [0..1] The initialization operation that uses the arguments to initialize the object after creation. The initialization operation may be omitted when implicit initialization occurs with no arguments. In Figure 8.5 add Operation (from EMOF) unidirectional reference from InstantiationExp to Operation -- forward role initializationOperation [0..1] -- reverse role instantiationExp [*]
Actions taken:
October 23, 2013: received issue
July 15, 2014: closed issue

Issue 19022: ObjectExp Abstract Syntax misses a ConstructorBody (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody)
Nature: Revision
Severity: Significant
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).

Resolution: The required association is already shown in Fig 8.3; just need to add the missing text
Revised Text: In 8.2.1.24 ObjectExp add body: ConstructorBody [1] {composes} The inline constructor body for the object to be instantiated or updated
Actions taken:
October 23, 2013: received issue
July 15, 2014: closed issue

Issue 19023: Enhance ObjectExp to allow constructors invocation (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody)
Nature: Enhancement
Severity: Minor
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>)? ')' )

Resolution: 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: [1]https://bugs.eclipse.org/bugs/show_bug.cgi?id=479657 ---------------------------------------------------------------------------------------- [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=479657
Revised Text:
Actions taken:
October 23, 2013: received issue
December 22, 2015: Deferred
March 29, 2016: closed issue

Discussion:

InstantiationExp.initailzationOperation may provide the required AS support. CS needs protyping to  determine what dosambiguation rules are required.  Disposition: Deferred

Issue 19095: Not possible to remove from a mutable List (qvt-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
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

Resolution: Duplicates in part Issue 13251. Disposition: See issue 19146 for disposition
Revised Text:
Actions taken:
November 19, 2013: received issue
July 15, 2014: closed issue

Issue 19096: Resolve expressions without source variable (qvt-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
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

Resolution: 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.
Revised Text: In 8.2.1.22 ResolveExp after the first paragraph add The source object is optional. When no source object is provided, this expression inspects all the targets created or updated by all mapping operations irrespective of the source objects.
Actions taken:
November 19, 2013: received issue
July 15, 2014: closed issue

Issue 19121: Imprecise result types of resolveIn expressions (qvt-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
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.

Resolution: OclAny rather Object is of course the top type
Revised Text: In 8.2.1.23 ResolveInExp replace The type of a ResolveInExp expression is computed using the same rules as for the type of a ResolveExp. by Type of a resolveIn expression The type of a ResolveInExp expression depends on the type of the �target� variable, the 'inMapping' operation and on the multiplicity indication (the �one� property). The overall returned type is specified in terms of an intermediate resolved type. If a 'target' variable is provided, the resolved-type is the type of the 'target' variable Otherwise if an 'inMapping' is provided, .the resolved-type is the type of the 'inMapping'. Otherwise the resolved-type is Object (the type representing all types, see Section 8.3.1). If �one� is true, the returned type is the resolved-type. Otherwise, the returned type is a Sequence of the resolved-type.
Actions taken:
November 22, 2013: received issue
July 15, 2014: closed issue

Issue 19146: Specify List::reject and other iterations (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
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.

Resolution: 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
Revised Text: <<Issue 13182 revises redundant (T) in some signatures.>> Replace 8.3.8 Operations On List All operations of the OCL Collection type are available. In addition the following are available. add List(T)::add(T) : Void Adds a value at the end of the mutable list. Synonym: append prepend List(T)::prepend(T) : Void Adds a value at the beginning of the mutable list. insertAt List(T)::insertAt(T,int) : Void Adds a value at the given position. The index starts at zero (in compliance with OCL convention). joinfields List(T)::joinfields(sep:String,begin:String,end:String) :String Creates a string separated by sep and delimited with begin and end strings. asList Set(T)::asList() : List(T) OrderedSet(T)::asList(T) : List(T) Sequence(T)::asList(T) : List(T) Bag(T)::asList(T) : List(T) Converts a collection into the equivalent mutable list. by The following operations can be invoked on any list. A list type is a parameterized type. The symbol T denotes the type of the values. The operations include all those of the OCL Sequence type. = List(T)::=(s : List(T)) : Boolean True if self contains the same elements as s in the same order. post: result = (size() = s->size()) and Sequence{1..size()}->forAll(i | at(i) = s->at(i)) <> List(T)::<>(c : List(T)) : Boolean True if c is not equal to self. post: result = not (self = c) add List(T)::add(T) : Void Adds a value at the end of the mutable list. post: size() = size@pre() + 1 post: Sequence{1..size@pre()}->forAll(i | at(i) = at@pre(i)) post: at(size()) = object append List(T)::append(object: T) : List(T) Returns a new list of elements, consisting of all elements of self, followed by object. post: result->size() = size() + 1 post: Sequence{1..size()}->forAll(i | result->at(i) = at(i)) post: result->at(result->size()) = object asBag List(T)::asBag() : Bag(T) Returns a Bag containing all the elements from self, including duplicates. The element order is indeterminate. post: result->forAll(elem | self->count(elem) = result->count(elem)) post: self->forAll(elem | self->count(elem) = result->count(elem)) asList List(T)::asList(T) : List(T) Returns a new list that is a shallow clone of self. post: Sequence{1..size()}->forAll(i | result->at(i) = self->at(i)) asOrderedSet List(T)::asOrderedSet() : OrderedSet(T) Returns a OrderedSet that contains all the elements from self, in the same order, with duplicates removed. post: result->forAll(elem | self ->includes(elem)) post: self->forAll(elem | result->count(elem) = 1) post: self->forAll(elem1, elem2 | self->indexOf(elem1) < self->indexOf(elem2) implies result->indexOf(elem1) < result->indexOf(elem2) ) asSequence List(T)::asSequence() : Sequence(T) Returns a Sequence that contains all the elements from self, in the same order. post: result->size() = size() post: Sequence{1..size()}->forAll(i | result->at(i) = self->at(i)) asSet List(T)::asSet() : Set(T) Returns a Set containing all the elements from self, with duplicates removed. The element order is indeterminate. post: result->forAll(elem | self->includes(elem)) post: self->forAll(elem | result->includes(elem)) at List(T)::at(i : Integer) : T Returns the element of the list at the i-th one-based index. pre : 1 <= i and i <= size() clone List(T)::clone(T) : List(T) Returns a new list that is a shallow clone of self. post: Sequence{1..size()}->forAll(i | result->at(i) = self->at(i)) count List(T)::count(object : T) : Integer Returns the number of occurrences of object in self. deepclone List(T)::deepclone(T) : List(T) Returns a new list that is a deep clone of self; that is a new list in which each element is in turn a deepclone of the corresponding element of self. excludes List(T)::excludes(object : T) : Boolean True if object is not an element of self, false otherwise. post: result = (self->count(object) = 0) excludesAll List(T)::excludesAll(c2 : Collection(T)) : Boolean Does self contain none of the elements of c2 ? post: result = c2->forAll(elem | self->excludes(elem)) excludesAll List(T)::excludesAll(c2 : List(T)) : Boolean Does self contain none of the elements of c2 ? post: result = c2->forAll(elem | self->excludes(elem)) excluding List(T)::excluding(object : T) : List(T) Returns a new list containing all elements of self apart from all occurrences of object. The order of the remaining elements is not changed. post:result->includes(object) = false post: result->size() = self->size()@pre - self->count(object)@pre post: result = self->iterate(elem; acc : List(T) = List{} | if elem = object then acc else acc->append(elem) endif ) first List(T)::first() : T Returns the first element in self. post: result = at(1) flatten List(T)::flatten() : List(T2) Returns a new list containing the recursively flattened contents of the old list. The order of the elements is partial. post: result = self->iterate(c; acc : List(T2) = List{} | if c.oclType().elementType.oclIsKindOf(CollectionType) then acc->union(c->flatten()->asList()) else acc->union(c) endif) includes List(T)::includes(object : T) : Boolean True if object is an element of self, false otherwise. post: result = (self->count(object) > 0) includesAll List(T)::includesAll(c2 : Collection(T)) : Boolean Does self contain all the elements of c2 ? post: result = c2->forAll(elem | self->includes(elem)) includesAll List(T)::includesAll(c2 : List(T)) : Boolean Does self contain all the elements of c2 ? post: result = c2->forAll(elem | self->includes(elem)) including List(T)::including(object : T) : List(T) Returns a new list containing all elements of self plus object added as the last element. post: result = append(object) indexOf List(T)::indexOf(obj : T) : Integer The one-based index of object obj in the list. pre : includes(obj) post : at(result) = obj insertAt List(T)::insertAt(index : Integer, object : T) : List(T) Returns a new list consisting of self with object inserted at the one-based position index. pre : 1 <= index and index <= size() post: result->size() = size() + 1 post: Sequence{1..(index - 1)}->forAll(i | result->at(i) = at(i)) post: result->at(index) = object post: Sequence{(index + 1)..size()}->forAll(i | result->at(i + 1) = at(i)) insertAt List(T)::insertAt(object : T, index : Integer) : Void The list is modifed to consist of self with object inserted at the one-based position index. pre : 1 <= index and index <= size() post: size() = size@pre() + 1 post: Sequence{1..(index - 1)}->forAll(i | at(i) = at@pre(i)) post: at(index) = object post: Sequence{(index + 1)..size()}->forAll(i | at(i) = at@pre(i - 1)) isEmpty List(T)::isEmpty() : Boolean Is self an empty list? post: result = (self->size() = 0) joinfields List(T)::joinfields(sep:String,begin:String,end:String) :String Creates a string separated by sep and delimited with begin and end strings. post: result = begin + Sequence{1..size()}->iterate(i; acc : String = '' | acc + if i = 1 then '' else sep endif + at(i).toString()) + end last List(T)::last() : T Returns the last element in self. post: result = at(size()) max List(T)::max() : T The element with the maximum value of all elements in self. Elements must be of a type supporting the max operation. The max operation - supported by the elements - must take one parameter of type T. Integer and Real fulfill this condition. post: result = self->iterate(elem; acc : T = self->any(true) | acc.max(elem)) min List(T)::min() : T The element with the minimum value of all elements in self. Elements must be of a type supporting the min operation. The min operation - supported by the elements - must take one parameter of type T. Integer and Real fulfill this condition. post: result = self->iterate(elem; acc : T = self->any(true) | acc.min(elem)) notEmpty List(T)::notEmpty() : Boolean Is self not an empty list? post: result = (self->size() <> 0) prepend List(T)::prepend(object : T) : List(T) Returns a new list consisting of object, followed by all elements in self. post: result->size = size() + 1 post: result->at(1) = object post: Sequence{1..size()}->forAll(i | result->at(i + 1) = at(i)) product List(T)::product(c2: Collection(T2)) : Set(Tuple(first: T, second: T2)) The cartesian product operation of self and c2. post: result = self->iterate(e1; acc: Set(Tuple(first: T, second: T2)) = Set{} | c2->iterate(e2; acc2: Set(Tuple(first: T, second: T2)) = acc | acc2->including(Tuple{first = e1, second = e2}))) remove List(T)::remove(element : T) : Void Removes .all elements from self equal to element. post: result = self@pre->reject(e = element) removeAll List(T)::removeAll(elements : Collection(T)) : Void Removes .all elements from self equal to any of elements. post: result = self@pre->reject(e | elements->includes(e)) removeAll List(T)::removeAll(elements : List(T)) : Void Removes .all elements from self equal to any of elements. post: result = self@pre->reject(e | elements->includes(e)) removeAt List(T)::removeAt(index : Integer) : T Removes .and returns .the list element at index. Returns invalid for an invalid index. pre: 1 <= index and index <= size() post: size() = size@pre() - 1 post: Sequence{1..index}->forAll(i | at(i) = at@pre(i)) post: Sequence{(index+1)..size()}->forAll(i | at(i) = at@pre(i+1)) post: result = at@pre(index) removeFirst List(T)::removeFirst() : T Removes .and returns .the first list element. Returns invalid for an empty list. pre: 1 <= size() post: size() = size@pre() - 1 post: Sequence{1..size()}->forAll(i | at(i) = at@pre(i+1)) post: result = at@pre(1) removeLast List(T)::removeLast() : T Removes .and returns .the last list element. Returns invalid for an empty list. pre: 1 <= size() post: size() = size()@pre - 1 post: Sequence{1..size()}->forAll(i | at(i) = at@pre(i)) post: result = at@pre(size@pre()) reverse List(T)::reverse() : List(T) Returns a new list containing the same elements but with the opposite order. post: result->size() = self->size() post: Sequence{1..size()}->forAll(i | result->at(i) = at(size() - (i-1))) selectByKind List(T)::selectByKind(type : Classifier) : List(T1) Returns a new list containing the non-null elements of self whose type is type or a subtype of type. The returned list element type T1 is the type specified as type. post: result = self ->collect(if oclIsKindOf(type) then oclAsType(type) else null endif) ->excluding(null) selectByType List(T)::selectByType(type : Classifier) : List(T1) Returns a new list containing the non-null elements of self whose type is type but which are not a subtype of type. The returned list element type T1 is the type specified as type. post: result = self ->collect(if oclIsTypeOf(type) then oclAsType(type) else null endif) ->excluding(null) size List(T)::size() : Integer The number of elements in the collection self. post: result = self->iterate(elem; acc : Integer = 0 | acc + 1) subSequence List(T)::subSequence(lower : Integer, upper : Integer) : Sequence(T) Returns a new sub-List of self starting at number lower, up to and including element number upper. pre : 1 <= lower and lower <= upper and upper <= size() post: result->size() = upper -lower + 1 post: Sequence{lower..upper}->forAll(i | result->at(i - lower + 1) = at(i)) sum List(T)::sum() : T The addition of all elements in self. Elements must be of a type supporting the + operation. The + operation must take one parameter of type T. It does not need to be commutative or associative since the iteration order over a list is well-defined. Integer and Real fulfill this condition. post: result = self->iterate(elem; acc : T = 0 | acc + elem) union List(T)::union (s : List(T)) : List(T) Returns a new list consisting of all elements in self, followed by all elements in s. post: result->size() = size() + s->size() post: Sequence{1..size()}->forAll(i | result->at(i) = at(i)) post: Sequence{1..s->size()}->forAll(i | result->at(i + size()) = s->at(i))) <New sub-sub-section number> Iterations on Lists There are no iterations defined for Lists since Lists are mutable and iteration domains are immutable. However the iterations defined for Sequences may be used without explicitly converting the List to a Sequence. Invocation of one the following list iterations returning non-Lists aList->iteration(...) is therefore shorthand for aList->asSequence()->iteration(...) List(T)::any(i : T[?]) : T[?] List(T)::collect(i : T[?]) : Collection(T1) List(T)::collectNested(i : T[?]) : Collection(T1) List(T)::exists(i : T[?]) : Boolean[?] List(T)::exists(i : T[?], j : T[?]) : Boolean[?] List(T)::forAll(i : T[?]) : Boolean[?] List(T)::forAll(i : T[?], j : T[?]) : Boolean[?] List(T)::isUnique(i : T[?]) : Boolean List(T)::iterate(i : T[?]; acc : T2[?]) : T2[?] List(T)::one(i : T[?]) : Boolean Invocation of one the following list iterations returning Lists aList->iteration(...) is shorthand for aList->asSequence()->iteration(...)->asList() List(T)::reject(i : T[?]) : List(T) List(T)::select(i : T[?]) : List(T) List(T)::sortedBy(i : T[?]) : List(T) <New sub-sub-section number> Operations on Collections The following operations are added to the standard OCL collections Collection::asList Collection(T)::asList(T) : List(T) Returns a new list containing all the elements of a collection. Whether the order is determinate depends on the derived collection type.. post: result->size() = size() post: self->asSet()->forAll(e | result->count(e) = self->count(e)) Collection::clone Collection(T)::clone(T) : Collection(T) Collections are immutable so a clone returns self. post: result = self Collection::deepclone Collection(T)::deepclone(T) : Collection(T) Collections are immutable so a deep clone returns self. post: result = self <New sub-sub-section number> Operations on Bags The following operations are added to the standard OCL bags Bag::asList Bag(T)::asList(T) : List(T) Returns a new list containing all the elements of a bag in an indeterminate order. Bag:: clone Bag(T)::clone(T) : Bag(T) Bags are immutable so a clone returns self. Bag:: deepclone Bag(T)::deepclone(T) : Bag(T) Bags are immutable so a deep clone returns self. <New sub-sub-section number> Operations on OrderedSets The following operations are added to the standard OCL ordered sets OrderedSet::asList OrderedSet(T)::asList(T) : List(T) Returns a new list that contains all the elements an ordered set in the same order. post: Sequence{1..size()}->forAll(i | result->at(i) = self->at(i)) OrderedSet:: clone OrderedSet(T)::clone(T) : OrderedSet(T) OrderedSets are immutable so a clone returns self. OrderedSet:: deepclone OrderedSet(T)::deepclone(T) : OrderedSet(T) OrderedSets are immutable so a deep clone returns self. <New sub-sub-section number> Operations on Sequences The following operations are added to the standard OCL sequences Sequence::asList Sequence(T)::asList(T) : List(T) Returns a new list that contains all the elements a sequence in the same order. post: Sequence{1..size()}->forAll(i | result->at(i) = self->at(i)) Sequence:: clone Sequence(T)::clone(T) : Sequence(T) Sequences are immutable so a clone returns self. Sequence:: deepclone Sequence(T)::deepclone(T) : Sequence(T) Sequences are immutable so a deep clone returns self. <New sub-sub-section number> Operations on Sets The following operations are added to the standard OCL sets Set::asList Set(T)::asList() : List(T) Returns a new list containing all the elements of a set in an indeterminate order. Set:: clone Set(T)::clone() : Set(T) Sets are immutable so a clone returns self. Set:: deepclone Set(T)::deepclone() : Set(T) Sets are immutable so a deep clone returns self.
Actions taken:
December 18, 2013: received issue
July 15, 2014: closed issue

Issue 19174: List does not support asList() (qvt-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

The asList() operation is defined for all concrete collection types. Consequently, it should be defined on List itself (returning self).      Suggestion: specify the operation for the Collection type:      Collection(T)::asList() : List(T)      Add another redefinition for the List type:    List(T)::asList() : List(T)

Resolution: The additional operation is shown in the Issue 19146 resolution.. Disposition: See issue 19146 for disposition
Revised Text:
Actions taken:
January 6, 2014: received issue
July 15, 2014: closed issue

Issue 19177: xcollect is ambiguously flattened (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

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

Resolution: 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
Revised Text: In 8.2.2.7 ImperativeIterateExp Collection(T)::xcollect(source, iterator, body) replace Collection(T)::xcollect(source, iterator, body) : Sequence(TT) = compute (res:Sequence(TT) := Sequence{}) source->forEach (iterator:T) { var target : TT := body; if (target<>null) res += target; }; Collection(T)::xselect(source, iterator, condition) : Sequence(T) = compute (res:Sequence(T) := Sequence{}) source->forEach (iterator:T) { var target : T := iterator; if (target<>null and condition) res += target; }; Collection(T)::xselectOne(source, iterator, condition) : Sequence(T) = compute (res:Sequence(T) := Sequence{}) source->forEach (iterator:T) { var target : T := iterator; if (target<>null and condition) {res += target; break;} }; Collection(T)::xcollectselect(source, iterator, target, body, condition) : Sequence(TT) = compute (res:Sequence(TT) := Sequence{}) source->forEach (iterator:T) { var target : TT := body; if (target<>null and condition) res += target; }; Collection(T)::xcollectselectOne(source, iterator, target, body, condition) : Sequence(TT) = compute (res:Sequence(TT) := Sequence{}) source->forEach (iterator:T) { var target : TT := body; if (target<>null and condition) {res += target; break;} }; T and TT are respectively the type of the source elements and the type of the target elements. When applying the imperative iterate expression if the source collection is not ordered, it is implicitly converted into the corresponding ordered collection (Set and Bag become respectively OrderedSet and Sequence). If the condition is not given, it should be replaced by true in the definitions above. by Collection(T)::xcollect(BODY) : BagOrSequence(TT) = compute (res : List(TT) := List{}) { self->forEach(COLLECTOR) { BODY->flatten()->forEach(target) { if (target <> null) res += target; }; }; }->asBagOrSequence(); Collection(T)::xselect(CONDITION) : BagOrOrderedSetOrSequenceOrSet(T) = compute (res : List(T) := List{}) { self->forEach(SELECTOR) { if (SELECTOR<> null and CONDITION) res += SELECTOR; }; }->asBagOrOrderedSetOrSequenceOrSet(); Collection(T)::xselectOne(CONDITION) : T = compute (res : T := null) { self->forEach(SELECTOR) { if (SELECTOR<> null and CONDITION) { res := SELECTOR; break; } }; }; Collection(T)::xcollectselect(BODY, CONDITION) : BagOrSequence(TT) = compute (res : List(TT) := List{}) { self->forEach(COLLECTOR) { BODY->flatten()->forEach(SELECTOR) { if (SELECTOR <> null and CONDITION) { res += SELECTOR; } }; }; }->asBagOrSequence(); Collection(T)::xcollectselectOne(BODY, CONDITION) : TT = compute (res : TT := null) { self->forEach(COLLECTOR) { BODY->flatten()->forEach(SELECTOR) { if (SELECTOR <> null and CONDITION) { res := SELECTOR; break; } }; if (res <> null) { break; } }; }; where *BagOrOrderedSetOrSequenceOrSet denotes the Bag, OrderedSet, Sequence or Set kind of the source Collection *BagOrSequence denotes either Bag or Sequence according to whether the source Collection is unordered or ordered *BODY is a TT-valued Imperative OCL expression that may use the COLLECTOR variable *CONDITION is a Boolean-valued Imperative OCL expression that may use the SELECTOR variable
Actions taken:
January 9, 2014: received issue
December 22, 2015: Resolved
March 29, 2016: closed issue

Issue 19178: What happens when an exception is thrown by an exception handler (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

QVTo provides no guidance as to how a nested exception should be handled.    Suggest that like C++, a nested exception is ill-formed and the transformation terminates.

Resolution: The QVTo exception mechanism is lightweight. Throwing an exception while handling another makes it very difficult to guarantee that the handler for the first executes correctly. Therefore declare nested exceptions as ill-formed.
Revised Text: << NB This issue is superseded by Issue 19208 >> In 8.2.2.13 TryExp add The selected exceptClause completes before the TryExp completes. Consequently if an exception is raised during execution of the exceptClause, the execution of the exceptClause cannot complete and so execution of the transformation terminates without any further changes occurring. The trace records may be examined to determine what actions the transformation performed prior to termination.
Actions taken:
January 10, 2014: received issue
July 15, 2014: closed issue

Issue 19201: Incorrect ModelType.additionalCondition multiplicity (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
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 [*].

Resolution: 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.
Revised Text:
Actions taken:
January 30, 2014: received issue
December 22, 2015: Closed; No Change
March 29, 2016: closed issue

Issue 19204: Specify the utility of an extent (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
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?

Resolution: 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.
Revised Text: Add the following section after 8.1.2 Model Types and before 8.1.3 Libraries 8.1.x Extents, Models and Model Parameters The inputs and output of a transformation are identified by Model Parameters which have a direction, model name and ModelType. transformation Uml2Rdbms(in uml:UML, out rdbms:RDBMS) 8.1.x.1 Implementation responsibilities A transformation is executed by a QVTo implementation which must load an external model for each in and inout parameter and identify a future external model for each out parameter. When the transformation completes successfully, the implementation must save the inout models and the no longer future out models. 8.1.x.2 Extents The interface between implementation and specified behavior uses a distinct MOF Extent associated with each Model Parameter. A MOF Extent identifies the root objects of its Model. The root objects are members of the Extent and are said to reside in the Extent. The initial members of in and inout Extents are the roots of loaded external models. There are no initial members of out Extents. Each Extent for an in Model Parameter is immutable. It may be shared when the same external model is loaded by multiple in Model Parameters. Other Extents are mutable and must be distinct even when the same external model is bound to more than one Model Parameter. There are therefore no shared model conflicts within the QVTo engine. Resolution of the conflict between multiple Extents that need to be saved to the same external model is a problem for the implementation to solve, perhaps by prohibiting the conflict in the first place. 8.1.x.3 Models A Model comprises a forest of model elements (objects) with each tree defined by MOF containment relationships. For many applications, a single root, and its containment tree, rather than a forest is sufficient. However during the course of a transformation, model elements are created for use by the model and these may form additional roots until the model elements are assigned to their intended container. Each Model Parameter has an Extent whose members are the root objects of a Model. The ModelParameter's ModelType identifies the permitted content of the Model, The ModelParameter's name may be used with the operations of the Model library type. uml.objectsOfKind(Class); The name may be used to assign all members of the Extent. rdbms := aModel.copy(); A model assignment displaces any previous members associated with the extent in favor of the root model elements of the replacement Model. The previous members cease to reside in any Extent and so become orphans. Additional Models and corresponding Extents may be created by the Model::copy() and Model::createEmptyModel() operations. These Extents have no associated external model and so their contents will be lost unless assigned to Extents with external models or unless passed to other transformations. The Models passed to nested transformation calls by Transformation::transform() or Transformation::parallelTransform() may not be modified after the call. This may require that a copy is created. 8.1.x.4 Object Containment and Extent Residence A MOF object can be contained by at most one other object, consequently the containment relationship of a model form a forest. The roots of the forest have no containers, rather they are members of at most one Extent and are therefore said to reside in that Extent. The non-roots of the forest are transitively contained by a root that is a member of the Extent; the non-roots are therefore also said to reside in the Extent. Objects that do not reside in an Extent are orphans. parent.child := firstChild; // firstChild contained by parentparent.child := secondChild; // secondChild contained by parent, displaced firstChild is a root object Assignment of a container relationship, or opposite containment relationship, establishes a new parent-child containment relationship. This may displace the previous child so that it has no container, however the displaced child retains its residence in its models' extent; the displaced child is therefore added to the extent's members and is an additional root object for the model. model.addElement(anObject); // anObject resides in model Similarly assignment of the residence of a root object, establishes or updates the residence of the root object and transitively of all its contained objects. Any previous residence is eliminated. When a transformation consistently assigns all residences and containments for all objects, the result is often a tree for the Extent of each inout and out parameter. However if any residence or containment is left unassigned, some orphan objects are lost. Direct object creation or construction typically results in orphans whose containment and residence is assigned later since there is no inference of a default residence. The object may be explicitly assigned to the root of some extent when it is created: column := new Column@mymodel(n,t); // mymodel is the extent for the new instance.object x:X@srcmodel { ? } // x is created within the ?srcmodel? Objects returned as out or inout parameters of a mapping are assigned to an explicit or inferred extent. If no extent can be inferred, typically because two ModelParameters use the same ModelType, the objects are orphans. This is a programming hazard that can be diagnosed by tooling. An object may be completely removed from its extent by invoking Model::removeElement(). This makes the object an orphan with no references to or from any other object. Cloned and deepcloned objects are added to the Extent of the source object; they are therefore new root objects until assigned to some container. 8.1.x.5 Orphans An orphan is a potentially lost object; it resides in no container and no extent and so will not contribute to any out or inout model. Orphans may arise as the result of: *Model::removeElement() explicitly orphaning an object *model assignment displacing an obsolete model *non-mapping object construction Creation of orphans by object construction is discouraged in two ways. An @extent may form part of the ObjectExp, or Mapping out parameter declaration. In the case of mappings, a default extent is inferred by metamodel compatibility. However objects constructed within helpers may be orphans. An orphan may cease to be an orphan when a container is assigned, or when Model::addElement() is used to add the orphan element to the members of the Extent that identifies the root objects of the Model. Although an orphan may have no container and may reside in no extent, it may still be referenced by objects that reside in an out extent. At the end of the transformation, when out extents are saved, out extents referencing orphans are not well-formed since the orphans are missing; the saved extent is incomplete and difficult to use. Practical implementations may assist diagnosis of the bad result by rescuing the referenced orphans as members of one or more extents or providing an additional lifeboat output model. In 8.2.1.6 replace More precisely there is a MOF extent corresponding to each parameter. by More precisely each ModelParameter has a ModelType for a MOF Extent whose members are the root objects of the corresponding Model. In 8.2.1.6 delete the following contradiction Any object creation occurs in an extent associated with a model parameter. In 8.2.1.6 delete the following (rewritten above) Relationship between MOF extents and model parameters When a model element is created by a transformation it is necessary to know in what model the model element is to be created. In particular, this makes it possible to use the inspection operations on model parameters like objects() and objectsOfType() to retrieve an object previously created. In MOF there is a notion of Extent that is simply defined as a container for Objects. Here we are correlating the notion of model (represented by model parameters in a transformation definition) with the notion of MOF extent stating that for each model parameter there is a MOF extent. In 8.2.1.16 delete the following fiction A mapping operation being a refinement of a relation, a mapping parameter is associated with a domain of the refined relation. This correspondence is based on the order of the declared parameters and domains, where the contextual parameter, if any, is the first and the result parameters are positioned after the ?regular? parameters. The type of the mapping parameter should necessarily be the same as the type specified by the object pattern of the domain (see Domain definition in Clause 7.11). In 8.2.1.24 ObjectExp add after the first paragraph Object creation, initialization and residence are separate activities. Object creation occurs when the referredObject has a null value; it is skipped if the referredObject variable references an existing object. Object initialization always occurs, but may be trivial if the body is empty. Object residence is left unchanged when the extent is omitted; it will be established as soon as the created object is put at the target end of some composition relationship. An explicit object residence may be established by specifying the model parameter for the required extent as the extent. In 8.2.2.12 UnlinkExp correct An unlink expression represents an explicit removal of a valuean object from a multivalued property link. In 8.2.2.12 UnlinkExp add The residence of the removed object is unaffected. If the unlink affects a containment relationship, the no longer contained object becomes a root object of its model. If total removal is required the Model::removeElement() operation may be used. In 8.3.4 correct 8.3.4 Operations on elementsElements In 8.3.4.10 clone add The returned object is added to the root of the model containing the source element. In 8.3.4.11 deepclone add The returned object is added to the root of the model containing the source element. In 8.3.5 correct 8.3.5 Operations on modelsModels In 8.3.5.1 correct Returns the listset of theall objects in the model extent. In 8.3.5.3 correct Returns the set of all the objects in the extentmodel that are not contained by other objects of the extentin the model. Before 8.3.5.4 removeElement add 8.3.5.x addElement Model::addElement (anObject : Element): Void The object is first displaced from any usage by setting its container to null, then the object is added to the model's extent so that it provides another root for the model. Any non-containment references to and from the object are unaffected. In 8.3.5.4 removeElement replace Removes an object of the model extent. All links between the object and other objects in the extent are deleted. References from collections to the ends of deleted links are removed. References from noncollections are set to null. by Removes an object from the model so that it becomes an orphan. All references to or from the object are eliminated. References from collections are removed. References from non-collections are set to null. In 8.3.5.6 copy replace Performs a complete copy of a model into another model. All objects belonging to the source extent are copied into the target extent. by Creates a deep copy of a model and its extent. All objects transitively contained in the source model are copied into the new model. The roots of the new model are the initial members of the new extent. The new extent has no associated external file and so the new contents may be lost unless assigned to another model or passed to another transformation. In 8.3.5.7 createEmptyModel replace Creates and initializes a model of the given type. This operation is useful when creating intermediate models within a transformation. by Creates a model and extent of the given type without any content. This operation is useful when creating intermediate models within a transformation.
Actions taken:
February 5, 2014: received issue
December 22, 2015: Resolved
March 29, 2016: closed issue

Issue 19205: Clarify deepclone on Collections (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

The Issue 19146 resolution is not sufficiently clear for Collection::deepclone.    Any nested mutables must be deepcloned, so the specify should require a reursive deepclone that one the retuirn decides between self or the clone according to whether any eleemnts need to change

Resolution: 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
Revised Text: In 8.3.11.3 Collection::deepclone replace: Collections are immutable so a deep clone returns self. post: result = self by Returns a collection that is a deep clone of self; that is a collection in which each element is in turn a deepclone of the corresponding element of self. May return self if there is no deep mutable content. In 8.3.12.3 Bag::deepclone replace: Bags are immutable so a deep clone returns self. by Returns a Bag that is a deep clone of self; that is a Bag in which each element is in turn a deepclone of the corresponding element of self. May return self if there is no deep mutable content. In 8.3.13.3 OrderedSet::deepclone replace: Sets are immutable so a deep clone returns self. by Returns an OrderedSet that is a deep clone of self; that is an OrderedSet in which each element is in turn a deepclone of the corresponding element of self. May return self if there is no deep mutable content. In 8.3.14.3 Sequence::deepclone replace: Sequences are immutable so a deep clone returns self. by Returns a Sequence that is a deep clone of self; that is a Sequence in which each element is in turn a deepclone of the corresponding element of self. May return self if there is no deep mutable content. In 8.3.15.3 Set::deepclone replace: Sets are immutable so a deep clone returns self. by Returns a Set that is a deep clone of self; that is a Set in which each element is in turn a deepclone of the corresponding element of self. May return self if there is no deep mutable content.
Actions taken:
February 5, 2014: received issue
December 22, 2015: Resolved
March 29, 2016: closed issue

Issue 19208: Issue 19178 resolution is rubbish (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

The proposed resolution for Issue 19178 'clarifies' nested exceptions.      It is wrong. The confusion arises from C++'s problem with a nested exception in a destructor not in a handler. QVTo has no destructors so there is no problem.      Issue 19178 should be closed without change.    Do not apply chnages from Issue 19178 resolution.

Resolution: For ease of reference, the erroneous 19178 revised text was: In 8.2.2.13 TryExp add The selected exceptClause completes before the TryExp completes. Consequently if an exception is raised during execution of the exceptClause, the execution of the exceptClause cannot complete and so execution of the transformation terminates without any further changes occurring. The trace records may be examined to determine what actions the transformation performed prior to termination. We just need to make clear that the handling of nested exceptions is normal.
Revised Text: <<Do not apply Issue 19178 revisions>> In 8.2.2.13 TryExp add A nested exception within an exceptClause terminates the exceptClause unless caught by a nested TryExp
Actions taken:
February 8, 2014: received issue
July 15, 2014: closed issue

Issue 19238: AssignExp unclear for OrderedSet (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
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.

Resolution: 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.
Revised Text:
Actions taken:
February 12, 2014: received issue
December 22, 2015: Duplicate or Merged
March 29, 2016: closed issue

Issue 19252: Redundant argument on matchIdentifier (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

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

Resolution: Redundant argument on matchIdentifier Issue 19146 removed most of the erroneous matchXXX arguments but omitted to do so for String:: matchIdentifier Discussion Yes
Revised Text: In 8.3.16.26 matchIdentifier String::matchIdentifier(s : String) : Boolean
Actions taken:
February 21, 2014: received issue
December 22, 2015: Resolved
March 29, 2016: closed issue

Issue 19275: Support abstract mappings/relations (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
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.

Resolution: 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
Revised Text: In Figure 7.4 and the QVTbase models add Rule::isAbstract : Boolean [1]. In 7.11.1.4 Rule add An abstract rule provides functionality that can be exploited by refined rules. An abstract rule is never matched directly and so never executes directly. In 7.11.1.4 Rule Associations add isAbstract : Boolean[1] indicates that the rule is abstract. Default is false. In 7.13.5 correct <relation> ::= ['top'] ['abstract'] 'relation' <identifier> In 9.18 correct Mapping ::= ['abstract'] 'map' MappingName ['in' TransformationName] ['refines' MappingName] '{' In A.3.1 correct abstract map attributes in umlRdbms refines flattening { In A.3.1 correct abstract map classAttributes in umlRdbms refines attributes { In A.3.1 correct abstract map primitiveAttribute in umlRdbms refines attributes { In A.3.1 correct abstract map complexAttributeAttributes in umlRdbms refines attributes { In A.3.1 correct abstract map complexAttribute in umlRdbms refines attributes {
Actions taken:
February 27, 2014: received issue
December 22, 2015: Resolved
March 29, 2016: closed issue

Issue 19428: Dynamic set of input models (qvt-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
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.

Resolution: 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
Revised Text: At the end of 7.1 add A declarative transformation is not restricted to a fixed number of models. Collections of input models may be provided and transformed as a single multi-rooted input model. At the end of 8.1.1 add. A transformation is not restricted to a fixed number of models. Collections of in and inout models may also be transformed. transformation Uml2Rdbms(in uml:Sequence(UML),out rdbms:RDBMS); The multiple models can be distinguished using collection operations. In 8.2.1.5 replace Each model parameter refers implicitly to a model participating in the query or transformation. by Each model parameter refers implicitly to a model or collection of models participating in the query or transformation. and The type of an instance of ModelParameter is an instance of ModelType. self.type.oclIsKindOf(ModelType) by The type of a ModelParameter is a ModelType or Collection of a ModelType. self.type.oclIsKindOf(ModelType) or (self.type.oclIsKindOf(CollectionType) and self.type.oclAsType(CollectionType).elementType.oclIsKindOf(ModelType)) and Model parameters are notated as simple parameters within the signature of a transformation. by Model parameters are notated as simple or collection parameters within the signature of a transformation. transformation ManyToOne(in many:Sequence(Mine),out one:Mine)
Actions taken:
May 22, 2014: received issue
December 22, 2015: Resolved
March 29, 2016: closed issue

Issue 19429: Inadequate definition of "late" semantics (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Significant
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.

Resolution: 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.
Revised Text:
Actions taken:
May 22, 2014: received issue
December 22, 2015: Deferred
March 29, 2016: closed issue

Issue 19505: Clarify availability of 'result' for Tuiple returns (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
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.

Resolution: 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
Revised Text: In "8.1.16 Pre-defined Variables: this, self, and result" replace 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. by Within a contextual operation, result is the name of the unique result parameter, which is a tuple when there are multiple result parameters. When the name of a single result parameter is specified explicitly, no pre-defined result variable exists.
Actions taken:
July 2, 2014: received issue
December 22, 2015: Resolved
March 29, 2016: closed issue

Issue 19548: invalid in QVT (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
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.

Resolution: 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.
Revised Text: After 8.1.17 Null add 8.1.18 Invalid When an OCL evaluation fails it does not raise an Exception, rather it returns the invalid value. The invalid may be the result of a hard error such as divide-by-zero, or an ordered-collection-index-out-of-bounds or a programming problem such as navigation of a null object. Every use of a source value by an ImperativeExpression has an implicit assertion that the source value is not invalid, therefore using invalid is an assertion failure. Initialization of, or assignment to, a variable stores rather than uses the value. invalid may be stored in a variable, however subsequent access of the variable will probably use it and encounter an assertion failure. An invalid value may be tested by the oclIsInvalid() operation without causing a failure.
Actions taken:
July 28, 2014: received issue
December 22, 2015: Resolved
March 29, 2016: closed issue

Issue 19571: Inadequate helper/query distinction (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
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?

Resolution: 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?
Revised Text:
Actions taken:
August 6, 2014: received issue
December 22, 2015: Duplicate or Merged
March 29, 2016: closed issue

Issue 19621: allInstances() needs clarification (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
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.

Resolution: 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.
Revised Text: Add a new sub-clause 6.5 OCL usage in QVT The QVT languages introduce controlled mechanisms for object mutation that conflict with OCL's expectations of stability. These conflicts are clarified in this subclause. . Essential OCL is used as the expressions language for QVT Relations, Core and Operational Mappings. It is a side effect free language that supports evaluation of constraints on the unchanging state of the objects in a model. (<footnote> Operation pre- and post-conditions and @pre extend this to two states.) The declarative QVTc and QVTr languages may cascade mappings in which OCL evaluations access intermediate objects. These evaluations occur predictably for either an old or a new state of an object. An old state is inherently stable. The new state is stabilized by the declarative computation of values before usage. An exception however arises for allInstances() for which the declarative mapping execution order is difficult for a programmer to predict with certainty. allInstances() is therefore defined to return the final state of instances in the domain within which allInstances() is invoked. Imperative OCL is an extension of Essential OCL with additional facilities to realize the side effects required by QVT Operational Mappings. The imperative QVTo language performs object mutations as it advances from one program state to another in a predictable order. OCL evaluation may be used within each state. The functionality of allInstances() is clarified in the Section 8.3.18. Before "8.3.18 predefined tags" add Operations on Classifiers Classifier::allInstances() : Set(T) The OCL definition is: The operation allInstances() returns all instances of the classifier and the classifiers specializing it. May only be used for classifiers that have a finite number of instances. This is the case, for example, for user defined classes because instances need to be created explicitly, and for enumerations, the standard Boolean type, and other special types such as OclVoid. This is not the case, for example, for data types such as collection types or the standard String, UnlimitedNatural, Integer, and Real types. This needs clarification for use in an imperative QVTo context for which OCL's expectation of an unchanging context is only valid within sub-expressions of an ImperativeExpression. For QVTo, the prevailing state is used; successive calls to allInstances() may return different sets of mutable instances. Instances are returned from all the model extents for input, inout and output models. Instances of intermediate objects are not returned unless they have been added to an extent. Instances from a metamodel are not returned unless the metamodel is also an input model. The Model::objectsOfKind() operation may be used to return selected instances from a particular model extent.
Actions taken:
September 25, 2014: received issue
December 22, 2015: Resolved
March 29, 2016: closed issue

Issue 19663: Exact QVTr Collection match (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
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] | '_'))?

Resolution: 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] | '_'))?
Revised Text: In 7,13.5 replace '++' (<identifier> | '_') by ['++' (<identifier> | '_')]
Actions taken:
November 28, 2014: received issue
December 22, 2015: Resolved
March 29, 2016: closed issue

Issue 19664: QVTr Multi-root match (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Enhancement
Severity: Significant
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.

Resolution: 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.
Revised Text: In the QVTr models and Fig 7.8 change RelationDomain::pattern : DomainPattern[0..1] to RelationDomain::pattern : DomainPattern[*] {ordered} and RelationDomain::rootVariable: Variable[1] to RelationDomain::rootVariable: Variable[+] {ordered} In 7.11.3.3 RelationDomain correct A relation domain has aone or more distinguished typed variablevariables called the root variablevariables that can be matched in a model of a given model type. A relation domain specifies a set of model elements of interest by means of a domain pattern, which can be viewed as a graph of object nodes, their properties and association links, with aone or more distinguished root nodenodes that isare bound to the corresponding root variable of the relation domain. and rootVariable: Variable[1+] {ordered} The distinguished typed variablevariables of the relation domain that can be matched in a model of a given model type. and pattern: DomainPattern [0..1] {composes ,ordered} The domain patternpatterns that specifiesspecify the model elements of the relation domain. The root object template expression (i.e., the root node) of theeach domain pattern must be bound to the corresponding root variable of the relation domain. In 7.11.3.8 replace The number and types of the arguments must match the number of domains and types of the root variables of the domains respectively. by The number and types of the arguments must match the total number and types of the root variables of the domains. The arguments are ordered firstly by the order of the domains in the called relation, and then by the order of the patterns of each domain. In 7.13.5 replace <domain> ::= [<checkEnforceQualifier>] 'domain' <modelId> <template> by <domain> ::= [<checkEnforceQualifier>] 'domain' <modelId> <template> (',' <template>)*
Actions taken:
November 28, 2014: received issue
December 22, 2015: Resolved
March 29, 2016: closed issue

Issue 19665: QVTr Variable Initialization (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Enhancement
Severity: Minor
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.

Resolution: 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.
Revised Text: In 7.13.5 replace <varDeclaration> ::= <identifier> (, <identifier>)* ':' <TypeCS> ';' to <varDeclaration> ::= <identifier> (, <identifier>)* ':' <TypeCS> ['=' <OclExpressionCS>] ';'
Actions taken:
November 28, 2014: received issue
December 22, 2015: Resolved
March 29, 2016: closed issue

Issue 19673: Rewind Issues 9379, 10938 (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Significant
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 trnasformation

Resolution: 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.
Revised Text:
Actions taken:
December 9, 2014: received issue
December 22, 2015: Deferred
March 29, 2016: closed issue

Issue 19687: Unclear multi-valued initialisation from single value (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

The two examples      mymultivaluedproperty += object Node {�}; // additive semantics&#61472;  mymultivaluedproperty := object Node {�}; // the list is reset and re-assigned&#61472;      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.

Resolution: 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
Revised Text:
Actions taken:
December 15, 2014: received issue
December 22, 2015: Duplicate or Merged
March 29, 2016: closed issue

Issue 19725: Allow QVTc to use initialized variables (qvt-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
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.

Resolution: 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.
Revised Text: In 9.18 Concrete Syntax replace Variable := VariableName ':' TypeDeclaration by Variable := VariableName ':' TypeDeclaration [':=' ValueOCLExpr]
Actions taken:
February 19, 2015: received issue
December 22, 2015: Resolved
March 29, 2016: closed issue

Issue 19760: Define return type for objectsOf...(T) operations more precisely (qvt-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
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) ?

Resolution: 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 [1]QVT13-12 can similarly exploit a T. The confusing wording of Model::createEmptyModel can be clarified, ---------------------------------------------------------------------------------------- [1] http://issues.omg.org/browse/QVT13-12
Revised Text: In 8.3.4.6 subobjectsOfType correct Element::subobjectsOfType(OclTypetype : Classifier) : Set(ElementT) add The returned Set element type T is the type specified as type. In 8.3.4.7 allSubobjectsOfType correct Element::allSubobjectsOfType(OclTypetype : Classifier) : Set(ElementT) add The returned Set element type T is the type specified as type. In 8.3.4.8 subobjectsOfKind correct Element::subobjectsOfKind(OclTypetype : Classifier) : Set(ElementT) add The returned Set element type T is the type specified as type. In 8.3.4.9 allSubobjectsOfKind correct Element::allSubobjectsOfKind(OclTypetype : Classifier) : Set(ElementT) add The returned Set element type T is the type specified as type. In 8.3.4.10 clone correct Element::clone() : ElementT add The returned type T is the type of the source element as known at compile time. In 8.3.4.11 deepclone correct Element::deepclone() : ElementT add The returned type T is the type of the source element as known at compile time. Before 8.3.5.2 objectsOfType add 8.3.5.2 objectsOfKind Model::objectsOfKind(type : Classifier) : Set(T) Returns the list of the objects in the model extent that have the type given. The returned Set element type T is the type specified as type. In 8.3.5.2 objectsOfType correct Model::objectsOfType(OclTypetype : Classifier) : Set(ElementT) Returns the list of the objects in the model extent that have the exact type given. The returned Element type is the type denoted by the type expression.The returned Set element type T is the type specified as type. in 8.3.5.7 createEmptyModel correct Creates and initializes a model of the giventhis model's model type.
Actions taken:
May 19, 2015: received issue
December 22, 2015: Resolved
March 29, 2016: closed issue

Issue 19810: NOP helper example due to non-mutating List operation (qvt-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
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.

Resolution: 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
Revised Text: In 8.1.8 Helper ... computeCandidates list.appendadd(self.retrieveCandidates());
Actions taken:
June 25, 2015: received issue
December 22, 2015: Resolved
March 29, 2016: closed issue

Issue 19816: Unspecified handling of imports without access/extends (qvt-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
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.

Resolution: 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.
Revised Text: In 8.2.1.4 ModuleImport The semantics of the library import. Possible values are access and extension. access is the default. In the QVTo model change ModuleImport.kind lowerbound to 0..11 and defaultValue to unspecifiedaccess. Consequently show the [1] multiplicity in 8.2.1.4 and Figure 8.1.
Actions taken:
July 9, 2015: received issue
December 22, 2015: Resolved
March 29, 2016: closed issue

Issue 19823: Calling the super implementation of an overriding operation (qvt-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
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.

Resolution: 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 [1]QVT13-93 clarifies the concept of a mapping identifier. An arbitrary mapping may therefore be called: self.map My::Tx::Your::Type::doIt(withSomething); ---------------------------------------------------------------------------------------- [1] http://issues.omg.org/browse/QVT13-93
Revised Text:
Actions taken:
August 3, 2015: received issue
December 22, 2015: Duplicate or Merged
March 29, 2016: closed issue