Issue 15523: QVTr already has queries but they are much less user friendly than e.g. MOFM2T's equivelent (qvt-rtf)
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity: 
Summary: QVTr already has queries but they are much less user friendly than e.g. MOFM2T's equivelent for which the first parameter is a hidden self, or indeed QVTo.

Perhaps something closer to Complete OCL would do, allowing def'd attributes or operations.

Resolution: QVTr already has queries but they are much less user friendly than e.g. MOFM2T's equivelent

QVTr already has queries but they are much less user friendly than e.g. MOFM2T's equivelent for which the first parameter is a hidden self, or indeed QVTo.

Perhaps something closer to Complete OCL would do, allowing def'd attributes or operations.

Discussion

QVTo has contextual helpers.

Syntactically it is trivial for QVTc and QVTo to have contextual queries just by allowing a scoped rather than simple name for the query.

Semantically to avoid duuplicating QVTo AS irregularities we can use the synonym package merges for Complete OCL to make the implementation easy.
Revised Text: In 7.13.5 replace

<query> ::= 'query' <identifier>

by

<query> ::= 'query' <queryId>

and add

<queryId> ::= <PathNameCS>

In 9.18 replace

Query ::= 'query' QueryName '('

by

Query ::= 'query' QueryId '('

and add

QueryId ::= PathNameCS
Actions taken:
August 13, 2010: received issue
December 22, 2015: Resolved
March 29, 2016: closed issue
Discussion: 
Perhaps it is sufficient to allow a QVTr query to be invoked with its first argument as a syntactical
source rather than argument.
Disposition: Deferred
End of Annotations:=====
ubject: Fw: Derived properties in QVTr
To: Juergen Boldt <juergen@omg.org>
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
From: Maged Elaasar <melaasar@ca.ibm.com>
Date: Wed, 15 Sep 2010 14:34:10 -0400
X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at
 09/15/2010 14:34:24


This is one...

----- Forwarded by Maged Elaasar/Ottawa/IBM on 09/15/2010 02:33 PM -----

Ed Willink <ed@willink.me.uk> 
08/13/2010 12:00 PM
 

To 
Maged Elaasar/Ottawa/IBM@IBMCA 


cc 
qvt-rtf@omg.org 


Subject 
Re: Derived properties in QVTr 
  
 

Hi Maged

[Juergen: this is worth an Issue.]

QVTr already has queries but they are much less user friendly than e.g. MOFM2T's equivelent for which the first parameter is a hidden self, or indeed QVTo.

Perhaps something closer to Complete OCL would do, allowing def'd attributes or operations.

Regards

Ed Willink

On 13/08/2010 16:36, Maged Elaasar wrote: 

Hi All, I have a question on QVTr:

If I want to specify a uni-directional transformation using QVTr, is it ok to use "derived" properties in source domains' object templates? I guess since the transform is not meant to be run in the opposite direction, this will not create a problem?

If that is allowed, it would be a good additional feature of QVTr to allow the definition of new derived properties right in the transform, instead of having them only in the source metamodel.

For example

transform A (...) {

property Class::allSuperClass : Class {
self->closure(self.superClass) // closure might not be standard collection op but I used it just to demonstrate the point
}

relation B {
checkonly domain source c:Class {
allSuperClass = super:Class {...}
}
}

}

does this make sense?


Maged Elaasar, PhD Candidate
Senior Software Engineer, Rational Modeling Tools
IBM Representative@OMG, CAS Research Staff Member
IBM Canada, Ottawa Lab, +1 613 270 4651 



No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 9.0.851 / Virus Database: 271.1.1/3067 - Release Date: 08/12/10 19:34:00

 




 
pic19370.gif