[mdt-ocl.dev] OCL delegate namespaces

[Ed Willink <ed@xxxxxxxxxxxxx>]

Hi

While waiting for clues on OCL UML editor integration I'm looking at 
making the OCL Console and generate Validate use the new pivot model 
functionality.

This mainly requires redirecting the OCL delegates, so for API 
compatibility Ecore files with

"http://www.eclipse.org/emf/2002/Ecore/OCL"; annotations feed OCL to the 
old LPG parser and evaluator

"http://www.eclipse.org/emf/2002/Ecore/OCL/Pivot"; annotations feed OCL 
to the new Xtext parser and evaluator

This gives the API compatibility that we require for 3.1.0, although 
"http://www.eclipse.org/emf/2002/Ecore/OCL/Pivot"; does not include 
"examples"; suggestions?

By placing all the new code in org.eclipse.ocl.examples.pivot etc we 
avoid the Xtext 2.0 problem of changing API on an established namespace, 
and certainly in 4.0 we only promote org.eclipse.ocl.examples.pivot to 
org.eclipse.ocl.pivot. org.eclipse.ocl and org.eclipse.ocl.ecore can 
remain for many releases if really necessary.

To the point:

In 4.0, do we redirect the delegates so that

"http://www.eclipse.org/emf/2002/Ecore/OCL";

accesses the new functionality, which should be compatible on the 
external API?

If we don't, all "http://www.eclipse.org/emf/2002/Ecore/OCL"; must be 
changed manually or by some new tool.

If we do, all "http://www.eclipse.org/emf/2002/Ecore/OCL/Pivot"; can be 
changed manually or by some new tool or by a compatibility support.

My preference is to redirect in 4.0 so that 
"http://www.eclipse.org/emf/2002/Ecore/OCL/Pivot"; has limited liftetime.

Should we add "http://www.eclipse.org/emf/2002/Ecore/OCL/3.1"; so that 
there is a delegate mapping that is more explicit?

    Regards

        Ed Willink