Issue 19664: QVTr Multi-root match (qvt-rtf) Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk) Nature: Enhancement Severity: Significant Summary: The QVTr AS and CS permit only a single pattern to be matched in the input (and output) domains. QVTc permits multi-matches. This can be worked around with nested collections as demonstrated by RDomainToMBottomPredicateForEnforcement in RelToCore remainingUnBoundDomainVars: Set(essentialocl::Variable); predicatesWithVarBindings:Set(qvtbase::Predicate); domain relations rdtVarsSeq:Sequence(Set(Element)) { rdtSet:Set(Element) { r:Relation{}, rd:RelationDomain{}, te:ObjectTemplateExp {bindsTo = v:Variable {}} ++ _ } ++ _ }; rdtVarsSeq->at(2) = predicatesWithoutVarBindings; rdtVarsSeq->at(3) = unboundDomainVars; The above is hard to read and uses nested collections in ways that are claimed to be unsupported. Much simpler to just write: domain relations r:Relation{}, rd:RelationDomain{}, te:ObjectTemplateExp {bindsTo = v:Variable {}}, predicatesWithVarBindings:Set(qvtbase::Predicate) {}, remainingUnBoundDomainVars: Set(essentialocl::Variable) {} ; Suggest in the AS, RelationDomain.pattern changes to RelationDomain.patterns, RelationDomain.rootVariable moves to DomainPattern.rootVariable. Suggest in the DomainCS CS, "pattern=DomainPatternCS" changes to "patterns+=DomainPatternCS (',' patterns+=DomainPatternCS)*" As a consequence additional variables may be passed in a RelationCallExp. These can still be in rootVariable order. Resolution: QVTr Multi-root match The QVTr AS and CS permit only a single pattern to be matched in the input (and output) domains. QVTc permits multi-matches. This can be worked around with nested collections as demonstrated by RDomainToMBottomPredicateForEnforcement in RelToCore remainingUnBoundDomainVars: Set(essentialocl::Variable); predicatesWithVarBindings:Set(qvtbase::Predicate); domain relations rdtVarsSeq:Sequence(Set(Element)) { rdtSet:Set(Element) { r:Relation{}, rd:RelationDomain{}, te:ObjectTemplateExp {bindsTo = v:Variable {}} ++ _ } ++ _ }; rdtVarsSeq->at(2) = predicatesWithoutVarBindings; rdtVarsSeq->at(3) = unboundDomainVars; The above is hard to read and uses nested collections in ways that are claimed to be unsupported. Much simpler to just write: domain relations r:Relation{}, rd:RelationDomain{}, te:ObjectTemplateExp {bindsTo = v:Variable {}}, predicatesWithVarBindings:Set(qvtbase::Predicate) {}, remainingUnBoundDomainVars: Set(essentialocl::Variable) {} ; Suggest in the AS, RelationDomain.pattern changes to RelationDomain.patterns, RelationDomain.rootVariable moves to DomainPattern.rootVariable. Suggest in the DomainCS CS, "pattern=DomainPatternCS" changes to "patterns+=DomainPatternCS (',' patterns+=DomainPatternCS)*" As a consequence additional variables may be passed in a RelationCallExp. These can still be in rootVariable order. Discussion This seems to be a completely unnecessary restriction that caused the author of relToCore significant difficulties. The only downside seems to be a slight increase in complexity of a RelationCallExp. No longer exactly one argument per domain, but linearizing the roots per domain is not exactly hard. (The spelling in the discussion is that of the Eclipse QVTr prototype. Changing pattern to patterns is not appropriate for QVT1.x where property names tend to be simple-singulars. Perhaps a change to owned-plurals and so ownedPatterns may be appropriate for QVT 2.0.) Exploiting this in relToCore should wait until an executable version has been debugged. Revised Text: In the QVTr models and Fig 7.8 change RelationDomain::pattern : DomainPattern[0..1] to RelationDomain::pattern : DomainPattern[*] {ordered} and RelationDomain::rootVariable: Variable[1] to RelationDomain::rootVariable: Variable[+] {ordered} In 7.11.3.3 RelationDomain correct A relation domain has aone or more distinguished typed variablevariables called the root variablevariables that can be matched in a model of a given model type. A relation domain specifies a set of model elements of interest by means of a domain pattern, which can be viewed as a graph of object nodes, their properties and association links, with aone or more distinguished root nodenodes that isare bound to the corresponding root variable of the relation domain. and rootVariable: Variable[1+] {ordered} The distinguished typed variablevariables of the relation domain that can be matched in a model of a given model type. and pattern: DomainPattern [0..1] {composes ,ordered} The domain patternpatterns that specifiesspecify the model elements of the relation domain. The root object template expression (i.e., the root node) of theeach domain pattern must be bound to the corresponding root variable of the relation domain. In 7.11.3.8 replace The number and types of the arguments must match the number of domains and types of the root variables of the domains respectively. by The number and types of the arguments must match the total number and types of the root variables of the domains. The arguments are ordered firstly by the order of the domains in the called relation, and then by the order of the patterns of each domain. In 7.13.5 replace <domain> ::= [<checkEnforceQualifier>] 'domain' <modelId> <template> by <domain> ::= [<checkEnforceQualifier>] 'domain' <modelId> <template> (',' <template>)* Actions taken: November 28, 2014: received issue December 22, 2015: Resolved March 29, 2016: closed issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 28 Nov 2014 07:40:22 -0500 To: Subject: Issue/Bug Report ******************************************************************************* Name: Ed Willink Employer: mailFrom: ed@willink.me.uk Terms_Agreement: Specification: QVT 1.2 Section: - FormalNumber: - Version: - Doc_Year: Year Doc_Month: Month Doc_Day: Day Page: - Title: QVTr Multi-root match Nature: Enhancement Severity: Significant CODE: 3TMw8 B1: Report Issue Remote Name: edwillink.plus.com Remote User: HTTP User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 Time: 07:40 AM Description: The QVTr AS and CS permit only a single pattern to be matched in the input (and output) domains. QVTc permits multi-matches. This can be worked around with nested collections as demonstrated by RDomainToMBottomPredicateForEnforcement in RelToCore remainingUnBoundDomainVars: Set(essentialocl::Variable); predicatesWithVarBindings:Set(qvtbase::Predicate); domain relations rdtVarsSeq:Sequence(Set(Element)) { rdtSet:Set(Element) { r:Relation{}, rd:RelationDomain{}, te:ObjectTemplateExp {bindsTo = v:Variable {}} ++ _ } ++ _ }; rdtVarsSeq->at(2) = predicatesWithoutVarBindings; rdtVarsSeq->at(3) = unboundDomainVars; The above is hard to read and uses nested collections in ways that are claimed to be unsupported. Much simpler to just write: domain relations r:Relation{}, rd:RelationDomain{}, te:ObjectTemplateExp {bindsTo = v:Variable {}}, predicatesWithVarBindings:Set(qvtbase::Predicate) {}, remainingUnBoundDomainVars: Set(essentialocl::Variable) {} ; Suggest in the AS, RelationDomain.pattern changes to RelationDomain.patterns, RelationDomain.rootVariable moves to DomainPattern.rootVariable. Suggest in the DomainCS CS, "pattern=DomainPatternCS" changes to "patterns+=DomainPatternCS (',' patterns+=DomainPatternCS)*" As a consequence additional variables may be passed in a RelationCallExp. These can still be in rootVariable order.