Allow variable in/out files

[eclipse-qvt-oml-bot]

| --- | --- | | Bugzilla Link | 420585 | | Status | NEW | | Importance | P3 enhancement | | Reported | Oct 29, 2013 03:15 EDT | | Modified | Nov 05, 2013 04:40 EDT | | Reporter | Ed Willink |

Description

The OMG QVTo spec would appear to allow input files to be a Set(ECORE) rather than just ECORE as the model type.

Particularly for output this could be useful in allowing a transformation to create a data-dependent number of output files. Presumably the launch config will need to define some kind of output file name pattern that is reified with some name contribution from the specific output file.

[eclipse-qvt-oml-bot]

By Sergey Boyko on Nov 03, 2013 07:36

Technically QVTo specification does not allow this - transformation parameters are defined as ModelParameters which in turn have ModelType as type. And ModelType inherits from Class (not from Classifier).\ Here is the same inconsistency as with ObjectExp where actually Classifier was meant.

Another point is that OrederedSet(ECORE)/Sequence(ECORE) should be used. The order here is important. Comparing with transformation specification - "ordered set of model parameters forms the signature of the transformation".

[eclipse-qvt-oml-bot]

By Ed Willink on Nov 03, 2013 08:08

I don't doubt that the specification has limitations.

If we think this is a useful capability, we can prototype it and raise an issue to have the specification changed.

[eclipse-qvt-oml-bot]

By Sergey Boyko on Nov 04, 2013 04:40

(In reply to Ed Willink from comment #2)\

If we think this is a useful capability, we can prototype it and raise an issue to have the specification changed.

Agree. Some thoughts:

1. Must the variability be allowed only for 'out' model parameters or also for 'in' and 'inout'.

2. In case it'll be allowed for 'out' model parameters I think simple flat placing of a number of output files will be impractical. Most need some hierarchical output structure based on some additional attribute(s) of output models.

3. Workaround is very straightforward. Various number of output models can be stored in simple Ecore model with the class which owns single feature (containment or not) like 'content'. This 'content' can be of general EClass type. It's a user responsibility to place output models to different files.

[eclipse-qvt-oml-bot]

By Ed Willink on Nov 05, 2013 04:40

I was thinking about a transformation from a hierarchy of input files to a hierarchy of output files. Seems a pity that no QVT can do this and so it requires external complexities.

So I thought that may be an input might be a Dict(String,XXXX) to map the relative document URI to the model. The launch configuration could use an ANT style regex to populate the Dict. Not very nice.

Access to the document URI is a problem for all QVTs and OCL too. Perhaps there should at least be a getDocumentURI() API for a model allowing an ANT style launcher regex to just populate a Sequence(XXX) and leave hierarchy to user actions. Perhaps a Document object could provide a richer API for the external context of its contained model.

That could solve in/inout. For out, some new construct is needed to add a new Document/Model to a Sequence(XXX) with a specified document URI relative to the output URI defined by the launcher.