El 14/09/2010 12:42, Scott escribió:
> If I use String.toLowerCase() in an OCL expression, at runtime I get:
>
> org.eclipse.ocl.SemanticException: Cannot find operation (toLowerCase())
> for the type (String)
>
> but no error from the OCLinEcore editor (as per the OCL spec).
>
> If I change to toLower(), it runs, but the editor marks it as an error,
> I assume there's no chance of EMF changing the name of their operation?
> Can you map the names?

Scott,

On the one hand, toLower() and toUpper() operations have been vaguely
defined/mentioned in an annex of the OCL specification (even in the old
OCL 2.0 specification ). In spite of the fact that they are still
mentioned in the said annex, they are now formally described in the new
OCL 2.2 specification, section 11.4.3

On the other hand, toLower() and toUpper() operations have been
supported by MDT/OCL since time ago (and considered as a non-standard
support see https://bugs.eclipse.org/bugs/show_bug.cgi?id=228839). When
the new Xtext editors were introduced, they probably were aligned to the
new string operations concrete syntax (toLowerCase() and toUpperCase())
while the syntax which is supported by the evaluator is the old one
(toLower() and toUpper()).

I see several problems here:

1. An OMG's issue is required to remove the toLower and toUpper mention
in the annex. Let us know if you prefer we report the issue to OMG.

2. Fix the MDT/OCL implementation. Let's wait Ed's opinion, but we could
have several no necessarily incompatible choices here:

a) In short time we could make Xtext editors support a deprecated
toLower() and toUpper() version.
b) In short time make a trick to map the new concrete syntax
toLowerCase() and toUpperCase() to the use old one.
c) In long time wait until the new model-driven oclstdlib is ready to be
exploited by the Xtext editors.

1 I will definitely submit this to the OMG, leave it to me.
2a Swapping an error marker for a warning would look better, happy to have a line through it until 2c
2b This would move the issue out of the users sight - my preference
2c A consistent implementation is of course best, but I think one of the above should be used in the meantime

The MDT/OCL parser continues to have 'traditional' behaviour that
anticipated a different OMG specification spelling. This behaviour is
hard encoded in a number of places.

The MDT/OCL examples editor is model-driven using the OMG compliant
definition in oclstdlib.oclstdlib. Hence the different editor/parser
behaviour.

When the model-driven functionality is complete, we will offer a number
of alternate 'standard' libraries to emulate different established
semantics.

For now just ignire the editor error, or edit oclstdlib.oclstdlib.

Regards

Ed Willink

On 15/09/2010 01:21, Scott wrote:
> Hi Adolfo, thanks, I didn't look past section 11.4.3, so:
>
> 1 I will definitely submit this to the OMG, leave it to me.
> 2a Swapping an error marker for a warning would look better, happy to
> have a line through it until 2c
> 2b This would move the issue out of the users sight - my preference
> 2c A consistent implementation is of course best, but I think one of the
> above should be used in the meantime
>
> Regards
> Scott