Issues for MOF QVT 1.2 Revision Task Force

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

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

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

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

Click here for this issue's archive.
Source: Nomos Software (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: Nomos Software (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:
Revised Text:
Actions taken:
March 25, 2007: received issue

Discussion:

Resolution: DEFERRED

Issue 10935: 9.18 Identifiers (qvt-rtf)

Click here for this issue's archive.
Source: Nomos Software (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:
Revised Text:
Actions taken:
March 25, 2007: received issue

Discussion:

Resolution: DEFERRED

Issue 10936: 9.18 Undefined semantics (qvt-rtf)

Click here for this issue's archive.
Source: Nomos Software (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:
Revised Text:
Actions taken:
March 25, 2007: received issue

Discussion:

Resolution: DEFERRED

Issue 10937: 9.18: Realized (qvt-rtf)

Click here for this issue's archive.
Source: Nomos Software (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:
Revised Text:
Actions taken:
March 25, 2007: received issue

Discussion:

Resolution: DEFERRED

Issue 10938: 9.17 Variable composition (qvt-rtf)

Click here for this issue's archive.
Source: Nomos Software (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:
Revised Text:
Actions taken:
March 25, 2007: received issue

Discussion:

Resolution: DEFERRED

Issue 10939: 9.18 Trailing | (qvt-rtf)

Click here for this issue's archive.
Source: Nomos Software (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:
Revised Text:
Actions taken:
March 25, 2007: received issue

Discussion:

Resolution: DEFERRED

Issue 10940: 9.18 GuardPattern assignments (qvt-rtf)

Click here for this issue's archive.
Source: Nomos Software (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:
Revised Text:
Actions taken:
March 25, 2007: received issue

Discussion:

Resolution: DEFERRED

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

Click here for this issue's archive.
Source: Nomos Software (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:
Revised Text:
Actions taken:
March 25, 2007: received issue

Discussion:

Resolution: DEFERRED

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

Click here for this issue's archive.
Source: Nomos Software (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:
Revised Text:
Actions taken:
March 25, 2007: received issue

Discussion:

Resolution: DEFERRED

Issue 10943: 9.18 Anonymous Maps (qvt-rtf)

Click here for this issue's archive.
Source: Nomos Software (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:
Revised Text:
Actions taken:
March 25, 2007: received issue

Discussion:

Resolution: DEFERRED

Issue 10944: 9.18 EnforcementOperation (qvt-rtf)

Click here for this issue's archive.
Source: Nomos Software (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:
Revised Text:
Actions taken:
March 25, 2007: received issue

Discussion:

Resolution: DEFERRED

Issue 10945: 9.18 Typographics Issues (qvt-rtf)

Click here for this issue's archive.
Source: Nomos Software (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:
Revised Text:
Actions taken:
March 25, 2007: received issue

Discussion:

Resolution: DEFERRED

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

Click here for this issue's archive.
Source: Nomos Software (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: Nomos Software (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 11056: Provide the list of reflective MOF operations that are available (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:

Is not very clear what are the reflective MOF operations that are available 
to QVT operational transformation writers

Resolution:
Revised Text:
Actions taken:
May 24, 2007: received issue

Discussion:

deferred

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:
Revised Text:
Actions taken:
May 24, 2007: received issue

Discussion:

Resolution: Deferred

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: deferred
Revised Text:
Actions taken:
May 24, 2007: received 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: Nomos Software (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:
Revised Text:
Actions taken:
June 1, 2007: received 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: Nomos Software (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:
Revised Text:
Actions taken:
October 10, 2007: received 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:
Revised Text:
Actions taken:
November 26, 2007: received 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:
Revised Text:
Actions taken:
November 26, 2007: received issue

Discussion:

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:
Revised Text:
Actions taken:
November 27, 2007: received issue

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

Click here for this issue's archive.
Source: Nomos Software (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:
Revised Text:
Actions taken:
December 3, 2007: received issue

Discussion:

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

Click here for this issue's archive.
Source: Nomos Software (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:
Revised Text:
Actions taken:
December 17, 2007: received issue

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

Click here for this issue's archive.
Source: Nomos Software (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:
Revised Text:
Actions taken:
December 17, 2007: received 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

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:
Revised Text:
Actions taken:
February 6, 2008: received issue

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

Discussion:

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

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:
Revised Text:
Actions taken:
April 3, 2008: received 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:
Revised Text:
Actions taken:
April 4, 2008: received issue

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: Nomos Software (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: Nomos Software (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:
Revised Text:
Actions taken:
June 6, 2008: received 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

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: receivd issue

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

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:
Revised Text:
Actions taken:
June 6, 2008: received 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:
Revised Text:
Actions taken:
June 6, 2008: received 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:
Revised Text:
Actions taken:
June 6, 2008: received 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:
Revised Text:
Actions taken:
June 6, 2008: received 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:
Revised Text:
Actions taken:
June 6, 2008: received 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:
Revised Text:
Actions taken:
June 6, 2008: received issue

Discussion:

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

Click here for this issue's archive.
Source: Nomos Software (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:
Revised Text:
Actions taken:
July 11, 2008: received issue

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

Click here for this issue's archive.
Source: Nomos Software (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:
Revised Text:
Actions taken:
July 11, 2008: received issue

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

Click here for this issue's archive.
Source: Nomos Software (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:
Revised Text:
Actions taken:
July 11, 2008: received 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: Nomos Software (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:
Revised Text:
Actions taken:
October 31, 2008: received issue

Discussion:

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:
Revised Text:
Actions taken:
November 15, 2008: received issue

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:
Revised Text:
Actions taken:
November 21, 2008: received issue

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:
Revised Text:
Actions taken:
December 15, 2008: received issue

Issue 13168: Typedef aliases issue (qvt-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, adolfosbh(at)opencanarias.com)
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:
Revised Text:
Actions taken:
December 18, 2008: received issue

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, adolfosbh(at)opencanarias.com)
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:
Revised Text:
Actions taken:
December 19, 2008: received issue

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

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, adolfosbh(at)opencanarias.com)
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:
Revised Text:
Actions taken:
December 19, 2008: received issue

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, adolfosbh(at)opencanarias.com)
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:
Revised Text:
Actions taken:
December 19, 2008: received 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, adolfosbh(at)opencanarias.com)
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:
Revised Text:
Actions taken:
December 19, 2008: received 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:
Revised Text:
Actions taken:
January 13, 2009: received 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:
Revised Text:
Actions taken:
January 13, 2009: received 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:
Revised Text:
Actions taken:
January 13, 2009: received 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:
Revised Text:
Actions taken:
January 13, 2009: received 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, adolfosbh(at)opencanarias.com)
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:
Revised Text:
Actions taken:
January 13, 2009: received issue

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, adolfosbh(at)opencanarias.com)
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:
Revised Text:
Actions taken:
January 15, 2009: received 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, adolfosbh(at)opencanarias.com)
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:
Revised Text:
Actions taken:
January 15, 2009: received 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, adolfosbh(at)opencanarias.com)
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:
Revised Text:
Actions taken:
January 15, 2009: received 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, adolfosbh(at)opencanarias.com)
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:
Revised Text:
Actions taken:
January 15, 2009: received 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, adolfosbh(at)opencanarias.com)
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:
Revised Text:
Actions taken:
January 15, 2009: received 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, adolfosbh(at)opencanarias.com)
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:
Revised Text:
Actions taken:
January 15, 2009: received 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, adolfosbh(at)opencanarias.com)
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:
Revised Text:
Actions taken:
January 15, 2009: received 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, adolfosbh(at)opencanarias.com)
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:
Revised Text:
Actions taken:
January 15, 2009: received 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, adolfosbh(at)opencanarias.com)
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:
Revised Text:
Actions taken:
January 15, 2009: received 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, adolfosbh(at)opencanarias.com)
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:
Revised Text:
Actions taken:
January 15, 2009: received 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, adolfosbh(at)opencanarias.com)
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:
Revised Text:
Actions taken:
January 15, 2009: received 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, adolfosbh(at)opencanarias.com)
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:
Revised Text:
Actions taken:
January 15, 2009: received 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, adolfosbh(at)opencanarias.com)
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:
Revised Text:
Actions taken:
January 15, 2009: received 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, adolfosbh(at)opencanarias.com)
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:
Revised Text:
Actions taken:
January 15, 2009: received 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, adolfosbh(at)opencanarias.com)
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:
Revised Text:
Actions taken:
January 15, 2009: received 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, adolfosbh(at)opencanarias.com)
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:
Revised Text:
Actions taken:
January 15, 2009: received 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, adolfosbh(at)opencanarias.com)
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:
Revised Text:
Actions taken:
January 15, 2009: received 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, adolfosbh(at)opencanarias.com)
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:
Revised Text:
Actions taken:
January 15, 2009: received 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, adolfosbh(at)opencanarias.com)
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:
Revised Text:
Actions taken:
January 15, 2009: received 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, adolfosbh(at)opencanarias.com)
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:
Revised Text:
Actions taken:
January 15, 2009: received 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, adolfosbh(at)opencanarias.com)
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:
Revised Text:
Actions taken:
January 15, 2009: received 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, adolfosbh(at)opencanarias.com)
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:
Revised Text:
Actions taken:
January 15, 2009: received 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, adolfosbh(at)opencanarias.com)
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:
Revised Text:
Actions taken:
January 15, 2009: received 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, adolfosbh(at)opencanarias.com)
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
January 15, 2009: received 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, adolfosbh(at)opencanarias.com)
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:
Revised Text:
Actions taken:
January 15, 2009: received 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, adolfosbh(at)opencanarias.com)
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:
Revised Text:
Actions taken:
January 15, 2009: received 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, adolfosbh(at)opencanarias.com)
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:
Revised Text:
Actions taken:
January 15, 2009: received 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, adolfosbh(at)opencanarias.com)
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.

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

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:
Revised Text:
Actions taken:
April 30, 2009: received 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:
Revised Text:
Actions taken:
June 14, 2009: received 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

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:
Revised Text:
Actions taken:
June 14, 2009: reeived 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 http://www.omg.org/spec/QVT/1.0/PDF


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


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


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


It should be 9 and 7 ;)

Resolution:
Revised Text:
Actions taken:
October 9, 2009: received 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

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

Click here for this issue's archive.
Source: Nomos Software (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:
Revised Text:
Actions taken:
November 11, 2009: reeived 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: Nomos Software (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:
Revised Text:
Actions taken:
November 11, 2009: received 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: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The numerous problems identified in http://www.omg.org/archives/qvt-rtf/msg00094.html need to be addressed.

Resolution:
Revised Text:
Actions taken:
November 16, 2009: received issue

Discussion:

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: Unisys (Dr. Doug Tolbert, dtolbert408(at)gmail.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

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

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

Click here for this issue's archive.
Source: Nomos Software (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:
Revised Text:
Actions taken:
July 18, 2010: received issue

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

Click here for this issue's archive.
Source: Nomos Software (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:
Revised Text:
Actions taken:
July 30, 2010: received issue

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

Click here for this issue's archive.
Source: Nomos Software (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:
Revised Text:
Actions taken:
August 10, 2010: received issue

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

Click here for this issue's archive.
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

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

Click here for this issue's archive.
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:
Revised Text:
Actions taken:
August 13, 2010: received issue

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:
Revised Text:
Actions taken:
August 3, 2010: received 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: Nomos Software (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:
Revised Text:
Actions taken:
August 13, 2010: received issue

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

Click here for this issue's archive.
Source: Nomos Software (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:
Revised Text:
Actions taken:
August 13, 2010: received 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:
Revised Text:
Actions taken:
October 12, 2010: received issue

Discussion:

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:
Revised Text:
Actions taken:
January 7, 2011: received 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:
Revised Text:
Actions taken:
January 21, 2011: received 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:
Revised Text:
Actions taken:
January 21, 2011: received 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

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:
Revised Text:
Actions taken:
December 27, 2012: received issue

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:
Revised Text:
Actions taken:
December 27, 2012: received issue

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: rewceived issue

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:
Revised Text:
Actions taken:
January 4, 2013: received issue

Issue 18572: QVT atomicity (qvt-rtf)

Click here for this issue's archive.
Source: Nomos Software (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:
Revised Text:
Actions taken:
March 21, 2013: received issue