|
|
|
| Re: oclxmi with ocl:///-URLs fails to load [message #1222474 is a reply to message #1222453] |
Fri, 20 December 2013 14:13  |
 Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi
I was surprised at the appearance of *.oclxmi, since my suspicion was
that it was more of a future intention once the problems of XMI
serialization for the OCL specification are resolved.
Perhaps it was used by the old IMP-based editor that migrated out of the
UMLX gtraphical project, but which has long since been superseded by the
Xtext editors in the OCL Examples and Editors add-on. These use a pivot
model to abstract away from Ecore/UML details. This is serializable and
at last loadable as *.oclas files. I chose 'Abstract Syntax' to avoid
the ambiguity as to whether it was the AS or CS in XMI and because the
oclxmi extension seems to be registered already.
Opening your file in the Sample Reflective Editor passes the acid test
that is loadable (apart from two containment validation bugs in 'your'
model).
One of the problems with OCL serialization as XMI arises in where to
contain synthesized types such as Set(String) and Tuple{name:String}.
The classic OCL with Ecore support creates these all as shared orphans
and requires the user of an OCL AST to reparent them. The
ocl:///oclenv.ecore#/1/OrderedSet(BOpParameter) is the consequence of a
failure to reparent the synthetic OrderedSet(BOpParameter) type before
saving. From the org.eclipse.ocl.AbstractTypeResolver code:
/**
* Creates the resource that persists my generated types.
Subclasses requiring
* persistence must override this default implementation, as it
creates a
* resource that does not support persistence and does not have a
useful URI.
* A subclass could even find some other resource, such as the model on
* which constraints are being parsed, if desired.
*
* @return the new resource
*/
protected Resource createResource() {
return new ResourceImpl(URI.createURI("ocl:///oclenv"));
//$NON-NLS-1$
}
(The Ecore and UML overrides are not helpful.)
The new pivot-based support creates an additional "$$" EPackage in which
all orphans are cloned prior to saving so that references to them can be
terminated locally. The equivalent junk URI is
http://www.eclipse.org/ocl/3.1.0/orphanage#... but it exists and is
provided as part of the saved file.
If you really want to play with OCL at the XMI level, I recommend that
you use the pivot-based support in the examples plugins. You can create
an XMI file by using the right button SaveAS within the Complete OCL
editor. The XMI is not yet stable, but it solves many of the problems.
For stability stick to OCL text interchange.
If you really want to see the original OCL, 59 lines of XMI is not hard
to reverse compile. But more realistically you want to track down the
bad production mechanism.
Regards
Ed Willink
On 20/12/2013 13:10, Bastian Ulke wrote:
> Sorry for that - you can find it attached to this message.
> I'm actually wondring if the oclxmi files are supposed to be opened
> and edited with some graphic editor. Am I right, that this is not the
> case?
|
|
|
Powered by
FUDForum. Page generated in 0.02410 seconds
] 
Search
Help
Register
Login
Home
