OCL should recognize the XML names of types and features

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 167266 | | Status | CLOSED WONTFIX | | Importance | P2 normal | | Reported | Dec 08, 2006 13:39 EDT | | Modified | May 27, 2011 02:47 EDT | | Version | 1.0.1 | | Reporter | Christian Damus |

Description

To support portability of OCL expressions between different Ecore implementations of the same metamodel, the OCL parser should be able to look up types and features by their XML names (which Ecore models would use to map the Java API names to the names prescribed by the standard schema).

For example, in the OCL metamodel itself, it should be possible to define

package ocl::expressions context OclExpression\
inv: ... /* constraint here */\
endpackage

instead of having to use the Java-friendly "OCLExpression" name.

[eclipse-ocl-bot]

By Christian Damus on Feb 15, 2008 10:14

Maged, if this looks like it could become a blocker for your XPath work, then we can see about prioritizing it for the 1.2 release.

[eclipse-ocl-bot]

By Ed Willink on Sep 25, 2009 16:14

The specific issue of the OclExpression spelling is an 'error' in the MDT OCL implementation listed amongst many others in bug 215110. As such this is a consistent error and so should not give Ecore portability issues. MDT OCL using Ecore is not compliant with OMG's EMOF at the AST level, so precise spelling of OclExpression is not mandatory. Changing the spelling of OclExpression would cause major and very overt API change and so does not seem to be justified.

The more general issue of the spelling of e.g. ">=" is addressed in bug 288694, though without an obvious solution.

Please comment on one of the above if this problem remains relevant.

[eclipse-ocl-bot]

By Ed Willink on May 27, 2011 02:47

Closing after over 18 months in resolved state.