View source for MDT/OCL Limitations

== Limitations ==

The Ecore and UML binding have evolved with OCL from 1.x to 2.0, 2.2 and 2.3. They have a substantial legacy usage that is difficult to change, so as problems with OCL 2.3 are identified, it is not clear whether they can be fixed for existing clients.

The new Pivot binding prototypes solutions to many problems and so may be considered a candidate for OCL 2.5.

This page identifies the differences between the Ecore (and UML) bindings and the Pivot binding and where appropriate significant Bugzillas that have been WONTFIXed in regard to the Ecore binding and the OCL 2.3 specification.

{| border="1"
! Facility !! Bugzillas !! Commentary 
|-
| Operation Lookup || [https://bugs.eclipse.org/339952 339952] ||
OCL 2.3 does not specify use of inherited operations.
The Ecore binding uses a local operation in preference to an inherited operation.
The Pivot binding selects the best static match of all inherited operations for subsequent dynamic dispatch.
|-
| Operation Dispatch || [https://bugs.eclipse.org/367822 367822] || 
OCL 2.3 does not specify dynamic dispatch of operations.
The Ecore binding invokes the static operation regardless of overriding.
The Pivot binding selects the dynamic overload.
|-
| Iteration Reference || ||
OCL 2.3's AST references iterations by name. Iterations are therefore unmodeled in the Ecore binding.
The Pivot binding introduces a library model allowing iterations to be referenced by e.g. IterationExp.referredIteration.
|-
| Complementary Feature Reference || ||
OCL 2.3 does not specify how a feature defined in a Complete OCL document is modeled for reference within the AST. They cannot be referenced in an Ecore binding XMI serialization.
The Pivot binding creates a complementary model that is logically merged; complementary features are referenceable.
|-
| Type references || ||
OCL 2.3 does not specify how external models are introduced into the OCL expression environment. The Ecore binding is unable to reference external models in expressions such as oclIsKindOf(SomeType). The Pivot binding introduces a URI form of qualification allowing oclIsKindOf(_'http:/...'::SomeType). 
|-
| Model references || ||
OCL 2.3 does not specify how external models are introduced into an OCL document. The Ecore binding therefore relies on either Java API or the OCL Model Registry to provide the missing context. The Pivot binding introduces an 'import' and a 'library' syntax to specify external models.
|-
| Value Equality || ||
OCL 2.3 specifies equality based on object identity; no OCL implementation respects this aspect of the specification since values must clearly be equal based on value not object identity. The Ecore binding uses Java objects and so treats real and integer values as distinct. The Pivot binding uses value equality for data types and so real and integer values may be equal and Sets containing a mix of integer and real values do not have duplicate numeric values.
|-
| Value polymorphism || ||
OCL 2.3 specifies a very incomplete hierarchy of polymorphic Value classes; OCL 2.3 does not require implementations to use them. The Ecore binding ignores this aspect of the specification and uses Java classes and collections directly; the Ecore binding has some subtle malfunctions on deep collection operations where equality is inconsistent. The Pivot binding implements a consistent polymorphic hierarchy of Value classes resulting in semantic consistency and extensibility.
|-
| Numeric accuracy || ||
OCL 2.3 specifies unlimited numeric precision. The Ecore binding ignores this aspect of the specification and uses Java's Integer and Double; the code has evolved to have significant support for Long and some tolerance of BigDecimal, BigInteger, Float and Short. The Pivot binding implements a consistent polymorphic hierarchy of Value classes with alternate Integer/Long/BigInteger equivalents that grow as necessary.
|-
| Reflection || ||
OCL 2.3 specifies oclType() with very restricted inconsistent capability. The Ecore binding does not implement oclType(); EObject::eClass() can be used to similar effect but with incorrect spelling of UML meta-class names. The Pivot binding implements a fully reflective oclType() so that OCL expressions can navigate the meta-model using 'UML' names.
|-
| UML alignment|| ||
The OCL 2.3 specification of UML-alignment is aspirational; some parts are actually aligned to UML 1.x. The Ecore binding deviates from UML alignment by using Ecore as its meta-model. The Pivot binding uses a Pivot meta-model that merges UML and OCL classes.
|-
| Library Model || ||
OCL 2.3 specifies the OCL Standard Library without a model. The Ecore binding provides a partial model accompanied by bespoke Java code. The Pivot binding provides a modeled library, and an associated editor; the library model can be replaced or extended.
|-
| Templates || ||
The Pivot binding Library Model uses UML template types to model Collections and UML template operations to model operations such as Collection::product.
|-
| Lambda Types || ||
The Pivot binding Library Model uses Lambda Types to model the body of an iteration.
|-
| Type Constructors || ||
The Pivot binding Library Model introduces a Tuple-like syntax to create immutable Class and DataType instances.
|}