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 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 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 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 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 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 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 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.
Source: International Business Machines (Dr. Maged Elaasar, melaasar(at)ca.ibm.com)
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.
Source: International Business Machines (Dr. Maged Elaasar, melaasar(at)ca.ibm.com)
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