MOF Query/View/Transformation Avatar
  1. OMG Specification

MOF Query/View/Transformation — Closed Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
QVT-90 Pre-ballot 2 FTF Appendix A: Erroneous memberSelection grammar QVT 1.0b1 QVT 1.0 Resolved closed
QVT-89 Chapter 7 QVTrelation Standard Library QVT 1.0b1 QVT 1.0 Resolved closed
QVT-88 RelationalTransformation as a subclass of Transformation QVT 1.0b1 QVT 1.0 Resolved closed
QVT-87 Rules for infering an extent QVT 1.0b1 QVT 1.0 Resolved closed
QVT-86 Top-levelness in QVT relations need to be enforced by a constraint QVT 1.0b1 QVT 1.0 Resolved closed
QVT-85 Escape characters in string literals QVT 1.0b1 QVT 1.0 Resolved closed
QVT-84 Kind of expressions in collection patterns QVT 1.0b1 QVT 1.0 Resolved closed
QVT-83 Relation To Core Transformation QVT 1.0b1 QVT 1.0 Resolved closed
QVT-82 Formatting QVT 1.0b1 QVT 1.0 Resolved closed
QVT-81 Typos QVT 1.0b1 QVT 1.0 Resolved closed
QVT-80 Ambiguity QVT 1.0b1 QVT 1.0 Resolved closed
QVT-79 Member selection operator QVT 1.0b1 QVT 1.0 Resolved closed
QVT-78 Filename QVT 1.0b1 QVT 1.0 Resolved closed
QVT-77 Missing oclExpressionCSList QVT 1.0b1 QVT 1.0 Resolved closed
QVT-76 Missing paramDeclaration QVT 1.0b1 QVT 1.0 Resolved closed
QVT-75 Member selection as domain body QVT 1.0b1 QVT 1.0 Resolved closed
QVT-74 Unsafe oclExpressionCS QVT 1.0b1 QVT 1.0 Resolved closed
QVT-73 Over-enthusiastic semicolon QVT 1.0b1 QVT 1.0 Resolved closed
QVT-72 Missing commas QVT 1.0b1 QVT 1.0 Resolved closed
QVT-71 Unquoted commas QVT 1.0b1 QVT 1.0 Resolved closed
QVT-70 Comments QVT 1.0b1 QVT 1.0 Resolved closed
QVT-69 OCL extensions QVT 1.0b1 QVT 1.0 Resolved closed
QVT-68 QVTrelation to QVTcore transformation QVT 1.0b1 QVT 1.0 Resolved closed
QVT-67 variable-assignment isn't defined in Core language QVT 1.0b1 QVT 1.0 Resolved closed
QVT-66 QVT Issue: Support for CMOF metamodels QVT 1.0b1 QVT 1.0 Resolved closed
QVT-65 Logging textual messages that depend on variables QVT 1.0b1 QVT 1.0 Resolved closed
QVT-64 Inconsistency of multiplicity of ImperativeIterateExp::target QVT 1.0b1 QVT 1.0 Resolved closed
QVT-63 When and where clause for mapping operations QVT 1.0b1 QVT 1.0 Resolved closed
QVT-62 Missing multiplicity of AnonymousLiteralPart::value QVT 1.0b1 QVT 1.0 Resolved closed
QVT-61 Missing iterator variable in resolve expressions QVT 1.0b1 QVT 1.0 Resolved closed
QVT-60 Missing variable references within inlined object expressions QVT 1.0b1 QVT 1.0 Resolved closed
QVT-59 Missing association from MappingParameter to a ModelParameter QVT 1.0b1 QVT 1.0 Resolved closed
QVT-58 Typo error ImperativeIteratorExp expected in diagram QVT 1.0b1 QVT 1.0 Resolved closed
QVT-57 Entry operations in operational definitions QVT 1.0b1 QVT 1.0 Resolved closed
QVT-56 isTopLevel should not be a derived property QVT 1.0b1 QVT 1.0 Resolved closed
QVT-55 RelationalTransformation as a subclass of Transformation QVT 1.0b1 QVT 1.0 Resolved closed
QVT-54 Typo error for properties whenOwner and whereOwner QVT 1.0b1 QVT 1.0 Resolved closed
QVT-53 Bad navigability in cross-package links QVT 1.0b1 QVT 1.0 Resolved closed
QVT-52 Revise the encoding of primitive domains QVT 1.0b1 QVT 1.0 Resolved closed
QVT-51 Incorrect composition of variables in patterns QVT 1.0b1 QVT 1.0 Resolved closed
QVT-50 Page 131 QVT 1.0b1 QVT 1.0 Resolved closed
QVT-49 Page 118 QVT 1.0b1 QVT 1.0 Resolved closed
QVT-48 Page 117 QVT 1.0b1 QVT 1.0 Resolved closed
QVT-47 Page 45 and 165 QVT 1.0b1 QVT 1.0 Resolved closed
QVT-46 Page 30 QVT 1.0b1 QVT 1.0 Resolved closed
QVT-45 Page 28 QVT 1.0b1 QVT 1.0 Resolved closed
QVT-44 Consider using the package keyword instead of metamodel QVT 1.0b1 QVT 1.0 Resolved closed
QVT-43 Consider using the case keyword within swith expression QVT 1.0b1 QVT 1.0 Resolved closed
QVT-42 Argument list missing in raise expression QVT 1.0b1 QVT 1.0 Resolved closed
QVT-38 Some errors in BNF grammar of the operational part QVT 1.0b1 QVT 1.0 Resolved closed
QVT-41 Consider adjusting the notation for unpack QVT 1.0b1 QVT 1.0 Resolved closed
QVT-40 Inconsistency in definition of TryExp with figure QVT 1.0b1 QVT 1.0 Resolved closed
QVT-39 Missing notation to indicate the enforced direction in mapping operations QVT 1.0b1 QVT 1.0 Resolved closed
QVT-37 Missing text for notation for class properties in Section 8.4.6 QVT 1.0b1 QVT 1.0 Resolved closed
QVT-36 Any used instead of MOF::Object in operational type extensions QVT 1.0b1 QVT 1.0 Resolved closed
QVT-35 Typos and omissions in the QVT operational Part QVT 1.0b1 QVT 1.0 Resolved closed
QVT-34 Top-level constraint too restrictive QVT 1.0b1 QVT 1.0 Resolved closed
QVT-33 8.4.3.5 != and <> QVT 1.0b1 QVT 1.0 Resolved closed
QVT-32 8.4.3.5 = and == QVT 1.0b1 QVT 1.0 Resolved closed
QVT-31 Pre-ballot 2 FTF Appendix A: Erroneous collectionTemplate grammar QVT 1.0b1 QVT 1.0 Resolved closed
QVT-30 Chapter 7,8,9 EssentialOCL usage QVT 1.0b1 QVT 1.0 Resolved closed
QVT-29 Chapter 7 Collection::=() QVT 1.0b1 QVT 1.0 Resolved closed
QVT-28 7.11.3.1 Relation.operationalImpl QVT 1.0b1 QVT 1.0 Resolved closed
QVT-27 Consider renaming 'AnonymousTuple' as 'OrderedTuple' QVT 1.0b1 QVT 1.0 Resolved closed
QVT-26 QVTOperational examples have some errors and need to be inline with grammar QVT 1.0b1 QVT 1.0 Resolved closed
QVT-25 Find better notation for explicit extent indication in op mapping parameter QVT 1.0b1 QVT 1.0 Resolved closed
QVT-24 8.4.6.2 QVToperational is not a syntax extension of OCL QVT 1.0b1 QVT 1.0 Resolved closed
QVT-23 7.13 Implicit Variable Declarations QVT 1.0b1 QVT 1.0 Resolved closed
QVT-22 7.13 Comments QVT 1.0b1 QVT 1.0 Resolved closed
QVT-21 7.11.2.3 CollectionTemplateExp.referredCollectionType QVT 1.0b1 QVT 1.0 Resolved closed
QVT-20 7.11.2.3 CollectionTemplateExp QVT 1.0b1 QVT 1.0 Resolved closed
QVT-19 7.11.1.2 Meta-model Id persistence QVT 1.0b1 QVT 1.0 Resolved closed
QVT-15 Distinguishing pure syntactic tags from other tags in QVTOperational QVT 1.0b1 QVT 1.0 Resolved closed
QVT-18 7.13.1 Collection conversions QVT 1.0b1 QVT 1.0 Resolved closed
QVT-17 7.13.1 Model class name semantics QVT 1.0b1 QVT 1.0 Resolved closed
QVT-16 7.13.1 Scoped transformation name QVT 1.0b1 QVT 1.0 Resolved closed
QVT-14 Extent of intermediate classes in QVT Operational QVT 1.0b1 QVT 1.0 Resolved closed
QVT-13 The QVT Operational StdLib has various mispellings and copy-paste errors QVT 1.0b1 QVT 1.0 Resolved closed
QVT-12 Clarify the return type of xselect operator QVT 1.0b1 QVT 1.0 Resolved closed
QVT-11 Incomplete specification for the resolution operation ResolveExp QVT 1.0b1 QVT 1.0 Resolved closed
QVT-10 The representation and the containment of 'this' variable is missing QVT 1.0b1 QVT 1.0 Resolved closed
QVT-9 The BNF syntax of QVTOperational is not complete QVT 1.0b1 QVT 1.0 Resolved closed
QVT-8 rules for solving type identifiers are missing in the QVTOperational syntax QVT 1.0b1 QVT 1.0 Resolved closed
QVT-7 Relations language should support "default assignments" QVT 1.0b1 QVT 1.0 Resolved closed
QVT-6 Relations language QVT 1.0b1 QVT 1.0 Resolved closed
QVT-5 Identifiers syntax to avoid reserved keywords QVT 1.0b1 QVT 1.0 Resolved closed
QVT-4 Collection Type syntax ambiguities QVT 1.0b1 QVT 1.0 Resolved closed
QVT-1 Query result syntax QVT 1.0b1 QVT 1.0 Resolved closed
QVT-3 Problem with Domain syntax QVT 1.0b1 QVT 1.0 Resolved closed
QVT-2 RelationalCallExp missing QVT 1.0b1 QVT 1.0 Resolved closed

Issues Descriptions

Pre-ballot 2 FTF Appendix A: Erroneous memberSelection grammar

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

    memberSelection has missing , in list

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

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

    closed, no change

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

Chapter 7 QVTrelation Standard Library

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

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

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

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

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

    Add the following subsection in the concrete syntax section 7.13:

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

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

RelationalTransformation as a subclass of Transformation

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

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

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

    {composes}

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

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

    duplicate of issue 9383, close

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

Rules for infering an extent

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

    The rules for inferring an extent from the type are not explained or referenced.
    Note: This issue is related to issue: 9388

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

    In relation with resolution 9388, replace the text describing the "modelParameter" role:

    The extent of the mapping parameter. Should be explicitly provided
    when there is an ambiguity on the extent that will own a potential
    created element corresponding to this parameter.

    By:

    """
    The extent of the mapping parameter. If not provided the extent is inferred by inspecting the model types of the transformation. See the inference rules below.
    """

    In addition, after the description of the metaclass properties, add the following paragraph:
    """
    Extent inference rule for mapping parameters:
    If the mapping parameter direction is "in", inspect the input model types of the transformation to find the one that contains the type of the parameter. A model type "contains" a type if the type is directly or indirectly contained by the package defining the model type.
    If the model parameter direction is "inout" or "out", inspect the inout or output model types of the transformation to find the one that contains the type of the parameter.
    In both cases there should be a unique model type found.
    """

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

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

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

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

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

    Add a "Constraints" subsection with the following content:

    """
    A non top-level relation should be invoked from the where clause of some other relation.
    self.isTopLevel implies not Relation.allInstances()->exists(r |
    r.where.predicate.conditionExpression->exists(ce |
    ce.oclIsTypeOf(RelationCallExp) and
    ce.oclAsType(RelationCallExp).referredRelation = self
    )
    )
    """

    NOTE:
    This issue is superseded by issue 11022. The resolution should hence not be applied.

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

Escape characters in string literals

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

    The escape characters used in string literals need to be adequately defined
    or referenced.
    Note: This issue is related to issue: 9427

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

    In relation with resolution 9427, replace the sentence:

    "All the usual escape characters using backslash can be used including the '\n' return-line character."

    By
    """
    All the usual escape characters using backslash can be used including the '\n' return-line character. The list of available escape characters are those defined for the Java language.

    EscapeSequence:
    \ b /* \u0008: backspace BS */
    \ t /* \u0009: horizontal tab HT */
    \ n /* \u000a: linefeed LF */
    \ f /* \u000c: form feed FF */
    \ r /* \u000d: carriage return CR */
    \ " /* \u0022: double quote" */
    \ ' /* \u0027: single quote ' */
    \ \ /* \u005c: backslash \ */
    OctalEscape /* \u0000 to \u00ff: from octal value

    OctalEscape:
    \ OctalDigit
    \ OctalDigit OctalDigit
    \ ZeroToThree OctalDigit OctalDigit
    OctalDigit: one of
    0 1 2 3 4 5 6 7
    ZeroToThree: one of
    0 1 2 3
    """

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

Kind of expressions in collection patterns

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

    The 'kind' property in collection template expression is not meant to specify
    Set/Bag/Sequence. It is meant to specify the kind of expression used in
    the collection pattern.
    Note: This issue is related to issue 9415.
    Suggested resolution:
    In order to avoid name clash with Ocl rename CollectionKind to CollectionPatternKind.
    IN section 7.11.2 insert the enumeration type CollectionPatternKind with the
    following definition:

    """
    CollectionPatternKind
    The enumeration type that specifies the kind of pattern expression used to specify
    the collection pattern. Possible values are: Enumeration, Comprehension and
    MemberSelection.

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

    The resolution of this issue is related to the resolution of issue 10784. Please refer to the resolution of issue 10784. There is no need to specify CollectionPatternKind in the new extended collection pattern suggested in 10784.

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

Relation To Core Transformation

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

    After adjusting the syntax as above to match the author's apparent expectation,
    syntax checking reveals 69 problems, marked up with --** in the attached.
    (Surprisingly few for a new language that has clearly not had a machine-assisted
    check before.)

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

    The relations-to-core transformation spec was out of sync with the meta models. The new updated spec is given in appendix B of this report.
    Replace the content of sections 10.3 by the new content in Appendix B of this report.

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

Formatting

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

    Inconsistent font for first line of 7.13.1.

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

    Font to be made consistent in 7.13.1.

    NOTE:
    This issue is superseded by issue 10616 which replaces all the content of the BNF section. Hence, the resolution should not be applied.

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

Typos

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

    In <domain>
    Replace: ['implementedby' <OperationCallExpCS>]
    By: ['implementedby' <operationCallExpCS>]

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

    Resolution: No change

    Remark:
    Looks like there was a mistake in entering the issue - OCL specifies OperationCallExpCS only.

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

Ambiguity

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

    Replace: objectTemplate ::= [<identifier>] ':' <typeCS> '{'
    By: <objectTemplate> ::= [<identifier>] ':' (primitiveTypeCS | tupleTypeCS | pathNameCS) '{'

    excluding collectionType that is ambiguous wrt collectionTemplate syntax

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

    Replace the content of section 7.13.1 and 7.13.2 by the new content given in Appendix A of this report. This new content is the updated grammar correcting typos and other mistakes.

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

Member selection operator

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

    With – as an OCL comment, ++ seems a very unfortunate choice of operator spelling.
    It also has minimal similarity to the C/Java increment operator which is unary.
    Please review. The usage seems to always be <big-clause> ++ <tiny>, so how about
    just a word.

    ?? <big-clause> 'in' <tiny>
    ?? <big-clause> 'over' <tiny>
    ?? <big-clause> 'forall' <tiny>

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

    Resolution: No change

    Remark:
    Which operator to use is a matter of taste. We checked with a few users and they preferred an operator over a keyword.

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

Filename

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

    Surely this should be a URI?
    Even if it is a filename no OS can cope without dots, slashes or ...

    Replace: <filename> ::= <identifier>
    By: <filename> ::= StringLiteralExpCS

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

    The <filename> element has been renamed <unit> to mean "compilation unit" and defined as a sequence of identifier separated by dots. It is now clear that arbitrary file names cannot be used in import statements.

    In order to apply the resolution: replace the content of section 7.13.1 and 7.13.2 by the new content given in Appendix A of this report. This new content is the updated grammar correcting typos and other mistakes.

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

Missing oclExpressionCSList

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

    Sole usage in collectionTemplate is as list of list, so presumably a typo

    Replace: <oclExpressionCSList> (',' <oclExpressionCSList>)*
    By: <oclExpressionCS> (',' <oclExpressionCS>)*

    However I cannot get past syntax ambiguities here between the '|' in a setComprehensionExpression
    and the '|' in an oclExpression. To get Relations to Core to parse I just do:

    Replace: <oclExpressionCSList> (',' <oclExpressionCSList>)*
    By: <templateCS>

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

    Replace the content of section 7.13.1 and 7.13.2 by the new content given in Appendix A of this report. This new content is the updated grammar correcting typos and other mistakes.

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

Missing paramDeclaration

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

    Suggest: <paramDeclaration> ::= <identifier> ':' <typeCS>

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

    Replace the content of section 7.13.1 and 7.13.2 by the new content given in Appendix A of this report. This new content is the updated grammar correcting typos and other mistakes.

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

Member selection as domain body

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

    Relations to Core uses a top of domain memberSelectionExprCS.

    In <dommain>
    Replace: '

    {' <propertyTemplate>* '}

    '
    By: '

    {' (<propertyTemplate>* | memberSelectionExprCS) '}

    '
    Or rather: '

    {' ((<propertyTemplate> (',' <propertyTemplate>)*) | memberSelectionExprCS) '}

    '

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

    Replace the content of section 7.13.1 and 7.13.2 by the new content given in Appendix A of this report. This new content is the updated grammar correcting typos and other mistakes.

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

Unsafe oclExpressionCS

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

    The extension to oclExpressionCS affects all cases where OCL expressions are invoked. Since the "| (<oclExpressionCS> ';')*" term
    covers epsilon, this introduces near catastrophic parsing ambiguities and meaningless syntax for existing usage.

    Suggest: restrict the semi-colon separated extension to the extended syntax where it has useful semantic meaning. Permitting the
    final semi-colon to be omitted seem needlessly generous/confusing/complicated. Therefore:

    Replace: <oclExpressionCS> ::= <propertyCallExpCS>

    <variableExpCS>
    <literalExpCS>
    <letExpCS>
    <ifExpCS>
    <template>
    '(' <oclExpressionCS> ')'
    (<oclExpressionCS> ';')*
    By: <oclExpressionCS> ::= <propertyCallExpCS>
    <variableExpCS>
    <literalExpCS>
    <letExpCS>
    <ifExpCS>
    <template>
    '(' <oclExpressionCS> ')'
    <oclStatementCS> ::= (<oclExpressionCS> ';')*

    and use this new construct as:

    Replace: <when> ::= 'when' '

    {' <oclExpressionCS> '}'
    By: <when> ::= 'when' '{' <oclStatementCS> '}'


    Replace: <where> ::= 'where' '{' <oclExpressionCS> '}

    '
    By: <where> ::= 'where' '

    {' <oclStatementCS> '}'


    In <domain>
    Replace: '{' <propertyTemplate>* '}' [ '{' <oclExpressionCS> '}' ]
    By: '{' <propertyTemplate>* '}' [ '{' <oclStatementCS> '}

    ' ]

    In <query>
    Replace: ';' | '

    {' <oclExpressionCS> '}

    '
    By: ';' | '

    {' <oclStatementCS> '}

    '

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

    Replace the content of section 7.13.1 and 7.13.2 by the new content given in Appendix A of this report. This new content is the updated grammar correcting typos and other mistakes.

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

Over-enthusiastic semicolon

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

    The Relation To Core example omits trailing semicolons following a brace-termated domain.

    In <domain>
    Replace: ['implementedby' <OperationCallExpCS>] ';'
    By: ['implementedby' <OperationCallExpCS> ';']

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

    Replace the content of section 7.13.1 and 7.13.2 by the new content given in Appendix A of this report. This new content is the updated grammar correcting typos and other mistakes.

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

Missing commas

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

    List of propertyTemplate are used without separators. The Relation To Core example uses a comma separator.

    In <domain>
    Replace: <propertyTemplate>*
    By: (<propertyTemplate> (',' <propertyTemplate>)*)

    In <objectTemplate>
    Replace: <propertyTemplate>*
    By: (<propertyTemplate> (',' <propertyTemplate>)*)

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

    Replace the content of section 7.13.1 and 7.13.2 by the new content given in Appendix A of this report. This new content is the updated grammar correcting typos and other mistakes.

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

Unquoted commas

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

    An unquoted comma is redundant in the BNF, so presumably the commas should quoted:

    Replace: <modelDecl> ::= <modelId> ':' <metaModelId> (, <metaModelId>)*
    By: <modelDecl> ::= <modelId> ':' <metaModelId> (',' <metaModelId>)*

    Replace: <keyDecl> ::= 'key' <classId> '

    {' <propertyId> (, <propertyId>)* '}

    ' ';'
    By: <keyDecl> ::= 'key' <classId> '

    {' <propertyId> (',' <propertyId>)* '}

    ' ';'

    Replace: <varDeclaration> ::= <identifier> (, <identifier>)* ':' <typeCS> ';'
    By: <varDeclaration> ::= <identifier> (',' <identifier>)* ':' <typeCS> ';'

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

    Replace the content of section 7.13.1 and 7.13.2 by the new content given in Appendix A of this report. This new content is the updated grammar correcting typos and other mistakes.

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

Comments

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

    The Relation To Core example uses a // comment, whereas OCL uses --. If this is intended then the OCL grammar must be extended

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

    Specify the comment convention in section 7.13 by adding, before sub-section 7.13.1 Relation Textual Syntax Grammar, a new sub-section named "Comments" with the following text:

    """
    The syntax supports two forms of comments, a line comment, and a paragraph comment.
    The line comment starts with the string '--' and ends with the next newline. The paragraph comment starts with the string '/' and ends with the string '/.' Paragraph comments may be nested.
    """

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

OCL extensions

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

    I've started writing a QVTr parser. So far it just does syntax analysis.
    It highlights a number of significant issues in the grammar and enables
    many mistakes to be removed from the Relations to Core example.

    OCL extension
    -------------

    7.13 should enumerate the new keywords:
    checkonly
    domain
    enforce
    extends
    implementedBy
    import
    key
    overrides
    primitive
    query
    relation
    top
    transformation
    when
    where
    and stress that they are not reserved words and so may appear in identifier. At least I presume this is the intent, since 'domain'
    is used in the Relation To Core example. I'm not entirely sure that a domain called OclAny is unambiguous, and is one called self
    useful?

    The OCL and consequently the QVT syntax lack formality here.
    OCL extensions

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

    Insert a new sub-section named "Keywords" in 7.13 to list the keywords. This section is to be inserted before the "Relations textual Syntax Grammar" sub-section. The text of the section will be as follows:

    Keywords:
    checkonly, domain, enforce, extends, implementedby, import, key, overrides
    primitive, query, relation, top, transformation, when, where.

    All these keywords are reserved words, they cannot be used as identifiers.
    The "_" OCL prefix convention for escaping reserved words can be used to refer to conflicting properties or class names.

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

QVTrelation to QVTcore transformation

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

    I've started looking at implementing QVTrelation->QVTcore in UMLX, but instantly hit problems.
    Since UMLX has built in type checking it identifies that:

    in RelationToTraceclass

    RelationDomain has a DomainPattern rather than an ObjectTemplateExp

    in SubTemplateToTraceClassProps

    ObjectTemplateExp has a PartTemplateItem rather than an ObjectTemplateExp

    These are easily fixed, but

    in TopLevelRelationToMappingForEnforcement

    there are too many discrepancies to resolve without major study; I'm very puzzled by the use of Sets for individual elements.

    Is there a revised draft that the FTF are working on that is any more consistent?

    FYI, I enclose the first two transformations in UMLX. I think they're a bit more intelligible, type consistent, although there a
    fair few UMLX loose ends to sort out.

  • Reported: QVT 1.0b1 — Wed, 26 Jul 2006 04:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    The relations-to-core transformation spec was out of sync with the meta models. The new updated spec is given in appendix B of this report.
    Replace the content of sections 10.3 by the new content in Appendix B of this report.

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

variable-assignment isn't defined in Core language

  • Key: QVT-67
  • Legacy Issue Number: 9463
  • Status: closed  
  • Source: Modeling Value Group ( Wim Bast)
  • Summary:

    There exist assignments to variables in the QVT examples.

    However, variable-assignment is not defined in the abstract and concrete syntax of the Core language.

    This should be fixed.

    Impact: only changes the QVT Core language definition.

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

    (1) In Section 9.17.8 (Assignment), replace all the introductory text
    by an "An assignment sets the property of target object or sets a
    the value of a variable. See PropertyAssignment and VariableAssignment
    definitions for detailed semantic of property assignment and variable
    assignment."
    Also, remove the 'targetProperty' association description.
    (2) In Section 9.17 add a new class named "PropertyAssignment" with
    the introductory description copy pasted from the actual description
    of Assignment class.
    Add the following sub-titles after the introductory text:
    """
    Superclasses
    Assignment
    Associations
    targetProperty: Property [1]
    The property whose value is to be assigned.
    The target property should be defined on the type of the slot expression.
    """
    (3) In Section 9.17 add a new class named "VariableAssignment" with
    the following definition:
    """
    An assignment sets the value of a variable.
    Superclasses
    Assignment
    Associations
    targetVariable: Variable [1]
    The variable whose value is to be assigned.
    """
    (4) In Figure, 9.3 make the needed changes so that the diagram reflects
    (1), (2) and (3) actions.

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

QVT Issue: Support for CMOF metamodels

  • Key: QVT-66
  • Legacy Issue Number: 9397
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    The QVT spec (ptc/05-11-01) is littered with references to EMOF but has not one reference to CMOF.
    Hence it's not clear whether QVT can be used to transform models that instantiate CMOF metamodels. This is a major requirement since UML2 is itself a CMOF metamodel.

    Note that it's not important here that the QVT metamodel itself is expressed only in EMOF: but that it can be applied to CMOF metamodels. This means that references such as ObjectTemplateExp::referredClass(from EMOF) (see Fig 7.6) should also support references to CMOF metaclasses. Though CMOF is a compatible extension of EMOF, it is important that the QVT specification makes it clear that references to CMOF classes must be supported and that compliant QVT engines should not lose information when they transform models for CMOF metamodels. This is also likely to requires changes to the specification logic that describes the execution of transformations - for example to fully support non-unique Associations.

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

    (1) Add a new top-level section named "QVT for CMOF" with the following content:

    For the sake of simplicity all previous chapters assume QVT used in the context of EMOF conformant metamodels. However this specification is also applicable to CMOF metamodels with a few restrictions.

    11.1 The QVT metamodel for CMOF

    The QVT metamodel for CMOF is a CMOF metamodel that is obtained by executing the following steps:

    The EMOF package is replaced by the CMOF Package.
    All other packages - including the EssentialOCL - are cloned, with the exception that all references to the original EMOF metaclasses are replaced by references to the corresponding CMOF metaclass.

    11.2 Semantic specificities

    The semantics of CMOF concerning the access and the modification of properties replaces the semantics of EMOF. For instance, in CMOF, setting a property that is specified as an association end implies that the corresponding association link instance is created and that any related sub-setted association is updated accordingly.

    There are some limitations when using QVT on CMOF metamodels which comes from the fact that we are cloning EssentialOCL - at the time being, the OCL specification does not define an "OCL for CMOF metamodels".

    • It is not possible to refer directly to an association; instead an association has to be accessed as a property from one of the owning classes. However, this does not address the case where both the ends of an association are owned by the association itself.

    (2) In the Compliance section 2, add a sub-section named "EMOF and CMOF compliance" after Section 2.3 Interoperability Dimension with the following content:

    A QVT tool may declare to be EMOF-compliant or CMOF-compliant (possibly both) depending on the kind of models that it is capable of working with. The same dimensions serving to characterize QVT-EMOF compliant implementations (in Figure 2.1) are applicable to QVT CMOF-compliant implementations. Note however that the XMI for an EMOF-compliant QVT tool is not the same as the XMI for a CMOF-compliant QVT tool since the XMI generation rules for CMOF are distinct from the corresponding generation rules for EMOF.

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

Logging textual messages that depend on variables

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

    He current representation of LogExp does not allow output
    messages that are variable dependent. This is not realistic.
    We should use here ordinary argument representation to encode
    The text of the message and the level.

    Suggestion: LogExp defined as a subclass of OperationCallExp.
    The 'text', 'level' and 'element' fields can therefore be removed
    since encoded as positional arguments.

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

    RESOLUTION
    (1) In Section 8.2.2.18 (LogExp) before "A log expression returns null"
    adds the following paragraph.
    "A log expression is a kind of operation call expression where the
    first argument contains the message to be print, the second argument
    gives the model element to be print (using an implict call to the 'who'
    operation from the QVT Standard Library) , and the third argument gives
    a level number for the log.
    Only the first argument is mandatory.
    (1) In Section 8.2.2.18 (LogExp) change the superclasses list
    by replacing 'ImperativeExpression' by 'OperationCallExp'.
    (2) In Section 8.2.2.18, remove the properties 'text', 'level'
    and 'element'
    (3) In Figure 8.6, change the inheritance of LogExp to OperationCallExp,
    remove 'text' and 'level' attributes and remove 'element' link.

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

Inconsistency of multiplicity of ImperativeIterateExp::target

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

    According to the class description the multiplicity of
    ImperativeIterateExp::target should be [0..1] not 1 in
    the diagram view.

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

    In Figure 8.5, replace the multiplicity of role target:Variable to '0..1' (instead of '1').

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

When and where clause for mapping operations

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

    Reusing the 'when' and 'where' clauses of the refined relation
    of a mapping operation to represent the 'when' and 'where' clauses
    of the mapping operation is semantically not very accurate since
    there are some differencies. Should better have their own
    representation.

    Suggestion: add specifics MappingOperation::when and
    MappingOperation::where associations.

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

    (1) In Section 8.2.1.15, add the associations
    MappingOperation::when and MappingOperation::where
    with the following descriptions:
    when : OclExpression [0..1]
    The pre-condition or the guard of the operational mapping.
    It acts as a pre-condition when the operation is called with strict
    semantics, it acts as a guard otherwise (see MappingCallExp)
    where : OclExpression [0..1]
    The post condition for the operational mapping.
    (2) In Section 8.2.1.15, in the introductory part, replaces
    "The when clause in the refined relation acts ..." by
    "The when clause acts ..."
    and "The where clause in the refined relation always acts as
    a post-condition " by "The where clause always acts as
    a post-condition "

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

Missing multiplicity of AnonymousLiteralPart::value

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

    The multiplicity of AnonymousLiteralPart::value is not indicated
    in the diagram. It should be equal to 1.

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

    In Figure 8.7, indicate the multiplicity of AnonymousLiteralPart::value
    to be equal to "1".

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

Missing iterator variable in resolve expressions

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

    A resolution operator implies iteration over the list of objects
    transformed from a source element. However no iteration variiable
    is represented.

    Suggestion:
    Define ResolveExp as a subclass of ImperativeLoopExp.
    As a consequence, the field ResolveExp::condition can be
    removed (since already contained by ImperativeLoopExp)

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

    NOTE: This resolution should not be applied since superseded by resolution 10925.

    A Resolution operator implies iteration over the list of objects
    transformed from a source element. However no iteration variiable
    is represented.

    RESOLUTION:
    (1) In Section 8.2.1.22 (ResolveExp), define ResolveExp as a subclass
    of ImperativeLoopExp by replacing "CallExp" by "ImperativeLoopExp".
    (2) In the same section 8.2.1.22, remove the association 'condition'
    (since already contained by ImperativeLoopExp)
    (3) In Figure 8.3, remove the link ResolveExp::condition and replaces
    inheritance of ResolveExp so that it inherits from "ImperativeLoopExp"

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

Missing variable references within inlined object expressions

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

    Inlined ObjectExp have no explicit result variable. Nevertheless
    An implicit variable is needed so that the representation of property
    access within the body of ObjectExp is consistent.
    These variables need to exist somewhere and so a container for these
    implicit variables is needed.

    Suggestion:
    Adding the association:
    OperationBody::variable : [*] Variable

    {composes}

    And make the multiplicity of ObjectExp::referredObject equal to '1'

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

    (1) In Section 8.2.1.17 (OperationBody), add the association
    """
    variable : [*] Variable

    {composes}

    The variables defined implicitly within this operation body.
    This concerns implicit variables in object expressions (ObjectExp).
    """
    (2) In Section 8.2.1.24, replace "referredObject: Variable [0..1]"
    by "referredObject: Variable [1]"
    (3) In figure 8.2 add the "OperationBody::variable Variable" unidirectional
    link
    (4) In figure 8.3 change multiplicity of ObjectExp::referredObject to '1'.

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

Missing association from MappingParameter to a ModelParameter

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

    Non primitive MappingParameters are related to ModelParameters
    but the the association is missing in the metamodel. Also, when
    The information cannot be infered from the parameter types
    there is no way to indicate this when using the textual syntax.
    Suggestion:
    Add the association
    'MappingParameter::extent : [0..1] ModelParameter'
    For the concrete syntax, use the '@' character:
    mymappingparameter:MyType@mymodelparameter
    Usage of this notation should not be mandatory when the model
    type can be automatically infered from the parameter type.

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

    (1) In Section 8.2.1.16 (MappingParameter) add the association:
    """
    extent : ModelParameter [0..1]
    The extent of the mapping parameter. Should be explicitly provided
    when there is an ambiguity on the extent that will own a potential
    created element corresponding to this parameter.
    """
    (2) In the same section 8.2.1.16, add the "Notation" subtitle
    as follows:
    """
    Notation
    The extent of a mapping parameter can be provided explicitly
    using its name as the scope prefix of its type, using the "::"
    symbol. The declarator has the form:
    mymappingparameter : myextent::MyType.
    It is not mandatory to provide the extent when it can be inferred
    from the type.
    Example:
    transformation T(in src:S, out dest1, out dest2);
    mapping X::foo(inout dest1::Y) : dest2:Y;
    // 'X' is a class of 'S' metamodel and 'Y' is a class of 'D' metamodel
    """
    Remark: No changes are needed in the grammar since the 'declarator' rule
    already supports this syntax.

    (3) In Figure 8.1, add the correspond link between MappingParameter
    and ModelParameter.

    (4) In Section 8.2.1 (ObjectExp), within the "Notation" subtitle,
    replace:
    """When provided the model parameter is notated within brackets
    after the object keyword.
    object[srcmodel] x:X

    { ... } // x is created within the 'srcmodel
    """
    by:
    """When an explicit extent is provided, the variable name
    prefixes the type of the object expression using the "::" symbol.
    object x: srcmodel::X { ... }

    // x is created within the 'srcmodel
    """
    (this change is required for consistency with mapping parameter notation).

    (5) In Section 8.2.2.23 (InstantiationExp), within the "Notation" subtitle,
    replace:
    """
    When provided the extent is notated by adding the variable name in brackets after the new keyword.
    column := new [mymodel] Column(n,t); // mymodel is the extent for the new instance.
    """

    by:
    """When an explicit extent is provided, the variable name
    prefixes the type of the instantiation expression using the "::" symbol.
    column := new mymodel::Column(n,t); // mymodel is the extent for the new instance.
    """

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

Typo error ImperativeIteratorExp expected in diagram

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

    The diagram refers to a CollectorExp undefined class. In fact
    This class is the ImperativeIteratorExp found in the class
    description

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

    Duplicate of issue 9254, close

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

Entry operations in operational definitions

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

    For models that have a well identified "root" element and type,
    it makes sence to designate a mapping operation on the root
    type to be the entry of the transformation. Currently this is not
    possible.

    Suggestion:
    Replace the 'OperationalTransformation::entry : EntryOperation'
    association by a more general 'Module::entry : Operation'

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

    In Section 8.2.1.1 (OperationalTransformation),
    remove the association "entry : EntryOperation [0..1]" and
    in Section 8.2.1.3 (Module) inserts the association "entry : Operation [0..1]".
    In Figure 8.1, make the corresponding move of the 'entry' link.

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

isTopLevel should not be a derived property

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

    For implementers discovering whether a relation is a top
    level relation may be nighmare. It would be preferible that
    this property be a "pain" property (not derived). This will
    be aligned with the concrete syntax where the 'top' keyword
    is explicitly set.

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

    (1) In 7.11.3.1, replace "/isTopLevel : Boolean" by "isTopLevel : Boolean".
    and remove the sentence "This is a derived attribute."
    (2) In Figure 7.7 replace "/isTopLevel" by "isTopLevel"

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

RelationalTransformation as a subclass of Transformation

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

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

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

    {composes}

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

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

    (1) In section 7.11.3 insert the definition of the "RelationTransformation"
    class with the following description:
    """
    A RelationalTransformation is a specialization of a Transformation
    representing a transformation definition that uses the QVT-Relation
    formalism.
    Superclasses
    Transformation (from BaseQVT)
    Associations
    key : [*] Key

    {composes}

    The keys defined within this transformation.
    """
    (2) In Figure 7.7 inserts the class "RelationTransformation" inheriting
    from "Transformation" and adds the link to the "Key" class

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

Typo error for properties whenOwner and whereOwner

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

    In the QVTBase diagram 'whenOwner' should be the opposite
    property of 'when' and 'whenOwner' the opposite property of
    when. Currently this is reverted.

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

    In figure 7.7, replace 'whenOwner' by 'whereOwner'
    and 'whereOwner' by 'whenOwner'

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

Bad navigability in cross-package links

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

    The reverse link from Transformation to Tag should become
    not navigable. Otherwise there is a dependency between EMOF
    and QVTBase packages.
    In the QVTOperational package the same stands for navigability:
    The opposite role 'owner' of Module::ownerTag
    The opposite role 'module' of Module::configProperty
    The opposite role 'tryBodyOwner' of TryExp::tryBody
    The opposite role 'computeOwner' of ComputeExp::returnedE

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

    (1) In Figure 7.4 make unidirectional the link Transformation::ownedTag
    (2) In Figure 8.1
    make unidirectional the link Module::ownedTag
    make unidirectional the link Module::configProperty
    (3) In Figure 8.6
    make unidirectional the link TryExp::tryBody
    (4) In Figure 8.5
    make unidirectional the link ComputeExp::returnedElement

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

Revise the encoding of primitive domains

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

    Primitive domains are simpler than other relation domains
    since they do are not dependent on a given typed model
    (primitive types are available to all metamodels) and there
    is no need to refer to a template expression.
    In QVTBase package, the multiplicity of Domain::typedModel
    should be '0..1' instead of '1' to avoid an arbitrary assignment
    to model typed model for the primitive diomain. In addition
    the multiplicity of RelationDomain-Pattern association should
    be changed to 0..1.

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

    (1) In Section 7.11.1.3, replace "typedModel: TypedModel [1]"
    by "typedModel: TypedModel [0..1]"
    In figure 7.4 change the corresponding multiplicity.

    (2) In 7.11.3.2, replace "/typedModel: TypedModel [1] (from Domain)"
    by "/typedModel: TypedModel [0..1] (from Domain)"
    and replace "pattern: DomainPattern [1]

    {composes}"
    by "pattern: DomainPattern [0..1] {composes}

    "
    Make the corresponding change in figure 7.7.

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

Incorrect composition of variables in patterns

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

    In QVTBase package, the association 'Pattern::bindsTo'
    cannot be composition since variables in relations
    specifications are owned by Relations and because
    variables can be bound to more than one pattern.
    The same applies for 'TemplateExp::Variable' in QVTRelation
    package which should not be a composition.

    Suggested resolution:
    Change the property definitions as:
    'Pattern::bindsTo : [*] Variable opposites pattern [*]'
    'TemplateExp::bindsTo : [0..1] Variable opposites pattern [*]
    If needed add OCL well-formedness in QVT Core to restrict
    multiplicity.

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

    (1) In 7.11.1.6, replaces "bindsTo: Variable [*]

    {composes}"
    by "bindsTo: Variable [*]"
    and in Figure 7.5 removes the corresponding composition symbol

    (2) In 7.11.2.1 replaces "bindsTo: Variable [0..1] {composes}

    "
    by "bindsTo: Variable [0..1]"
    and in Figure 7.6 removes the corresponding composition symbol

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

Page 131

  • Key: QVT-50
  • Legacy Issue Number: 9255
  • Status: closed  
  • Source: Hewlett Packard Enterprise ( Susan Entwisle)
  • Summary:

    Section 10.2.2.24 third sentence “In the perspective of the runtime environment a typedef is never instantiated” appears to be redundant as the same intent is expressed in second sentence “A typedef is never instantiated”

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

    In Section 8.2.2.24, remove the sentence "A Typedef is never instantiated"

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

Page 118

  • Key: QVT-49
  • Legacy Issue Number: 9254
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Section 10.2.2.7 ImperativeIterateExp is missing from the class diagram in Section 10.2.2 The ImperativeOCL Package

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

    In Figure 8.4 and Figure 8.5, rename CollectorExp as ImperativeIterateExp
    (because CollectorExp is in fact an old name for ImperativeIterateExp).

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

Page 117

  • Key: QVT-48
  • Legacy Issue Number: 9253
  • Status: closed  
  • Source: Hewlett Packard Enterprise ( Susan Entwisle)
  • Summary:

    Section 10.2.2.6 ForExp is missing from the class diagram in Section 10.2.2 The ImperativeOCL Package

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

    closed no change

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

Page 45 and 165

  • Key: QVT-47
  • Legacy Issue Number: 9252
  • Status: closed  
  • Source: Hewlett Packard Enterprise ( Susan Entwisle)
  • Summary:

    the naming and diagram conventions should be introduced before they are used in Section 9.11 and 11.7, respectively

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

    In the introductory text of section 7.11 and sections 9.7
    add the following paragraph (similar to paragraph found in 8.2):

    """
    The metaclasses imported from other packages are shaded and annotated with 'from <package-name>' indicating the
    original package where they are defined. The classes defined specifically by the two packages of the QVT Operational
    formalism are not shaded.
    Within the class descriptions, metaclasses and meta-properties of the metamodel are rendered in courier font. Courier font is also used to refer to identifiers used in the examples. Keywords are written
    in bold face. Italics are freely used to emphasize certain words, such as specific concepts, it helps understanding.
    However that emphasis is not systematically repeated in all occurrences of the chosen word.
    """
    NOTE (Correction of typo after AB review):
    When applying the change in section 7.11, "the two packages of the QVT Operational" should be replaced by "the packages of the QVT Relation". When applying the change in section 9.7 it should be "the packages of the QVT Core".

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

Page 30

  • Key: QVT-46
  • Legacy Issue Number: 9251
  • Status: closed  
  • Source: Hewlett Packard Enterprise ( Susan Entwisle)
  • Summary:

    Chapter 9 The Relations Language contains long and complex sentences, which reduce the readability of the specification

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

    closed no change

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

Page 28

  • Key: QVT-45
  • Legacy Issue Number: 9250
  • Status: closed  
  • Source: Hewlett Packard Enterprise ( Susan Entwisle)
  • Summary:

    states that the plugin has access to object references in models, and may do arbitrary things to those objects. The specification should state that this approach breaks encapsulation of the object.

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

    In section 6.2, page 25, replaces the sentence
    "The plugin implementation has access to object references in models,
    and may do arbitrary things to those objects." by:

    "The plugin implementation has access to object references in models,
    and may do arbitrary things to those objects, possibly breaking
    encapsulation".

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

Consider using the package keyword instead of metamodel

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

    In Section 8.4.5 Notation for metamodels, the keyword 'package' could be more appropriate
    to represent nested packages within a metamodel definition or even a package containing
    only tags

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

    (1) In section 8.4.5, replace "A MOF Package is notated using the metamodel keyword followed by a name" by "A MOF Package is notated either using the 'package' keyword or the 'metamodel' keyword followed by a name. Both notations are equivalent when translating to the corresponding EMOF metamodel representation. The 'metamodel' keyword should preferably be used when referring to a top-level package that represents a complete metamodel.

    For the impact in BNF grammar, see issue resolution for 10026.

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

Consider using the case keyword within swith expression

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

    Consider using the 'case' keyword within swith expressions to have a similar
    notation as in other languages.

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

    In Section8.2.2.8 SwitchExp, replace the code after "following syntax pattern" by
    switch

    { case cond1 ? exp1; case cond2 ? exp2; … else ? expN; }

    For the change in the BNF grammar, see resolution of issue 10026.

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

Argument list missing in raise expression

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

    The RaiseExp does not allow the possibility to pass ramaters to the exception.
    Also, the use of strings instead of exception class references should be clarified

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

    (1) In Section 10.2.2.14 RaiseExp, add the following property:
    argument : OclExpression [0..1]

    {composes}

    - The argument accompagning the raised exception
    (2) Apply update of diagram Figure 8.6 as defined in Appendix D Updated Diagrams -2nd ballot..
    (3) Within the Notation sub-section, after "can be provided a simple strings." Add the sentence: In that case the implicit referred exception is the user Exception defined in the QVT standard library and the string is the argument of the raise expression.
    (4) Within the Section 8.3.1 Predefined Types, add, after Status definition, a new sub-section named Exception with the following definition:
    "This M1 class named Exception represents a base class for all instantiated Exceptions. It is itself an instance of the Exception metatype.

    For any impact in BNF see resolution of issue 10026.

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

Some errors in BNF grammar of the operational part

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

    The grammar defined by the resolution of issue 10923 still contains some errors.
    For instance the expression is missing in the <elif_part> definition. Also some
    uniformity could be achieved in the names of BNF rules, like using always "_header"
    suffix instead of using sometiimes "_header" and sometimes "_h".

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

  • Reported: QVT 1.0b1 — Fri, 18 May 2007 04:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    This resolution replaces the resolution given by issue 10923 (2nd Ballot)
    (1) Replaces the BNF grammar with the following:

    // keywords

    Bag, Collection, Dict, OrderedSet, Sequence, Set, Tuple, abstract,
    access, and, any, assert, blackbox, break, case, class, collect,
    collectNested, collectOne, collectselect, collectselectOne,
    composes, compute, configuration, constructor, continue, datatype,
    default, derived, disjuncts, do, elif, else, end, endif,
    enum, except, exists, extends, exception, false, forAll, forEach ,
    forOne, from, helper, if, implies, import , in, inherits, init,
    inout, intermediate, invresolve, invresolveIn, invresolveone,
    invresolveoneIn , isUnique, iterate, late, let, library, literal,
    log, main, map, mapping, merges, metamodel, modeltype, new, not,
    null, object, one, or, ordered, out, package, population, primitive, property,
    query, raise, readonly, references, refines, reject, resolve, resolveIn, resolveone,
    resolveoneIn, return, select, selectOne, sortedBy, static,
    switch, tag, then, transformation, true, try, typedef, unlimited,
    uses, var, when, where, while, with, xcollect , xmap, xor, xselect

    // start rule
    <topLevel> ::= <import>* <unit_element>*

    <import> ::= 'from' <unit> 'import' (<identifier_list> | '*') ';'

    'import' <unit> ';'
    <unit> ::= <identifier> ('.' <identifier>)*

    <identifier_list> ::= <identifier> (',' <identifier>)*

    // definitions in a compilation unit
    <unit_element>
    ::= <transformation>

    <library>
    <access_decl>
    <modeltype>
    <metamodel>
    <classifier>
    <property>
    <helper>
    <constructor>
    <entry>
    <mapping>
    <tag>
    <typedef>

    // Transformation and library definitions

    <transformation> ::= <transformation_decl> | <transformation_def>
    <transformation_decl> ::= <transformation_h> ';'
    <transformation_def> ::= <transformation_h> '

    {' <module_element>* '}' ';'?

    <library> ::= <library_decl> | <library_def>
    <library_decl> ::= <library_h> ';'
    <library_def> ::= <library_h> '{' <module_element>* '}

    ' ';'?

    // Transformation header
    <transformation_h> ::= <qualifier>* 'transformation' <identifier>
    <transformation_signature> <transformation_usage_refine>?
    <transformation_usage_refine> ::= <module_usage> | <transformation_refine>
    <transformation_signature> ::= <simple_signature>
    <transformation_refine> ::= 'refines' <moduleref>

    // Library header
    <library_h> ::= 'library' <identifier> <library_signature>? <module_usage>?
    <library_signature> ::= <simple_signature>

    // import of transformation and library
    <module_usage> ::= <access_usage> | <extends_usage>
    <access_usage> ::= 'access' <module_kind>? <moduleref_list>
    <extends_usage> ::= 'extends' <module_kind>? <moduleref_list>
    <module_kind> ::= 'transformation' | 'library'
    <moduleref_list> ::= <moduleref> (',' <moduleref>)*
    <moduleref> ::= <scoped_identifier> <simple_signature>?
    <access_decl> ::= <access_usage> ';'

    // module definitions
    <module_element>
    ::= <classifier>

    <property>
    <helper>
    <constructor>
    <entry>
    <mapping>
    <tag>
    <typedef>
    <access_decl>

    // general purpose grammar rules
    <qualifier> ::= 'blackbox' | 'abstract' | 'static'
    <complete_signature> ::= <simple_signature> (':' param_list)?
    <simple_signature> ::= '(' <param_list>? ')'
    <param_list> ::= <param> (',' <param>)*
    <param> ::= <param_direction>? <declarator>
    <param_direction> ::= 'in' | 'inout' | 'out'
    <simple_declarator> ::= <typespec>

    <scoped_identifier> ':' <typespec>
    <declarator> ::= <typespec> <init_part>?
    <scoped_identifier> ':' <typespec> <init_part>?
    <simple_declarator_list> ::= <simple_declarator> (',' <simple_declarator>)*
    <declarator_list> ::= <declarator> (',' <declarator>)*
    <declarator_semi_list> ::= <declarator> (';' <declarator>)*
    <init_part> ::= <init_op> <expression>
    <init_op> ::= '='
    ':=' '::='
    <typespec> ::= <type_reference> <extent_location>?
    <type_reference> ::= <scoped_identifier>
    <complex_type>
    <extent_location> ::= '@' <identifier>
    <complex_type> ::= <complex_type_key>
    <collection_key> '(' <typespec> ')'
    'Tuple' '(' <declarator_list> ')'
    'Dict' '(' <typespec> ',' <typespec> ')'
    <complex_type_key> ::= <collection_key>
    'Dict' 'Tuple'
    <collection_key> ::= 'Collection'
    'Set' 'OrderedSet' 'Sequence' 'Bag'
    'List'
    <scoped_identifier> ::= <identifier> ('::' <identifier>)*
    <scoped_identifier_list> ::= <scoped_identifier> (',' <scoped_identifier>)*
    <expression_list> ::= <expression_semi_list> ';'?
    <expression_semi_list> ::= <expression> (';' <expression>)*
    <expression_comma_list> ::= <expression> (',' <expression>)*
    <expression_block> ::= ' {' <expression_list>? '}

    '
    <expression_statement> ::= <expression> ';'

    <expression_block> ';'?

    // model types compliance and metamodel declarations
    <modeltype> ::= 'modeltype' <identifier> <compliance_kind>?
    'uses' <packageref_list> <modeltype_where>? ';'
    <modeltype_where> ::= 'where' <expression_block>
    <packageref_list> ::= <packageref> (',' <packageref>)*
    <packageref> ::= (<scoped_identifier> ( '(' <uri> ')' )? | <uri>)
    <compliance_kind> ::= <STRING> // like: "strict" and "effective"
    <uri> ::= <STRING>

    // Syntax for defining explicitly metamodel contents
    <metamodel> ::= <metamodel_decl> | <metamodel_def>
    <metamodel_decl> ::= <metamodel_h> ';'
    <metamodel_def> ::= <metamodel_h> '

    {' <metamodel_element>* '}

    ' ';'?

    <metamodel_h> ::= ('metamodel' | 'package') scoped_identifier
    <metamodel_element> ::= <classifier> | <enumeration> | <tag>

    <classifier> ::= <classifier_decl> | <classifier_def>
    <classifier_decl> ::= <classifier_h> ';'
    <classifier_def> ::= <classifier_h> '

    {' <classifier_feature_list>? '}

    ' ';'?

    <classifier_h> ::= <classifier_info> <scoped_identifier> <classifier_extension>?
    <classifier_info> ::= 'datatype'

    'primitive' 'exception'
    'intermediate'? <qualifier>* 'class'
    <classifier_extension> ::= 'extends' <scoped_identifier_list>
    <classifier_feature_list> ::= <classifier_feature> (';' <classifier_feature>)* ';'?
    <classifier_feature> ::= <classifier_property>
    <classifier_operation> <tag>

    <classifier_property> ::= <feature_qualifier>? <declarator> <multiplicity>?
    <opposite_property>?
    <feature_qualifier> ::= <stereotype_qualifier>? <feature_key>*
    <feature_key> ::= 'composes' | 'references' | 'readonly' | 'derived' | 'static'
    <stereotype_qualifier> ::= '<<' <identifier_list> '>>'
    <multiplicity> ::= '[' multiplicity_range ']'
    <multiplicity_range> ::= <INTEGER> | '' | <INTEGER> '...' <INTEGER> | <INTEGER> '...' ''
    <classifier_operation> ::= <feature_qualifier>? <declarator> <complete_signature>

    <enumeration> ::= <enumeration_h> ';'

    <enumeration_h> ' {' <identifier_list> '}

    ' ';'?

    <enumeration_h> ::= 'enum' <identifier>
    <opposite_property> ::= 'opposites' '~' <identifier> <multiplicity>?

    <tag> ::= 'tag' <tagid> <scoped_identifier> ('=' <tagvalue>)? ';'
    <tagid> ::= <STRING>
    <tagvalue> :: <expression>

    // typedefs
    <typedef> ::= 'typedef' <identifier> '=' <typespec> (typedef_condition)? ';'
    <typedef_condition> ::= '[' <expression> ']'

    // Properties in transformation
    <property> ::= 'intermediate'? <property_key>+ <declarator> ';'
    <property_key> ::= 'derived' | 'literal' | 'configuration' | 'property'

    // Syntax for helper operations
    <helper> ::= <helper_decl> | <helper_simple_def> | <helper_compound_def>
    <helper_header> ::= <helper_info> <scoped_identifier> <complete_signature>
    <helper_info> ::= <qualifier>* <helper_kind>
    <helper_kind> ::= 'helper' | 'query'
    <helper_decl> ::= <helper_header> ';'
    <helper_simple_def> ::= <helper_header> '=' <expression> ';'
    <helper_compound_def> ::= <helper_header> <expression_block> ';'?

    // Syntax for constructors
    <constructor> ::= <constructor_decl> | <constructor_def>
    <constructor_header> ::= <qualifier>* 'constructor' <scoped_identifier>
    <simple_signature>
    <constructor_decl> ::= <constructor_header> ';'
    <constructor_def> ::= <constructor_header> <expression_block> ';'?

    // Syntax for entries
    <entry> ::= <entry_decl> | <entry_def>
    <entry_header> :: 'main' <simple_signature>
    <entry_decl> ::= <entry_header> ';'
    <entry_def> ::= <entry_header> <expression_block> ';'?

    // syntax for mapping operations
    <mapping> ::= <mapping_decl> | <mapping_def>
    <mapping_decl> ::= <mapping_full_header> ';'
    <mapping_def> ::= <mapping_full_header> '

    {' <mapping_body> '}

    ' ';'?
    <mapping_full_header> ::= <mapping_header> <when>? <where>?
    <mapping_header> ::= <qualifier>* 'mapping' <param_direction>?
    <scoped_identifier> <complete_signature> <mapping_extra>*
    <mapping_extra> ::= <mapping_extension> | <mapping_refinement>
    <mapping_extension> ::= <mapping_extension_key> <scoped_identifier_list>
    <mapping_extension_key> ::= 'inherits' | 'merges' | 'disjuncts'
    <when> ::= 'when' <expression_block>
    <where> ::= 'where' <expression_block>
    <mapping_refinement> ::= 'refines' <scoped_identifier>
    <mapping_body> ::= <init_section>? <population_section>? <end_section>?
    <init_section> ::= 'init' <expression_block>
    <population_section> ::= <expression_list>

    'population' <expression_block>
    <end_section> ::= 'end' <expression_block>

    // Expressions

    <expression> ::= <assign_exp>

    <let_exp>
    <var_init_exp>

    <assign_exp> ::= <implies_exp>

    <unary_exp> <assign_op> <expression> <default_val>?
    <unary_exp> <assign_op> <expression_block> <default_val>?

    <assign_op> := ':=' | '::=' | '+=' | '-='

    <default_val> ::= 'default' <assign_exp>

    <implies_exp> ::= <or_exp>

    <implies_exp> 'implies' <or_exp>

    <or_exp> ::= <and_exp>

    <or_exp> <or_op> <and_exp>

    <or_op> ::= 'or' | 'xor'

    <and_exp> ::= <cmp_exp>

    <and_exp> 'and' <cmp_exp>

    <cmp_exp> ::= <additive_exp>

    <cmp_exp> <cmp_op> <additive_exp>

    <cmp_op> ::= '=' | '==' | '<>' | '<' | '>' | '<=' | '>='

    <additive_exp> ::= <mult_exp>

    <additive_exp> <add_op> <mult_exp>

    <add_op> ::= '+' | '-'

    <mult_exp> ::= <unary_exp>

    <mult_exp> <mult_op> <unary_exp>

    <mult_op> ::= '*' | '/' | '%'

    <unary_exp> ::= <postfix_exp>

    <unary_op> <unary_exp>

    <unary_op> ::= '-' | 'not' | '#' | '##' | '*'

    <postfix_exp> ::= <primary_exp>

    <postfix_exp> '(' <arg_list>? ')'
    <postfix_exp> '!'? '[' <declarator_vsep>? <expression> ']'
    <postfix_exp> <access_op>
    (<scoped_identifier>
    <iterator_exp> <block_exp>
    <control_exp> <rule_call_exp>
    <resolve_exp> <resolve_in_exp>)

    <declarator_vsep> ::= <simple_declarator> '|'
    <multi_declarator_vsep> ::= <simple_declarator_list> '|'

    <resolve_exp> ::= <resolve_key> '(' <resolve_condition>? ')'
    <resolve_condition> ::= <declarator> ('|' <expression>)?
    <resolve_key> ::= 'late'? <resolve_kind>
    <resolve_kind> ::= 'resolve' | 'resolveone' | 'invresolve' | 'invresolveone'

    <resolve_in_exp> ::= <resolve_in_key> '(' <scoped_identifier>
    (',' <resolve_condition>)?')'
    <resolve_in_key> ::= 'late'? <resolve_in_kind>
    <resolve_in_kind> ::= 'resolveIn' | 'resolveoneIn' | 'invresolveIn' | 'invresolveoneIn'

    <access_op> ::= '.' | '>' | '!>'

    <primary_exp> ::= <literal>

    <scoped_identifier>
    <if_exp>
    <block_exp>
    <control_exp>
    <rule_call_exp>
    <quit_exp>
    <try_exp>
    <raise_exp>
    <assert_exp>
    <log_exp>
    '(' <expression> ')'

    <literal> ::= <literal_simple>

    <literal_complex>

    <literal_simple> ::= <INTEGER> | <FLOAT> | <STRING>

    'true' 'false' 'unlimited' 'null'

    <literal_complex> ::= <literal_collection>

    <literal_tuple>
    <literal_dict>

    <literal_collection> ::= <collection_key> '

    {' <collection_item_list>? '}

    '

    <literal_tuple> ::= 'Tuple' '

    {' <tuple_item_list>? '}

    '

    <literal_dict> ::= 'Dict' '

    {' <dict_item_list>? '}

    '

    <collection_item_list> ::= <expression_comma_list>
    <tuple_item_list> ::= <declarator_list>
    <dict_item_list> ::= <dict_item> (',' <dict_item>)*
    <dict_item> ::= <literal_simple> '=' <expression>

    <if_exp> ::= 'if' <expression> <then_part>
    <elif_part>* <else_part>? 'endif'
    <then_part> ::= 'then' <if_body>
    <elif_part> ::= 'elif' <if_body>
    <else_part> ::= 'else' <if_body>
    <if_body> ::= <expression> | <expression_block>

    <iterator_exp> ::= <simple_iterator_op> '(' <declarator_vsep>? <expression> ')'

    <multi_iterator_op> '(' <multi_declarator_vsep>? <expression> ')'
    <iterate_exp>

    <simple_iterator_op> ::= 'reject' | 'select' | 'collect' | 'exists'

    'one' 'any' 'isUnique' 'collectNested'
    'sortedBy' 'xselect' 'xcollect'
    'selectOne' 'collectOne'
    'collectselect' 'collectselectOne'

    <multi_iterator_op> ::= 'forAll'

    <iterate_exp> ::= 'iterate' '(' <declarator_list> ';'
    <declarator> '|' <expression> ')'

    <iter_declarator> ::= <declarator>
    <iter_declarator_list> ::= <declarator_list>

    <block_exp> ::= (<object_exp> | <do_exp> | <switch_exp>)

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

    <do_exp> ::= 'do' <expression_block>

    <switch_exp> ::= 'switch' ('(' <iter_declarator> ')')? <switch_body>
    <switch_body> ::= '

    {' <switch_alt>+ <switch_else>? '}

    '
    <switch_alt> ::= 'case' '(' <expression> ')' <expression_statement>
    <switch_else> ::= 'else' <expression_statement>

    <control_exp> ::= (<while_exp> | <compute_exp> | <for_exp>)

    <while_exp> ::= 'while' '(' (<declarator> ';')? <expression> ')'
    <expression_block>
    <compute_exp> ::= 'compute' '(' <declarator> ')' <expression_block>
    <for_exp> ::= ('forEach' | 'forOne') '(' <iter_declarator_list>
    (';' <declarator>)? ('|' <expression>)? ')' <expression_block>

    <rule_call_exp> ::= ('map' | 'xmap' | 'new' )
    ('(' <declarator> ')')? <scoped_identifier>

    <let_exp> ::= 'let' <declarator_list> 'in' <expression>

    <var_init_exp> ::= 'var' <declarator_list>

    'var' '(' <declarator_list> ')'

    <quit_exp> ::= 'break' | 'continue' | <return_exp>)

    <return_exp> ::= 'return' <expression>?

    <try_exp> ::= 'try' <expression_block> <except>+

    <except> ::= 'except' '(' <scoped_identifier_list> ')' <expression_block>

    <raise_exp> ::= 'raise' <scoped_identifier> ('(' <arg_list>? ')')?
    <arg_list> ::= <expression_comma_list>

    <assert_exp> ::= 'assert' <identifier>? '(' <expression> ')'
    ( 'with' <log_exp> )?

    <log_exp> ::= 'log' '(' <arg_list> ')' ('when' <expression>)?

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

Consider adjusting the notation for unpack

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

    The notation x,y, z = foo() may be difficult to parse. Consider revising it.
    For instance using parenthesis: (x,y,z) = foo().
    Also consider extending this notation to non anonymous tuples

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

    1) In Section 8.2.2.22, add a property named 'source' with the following definition:
    source : OclExpression [1]

    {composes}

    The source expression to be unpacked. The type of the expression should necessarily be an ordered tuple.
    (2) In Section 8.2.2.22, rename the property 'variable' as 'targetVariable'
    (3) In Section 8.2.2.22, in the Notation section, replace all the text by the following:
    The notation is similar to an assignment expression except that the list of variables is in parenthesis and prefixed by the var keyword.
    var (x,y,z) := self.foo(); // assuming 'foo' returns a tuple of three elements
    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();
    es equivalent to:
    var x:X; var y:Y; var (x,y,z) := foo();
    (3) Update the diagram 8.6 as given by appendix D

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

Inconsistency in definition of TryExp with figure

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

    The tryBody property is multivalued in the class description but monovalued in the
    Diagram. What is the correct multiplicity?

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

    (1) In the class description of TryExp, in the property 'tryBody' description add the '

    {composes, ordered}' mention.
    (2) In the class description of TryExp, replaces the exceptBody property by the following:
    exceptClause : CatchExp [*] {composes, ordered}

    The exception clauses providing the code to execute in case of failure.
    (3) In the class description of TryExp, removes the 'exception : Type' property description.
    (4) Replaces the exceptBody property by the following:
    exceptClause : CatchExp [*]

    {composes, ordered}
    The exception clauses providing the code to execute in case of failure.
    (5) After the section describind the TryExp, add a new section to describe the CatchExp class with the following content.:
    """
    A catch expression represents the the code to be executed when a exception matching a given list of exception types is fired durin the execution of the containing try expression.
    Superclasses
    ImperativeExpression
    Associations
    exception : Type [*] {ordered}
    The list of exceptions being treated by this catch handler.
    body : OclExpression [*] {composes, ordered}

    The list of expressions to execute in sequence.
    Notation:
    The notation uses the 'except' keyword with the list of exception types in parenthesis and the body in braces.
    except (exception1,exception2)

    { expression1; … }

    (5) Update Figure 8.6 anf Figure 8.3 using the new version of Appendix D of this report.

    Remark: For the BNF grammar modification see resolution of 10026.

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

Missing notation to indicate the enforced direction in mapping operations

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

    The enforced direction cannot be indicated when the 'refined' keyword is used to
    Indicate that a mapping operation refines a relation

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

    (1) In Section 8.2.1.1 OperationalTransformation, replaces the sentence starting with "When an operational transformation refines a relational transformation, …" by the following sentence: "An operational transformation may be explicitly declared as the 'refinement' of a relational transformation. In that case each model parameter in the operational transformation corresponds to a typed model in the relational transformation. The enforced direction is the one corresponding to the output parameter of the operational transformation". Also remove constraint concerning enforcedDirection.
    (2) In Section 8.2.1.1 OperationalTransformation, removes the enforcedDirection property definition.

    Note: This resolution also implies removing the first constraint in Constraints section of 8.2.1.1 section.

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

Missing text for notation for class properties in Section 8.4.6

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

    In 8.4.5 the text describes the notation for defining classes. However the notation
    For describing properties within classes is not indicated. Also notation for primitive
    data type is not indicated

  • Reported: QVT 1.0b1 — Fri, 18 May 2007 04:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    (1) In Section 8.4.5 replace the sentence:
    "The properties of a class are notated using a declarator made of: a name, a type, optional property qualifiers (derived, static, …) and a initialisation expression.
    isStatic : Boolean = 0;
    "
    By the following, text:

    "The properties of a class are notated using a declarator made of: a name, a type, optional property qualifiers and an optional initialisation expression.
    The general syntax pattern is:

    <qualifier>* <propname> ':' <typespec> ('=' <init>)? '<multiplicity>'? 'ordered'?
    (opposites <propname>)?

    For properties typed by primitive types or collection of primitive types, the valid property qualifiers are 'derived' and 'readonly' to represent respectively a derived attribute or a readonly attribute. When provided, the initialization value for a derived attribute represents the expression used to compute the value of the derived property.

    The syntax of multiplicity specification follows the regular convention from UML, where brackets sourrounds the definition (such as [0..1], [1], [*] and [0..*]). When absent the [0..1] multiplicity is assumed.

    Examples:
    isStatic : Boolean = 0;
    values : Sequence(String);
    derived size : Integer = self.ownedElement->size();

    To indicate that an attribute acts as a qualifying identifier for the class, a stereotype qualifier named 'id' is used. The syntax for stereotyped qualifiers is:
    '<<' <IDENTIFIER> (',' <IDENTIFIER>)? '>>'
    Example: <<id> uuid:String [1]; // a mandatory qualifying uuid attribute

    For properties referencing non primitive types, the same syntax is used except that the 'composes' or 'references' qualifier is used to distinguish between composite or non composite association ends. The 'opposites' keyword is used to indicate the opposite property if any.

    Example:
    composes ownedElement : Element [*] ordered opposites namespace;
    references usedElement : Element [*];

    (2) In Section 8.4.5, before "an enumeration type…" add the following sentence "A primitive type is declared using the 'primitive' keyword.
    'primitive' <primitivetypename>.
    Example: primitive Double;

    (3) In Section 8.4.5, after presenting the notation for primitive types, adds the following sentence.
    An exception is declared using the 'exception' keyword followed by the name of the exception. Inheritance between exceptions is introduced usin the 'extends' keyword.
    Example: exception VeryStrangeException extends UnexpectedException;

    Remark: For the BNF grammar modification see resolution of 10026.
    Note: Fix in resolution text: (opposites <propname>)? Should be replaced by
    (opposites '' ? <propname> <multiplicity>?) to be inline with grammar. Also, after 'the opposite property if any.' add "When present, the '' annotation indicates that the opposite property is not navigable".

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

Any used instead of MOF::Object in operational type extensions

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

    In OCL the Any type does not includes primitive types. In ListType and DictType
    definitions the Any is used as the more general type for elements whereas Object
    should be used to allow types like dictionaries with string as keys.

  • Reported: QVT 1.0b1 — Fri, 18 May 2007 04:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    Within the text descriptions of the classes ListType, DictionaryType, AnonymousTupleType replace all occurrences of the word Any by the word Object.
    Also in Section 8.2.1.14 Type Extensions, replace 'the type Any is assumed' by 'the generic MOF type Object is assumed'.

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

Typos and omissions in the QVT operational Part

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

    The QVT operational part have some typos, omissions as well as some english
    language errors that need to be corrected.
    For instance:

    (1) In Type Extensions sub-section: "to the type systems" => "to the type system".
    (2) In Typedef definition, repetition of "is never instantiated".
    (3) In AnonymousTupleLiteralExp, TupLiteralPart does not exist. Should be
    AnonymousTupleLiteralPart. The multiplicity of 'part' should be '*' and 'ordered'
    is missing.

  • Reported: QVT 1.0b1 — Fri, 18 May 2007 04:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    Resolution:

    (1) In section 8.1.1 replace "if the source text file only defines…" by "if the source text file defines …".
    (2) In Section 8.1.2 replace "The UML and RDBMS refer to…" by "The UML and RDBMS model types refer to …".
    (3) In Section 8.1.2 replace "…the transformation writer may explicitly indicate …" by "…the transformation writer may indicate…" (this avoids repetition of explicit in the following sentence). Also replace 'to be build' by 'to be built' (English).
    (4) In Section 8.1.4, replace "is always a refinement of a relation…" by "is always a refinement of an implicit relation…"
    (5) In Section 8.1.4, replace "The packageToSchema mapping operation defined below defines …" by "The packageToSchema mapping operation below defines…" (avoid redundancy).
    (6) In Section 8.1.4, replace "rather than a creating …" "rather than creating …"
    (7) In Section 8.1.5 replace "Afterthat the list of expressions of the body of the object expressions are executed…" by "The list of expressions of the body of the object expression are then executed…"
    (8) In Section 8.1.5 replace "implicance" by "outcome"
    (9) In Section 8.1.5 replace "is described in …" by "in described in Section …"
    (10) In Section 8.1.6 replace "do not imples…" by "does not implies…"
    (11) In Section 8.1.6 replace "an object expression do not creates an instance if the target variable has a non null value." By an object expression, such as 'object x:X

    {…}', does not create an instance if the target variable - 'x' in the example - has a non-null value".
    (12) In Section 8.1.6 replace "is systematically…" by "will be systematically…"
    (13) In Section 8.1.6 replace "we are using here the "collect shorthand" by "we are using here the collect shorthand convention". Also use italics to mark 'collect shorthand'.
    (14) In Section 8.1.6 replace "that create instance" by "that creates instances"
    (15) In Section 8.1.7 replace"various mapping" by "various mappings"
    (16) In Section 8.1.7, in code '…getSqlType(a.type))}' remove the final closing brace.
    (17) In Section 8.1.7, replace "does not interleave" by "does not interleaves"
    (18) In Section 8.1.7, add blank space between "best" and "solution".
    (19) In Section 8.1.8, replace 'list += self.retrieveCandidates();' by 'list.append(self.retrieveCandidates())'.
    (20) In Section 8.1.9, replace 'Below an example' 'Below we provide an example'.
    (21) In Section 8.1.9, replace 'scope of transformation' by 'scope of the transformation'
    (22) In Section 8.1.10, replace '#Table' by 'Table' and remove "(the notation '#Table' is a shorthand for isKindOf(Table))"
    (23) In Section 8.1.10, remove 'to the invresolve operator'
    (24) In Section 8.1.10, remove the open and close parenthesis introduced after 'until the end of the transformation'. Insert a comma instead of the open parenthesis.
    (25) In Section 8.1.10, replace ', as in the' by '. The' (to create a new sentence)
    (26) In Section 8.1.10, replace '#JAVA::Interface' by 'JAVA:Interface'
    (27) In Section 8.1.10, replace 'We provide below a solution' by 'We provide below an equivalent solution'.
    (28) In Section 8.1.11, replace "real" by "and complex". Also, insert "To this end " before "The language…".
    (29) In Section 8.1.11 replace 'almost a mapping' by ''mappings'.
    (30) In Section 8.1.11 replace 'This occurs in rule 2 for Foo instance" by "This occurs in Rule 2 for the Foo instances"
    (31) In Section 8.1.13, in the code after 'Below and example' move the open brace so that it is after the closing bracket of the when clause and not after "JAVA::Constructor". Apply this for the two operations convertConstructor and convertOperation.
    (32) In Section 8.1.14, replace 'a anonymous' by 'an anonymous'
    (33) In Section 8.1.14, replace '_parentInstance' by 'container'
    (34) In Section 8.1.14, before the sentence 'A typedef can also…' inserts the sentence: "The '#Metaclass" notation - respectively '##Metaclass' - is a shorthand for isKindOf(Metaclass) - respectively isTypeOf(Metaclass).
    (35) In Section 8.1.15 replace 'confortable' by 'comfortable', 'realize' by 'realizes', remove 'some nice' and 'that we found'.
    (36) In Section 8.1.15, remove "'a block expression is not a function!).
    (37) In Section 8.1.15, replace 'the role of a for loop in Java' by 'the role of a loop instruction is Java language'.
    (38) In Section 8.1.15, replace 'that is not constrained' by 'that is less constrained'
    (39) In Section 8.1.15 replace the code starting with var x:= by the following simplified code:
    var x:= if (self.name.startsWith("_") "PROTECTED"
    elif (self.type.isPrimitive() "NORMAL"
    else "UNEXPECTED";
    (40) At the beginning of Section 8.1.16, replace 'This…' by 'The variable this …'
    (41) In Section 8.1.18 replace the quotes around 'compiling'
    (42) In Section 8.1.18 replace the sentence 'Synchronization is done … of the transformation' by "Synchronization is achieved through the invocation of the wait operation on the status variable returned by the 'transform' operation.
    (43) In Section 8.1.18 replace 'tho two pim model' by 'the two PIM models'
    (44) In Section 8.1.18 replace "is a magical requirement to psm transformation" by "is a 'Requirement to PSM' transformation.
    (45) In Section 8.2.2.1, replace '… this package grouped into…' by '… this package are grouped into …'
    (46) In Section 8.2.1.1.1 Operational Transformation, add missing comma in 'that is,' after 'may define configuration properties'.
    (47) In Section 8.2.1.1.1, Operational Transformation replace 'TransformationInstanceExp' by 'InstantiationExp'.
    (48) In Section 8.2.1.1.1 Operational Transformation, in constraints subsection, replace all occurrences of '<>OclUndefined' by '.isOclUndefined()'.
    (49) In Section 8.2.1.1.1 Operational Transformation, in semantics subsection, remove "For convenience," and replace "is described" by "is described below"
    (50) In Section 8.2.1.1.1 Operational Transformation, in notation subsection, replace 'within brackets' by 'within braces'. Also replaces "using the refined keyword" by "using the refines keyword".
    (51) In Section 8.2.1.1.2 Library, replace 'no implementation' by 'this means that no implementation'. Also in semantics sub-section, remove 'for convenience' and replace 'is described' by 'is described below'.
    (52) In Section 8.2.1.1.2 Library, replace 'For each declared model types there is conceptually a …' by 'For each declared model type there is, conceptually, a …'. Also, in notation section, adds commas before and after "in this case".
    (53) In Section 8.2.1.4 ModuleImport, replace 'non library' by 'non-library'
    (54) In Section 8.2.1.5 ModelParameter, in notation sub-section,, remove "If the direction kind is not provided the in value is assumed".
    (55) In Section 8.2.1.6 ModelType, replace the sentence "The binding between …" by the sentence "See semantics sub-section for the binding rules between actual and effective types ". Also remove sentence "In both cases …" (since already in the semantics part).
    (56) In Section 8.2.1.6 Model Type, replace "To restrict the set of valid participant models further…" by "To restrict further the set of valid participant models …".
    (57) In Section 8.2.1.6 Model Type, in "Semantics of model compliance subsection", replace "In both cases (strict or effective), model compliance implies additionally to comply with extra constraints of the model type" by "In both cases - strict of effective - model compliance implies that all the extra conditions (see extraCondition property) are satisfied as well as any pre-existing well-formedness rule that exists for the associated metamodel.
    (58) In Section 8.2.1.6 Model Type, in "Semantics of model compliance subsection", remove sentence "Effective compliance allows defining… with UML 1.3 models" (since it is a repetition).
    (59) In Section 8.2.1.6 Model Type, in Notation sub-section, add missing double quote in example "modeltype UML uses SimpleUML…".
    (60) In Section 8.2.1.6 Model Type, in Notation sub-section, replace "A modeltype symbol" by "A modeltype declaration in a transformation signature"
    (61) In Section 8.2.1.6 ImperativeOperation, within the description of the ownedParameter association, replace "The other parameters of the operation" by "The list of parameters of the operation excluding the context and result parameters".
    (62) In Section 8.2.1.11 EntryOperation, replace "which is invoked on entry" by "which is invoked when the transformation execution starts".
    (63) In Section 8.2.1.11 Helper, replace "that is executed is sequence" by "that is executed in sequence". Also replace the sentence "The notation is the notation for any imperative operation …" by "The notation uses the standard convention for notating operations in UML except that the query or helper keywords are used to prefix the declaration. The latter 'helper' prefix is used when the operation provokes side-effects. Also, replace "He self variable…" by "The self variable …".
    (64) In Section 8.2.1.13 Constructor, replace "A constructor operation is implicitly or explicitly invoked through instantiation expression." by "A constructor operation can be explicitly invoked through an instantiation expression."
    (65) In Section 8.2.1.15 MappingOperation, add 'conceptually' after 'always refines'. Also, replace "This essentially means…" by "This means…" (three occurrences). Add commas sourrounding "among the set of disjuncted mappings". Replace "the details of the semantics of the reuse facilities" by "the details of these resuse facilities". Also replace 'refinedRelation: Relation[1]' by 'refinedRelation [0..1]' (consistency with OperationalTransformation:refined multiplicity), add 'if any' after 'the refined relation' and remove sentence 'The relation defines the guard…'..
    (66) In Section 8.2.1.15 MappingOperation, semantics sub-section, replace "After passing of the parameters" by "After passing the parameters". Also, replace "of the actual object parameters and the…" by "of the actual parameters as well as…". Also replace "if the out parameter was…" "if the out parameters were…".
    (67) In Section 8.2.1.15 OperationBody, replace "which is made of an ordered list" by "which is an ordered list". Also in Notation sub-section, replace "semi colons" by "semi-colons".
    (68) In Section 8.2.1.18 ConstructorBody, replace "An constructor body" by "A constructor body". Also replace "semi colons" by "semi-colons". Add comma after 'body notation'.
    (69) In Section 8.2.1.19 MappingBody, replace
    initSection : OclExpression [0..1] {ordered} by
    initSection : OclExpression [0..*] {composes,ordered}
    (70) In Section 8.2.1.19 MappingBody, replace
    /content : OclExpression [0..*] {ordered} by
    /content : OclExpression [0..*] {composes,ordered} (from OperationBody)
    (71) In Section 8.2.1.19 MappingBody, replace
    endSection : OclExpression [0..1] {ordered} by
    endSection : OclExpression [0..*] {composes,ordered}
    (72) In Section 8.2.1.19 MappingBody, notation sub-section replaces "uses firstly braces" by "uses braces". Also replace "On the contrary," by "The" (to avoid double negation). Also replace "may be required is certain " by "may, however, be required in certain ".
    (73) In Section 8.2.1, sub-section "Concepts related with the usage of imperative operations", replace "related with" by "related to".
    (74) In Section 8.2.1.20, replace "Unless isScoped is true" by "Unless isVirtual is true". Also, in attributes sub-section, replace 'virtual : Boolean = true' by 'isVirtual : Boolean = true'.
    (75) In Section 8.2.1.20 ImperativeCallExp in notation sub-section, replace "An imperative call is notated as any other operation call where the source …" by " An imperative call is notated as any other operation call. The source …". Also, after "in terms of the execution semantics" adds "- the source is the transformation class itself, denoted by 'this' -".
    (76) In Section 8.2.1.21 MappingCallExp, replace "value of the strict" by "values of the isStrict". Also remove ", that is, provokes an exception if it evaluates to false".
    (77) In Section 8.2.1.21 MappingCallExp in Notation section, replace "is noateted as any other imperative operation call" by "is notated as any operation call". Also replace "is used when strict is true" by "is used when isStrict is true". Also replaces "Depending whether" by "If" and replaces "the call notation will require or not require a source object" by "the call requires a source object". In all the text replace "non strict" by "non-strict".
    (78) In Section 8.2.1.21 MappingCallExp in Notation section, replace "on a list" by "on a list as source". Also replace #Class by Class.
    (79) In Section 8.2.1.21 MappingCallExp in Notation section, Replace text from "We should note that …" to "as the source of the call" by "Invoking a mapping operation with a transformation instance as the source argument may be useful when a transformation make usage of other coarse-grained transformations (transformation composition)."
    (80) In Section 8.2.1.22 ResolveExp, replace "Finally, the last orthogonal variant," by "The last orthogional variant". Also replace "It is typically useful" by "It may be useful".
    (81) In Section 8.2.1.22 ResolveExp, sub-section semantics, replace "corresponding relation" by "corresponding implicit relation". Also replace parenthesis in "or, what is equivalent…", by dashes "-". Also add add comma after "In this sense" and remove comma in "see, AssignExp". Also remove "later - more precisely -"
    (82) In Section 8.2.1.24 ObjectExp, remove "specific" word. Replace "non null" by "non-null". Replace "All visible variables" by "All variables" Add comma after "When provided". Replace
    "list->object {…}

    // shorthand for list->xcollect object

    {…}
    by : "list->object X{…}

    // shorthand for list->xcollect object X

    {…}

    (83) In Section 8.2.2.3 ComputeExp, replace "defines body" by "defines a body". Replace "and return null" by "and returns null". In the definition of the body property, add the "

    {composes, ordered}" indication.
    (84) In Section 8.2.2.3 ImperativeLoopExp, replace "imperative loop constructs" by "imperative loop constructs such as".
    (85) In Section 8.2.2.6 ForExp adds commas before and after "whereas". Add the {composes, ordered}

    indication in '/iterator' property description. Replace 'Set(T)::forEach(source, iterator, condition, body) : Seq(TT)'
    by 'Collection(T)::forEach(source, iterator, condition, body)'. Also replace 'Set(T)::forOne(source, iterator, condition, body) : Seq(TT)'
    by 'Collection(T)::forOne(source, iterator, condition, body)'. Add "T represents the type of the source element". Adds the paragraph "Collection(T) is any collection type. When applying the for expression, if the source collection is not ordered it is implicitly converted into the corresponding ordered collection (Set and Bag become respectively OrderedSet and Sequence). Replace "is embedded with" by "is embedded within".
    (86) In Section 8.2.2.7 ImperativeIterateExp, in semantics sub-section, replace occurrences of Seq(T) as Collection(T) and replace occurrences of Seq(TT) as Sequence(TT). Also before "If the condition…" add the sentence: " When applying the imperative iterate expression, if the source collection is not ordered it is implicitly converted into the corresponding ordered collection (Set and Bag become respectively OrderedSet and Sequence). Replace "collectectSelect" by "collectselect". Also, add comma after "hence".
    (87) In Section 8.2.2.7 ImperativeIterateExp, remove repeated sentence "The target variable …". Replace "the target variable is implicit here" by "the iterator variable is implicit here".
    (88) In Section 8.2.2.8 SwitchExp in alternativePart property definition, replace

    {ordered}

    by

    {ordered, composes}

    . Also replace "Tre endif keyword can be skipped since it …" by "The endif keyword may be skipped. It …". Also replace "produces a grammar conflict in parsers that can can be solved through look ahead" by "may produce a grammar conflict in parsers which can, however, be solved through appropriate look-ahead.
    (89) In Section 8.2.2.10 VariableExp replaces "A variable initialization expression represents the declaration and the initialization of a variable" by "A variable initialization expression represents the declaration of a variable with an optional initialization value". Also replace "ImpertaiveExpression by ImperativeExpression". In the description of 'withReturn' property, add "The default value is false". Also remove the sentence "See the execution semantic section for the definition of scope rules". Replace "Multiple variable declaration" by "Multiple variable declarations".
    (90) In Section 8.2.2.11 AssignExp, replace "If the value filed…" by "If the provided value is made…". Also replace "by a deferred resolve expressions" by "by a deferred resolve expression". Remove sentence "See semantics details below. Replace "(but null if a fuure value is in right-hand side)" by "unless it is a future value, in which case null is returned". In 'isReset' description, add commas around "for a multivalued target". In association definitions adds the following indications:

    {composes, ordered} for value, {composes} for left and defaultValue. In Notation section, replace "'::=' object Node" by ":= objectNode".
    (91) In Section 8.2.2.11 TryExp, replace "catching of the exception occurs" by "catching of an exception occurs".
    (92) In Section 8.2.2.10 ContinueExp, replace "A continue expression is used, within an interation over a list of expressions" by "Within an interation over a list of expressions, a continue expression is used…". Also, replace "break" by "continue" and remove "- like the side-effect free OCL iterate expression."
    (93) In Section 8.2.2.19 AssertExp, replace "an qassertion holds" by "a condition holds". In Associations sub-section replace: "assertion: OclExpression [0..1]" by "assertion:OclExpression [1] {composes}. Also replace "(warning or fatal keywords)" by "- warning or fatal indentifiers - ".
    (94) In Section 8.2.2.23 InstantiationExp, replace the code after "the following shorthand can be used" by:
    column := self.attribute->new(a) Column(a.name,a.type.name);
    // equivalent code:
    // column := self.attribute->xcollect(a|new Column(a.name,a.type.name));
    (95) In Section 8.2.2 Type Extensions sub-chapter, replace "are two mutable extensions of Collection Types" by "are two mutable collection types".
    (96) In Section 8.2.2.24, replace "A typedef allows to constraint" by "A typedef allows constraining". Remove "A typedef is never instantiated" and Remove "In the perspective of the runtime environment a typedef is never instantiated. Replace "This is specifically used" by "This may be used for". Remove the paragraph starting with "When the base class is not …".
    (97) In Section 8.2.2.25 ListType, replace "It contains an ordered …" by "A value conforming to this type contains an ordered …"
    (98) In Section 8.2.2.25 DictionaryType, replace "elments" by "elements"
    (99) In Section 8.2.2.28, replace "used in defining" by "used when defining". Also replace "ithin" by "within". Also replace "provide means" by "provide a mean".
    (100) In Section 8.2.2.29 DictLiteralExp, replace "part : OclExpression [1] {composes}" by "part : OclExpression [*] {composes, ordered}

    "
    (101) In Section 8.2.2.30 AnonymousTupleLiteralExp, replace 'consist' by 'consists'. Also replace 'TupLiteralPart' by 'OrderedTupleLiteralPart'.. replaces 'part : oclxpression [1]

    {composes}

    ' by 'part : OclExpression [*]

    {composes, ordered}
  • Updated: Fri, 6 Mar 2015 20:54 GMT

Top-level constraint too restrictive

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

    The constraint prevents a usage of non top-level relations in a when clause which includes a negation expression. For example:

    relation A

    { ... }


    relation B { ... when

    { not A() }

    }
    This issue is related to resolution of issue 10626 in 2nd ballot.

  • Reported: QVT 1.0b1 — Fri, 18 May 2007 04:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    This issue resolution invalidates the instruction resolution given by issue 10626.

    Modify the description of property 'isTopLevel' in section 7.11.3.1 as follows:

    isTopLevel : Boolean
    Indicates whether the relation is a top-level relation or a non-top-level relation. The execution of a transformation requires that all its toplevel relations must hold, whereas a non-top-level relation is required to hold only when it is invoked from another relation.

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

8.4.3.5 != and <>

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

    Having two identical operators is redundant and so a bad idea and certainly contrary
    to the spirit of being an OCL extension.

    Suggest: remove != so that novices learn that <> is difference in OCL.

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

    Resolved by applying the resolution of issue 10990.

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

8.4.3.5 = and ==

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

    Having two identical operators is redundant and so a bad idea.

    Introducing a new operator that looks just like a C/Java comparison operator is
    guaranteed to confuse all novices into thinking that = obviously means assignment.

    So this friendly addition is really unfriendly to novices and redundant for experts.

    Suggest: remove == so that novices learn that = is comparison very quickly.

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

    Resolved

    In Section 8.4.3 "Shorthands used to invoke specific pre-defined operations", remove 'both alternative should be available' in numbers 5 and 6. In addition, at the end of this section, add the following paragraph:
    """
    The alternative '==' and '!=' notations can only be used if the source file pre-declares the intention of using them by means of a directive placed before entering the library of the transformation definitions. The syntax of this directive should be a comment having the following form:
    – directive: use-traditional-comparison-syntax or
    // directive: use-traditional-comparison-sysntax
    This declaration makes illegal the usage of the corresponding OCL-like syntax ('=' and '<>') within the compilation unit.

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

Pre-ballot 2 FTF Appendix A: Erroneous collectionTemplate grammar

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

    [ '

    {' <memberSelection> '}

    ' ] in collectionTemplate should be '

    {' [ <memberSelection> ] '}

    '

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

    Resolution: No change
    This has already been fixed in the grammer given in Appendix A of the FTF report of ballot 2

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

Chapter 7,8,9 EssentialOCL usage

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

    The OCL spec identifies Essential OCL as a subset of the OCL Abstract Syntax.
    The OCL spec does not identify an Essential OCL Concrete Syntax.

    The QVT spec should define the Essential OCL Concrete Syntax as a listed subset of
    OCL Concrete Syntax clauses. Presumably all productions in OCL section 9.3 but
    perhaps excluding OclMessageExpCS, OclMessageArgumentsCS and OclMessageArgCS.

    The QVT spec should clearly define whether all OCL keywords are also keywords
    of QVT - a convenience to tool builders re-using OCL implementations, or
    alternatively enumerate only those that are appropriate:

    i.e. and, else, endif, if, implies, in, let, not, or, then, xor.

    (omitting: attr, context, def, endpackage, inv, oper, package, post, pre)

    Perhaps some counterpart to OCL Chapter 12 is required:
    'The Use of OCL Expressions in QVT Models'

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

    No Data Available

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

Chapter 7 Collection::=()

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

    The QVTrelation Standard library should define additional variants of '=' to accommodate the
    permitted matching in predicates.

    e.g.

    Set(T)::=(Bag(T))
    Set(T)::=T

    which appears in the rel2core.

    This avoids the need for detailed descriptions of type conversion schemes to handle
    matching of collections and alternate-kind collections/scalars.

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

    No Data Available

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

7.11.3.1 Relation.operationalImpl

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

    Relation.operationalImpl is shown in Fig 7.7, but not listed in 7.11.3.1.

    It should be a composition (in both).

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

    Update the description of class Relation in section 7.11.3.1 as follows:

    Insert the folloing sentence in the description part before the sentence 'Please refer to sections 7.1 - 7.9 for a detailed description of the semantics, and section 12 for a more formal description in terms of a mapping to the core model.':
    A relation may optionally have an associated black-box operational implementation to enforce a domain.

    Add the following in the 'Associations' sub-section:

    operationalImpl: RelationImplementation [*]

    {composes}

    The set of black-box operational implementations, if any, that are associated with the relation to enforce its domains.

    Also update the the diagram given in Fig 7.7 'QVT Relation Package' to show the association from Relation to RelationImplementation as a composite.

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

Consider renaming 'AnonymousTuple' as 'OrderedTuple'

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

    'Anonymous tuple' is very long. Ordered tuple is similar to 'OrderedSet' in respect
    To 'Set'. Could be a better name.

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

    (1) In all the document, replace all references to AnonymousTuple by OrderedTuple.
    (2) For impact in diagrams apply the diagram updates as specified in Appendix D.

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

QVTOperational examples have some errors and need to be inline with grammar

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

    Some of the examples provided in the spec have either syntax errors either or missing
    elements

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

    (1) Replace the contents of A2.1: Operational Mapping Examples by the following:

    metamodel BOOK {
    class Book

    {title: String; composes chapters: Chapter [*];}

    class Chapter

    {title : String; nbPages : Integer;}

    }

    metamodel PUB {
    class Publication

    {title : String; nbPages : Integer;}

    }

    transformation Book2Publication(in bookModel:BOOK,out pubModel:PUB);

    main()

    { bookModel->objectsOfType(Book)->map book_to_publication(); }

    mapping Class::book_to_publication () : Publication

    { title := self.title; nbPages := self.chapters->nbPages->sum(); }

    (3) Replace the contents of 12.2 by

    – This QVT definition performs an in place transformation on
    – a UML class-diagram model by privatizing the attributes and
    – creating accessor methods

    modeltype UML uses "omg.org.uml14";

    transformation Encapsulation(inout classModel:UML);

    // Indicating that UML1.4 Name type is to be treated as a String
    tag "TypeEquivalence" UML::Name = "String";

    – entry point: selects the packages and applies the transformation
    – on each package

    main()

    { classModel.objectsOfType(Package) ->map encapsulateAttributesInPackageClasses(); }

    – Applies the transformation to each class of the package

    mapping inout Package::encapsulateAttributesInPackageClasses () {
    init

    {self.ownedElement->map encapsulateAttributesInClass();}

    }

    – Performs the encapsulation for each attribute of the class
    – The initialization section is used to retrieve the list of attributes
    – The population section is used to add the two accessor operations
    – The end section is used to privatize each attribute

    mapping inout Class::encapsulateAttributesInClass ()
    {
    init

    { var attrs := self.feature[Attribute];}

    operation := { – assignment with additive semantics
    attrs->object(a) Operation

    { name := "get_" + self.name.upperFirst(); visibility := "public"; type := a.type; }

    ;
    attrs->object(a) Operation {
    name := "set_" + self.name.upperFirst();
    visibility := "public";
    parameter := object Parameter

    { name := 'a_'+ self.name.upperFirst(); kind := "in"; type := a.type;}

    ;
    };
    };
    end

    { attrs->map privatizeAttribute();}

    }

    – in place privatization of the attribute

    mapping inout Attribute::privatizeAttribute ()

    { visibility := "private"; }

    (4) Replaces the content of A2.3 by the following

    The metamodels used here are the same metamodels used for the relational version given in Appendix A.1.1. We provide below their definition using the concrete syntax for metamodels. Note we are assuming that all multi-valued associations are ordered.

    metamodel SimpleUml {

    abstract class UMLModelElement

    { kind : String; name : String; }

    class Package extends UMLModelElement

    { composes elements : PackageElement [*] ordered opposites namespace [1]; }

    abstract class PackageElement extends UMLModelElement {
    }

    class Classifier extends PackageElement {
    }

    class Attribute extends UMLModelElement

    { references type : Classifier [1]; }

    class Class extends Classifier

    { composes attribute : Attribute [*] ordered opposites owner [1]; references general : Classifier [*] ordered; }

    class Association extends PackageElement

    { source : Class [1] opposites reverse [*]; destination : Class [1] opposites forward [*]; }

    class PrimitiveDataType extends Classifier {
    }

    }

    metamodel SimpleRdbms {

    abstract class RModelElement

    { kind : String; name : String; }

    class Schema extends RModelElement

    { composes tables : Table [*] ordered opposites schema [1]; }

    class Table extends RModelElement

    { composes column : Column [*] ordered opposites owner[1]; composes _key : Key [*] ordered opposites owner[1]; // '_key' is an automatic alias for 'key' composes foreignKey : ForeignKey [*] ordered opposites owner[1]; }

    class Column extends RModelElement

    { type : String; }

    class Key extends RModelElement

    { references column : Column [*] ordered opposites _key [*]; }

    class ForeignKey extends RModelElement

    { references refersTo : Key [1]; references column : Column [*] ordered opposites foreignKey [*]; }

    }

    Below the transformation definition.

    transformation Uml2Rdb(in srcModel:UML,out dest:RDBMS);

    – Aliases to avoid name conflicts with keywords
    tag "alias" RDBMS::Table::key_ = "key";
    – defining intermediate data to reference leaf attributes that may
    – appear when struct data types are used
    intermediate class LeafAttribute

    { name:String; kind:String; attr:UML::Attribute; }

    ;
    intermediate property UML::Class::leafAttributes : Sequence(LeafAttribute);

    – defining specific helpers

    query UML::Association::isPersistent() : Boolean

    { result = (self.source.kind='persistent' and self.destination.kind='persistent'); }

    – defining the default entry point for the module
    – first the tables are created from classes, then the tables are
    – updated with the foreign keys implied by the associations

    main()

    { srcModel.objects()[Class]->map class2table(); -- first pass srcModel.objects()[Association]->map asso2table(); -- second pass }

    – maps a class to a table, with a column per flattened leaf attribute

    mapping Class::class2table () : Table
    when

    {self.kind='persistent';}

    {
    init

    { -- performs any needed intialization self.leafAttributes := self.attribute ->map attr2LeafAttrs("",""); // ->flatten(); }

    – population section for the table
    name := 't_' + self.name;
    column := self.leafAttributes->map leafAttr2OrdinaryColumn("");
    key_ := object Key

    { -- nested population section for a 'Key' name := 'k_'+ self.name; column := result.column[kind='primary']; }

    ;
    }

    – Mapping that creates the intermediate leaf attributes data.

    mapping Attribute::attr2LeafAttrs (in prefix:String,in pkind:String)
    : Sequence(LeafAttribute) {
    init {
    var k := if pkind="" then self.kind else pkind endif;
    result :=
    if self.type.isKindOf(PrimitiveDataType)
    then – creates a sequence with a LeafAttribute instance
    Sequence {
    object LeafAttribute

    {attr:=self;name:=prefix+self.name;kind:=k;}

    }
    else self.type.asType(Class).attribute
    >map attr2LeafAttrs(self.name+"_",k)>asSequence()
    endif;
    }
    }

    – Mapping that creates an ordinary column from a leaf attribute

    mapping LeafAttribute::leafAttr2OrdinaryColumn (in prefix:String): Column

    { name := prefix+self.name; kind := self.kind; type := if self.attr.type.name='int' then 'NUMBER' else 'VARCHAR' endif; }

    – 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 ;
    }

    – mapping to build the foreign keys

    mapping Association::asso2ForeignKey() : ForeignKey

    { name := 'f_' + self.name; refersTo := self.source.resolveone(Table).key_; column := self.source.leafAttributes[kind='primary'] ->map leafAttr2ForeignColumn(self.source.name+'_'); }

    – Mapping to create a Foreign key from a leaf attributes
    – Inheriting of leafAttr2OrdinaryColumn has the effect to call the
    – inherited rule before entering the property population section

    mapping LeafAttribute::leafAttr2ForeignColumn (in prefix:String) : Column
    inherits leafAttr2OrdinaryColumn

    { kind := "foreign"; }

    (5) Replaces the content of A2.4 by the following

    modeltype UML uses "omg.org.spem_umlprofile";
    modeltype SPEM uses "omg.org.spem_metamodel";
    transformation SpemProfile2Metamodel(in umlmodel:UML,out spemmodel:SPEM);

    query UML::isStereotypedBy(stereotypeName:String) : Boolean;
    query UML::Classifier::getOppositeAends() : Set(UML::AssociationEnd);

    main ()

    { -- first pass: create all the SPEM elements from UML elements umlmodel.rootobjects()[UML::Model]->map createDefaultPackage(); -- second pass: add the dependencies beyween SPEM elements umlmodel.objects[UML::UseCase]->map addDependenciesInWorkDefinition(); }

    mapping UML::Package::createDefaultPackage () : SPEM::Package

    { name := self.name; ownedElement := self.ownedElement->map createModelElement(); }

    mapping UML::Package::createProcessComponent () : SPEM::ProcessComponent
    inherits createDefaultPackage
    when

    {self.isStereotypedBy("ProcessComponent");}

    {}

    mapping UML::Package::createDiscipline () : SPEM::Discipline
    inherits createDefaultPackage
    when

    {self.isStereotypedBy("Discipline");}


    {}

    mapping UML::ModelElement::createModelElement () : SPEM::ModelElement
    disjuncts
    createProcessRole, createWorkDefinition,
    createProcessComponent, createDiscipline
    {}

    mapping UML::UseCase::createWorkDefinition () : SPEM::WorkDefinition
    disjuncts
    createLifeCycle, createPhase, createIteration,
    createActivity, createCompositeWorkDefinition
    {}

    mapping UML::Actor::createProcessRole () : SPEM::ProcessRole
    when

    {self.isStereotypedBy("ProcessRole");}

    {}

    – rule to create the default process performer singleton
    mapping createOrRetrieveDefaultPerformer () : SPEM::ProcessPerformer {
    init

    { result := resolveoneByRule(createOrRetrieveDefaultPerformer); if result then return endif; }

    name := "ProcessPerformer";
    }

    mapping abstract UML::UseCase::createCommonWorkDefinition ()
    : SPEM::WorkDefinition
    {
    name := self.name;
    constraint :=

    { self.constraint[isStereotypedBy("precondition")] ->map createPrecondition(); self.constraint[isStereotypedBy("goal")]->map createGoal(); }

    ;
    }

    mapping UML::UseCase::createActivity () : SPEM::WorkDefinition
    inherits createCommonWorkDefinition
    when

    {self.isStereotypedBy("Activity");}

    {}

    mapping UML::UseCase::createPhase () : SPEM::Phase
    inherits createCommonWorkDefinition
    when

    {self.isStereotypedBy("Phase");}

    {}

    mapping UML::UseCase::createIteration () : SPEM::Iteration
    inherits createCommonWorkDefinition
    when

    {self.isStereotypedBy("Iteration");}

    {}

    mapping UML::UseCase::createLifeCycle () : SPEM::LifeCycle
    inherits createCommonWorkDefinition
    when

    {self.isStereotypedBy("LifeCycle");}

    {}

    mapping UML::UseCase::createCompositeWorkDefinition () : SPEM::WorkDefinition
    inherits createCommonWorkDefinition
    when

    {self.isStereotypedBy("WorkDefinition");}

    {}

    mapping UML::Constraint::createPrecondition () : SPEM::Precondition

    { body := self.body; }

    mapping UML::Constraint::createGoal () : SPEM::Goal

    { body := self.body; }

    mapping UML::UseCase::addDependenciesInWorkDefinition ()
    : SPEM::WorkDefinition
    merging addDependenciesInActivity
    {
    init

    { result := self.resolveone(WorkDefinition); var performers := self.getOppositeAends()[i|i.association [isStereotypedBy("perform")]->notEmpty()]; assert (not performers->size()>1) with log("A unique performer is allowed",self); }

    subWork := self.clientDependency[*includes].supplier
    ->resolveone(WorkDefinition);
    performer := if performers then performers->first()
    else createOrRetrieveDefaultPerformer() endif;
    }

    mapping UseCase::addDependenciesInActivity () : WorkDefinition
    when

    {self.stereotypedBy("Activity");} { assistant := self.getOppositeAends()[i|i.association [a|a.isStereotypedBy("assist")]->notEmpty()]->resolve(); }
  • Updated: Fri, 6 Mar 2015 20:54 GMT

Find better notation for explicit extent indication in op mapping parameter

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

    Find better notation for explicit extent indication in operational mapping parameters.

    Though the type names prefixed with the extent work from the point of implementation, I suspect it
    might add on complexity of type resolution.
    All the folks are pretty much used to local and qualified name convention concerning the '::' separator use.
    Is 'bag::Foo' a qualified type name or unqualified one but to be created in a 'bag' extent?
    I think that including model param names into type resolution may increase the level of ambiguity as in this way, param names can impose clashes with packages, model types.

    This issue is related to resolution of 9388 in Ballot1.

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

    Replace resolution of issue 9388 (Ballot 1) by the following resolution text.

    (1) In Section 8.2.1.16 (MappingParameter) add the association:
    """
    extent : ModelParameter [0..1]
    The extent of the mapping parameter. Should be explicitly provided
    when there is an ambiguity on the extent that will own a potential
    created element corresponding to this parameter.
    """
    (2) In the same section 8.2.1.16, add the "Notation" subtitle
    as follows:
    """
    Notation
    The extent of a mapping parameter can be provided explicitly
    using the '@' symbol after the type of the mapping parameter. In that case the declarator has the form:
    mymappingparameter : myextent::MyType@mymodelparameter.
    It is not mandatory to provide the extent when it can be inferred
    from the type.
    Example:
    transformation T(in src:S, out dest1, out dest2);
    mapping X::foo(inout Y@dest1) : Y@dest2;
    // 'X' is a class of 'S' metamodel and 'Y' is a class of 'D' metamodel
    """

    (3) In Figure 8.1, add the correspond link between MappingParameter
    and ModelParameter.

    (4) In Section 8.2.1 (ObjectExp), within the "Notation" subtitle,
    replace:
    """When provided the model parameter is notated within brackets
    after the object keyword.
    object[srcmodel] x:X

    { ... } // x is created within the 'srcmodel
    """
    by:
    """When an explicit extent is provided, the model parameter variable name
    postfixes the type of the object expression using the "@" separator symbol.
    object x: X@srcmodel { ... }

    // x is created within the 'srcmodel
    """
    (this change is required for consistency with mapping parameter notation).

    (5) In Section 8.2.2.23 (InstantiationExp), within the "Notation" subtitle,
    replace:
    """
    When provided the extent is notated by adding the variable name in brackets after the new keyword.
    column := new [mymodel] Column(n,t); // mymodel is the extent for the new instance.
    """

    by:
    """When an explicit extent is provided, the variable name
    postfixes the type of the instantiation expression using the "@" separator symbol.
    column := new Column@mymodel(n,t); // mymodel is the extent for the new instance.
    """
    (6) In BNF grammar (Section 8.4.6.1), define the <typespec> rule as follows:
    <typespec> ::= <type_reference> <extent_location>?
    <type_reference> ::= <scoped_identifier> | <complex_type>
    <extent_location> ::= '@' <identifier>

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

8.4.6.2 QVToperational is not a syntax extension of OCL

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

    The syntax claims to extend the OCL syntax. But it doesn't, or
    at least not with the same semantics.

    For instance:

    The QVToperational grammar defines:
    'or' and 'xor' with lower precedence than 'and'
    OCL (7.4.7) defines them the same precedence .

    The QVToperational grammar defines:
    'if' as primary
    OCL (7.4.7) defines 'if' between relational and additive.

    The changed precedences may be better, but they are not OCL.

    The QVToperational type/declaration system is difficult to compare with
    OCL; it certainly doesn't look compatible.

    Suggest: Re-specify the QVToperational grammar so that the
    name, type and expression sub-grammars are
    demonstrably an extension of their Essential OCL counterparts.

    i.e. each production such as PrimitiveLiteralExpCS should be used unchanged
    or reproduced preferably containing only additional clauses, but perhaps
    replacement clauses that can be analyzed to provide equivalent/extended coverage

    Else: Remove all claims that there is any similarity
    between QVToperational and OCL.

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

    No Data Available

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

7.13 Implicit Variable Declarations

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

    The RelationsToCore example declares only those variables that are necessary. It is
    possible to deduce the types of variables not declared explicitly from the property
    with which the variable is associated in a property template, or from the relation
    whose invocation the variable participates in.

    Are QVTrelation tools required to deduce implicit declarations?

    If so, what are the detailed semantics for resolution of conflicting inference between
    explicit and implicit declarations and between implicit and implicit declarations.

    Do these semantics depend on collection kind, enforcement direction and relation
    invocation binding?

    Note that invocation of a relation with ridiculous types is probably but not
    necessarily an error. In some circumstances the user may not be aware that a match
    is impossible. When using third party models, the user perhaps should not be aware
    that a match is impossible. The ridiculous match may be a precautionary cover for
    a hoped for impossible case.

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

    Add the following sub section in section 7.13 Concrete Syntax:

    Implicit declaration of variables:

    There is no need to explicitly declare variables that are bound to object or collection templates. All other variables must be explictly declared. Consider the following template declarations:
    c:Class

    {<template-body>}
    cs:Set(Class) {<template-body>}

    Here there is no need to have explcit declaration for variables c and cs as their types are obvious from the template declarations.

    If there exists an explcit declaration for a variable that is bound to an object or a collection template, then the explicitly declared type must either be the same or more generic than the type specified by the template. If an implictly declared variable has bindings with more than one object template (resp collection template), then the types of all such templates must be the same.

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

7.13 Comments

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

    Is there a syntax for comments?

    Suggest: – comments to avoid confusion with OCL.

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

    Resolution: No change.
    This has already been addressed by the resolution of issue 10604.

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

7.11.2.3 CollectionTemplateExp.referredCollectionType

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

    CollectionTemplateExp.referredCollectionType refers to a CollectionType, but that type may not exist,
    since the reference is a parameterisation of a collection; the collection kinds exist in OCL, the
    parameter types in the user model, but the parameterised collections exist only as references.

    Suggest:
    remove: CollectionTemplateExp.referredCollectionType
    add: CollectionTemplateExp.referredElementType : Type[0..1]
    add: CollectionTemplateExp.collectionKind : CollectionKind[1]

    to capture the reference without requiring type synthesis.

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

    (1) In Section 7.11.1.1, within "associations" sub-section, add the following property:

    /ownedType : Type [0..*] (from Package)

    {composes,ordered}

    All the types being defined by this transformation. Specifically this
    includes any composite type used to define the type of a variable or a parameter, for instance a 'Set(MyMetaclass)' parameterized type instance.

    (2) In Section 7.11.1.1, add a "Remark" sub-section with the following
    sentence:
    Remark:
    Instances of parameterized types defined in different transformations
    denote the same type if the base types are the same: for instance
    'Tx1::Set(Integer)' and 'Tx2::Set(Integer)' denote the same type
    'Set(Integer)'.

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

7.11.2.3 CollectionTemplateExp

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

    The description for match is 'specifies a variable'. This is a poor
    description for a VariableExp that references a variable.

    CollectionTemplateExp.match should compose its expression.

    CollectionTemplateExp.part should compose its expression

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

    No Data Available

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

7.11.1.2 Meta-model Id persistence

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

    The concrete QVTrelation syntax references meta-models by an identifier,
    which define TypedModel.usedPackages in the abstract syntax.

    The meta-model identifier is not present in the abstract syntax,
    making it difficult to unparse the abstract syntax back to concrete.

    It is possible in principle to invert the meta-model-id to package
    conversion to identify meta-model-ids that could give the required forward
    conversion, but there is no guarantee that this would be unique.

    Suggest:

    Add TypedModel.metaModelNames : String[0..*] to persist these annotations

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

    Comment:
    The 'metaModelId' of concrete syntax is actually a reference to the package name of a used package in the abstract syntax. There is no need to provide anything more in the abstract syntax.
    Resolution: No change

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

Distinguishing pure syntactic tags from other tags in QVTOperational

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

    Need to distinguish between tags that are owned by model elements from tags
    which are purely syntactical (like the 'alias' tag). At least the complete list of the
    syntactical tags should be provided

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

    In Section 8.3.11 Predefined Tags. Add the following sentence after the sentence describing the "alias" tag.
    "This is a purely syntactic tag. Consequently the representation of this Tag can be skipped after parsing the source file".

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

7.13.1 Collection conversions

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

    Given a property template in which the property is a collection, under what
    circumstances:

    Is it permissible for the right hand side to be a non-collection?

    Is it permissible for the right hand side to be a different collection kind.

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

    Add the following to the description of class PropertyTemplateItem in section 7.11.2.4:

    A property template item has a valid match when the value of the referred property matches the value specified by the value expression. The following rules apply when the value is specified by a template expression:

    • If the value expression is an object template expression and the referred property is single-valued then the property value must match the object template expression.
    • If the value expression is an object template expression and the referred property is multi-valued then at least one of the property values must match the object template expression.
    • If the value expression is a collection template expression and the referred property is single-valued then the property value is treated as a singleton collection that must match the collection template expression
    • If the value expression is a collection template expression and the referred property is multi-valued then the collection of property values must match the collection template expression. The following rules apply:
      o If the property value is a set, then the collection type of the collection template expression must be a set.
      o If the property value is an ordered set, then the collection type of the collection template expression can be one of set, sequence or ordered set.
      o If the property value is a sequence, then the collection type of the collection template expression can be one of set, sequence or ordered set. When the collection type is a set or an ordered set, a valid match requires that each value of the property be unique.
  • Updated: Fri, 6 Mar 2015 20:54 GMT

7.13.1 Model class name semantics

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

    Given a class pack::age::cls in mdlid, in what circumstances are

    cls
    age::cls
    pack::cls
    mdlid::cls
    mdlid::pack::cls

    permissible model references?

    Suggest:

    The full mdlid::pack::age::cls is always permissible.
    Omitted qualifications are permitted if a search of all possibilities for
    omitted elements yields a unique solution.

    In particular same model transformations should not need the redundant mdlid.

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

    Comment:
    The semantics of how named elements are identified in package namespaces comes from MOF. QVT has no special semantics of its own for this purpose.
    Resolution: No change

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

7.13.1 Scoped transformation name

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

    How can a transformation be defined in a nested package?

    Surely OMG should be able to define org.omg.qvt.RelationToCore?

    Suggest: introduce a Java-like package statement.

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

    (1) Within 7.13 Section, add a preliminary sub-section named "Compilation Units" with the following content.

    A relational transformation specification provided using concrete syntax in a text file may import one or more compilation units. A compilation unit corresponds to another relational transformation definition given either using the concrete syntax definition or the abstract representation.

    Within an import statement a compilation unit is referenced by means of a simple unqualified aplhanumeric identifier - with no special characters and blanks characters allowed - or is referenced by means of a qualified one. In the latter case, the qualification is given by a list of namespaces separated by the dot character. These namespaces have no representation in the metamodel. It is up to an implementation to make a correspondence between the namespace hierarchy and the hierarchy of the file system.

    (2) In section 8.4.1, replace the first paragraph by the following two paragraphs:

    An operational transformation specification provided using concrete syntax in a text file may import one or more compilation units. A compilation unit corresponds to another operational transformation or library definition given either using the concrete syntax definition or the abstract representation.

    Within an import statement a compilation unit is referenced by means of a simple unqualified aplhanumeric identifier - with no special characters and blanks characters allowed - or is referenced by means of a qualified one. In the latter case, the qualification is given by a list of namespaces separated by the dot character. These namespaces have no representation in the metamodel. It is up to an implementation to make a correspondence between the namespace hierarchy and the hierarchy of the file system.

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

Extent of intermediate classes in QVT Operational

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

    The extent when creating instances of intermediate classes cannot be determined
    if there is no modeltype associated with the definition of intermediate classes.

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

    (1) In section 8.2.1.3 Module, in the description of derived property ownedType, append the following sentence: If the module contains the declaration of intermediate classes (see OperationalTransformation::intermediateClass definition) a model type named '_INTERMEDIATE' is automatically defined and inserted in the list of owned types. The model type package is also named '_INTERMEDIATE'.
    This package is nested by the transformation (by means of the inherited Package::nestedPackage property).
    (2) In section 8.2.1.3 Module, in the description of the property usedModelType replace the description paragraph by: "The list of model types being used. This includes the implicit '_INTERMEDIATE' model type when available (see ownedType description).
    (3) In Section 8.2.1.1 Transformation, in the description of the property modelParameter, add the sentence "If the transformation defines intermediate classes this contains a parameter named '_intermediate'
    of the type '_INTERMEDIATE' (see 'Module::ownedType' property description).

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

The QVT Operational StdLib has various mispellings and copy-paste errors

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

    The QVT Operational StdLib has various mispellings and copy-paste errors and lacks
    sometimes of precision. Here's a list of encountered problems:

    • List<Element> => List(Element)
    • MarkedAs has a string parameter
    • Missing a 'stereotypedKindOf'
    • Return type of Model::objects() should be a Sequence
    • Return type of Dictionary::size should be 'Integer'
    • Copy-paste error in values(), keys() and isEmpty() Dictionary
      operations: unexpected 'size' in signature
    • In List, "all aperations in OCL..." should be replaced by something
      more precise, like
      "all operations of the OCL Collection type are available"
    • List::insertAt : int => Integer. Should indicate the starting position for the index.
    • String::format Should indicate whether the type is a tuple or a dictionary,
      may be by splitting the operation in two operations.
    • Indentation problem starting from String::substringAfter
    • String::equals should better be named 'match' is different than the MOF Object::equals
    • Integer::range, the type of start and end parameters is missing
    • An M1 type named 'Property' is missing to comply with MOF reflexive API
    • The result type of Status::raisedException should be a M1 class named
      'Exception' (base type of all exceptions.
    • Methods imported from MOF::reflect should be repeated in the spec for clarity
      - Alphanumeric names for pre-defined OCL operations like '+', '-' … were missing.
    • The return type of objectsOfType should depend on the argument (like oclAsType).
  • Reported: QVT 1.0b1 — Tue, 17 Apr 2007 04:00 GMT
  • Disposition: Resolved — QVT 1.0
  • Disposition Summary:

    Resolution:

    (1) In Section 8.3 Replace all occurrences of List<Element> by List(Element)
    (2) Change the signature of markedAs: Element::markedAs(String value) : Boolean
    (3) After the operation "stereotypedBy", add the operation "stereotypedStrictlyBy" with the following definition: Element::stereotypedStrictlyBy(String) : Boolean : Same than stereotypedBy except that base stereotype are not taken into account.
    (4) Change the signature of Dictionary::size as: Dictionary(KeyT,T)::size() : Integer
    (5) Change the signature of Dictionary::values, Dictionary::keys and Dictionary:isEmpty as follows:
    Dictionary(KeyT,T)::values() : List(T)
    Dictionary(KeyT,T)::Keys() : List(KeyT)
    Dictionary(KeyT,T)::isEmpty() : Boolean,
    (6) Replace "all operations in OCL are available" by " all operations of the OCL Collection type are available"
    (7) In insertAt description, add the following sentence: "The index starts at zero (in compliance with OCL convention)"
    (8) Rename String::equals by String::match with the following signature and description.
    String::match (String matchpattern) : Boolean
    Returns true if the value of the String matches the regular expression, else return false. The syntax of regular expression is the syntax or regular expression in Java language.
    (9) Change the signature of the range operation as follows:
    Integer::range (start: Integer,end: Integer) : List(Element)
    (10) In Section 8.3.1 Predefined types, add the definition of a 'Exception' type with the following definition: This M1 class named Exception represents the base class for exceptions. The M1 Exception type is an instance of the Class metatype.
    (11) In Section 8.3.3, replace " All MOF reflective operations applying on Objects " by The reflective operations inherited from MOF that are available in QVT specification are:
    (12) In Section 8.3.2 Synonym types and synonym operations, insert the following paragraph at the end: The following synonyms are defined for the following pre-defined OCL operations:
    String : operator+ -> concat
    Integer: operator+ -> plus,
    operator- (binary) -> minus,
    operator- (unary) -> unaryminus
    operator* -> multiply
    operator/ -> divide
    Real: operator+ -> plus,
    operator- (binary) -> minus,
    operator- (unary) -> unaryminus
    operator* -> multiply
    operator/ -> divide

    (13) In the description of objectsOfType, add the following sentence:
    " The returned Element type is the type denoted by the type expression." And correct the signature as follow:
    Model::objectsOfType(OclType) : Set(Element)
    (14) Within section 8.3.8 Operation list, add the following operations:
    Set(T)::asList() : List(T)
    OrderedSet(T)::asList() : List(T)
    Sequence(T)::asList() : List(T)
    Bag(T)::asList() : List(T)

    Converts a collection into the equivalent mutable list.
    (15) In the signature of the following operations replace the result type by Set(Element): subobjects, allSubobjects, subobjectsOfType, allSubobjectsOfType, allsubobjectsOfKind. (Remark: this is in line with the result type of Model::objects()). Also in this signature replace 'TypeType' by 'OclType' (which is the M1 type).

    NOTE: Typo fixes after AB review
    In addition the following fixes need to be done in section 8.3.9 Operations on strings: the syntax for parameters should be: <paramname> : <type> instead of <type> <paramname> as found in: 'replace', 'equals', 'equalsIgnoreCase', 'find', 'rfind', 'startStrCounter', 'getStrCounter', 'incStrCounter'. Also 'void' type should be spelled 'Void' in 8.3.8 for 'add', 'prepend' and 'insertAt' signature.

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

Clarify the return type of xselect operator

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

    Various examples provided in the spec suggest that the return type of xselect operator
    (bracket notation) depends on the filter expression (implicit casting).
    However this is currently not explained in the definition of the operator.

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

    (1) In section 8.2.2.7 ImperativeIterateExp add the following sentence at the end of the 2nd paragraph: "Also a specific implicit type casting rule applies depending on the condition expression that is associated with the iteration (see implicit type casting rules sub-section)."
    (2) Before the Semantics sub-section, add a sub-section named "Type re-casting" with the following text:
    """The type of the sequence or the object returned by the ImperativeIterateExp construct depends on the usage of the 'condition' expression is used: if the condition is an instance of TypeExp, the condition is firstly re-interpreted as a Boolean expression of the form 'oclIsKind(TypeExp)'. Additionally, the returned sequence (resp. the returned single object) is re-casted as a sequence of the type denoted in the type expression (resp. as an instance of the denoted type). If the 'condition' expression is not used or is not a TypeExp instance no implicit re-casting semantic applies.
    Example:
    self.mysequence[MyType]
    // the type of this expression is a Sequence of 'MyList'
    self.mysequence[oclIsKind(MyType) and name=="foo"]
    // the type is the type of the self.mysequence source expression
    """
    NOTE: There is a typo in the resolution text within item (2): the sentence
    "// the type of this expression is a Sequence of 'MyList'" should be
    "// the type of this expression is a Sequence of 'MyType'"

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

Incomplete specification for the resolution operation ResolveExp

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

    The type returned by ResolveExp and ResolveInRule is not clear: a OclAny?
    The type of the filtered objects?
    The semantics of ResolveInRule when no source is passed is also unclear.
    The variant 'invresolveIn' (combining inverse and rule scope) is missing.
    Consider simplifying ResolveExp definition: instead of an arbitrary condition
    expression use a type reference representing both: the returned type and
    the filtering expression

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

    Resolution:

    (1) Skip the three resolution instructions defined for issue 9390 in ballot1.
    (2) Add a new property "ResolveExp::target : Variable [0..1] composes" with the following description text: """a variable whose type indicates the primary condition for filtering the potential result objects. The extra condition (see 'condition' property) may use the variable to express a complementary filtering condition. This variable also has an influence in the type returned by the resolve expression (see type returned by the resolution expression)."""
    (3) In Section 8.2.1.22 ResolveExp, just before "semantics" sub-section add a sub-section "Type of a resolve expression" with the following content text: "The type of a ResolveExp expression depends on the type of the 'target' variable and on the multiplicity indication (the 'one' property). If 'one' is true, the returned type is the type of the 'target' variable. Otherwise, the returned type is a Sequence of the type of the 'target' variable. If no target variable is provided the type is either Object (the type representing all types, see Section 8.3.1) either a Sequence of Objects - depending on the multiplicity"
    (4) In section 8.2.1.22 ResolveInExp, just before "superclasses" sub-section add the section: "The type of a ResolveInExp expression is computed using the same rules as for the type of a ResolveExp."
    (5) In section 8.2.1.22 ResolveInExp, after the sentence " All variants described for the resolve expression are applicable to the resolve in expression" add a new paragraph with the sentence "A resolve in expression may be applied with an empty source argument. In that case it inspects all objects created or updated by the rule (instead of inspecting only the objects created or updated from the source object) ."
    (6) In section 8.1.22 ResolveExp, replace the content of Notation section by:
    The notation uses one of these three forms:
    <resolve_op> '(' (<identifier> ':' )? <typespec> ')' // no extra condition

    <resolve_op> '(' (<identifier> ':' )? <typespec> ' ' <expression> ')' // with extra condition
    <resolve_op> '(' ')' // no target, no extra condition
    where the <resolve_op> is one of the following: resolve and invresolve and invresolveone. When isDeferred is true the late keyword is used before the operation name. The resolution operator may be called on a list. This is a shorthand for invoking it in the body of a ForEachExpr expression.
    myresult := mysourceobject.resolveone(Table);
    myresult := mysourceobject.resolveone(t:Table
    t.name.startsWith("_"));
    myprop := mylist->late resolve(Table);
    // shorthand for mylist->forEach i.late resolve(Table)

    (7) In section 8.2.1.22 ResolveInExp, replace the sentence "The notation uses …" by the sentence "The notation uses the same syntax as ResolveExp except that the operation names are one of the following resolveIn, resolveoneIn, invresolveIn or invresolveoneIn".The two variants starting with "inv" prefix correspond to the "inverse" variant (ResolveExp::isInverse == true). Also, after "is the condition to evaluate?", add the sentence: "The reference to the rule is given by a qualified identifier (context class and name). As a limitation of the concrete syntax, it is not possible to provide a reference to a rule is there is an ambiguity (having the same name and context but different parameters).
    (8) In Section 8.2.2.5, replace the sentence defining the "condition" property by "An optional additional Boolean condition to be evaluated to filter the potential results."

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

The representation and the containment of 'this' variable is missing

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

    In the section defining the OperationalTransformation class a 'this' predefined variable
    is defined but its exact representation and containment in the metamodel is missing.

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

    Resolution:

    (1) Add the composite property Module::ownedVariable of type Variable, with multiplicity '*' with the following definition:
    "The list of variables owned by the module."

    (2) Update the diagram Figure 8.1 with the new 'ownedVariable' association (see diagram the Appendix C ("Updated Diagrams") of this report.

    (3) In section 8.2.2.1 (Operational Transformation), after the sentence " The instantiation of the transformation is either implicit (the instance being referred though the predefined this variable) or explicit. In the latter case an InstantiationExp expression is used. " add the sentence: The implicit 'this' variable is represented by a Variable instance named "this" having the transformation as its type and owned by the transformation through the 'ownedVariable' property.

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

The BNF syntax of QVTOperational is not complete

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

    The BNF syntax of QVTOperational is not complete. Various elements are missing in the QVTOperational BNF like the 'late' keyword and the notation for enumeration and datatypes.

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

    The grammar was out of sync in respect with the metamodel. The issue is resolved globally by providing by new version of the grammar. The following text should replace the actual content of section 8.4.6.1.

    // keywords

    Bag, Collection, Dict, OrderedSet, Sequence, Set, Tuple, abstract,
    access, and, any, assert, blackbox, break, class, collect,
    collectNested, collectOne, collectselect, collectselectOne,
    composes, compute, configuration, constructor, continue, datatype,
    default, derived, disjuncts, do, elif, else, end, endif, enforcing,
    enum, except, exists, extends, extends, false, forAll, forEach ,
    forOne, from, helper, if, implies, import , in, inherits, init,
    inout, intermediate, invresolve, invresolveIn, invresolveone,
    invresolveoneIn , isUnique, iterate, late, let, library, literal,
    log, main, map, mapping, merges, metamodel, modeltype, new, not,
    null, object, one, or, out, package, population, primitive, property,
    query, raise, refines, refines, reject, resolve, resolveIn, resolveone,
    resolveoneIn, return, select, selectOne, sortedBy, static, static,
    switch, tag, then, transformation, true, try, typedef, unlimited,
    uses, when, where, while, with, xcollect , xmap, xor, xselect

    // start rule
    <topLevel> ::= <import>* <unit_definition>*

    <import> ::= 'from' <unit> 'import' (<identifier_list> | '*') ';'

    'import' <unit> ';'
    <unit> ::= <identifier> ('.' <identifier>)*

    <identifier_list> ::= <identifier> (',' <identifier>)*

    // definitions in a compilation unit
    <unit_definition>
    ::= <transformation>

    <library>
    <access_usage> ';'
    <modeltype>
    <metamodel>
    <class>
    <property>
    <helper>
    <constructor>
    <entry>
    <mapping>
    <tag>
    <typedef>

    // Transformation and library definitions

    <transformation> ::= <transformation_h> (";" | '

    {' <module_definition>* '}' ';'?)
    <library> ::= <library_h> (";" | '{' <module_definition>* '}

    ' ';')

    // Transformation header
    <transformation_h> ::= <qualifier>* 'transformation' <identifier>
    <transformation_signature> <transformation_usage_refine>?
    <transformation_usage_refine> ::= <module_usage> | <transformation_refine>
    <transformation_signature> ::= <simple_signature>
    <transformation_refine> ::= 'refines' <moduleref> 'enforcing' <identifier>

    // Library header
    <library_h> ::= 'library' <identifier> <library_signature>? <module_usage>?
    <library_signature> ::= <simple_signature>

    // import of transformation and library
    <module_usage> ::= <access_usage> | <extends_usage>
    <access_usage> ::= 'access' <module_kind>? <moduleref_list>
    <extends_usage> ::= 'extends' <module_kind>? <moduleref_list>
    <module_kind> ::= 'transformation' | 'library'
    <moduleref_list> ::= <moduleref> (',' <moduleref>)*
    <moduleref> ::= <scoped_identifier> <simple_signature>?

    // module definitions
    <module_definition>
    ::= <class>

    <property>
    <helper>
    <constructor>
    <entry>
    <mapping>
    <tag>
    <typedef>

    // general purpose grammar rules
    <qualifier> ::= 'blackbox' | 'abstract' | 'static'
    <complete_signature> ::= <simple_signature> (':' param_list)?
    <simple_signature> ::= '(' <param_list>? ')'
    <param_list> ::= <param> (',' <param>)*
    <param> ::= <param_direction>? <declarator>
    <param_direction> ::= 'in' | 'inout' | 'out'
    <simple_declarator> ::= <typespec>

    <scoped_identifier> ':' <typespec>
    <declarator> ::= <typespec> <init_part>?
    <scoped_identifier> ':' <typespec> <init_part>?
    <simple_declarator_list> ::= <simple_declarator> (',' <simple_declarator>)*
    <declarator_list> ::= <declarator> (',' <declarator>)*
    <declarator_semi_list> ::= <declarator> (';' <declarator>)*
    <init_part> ::= <init_op> <expression>
    <init_op> ::= '='
    ':=' '::='
    <typespec> ::= <type_reference> <extent_location>?
    <type_reference> ::= <scoped_identifier>
    <complex_type>
    <extent_location> ::= '@' <identifier>
    <complex_type> ::= <complex_type_key>
    <collection_key> '(' <typespec> ')'
    'Tuple' '(' <declarator_list> ')'
    'Dict' '(' <typespec> ',' <typespec> ')'
    <complex_type_key> ::= <collection_key>
    'Dict' 'Tuple'
    <collection_key> ::= 'Collection'
    'Set' 'OrderedSet' 'Sequence' 'Bag'
    'List'
    <scoped_identifier> ::= <identifier> ('::' <identifier>)*
    <scoped_identifier_list> ::= <scoped_identifier> (',' <scoped_identifier>)*
    <expression_list> ::= <expression_semi_list> ';'?
    <expression_semi_list> ::= <expression> (';' <expression>)*
    <expression_comma_list> ::= <expression> (',' <expression>)*
    <expression_block> ::= ' {' <expression_list>? '}

    '

    // model types compliance and metamodel declarations
    <modeltype> ::= 'modeltype' <identifier> <compliance_kind>?
    'uses' <packageref_list> <modeltype_where>? ';'
    <modeltype_where> ::= 'where' <expression_block>
    <packageref_list> ::= <packageref> (',' <packageref>)*
    <packageref> ::= (<scoped_identifier> ( '(' <uri> ')' )? | <uri>)
    <compliance_kind> ::= <STRING> // like: "strict" and "effective"
    <uri> ::= <STRING>

    // Syntax for defining explicitly metamodel contents
    <metamodel> ::= <metamodel_h> (";" | '

    {' <metamodel_def>* '}

    ' ';')
    <metamodel_h> ::= ('metamodel' | 'package') scoped_identifier
    <metamodel_def> ::= <class> | <enumeration> | <tag>

    <class> ::= <class_h> (";" | '

    {' <class_feature_list>? '}

    ' ';')
    <class_h> ::= <class_info> <scoped_identifier> <class_extension>?
    <class_info> ::= 'datatype'

    'primitive'
    'intermediate'? <qualifier>* 'class'
    <class_extension> ::= 'extends' <scoped_identifier_list>
    <class_feature_list> ::= <class_feature> (';' <class_feature>)*
    <class_feature> ::= <class_property>
    <class_operation> <tag>

    <class_property> ::= <feature_key>? <declarator> <multiplicity>?
    <opposite_property>?
    <feature_key> ::= 'composes' | 'derived' | 'static'
    <multiplicity> ::= '[' multiplicity_range ']'
    <multiplicity_range> ::= <INTEGER> | '*' | <INTEGER> '...' <INTEGER>
    <class_operation> ::= <feature_key>? <declarator> <complete_signature>

    <enumeration> ::= <enumeration_h> ';'

    <enumeration_h> ' {' <identifier_list> '}

    ' ';'?

    <enumeration_h> ::= 'enum' <identifier>
    <opposite_property> ::= 'opposites' <identifier>

    <tag> ::= 'tag' <tagid> <scoped_identifier> ('=' <tagvalue>)? ';'
    <tagid> ::= <STRING>
    <tagvalue> :: <expression>

    // typedefs
    <typedef> ::= 'typedef' <identifier> '=' <typespec> (typedef_condition)? ';'
    <typedef_condition> ::= '[' <expression> ']'

    // Properties in transformation
    <property> ::= 'intermediate'? <property_key>+ <declarator> ';'
    <property_key> ::= 'derived' | 'literal' | 'configuration' | 'property'

    // Syntax for helper operations
    <helper> ::= <helper_decl> | <helper_simple_def> | <helper_compound_def>
    <helper_header> ::= <helper_info> <scoped_identifier> <complete_signature>
    <helper_info> ::= <qualifier>* <helper_kind>
    <helper_kind> ::= 'helper' | 'query'
    <helper_decl> ::= <helper_header> ';'
    <helper_simple_def> ::= <helper_header> '=' <expression> ';'
    <helper_compound_def> ::= <helper_header> <expression_block> ';'?

    // Syntax for constructors
    <constructor> ::= <constructor_decl> | <constructor_def>
    <constructor_header> ::= <qualifier>* 'constructor' <scoped_identifier>
    <simple_signature>
    <constructor_decl> ::= <constructor_header> ';'
    <constructor_def> ::= <constructor_header> <expression_block> ';'?

    // Syntax for entries
    <entry> ::= <entry_decl> | <entry_def>
    <entry_header> :: 'main' <simple_signature>
    <entry_decl> ::= <entry_header> ';'
    <entry_def> ::= <entry_header> <expression_block> ';'?

    // syntax for mapping operations
    <mapping> ::= <mapping_decl> | <mapping_def>
    <mapping_decl> ::= <mapping_full_header> ';'
    <mapping_def> ::= <mapping_full_header> '

    {' <mapping_body> '}

    ' ';'?
    <mapping_full_header> ::= <mapping_header> <when>? <where>?
    <mapping_header> ::= <qualifier>* 'mapping' <param_direction>?
    <scoped_identifier> <complete_signature> <mapping_extra>*
    <mapping_extra> ::= <mapping_extension> | <mapping_refinement>
    <mapping_extension> ::= <mapping_extension_key> <scoped_identifier_list>
    <mapping_extension_key> ::= 'inherits' | 'merges' | 'disjuncts'
    <when> ::= 'when' <expression_block>
    <where> ::= 'where' <expression_block>
    <mapping_refinement> ::= 'refines' <scoped_identifier_list>
    <mapping_body> ::= <init_section>? <population_section>? <end_section>?
    <init_section> ::= 'init' <expression_block>
    <population_section> ::= <expression_list>

    'population' <expression_block>
    <end_section> ::= 'end' <expression_block>

    // Expressions

    <expression> ::= <assign_exp>

    <let_exp>
    <var_init_exp>

    <assign_exp> ::= <implies_exp>

    <unary_exp> <assign_op> <expression> <default_val>?
    <unary_exp> <assign_op> <expression_block> <default_val>?

    <assign_op> := ':=' | '::=' | '+=' | '-='

    <default_val> ::= 'default' <assign_exp>

    <implies_exp> ::= <or_exp>

    <implies_exp> 'implies' <or_exp>

    <or_exp> ::= <and_exp>

    <or_exp> <or_op> <and_exp>

    <or_op> ::= 'or' | 'xor'

    <and_exp> ::= <cmp_exp>

    <and_exp> 'and' <cmp_exp>

    <cmp_exp> ::= <additive_exp>

    <cmp_exp> <cmp_op> <additive_exp>

    <cmp_op> ::= '=' | '==' | '<>' | '<' | '>' | '<=' | '>='

    <additive_exp> ::= <mult_exp>

    <additive_exp> <add_op> <mult_exp>

    <add_op> ::= '+' | '-'

    <mult_exp> ::= <unary_exp>

    <mult_exp> <mult_op> <unary_exp>

    <mult_op> ::= '*' | '/' | '%'

    <unary_exp> ::= <postfix_exp>

    <unary_op> <unary_exp>

    <unary_op> ::= '-' | 'not' | '#' | '##' | '*'

    <postfix_exp> ::= <primary_exp>

    <postfix_exp> '(' <arg_list>? ')'
    <postfix_exp> '!'? '[' <declarator_vsep>? <expression> ']'
    <postfix_exp> <access_op>
    (<scoped_identifier>
    <iterator_exp> <block_exp>
    <control_exp> <rule_call_exp>)
    <postfix_exp> <resolve_exp>
    <postfix_exp> <resolve_in_exp>

    <declarator_vsep> ::= <simple_declarator> '|'
    <multi_declarator_vsep> ::= <simple_declarator_list> '|'

    <resolve_exp> ::= <resolve_key> '(' <resolve_condition>? ')'
    <resolve_condition> ::= <declarator> ('|' <expression>)?
    <resolve_op> ::= 'late'? <resolve_kind>
    <resolve_kind> ::= 'resolve' | 'resolveone' | 'invresolve' | 'invresolveone'

    <resolve_in_exp> ::= <resolve_in_key> '(' <scoped_identifier>
    (',' <resolve_condition>)?')'
    <resolve_in_op> ::= 'late'? <resolve_in_kind>
    <resolve_in_kind> ::= 'resolveIn' | 'resolveoneIn' | 'invresolveIn' | 'invresolveoneIn'

    <access_op> ::= '.' | '>' | '!>'

    <primary_exp> ::= <literal>

    <scoped_identifier>
    <if_exp>
    <block_exp>
    <control_exp>
    <rule_call_exp>
    <quit_exp>
    <try_exp>
    <raise_exp>
    <assert_exp>
    <log_exp>
    '(' <expression> ')'

    <literal> ::= <literal_simple>

    <literal_complex>

    <literal_simple> ::= <INTEGER> | <FLOAT> | <STRING>

    'true' 'false' 'unlimited' 'null'

    <literal_complex> ::= <literal_collection>

    <literal_tuple>
    <literal_dict>

    <literal_collection> ::= <collection_key> '

    {' <collection_item_list>? '}

    '

    <literal_tuple> ::= 'Tuple' '

    {' <tuple_item_list>? '}

    '

    <literal_dict> ::= 'Dict' '

    {' <dict_item_list>? '}

    '

    <collection_item_list> ::= <expression_comma_list>
    <tuple_item_list> ::= <declarator_list>
    <dict_item_list> ::= <dict_item> (',' <dict_item>)*
    <dict_item> ::= <literal_simple> '=' <expression>

    <if_exp> ::= 'if' <expression> <then_part>
    <elif_part>* <else_part>? 'endif'
    <then_part> ::= 'then' <if_body>
    <elif_part> ::= 'elif' <if_body>
    <else_part> ::= 'else' <if_body>
    <if_body> ::= <expression> | <expression_block>

    <iterator_exp> ::= <simple_iterator_op> '(' <declarator_vsep>? <expression> ')'

    <multi_iterator_op> '(' <multi_declarator_vsep>? <expression> ')'
    <iterate_exp>

    <simple_iterator_op> ::= 'reject' | 'select' | 'collect' | 'exists'

    'one' 'any' 'isUnique' 'collectNested'
    'sortedBy' 'xselect' 'xcollect'
    'selectOne' 'collectOne'
    'collectselect' 'collectselectOne'

    <multi_iterator_op> ::= 'forAll'

    <iterate_exp> ::= 'iterate' '(' <declarator_list> ';'
    <declarator> '|' <expression> ')'

    <iter_declarator> ::= <declarator>
    <iter_declarator_list> ::= <declarator_list>

    <block_exp> ::= (<object_exp> | <do_exp> | <switch_exp>)

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

    <do_exp> ::= 'do' <expression_block>

    <switch_exp> ::= 'switch' ('(' <iter_declarator> ')')? <switch_body>
    <switch_body> ::= '

    {' <switch_alt>+ <switch_else>? '}

    '
    <switch_alt> ::= '(' <expression> ')' '?' <expression> ';'
    <switch_else> ::= 'else' '?' <expression> ';'

    <control_exp> ::= (<while_exp> | <compute_exp> | <for_exp>)

    <while_exp> ::= 'while' '(' (<declarator> ';')? <expression> ')'
    <expression_block>
    <compute_exp> ::= 'compute' '(' <declarator> ')' <expression_block>
    <for_exp> ::= ('forEach' | 'forOne') '(' <iter_declarator_list>
    (';' <declarator>)? ('|' <expression>)? ')' <expression_block>

    <rule_call_exp> ::= ('map' | 'xmap' | 'new' )
    ('(' <declarator> ')')? <scoped_identifier>

    <let_exp> ::= 'let' <declarator_list> 'in' <expression>

    <var_init_exp> ::= 'var' <declarator>

    'var' '(' <declarator_list> ')'

    <quit_exp> ::= 'break' | 'continue' | <return_exp>)

    <return_exp> ::= 'return' ('(' <expression> ')')?

    <try_exp> ::= 'try' <expression_block> <except>+

    <except> ::= 'except' '(' <scoped_identifier_list> ')' <expression_block>

    <raise_exp> ::= 'raise' <scoped_identifier> ('(' <arg_list>? ')')?
    <arg_list> ::= <expression_comma_list>

    <assert_exp> ::= 'assert' <identifier>? '(' <expression> ')'
    ( 'with' <log_exp> )?

    <log_exp> ::= 'log' '(' <arg_list> ')' ('when' <expression>)?

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

rules for solving type identifiers are missing in the QVTOperational syntax

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

    ISSUE: The rules for solving type identifiers are missing in the QVTOperational syntax.

    The resolution rules when referencing types identifiers is missing in the
    QVTOperational syntax. For instance it is not clear weather unqualified type references
    should first be searched in the modeltype packages or in the transformation module.

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

    Add a new sub-section 8.4.7 (after sub-section 8.4.6 BNF) named "Solving type identifiers" with the following content:

    When referring to a type within an operational transformation definition it is possible to either qualify the type name with a model type or a package name, or, alternatively, leave the name of the type unqualified. In the latter case, a list of rules applies to resolve the symbol into the denoted type. If the resolution rule provides more than one result the specification is erroneous.

    • Firstly a type definition existing at the level of the current module (a transformation or a library) is searched.
    • In not found, all the packages of the model types declared in the module are recursively visited to found a type with the same name.
  • Updated: Fri, 6 Mar 2015 20:54 GMT

Relations language should support "default assignments"

  • Key: QVT-7
  • Legacy Issue Number: 10785
  • Status: closed  
  • Source: TCS ( Sreedhar Reddy)
  • Summary:

    Relations language should also support the 'default assignments' feature supported by
    the core language. This feature allows default values to be specified for the variables of
    an enforced target domain. Default assignments do not play a role in checking.

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

    Update the relations meta model in Fig 7.7 QVT Relation Package to add class 'RelationDomainAssignment'; class Assignment to have two associations to OclExpression - 'variable' and 'value'; class RelationDomain to have the association 'defaultAssignment' with class Assignment. Add the following text description in section 7.11.3.

    Add the following to the description of class RelationDomain.
    In bidirectional relations, sometimes it is not be possible to automatically compute the values required to enforce a relation in the reverse direction. This can be addressed by allowing a domain to specify default value assignments for its variables. The default assignments are executed only during enforcement and the values they assign must be capable of satisfying the relationship condition. Default assignments do not play a role in checking.

    Associations
    defaultAssignment : RelationDomainAssignment [0..*] Composes - the assignments that set default values for the variables of the domain that are required for its enforcement.

    Class RelationDomainAssignment
    A relation domain assignment sets the value of a domain variable by evaluating the associated expression in the context of a relation.

    Associations
    variable : Variable [1] - the variable being assigned
    valueExp : OclExpression [1] Composes - the expression that provides the value of the variable.

    Concrete syntax:
    Extend the production of <domain> with ['default_values' '

    {' (<assignmentExp>)+ '}

    ']
    <assignmentExp> ::= <identifier> '=' <OclExpressionCS> ';'

    The updated grammar is given in Appendix A of this report. This should replace the grammar given in section 7.13.

    Discussion:

    To see how this feature helps, let's consider the following bi-directional relation:

    top relation AttributeToColumn
    {
    n,utyp,rtyp : String;

    enforce domain uml
    a:Attribute

    { name = n, type = utyp }

    default_values

    { utyp = SqlToUmlDataType(rtyp); }

    ;

    enforce domain rdbms
    c:Column

    { name = n, dataType = rtyp }

    ;

    where

    { rtyp = UmlToSqlDataType(utyp); }

    }

    This relation uses a function in its where clause to compute a database type from an uml type. This works fine when the relation is enforced in the direction of 'rdbms'. It also works fine in 'checkonly' mode. However it does not work when the relation is enforced in the direction of 'uml' as the function 'UmlToSqlDataType' cannot be used to compute the uml type from the database type. We can solve this problem by using the default values section where we put an assignment that computes the required value for the uml domain.

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

Relations language

  • Key: QVT-6
  • Legacy Issue Number: 10784
  • Status: closed  
  • Source: TCS ( Sreedhar Reddy)
  • Summary:

    Relations language: It appears redundant to have three different collection template
    expressions, viz. enumeration, comprehension and member selection. They can be unified into
    one expression. Suppose we have an extended member selection expression such as
    the following:
    <collectionTemplate> ::= [<identifier>] ':' <CollectionTypeIdentifierCS>
    '(' <TypeCS> ')'
    ['

    {' <memberSelection> '}

    ']

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

    Enumeration can be specified as a collection of members to be matched:
    e.g. cs:Set(Class)

    { c1, c2, c3 ++ _ }


    Comprehension can be specified as a condition that each member of the collection
    must satisfy:
    e.g. cs:Set(Class)

    { cs->forAll(c| <condition>) }

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

    Suggestion accepted and reflected in the meta model and concrete syntax as follows:

    Meta model:
    Make the following changes to class CollectionTemplateExp in Figure 7.6 - QVT Template Package:
    · Rename the associations 'part' and 'match' to 'member' and 'rest'.
    · Make the 'member' association ordered and set its cardinality to '1..*'; set the cardinality of 'rest' to '1'.

    Modify the text explanation of CollectionTemplateExp in section 7.11.2.3 as follows:

    7.11.2.3 CollectionTemplateExp
    A collection template expression specifies a pattern that matches a collection of elements.
    It specifies a set of member expressions that match individual elements, and a collection-typed variable that matches the rest of the collection. The type of collection that a template matches is given by the referred collection type. If the referred collection type is a sequence then the matching member elements must be present at the head of the sequence in the order specified by the member expressions.

    Superclasses
    TemplateExp

    Associations
    referredCollectionType : CollectionType [1]
    The type of the collection that is being specified. It can be any of the EMOF
    collection types such as Set, Sequence, OrderedSet, etc.

    member : OclExpression [1..*]
    The expressions that the elements of the collection must have matches for. A
    special variable _ may be used to indicate that any arbitrary element may be
    matched and ignored.

    rest : OclExpression [1]
    The variable that the rest of the collection (i.e. excluding elements matched by
    member expressions) must match. A special variable _ may be used to indicate that
    any arbitrary collection may be matched and ignored.

    Concrete syntax:
    <collectionTemplate> ::= [<identifier>] ':' <CollectionTypeIdentifierCS>
    '(' <TypeCS> ')'
    ['

    {' <memberSelection> '}

    ']

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

    The updated grammar is given in Appendix A of this report. This replaces the grammar given in section 7.13.

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

Identifiers syntax to avoid reserved keywords

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

    In order not to define new keywords as reserved:
    Define:

    <relationIdentifier> ::= 'checkonly'
    <relationIdentifier> ::= 'domain'
    <relationIdentifier> ::= 'enforce'
    <relationIdentifier> ::= 'extends'
    <relationIdentifier> ::= 'implementedBy'
    <relationIdentifier> ::= 'import'
    <relationIdentifier> ::= 'key'
    <relationIdentifier> ::= 'overrides'
    <relationIdentifier> ::= 'primitive'
    <relationIdentifier> ::= 'query'
    <relationIdentifier> ::= 'relation'
    <relationIdentifier> ::= 'top'
    <relationIdentifier> ::= 'transformation'
    <relationIdentifier> ::= 'when'
    <relationIdentifier> ::= 'where'

    <pathNameCS> ::= <relationIdentifier> – extending OCL to allowing QVTr keywords in expressions

    <simpleNameCS> ::= <relationIdentifier> – extending OCL to allowing QVTr keywords in expressions

    <identifier> ::= IDENTIFIER – all non keyword 'alphanumerics'
    <identifier> ::= <relationIdentifier>
    <identifier> ::= 'self'

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

    Resolution: No change

    Remark:
    This issue is related to issue 10603. Please refer to the resolution given for issue 10603.
    As per that resolution the grammar will explicitly identify and list the keywords. Keywords may be implemented in one of several ways and we do not think the standard should mandate an implementation choice.

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

Collection Type syntax ambiguities

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

    In order to avoid ambiguities on collectionTypeCS:

    In <objectTemplate >
    Replace: <typeCS>
    By: <objectTypeCS >
    objectTypeCS ::= tupleTypeCS | primitiveTypeCS | pathNameCS

    This disambiguates. I don't know whether the residual case of

    ':' <colectionTypeCS> '{' ...

    without an identifier has any meaning. If it does, it would seem like a collection
    rather than object behaviour.

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

    Replace the content of section 7.13.1 and 7.13.2 by the new content given in Appendix A of this report. This new content is the updated grammar correcting typos and other mistakes.

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

Query result syntax

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

    The grammar defines a list of named and typed input parameters and a list of named and typed output results.
    The example uses the conventional named and typed input parameters and a result type, which may be a set.
    Since the latter is what an Operation does, I presume that the QVTrelational concrete syntax is in error.

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

    Replace the content of section 7.13.1 and 7.13.2 by the new content given in Appendix A of this report. This new content is the updated grammar correcting typos and other mistakes.

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

Problem with Domain syntax

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

    In order to accommodate top level collection templates in domains

    In <domain>
    Replace: [ <identifier> ] ':' <typeCS>'

    {' <propertyTemplate>* '}

    '
    By: <templateCS>

    (or rather <template> if the missing CS is left omitted)

    ?? since any TemplateExp can have a where, should the [ '

    {' <oclExpressionCS> '}

    ' ]
    in <domain> be part of <template> instead ??

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

    Replace the content of section 7.13.1 and 7.13.2 by the new content given in Appendix A of this report. This new content is the updated grammar correcting typos and other mistakes.

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

RelationalCallExp missing

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

    Since this is missing from the specification, it is difficult to be sure what the semantics of
    type discrepancies are between invocation and definition. One perspective is that mis-matches
    correspond to overloaded pattern matches so that the first, best or any, or any distinct matches apply
    with a total type inconsistency being a silent error/behaviour. Another perspective is that
    like function calls, all implementation should derive from some abstract interface so that
    all invocations can be type checked against the abstract interface. I think we need some words.
    I prefer complinace with an abstract interface, and invocation of all distinct matches, so that
    when someone extends the transformation exuisting behaviours are not suppressed.

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

    Add class RelationCallExp in Fig 7.7 QVTRelation package and the following text in section 7.11.3

    RelationCallExp
    A relation call expression specifies the invocation of a relation. A relation may be invoked from the when or where clause of another relation. The expression contains a list of argument expressions corresponding to the domains of the relation. The number and types of the arguments must match the number of domains and types of the root variables of the domains respectively.

    Superclasses
    OclExpression
    Associations
    argument : OclExpression [2..*]

    {Composes, Ordered}

    - Arguments to the relation call.
    referredRelation : Relation [1] - The relation being invoked.

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