QVT 1.3 RTF Avatar
  1. OMG Issue

QVT13 — QVTr: syntax mapping (correction to Issue 10646 resolution)

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

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

    {' metaModelIdListCS '}

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

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

    QVTr syntax mapping (correction to Issue 10646 resolution)

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

    {' metaModelIdListCS '}

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

    Discussion

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

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