Community
Participate
Working Groups
XMI persistence for the pivot is relatively straightforward; just needs localisation of specialized orphan types. XMI persistence of Complete OCL is very dubious because of the number of dangling references. Should the pivot always be persusted as a folder of XMIs for the ResourceSet? Should the pivot be cleanly serialized with polymorphic references back to the original Ecore/UML/...? Probably need SaveAs actions for at least Complete OCL. OCL COnsole Save Expression deserves a review.
The most useful Complete OCL XMI persistence use case is probably to save the full pivot model in a single file with all contributions folded so that a consumer does not need to worry about the diverse contribution sources. What is 'all'? If for instance there is a reference to an EString, then that could probably be preserved as an outgoing reference, rather than pulling in the whole of the Ecore model. Except that if Complete OCL adds an operation to EString the variant EString must be saved and consequently the whole of Ecore. So the Complete OCL save should - fold all packages and types into the primary model(s) - allocate modified URIs to all packages containing modified content - allocate modified URIs to all packages transitively referencing modified content - save all modified URIs A more specialized Complete OCL XMI persistence use case may save the full pivot model and preserve the contribution diversity. This will require the inter-package, inter-type relationships to be modeled as explicit properties rather than secret eAdapters.
How will the user use modified URIs? If they are each in different files, there is a risk that a consuming tool may require an import for each, which will be really tedious, particularly if the modified URIs are cryptic. If they are in a single multi-rooted file, it is doubtful that this is legal OMG-wise, and there is a certainty that some consuming tools will malfunction. So that leaves a re-rooted single file (which could be multiple files via cross-containment for huge applications). So the user specifies the output file name and/or root nsURI and/or root package name for creation and again for consumption. For a usage enhancing ecore's EDate, the enhanced EDate might be Completed::ecore::EDate that should be able to co-exist with the original ecore::EDate in a multi-model transformation tool; particularly if aliases/model-names ensure that original ecore has a clearly distinct name from the Completed::ecore::EDate that might be accessible as just ecore::EDate or EDate with respect to some context in which Completed::... is the default. To guarantee uniqueness and predictability all original nsURIs need to be replaced by the concatenation of the root nsURI and the original nsURI.
These problems are all solved by the pivot and is ".oclas" extension.
