Community
Participate
Working Groups
QVTd tooling currently uses the OCL Standard Library. Additional functionality may be required (certainly is for QVTo) so we should be using a QVTr/c Standard Library. Introduce it as an OCL extension to ensure that the tooling is extensible before we actually need it.
> Introduce it as an OCL extension This proves a little harder than expected forcing clarification of imports. The minimal QVTd library support for Model::objectsOfKind(OclType) and Transformation::modelFor(TypedModel) extends qvtbase::Transformation and pivot::Model. So as a minimum, a library may extend two packages. Easily achieved by interpreting "library name : nsPfx = 'nsURI'" as a merge into "nsURI' rather than a document 'nsURI'. The library extends so we have to reference the Java Pivot metamodel and create a Java QVTbase metamodel. The QVTbase metamodel has unnavigable opposites terminating in the Pivot model, so the missing opposites need creating. Resolveable by creating a merge contribution rather than modifying the Pivot metamodel. See Bug 465433. The additional reference support requires useful extension to the GeneralOCLstdlib/GenerateMetamodel MWE2 scripts. OCL changes pushed to OCL master for M7. QVTbaseLibrary pushed to QVTd master for M7.
(In reply to Ed Willink from comment #1) > The minimal QVTd library support for Model::objectsOfKind(OclType) and > Transformation::modelFor(TypedModel) extends qvtbase::Transformation and > pivot::Model. But these are M2 classes. The required QVTo functionality is for M1 classes. (OMG Issue raised for the confusion re-use of names at M1/M2 without clear namespaces.)
(In reply to Ed Willink from comment #2) > But these are M2 classes. The required QVTo functionality is for M1 classes. > (OMG Issue raised for the confusion re-use of names at M1/M2 without clear > namespaces.) http://solitaire.omg.org/browse/QVT13-52
