Inconsistent handling of common supertype of primitive types

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 260403 | | Status | CLOSED FIXED | | Importance | P3 normal | | Reported | Jan 08, 2009 10:36 EDT | | Modified | May 27, 2011 02:48 EDT | | Version | 1.3.0 | | Reporter | Radomil Dvorak |

Description

Just tried to define a Set(OclAny) containing various primitive values, using the Set literal.

Parsing the expression: Set { 'aString', 10 }\ results in error: "Type mismatch. No common supertype: (String), (Integer)"

Suspecting the OclAny should be the common supertype, I have tried the\ expression bellow using the OCLConsole:

Evaluating:\ let s1 : Set(OclAny) = Set {}->including(10) in \ let s2 : Set(OclAny) = s1->including('aString') in s2\ \ Results:\ 'aString'\ 10

Logically, I would assume that it's correct if values of these types conforming to OclAny can coexist in the same Collection(OclAny).\ So I expect the Set literal to work this way too. Am I wrong?

[eclipse-ocl-bot]

By Christian Damus on Jan 08, 2009 10:45

(In reply to comment #0)\

Logically, I would assume that it's correct if values of these types conforming to OclAny can coexist in the same Collection(OclAny). So I expect the Set literal to work this way too. Am I wrong?

I don't think you're wrong, no.

OCL has, of course, a horrible problem in the definition of OclAny as a type to which all others (exceptio the collection types) conform. OCL 2.1 RTF has adopted a resolution that makes collection types to conform to OclAny, but even so, the UML semantics of classifiers preclude any classifier from conforming to OclAny except for other AnyTypes (of which there are none). Another UMLism that OCL forgot. Oh, well.

In any case, here MDT OCL is inconsistent with itself, so it should be fixed to behave as you expected. You would probably find the same issue with Classes that, as far as the UML model knows, are unrelated.

[eclipse-ocl-bot]

By Radomil Dvorak on Jan 08, 2009 11:06

You would probably find the same issue with Classes that, as far as the UML model knows, are unrelated.

Right ;).\ Additionally, 'aString'.oclIsKindOf(OclAny) results in false, the same case is with Classes.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Jan 09, 2009 12:59

I have worked a little bit on the issue, and definitely the commonSuperType method needs to be revised. Besides, I have detected more problems with the relation between Integer, Real and UnlimitedNatural primitive types.

For example, specification says that Integer must conform to Real. However it doesn't mention anything about UnlimitedNatural primitive type. In MDT-OCL, UnlimitedLiteral is considered to conforms to Real as well. Which is the relation between UnlimitedNatural and Integer ?.

I'll supply a patch to solve the problem, though, some comments about how the type conformance must be considered among these primitive types will be needed.

Cheers,\ Adolfo.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Jan 13, 2009 17:21

Created attachment 122464 (attachment deleted)\ Proposing Patch

The proposed patch includes the following changes:

• Refactoring of the commonSuperType to solve the bug.
• Fix for 3 ocl.ecore.test test cases which were erroneously considering that some types which have a common OclAny type were unrelated types.
• Fix for 2 ocl.uml.text test cases which were erroneously considering that some types which have a common OclAny type were unrelated types.
• An extra test case to check the correct evaluation of collections which are declared as OclAny type including objects of different types.

P.S: From the discussion in mdt-ocl.dev mail list, Christian and I have decided deferring to the next version the problem related to UnlimitedNatural type.\ P.S.2: Radek's concern about the common super type should be solved. Please, confirm it.

Cheers,\ Adolfo.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Jan 13, 2009 17:28

Created attachment 122465 (attachment deleted)\ Proposed patch

Sorry, I didn't upload the last version of the patch >.<

This should the good one.

Cheers,\ Adolfo.

[eclipse-ocl-bot]

By Radomil Dvorak on Jan 14, 2009 07:53

(In reply to comment #4)

I can confirm the common super type problem is solved.

Concerning UnlimitedNatural, I can see a remaining issue in \ org.eclipse.ocl.ecore.internal.UMLReflectionImpl.getOCLType(Object), which \ maps the type of ETypeElement::upperBound feature to UnlimiteNatural.\ With the absence of clear conformancy rules here, it is hard to make any use \ of this feature. \ For instance, I can not write a QVT transformation which sets a\ value other then *.

Can not that be just of Integer type?

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Jan 14, 2009 08:26

(In reply to comment #6)

(In reply to comment #4)

I can confirm the common super type problem is solved.

Concerning UnlimitedNatural, I can see a remaining issue in org.eclipse.ocl.ecore.internal.UMLReflectionImpl.getOCLType(Object), which maps the type of ETypeElement::upperBound feature to UnlimiteNatural. With the absence of clear conformancy rules here, it is hard to make any use of this feature. For instance, I can not write a QVT transformation which sets a value other then *.

Can not that be just of Integer type?

If you define the type of that attribute as Integer, you couldn't then stablish the * value to it, so we have the same problem. Besides, I guess that it may produce comptibility problems.

It seems that it's a specification problem related to the use of the UnlimitedNatural primitive type,which is supposed to be applied in OCL, stablished in UML.

I think that we should invest some thoughts around this, though, I guess this will have to be deferred until MDT-OCL 2.0.

I raised a bug related to the conformance of UnlimitedNatural and Real type (which is erroneusly established in the MDT-OCL implementation):

https://bugs.eclipse.org/bugs/show_bug.cgi?id=261008.

Maybe, you could open a new one for this issue, or just sending an OMG issue related to the type conformance of UnlimitedNatural with other primitive types.

There are some Chrisitian's thoughts in the mdt-ocl.dev mailing list.

Cheers,\ Adolfo.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Jan 14, 2009 08:42

BTW, I didn't mention that I agree about the fact that Integer type would be much more useful for a transformation writer than the UnlimitedNatural type ;).

Cheers,\ Adolfo.

[eclipse-ocl-bot]

By Christian Damus on Jan 14, 2009 09:23

(In reply to comment #6)

(In reply to comment #4)

I can confirm the common super type problem is solved.

Great! Thanks to you and to Adolfo.

For instance, I can not write a QVT transformation which sets a value other then *.

Can not that be just of Integer type?

In addition to Adolfo's answer, it is worth noting that the range of the UnlimitedNatural as specified by UML is the mathematical set of the whole numbers, plus *. Thus, it is possible to set values of 0, 1, 2, etc. as the upper bound of a property.

I suspect that the actual reason why you can't write a QVT transformation that sets anything other than * is that this is the only literal value for UnlimitedNaturals that is defined by the OCL grammar, as laid out in the spec and (alas!) the MDT implementation. '0', '1', etc. are parsed as Integers which, as we know, are not related by type conformance to UnlimitedNaturals.

If this is your problem (or even if it isn't), we should implement automatic coercion of integers to naturals and vice-versa in the range of their overlap in the 1.3 release. The OCL spec is simply broken, so we have to do something practical. Besides, mathematics doesn't recognize "types" of numbers, only sets. The mapping from these sets to UML's type system is imprecise. UML should probably only have an Integer type and denote unlimited upper bound (which is the only meaningful use of * anyway) as a boolean attribute of the MultiplicityElement, or simply absence of an upper bound, or both (the boolean being derived).

[eclipse-ocl-bot]

By Radomil Dvorak on Jan 14, 2009 09:28

(In reply to comment #8)

BTW, I didn't mention that I agree about the fact that Integer type would be much more useful for a transformation writer than the UnlimitedNatural type ;).

A bit more then useful, IMO.\ Ecore seems to introduce more semantics then UnlimitedNatural can handle.\ It needs another negative Integer value (-2) to express unspecified value, \ no literal can help.\ I would not mind if I can not set but can use -1 instead. Ecore being\ my user model to a transf. is problematic due to this type mapping.

I can override UMLReflection.getOCLType(Object) in QVTO, I just wondered about\ Christian's point of view, if it's an OCL problem at all ;).

AFAIU what he says, the only issue for OMG would be eliminating\ UnlimitedNatural.\ However, I understand it would be a breaking change.

PS:Just got mid-air collision with Christian

[eclipse-ocl-bot]

By Christian Damus on Jan 14, 2009 09:43

(In reply to comment #10)

(In reply to comment #8)

BTW, I didn't mention that I agree about the fact that Integer type would be much more useful for a transformation writer than the UnlimitedNatural type ;).

A bit more then useful, IMO. Ecore seems to introduce more semantics then UnlimitedNatural can handle. It needs another negative Integer value (-2) to express unspecified value, no * literal can help.

As I understand it, this value only occurs in Ecore models imported from XSD and then only in feature maps for element wildcards (because you don't know which feature may actually have a value in that slot). These XSD concepts have nothing to do with modeling, and are only an annoying impedance mismatch between a horrible XSD idiom and EMOF.

Anyone transforming real models to the kind of Ecore that precisely models an XSD schema would have to be crazy, in my opinion :-) In any case, feature maps have no analogue in UML/MOF, so it's probably not interesting to QVT.

I can override UMLReflection.getOCLType(Object) in QVTO, I just wondered about Christian's point of view, if it's an OCL problem at all ;).

Nope, not a problem for OCL, as we flagrantly disregard feature maps and other XSD-ness ;-)

[eclipse-ocl-bot]

By Radomil Dvorak on Jan 14, 2009 10:10

Anyone transforming real models to the kind of Ecore that precisely models an XSD schema would have to be crazy, in my opinion :-)

LOL, per my experience people tend to do crazy things, OK, let's do not support their effort in this direction.

As for the automatic coersion idea, I can imagine a runtime value coersion, \ but I'm not sure I understand how it can be supported at compilation time as they are not related by type conformance, as mentioned in this bugzilla.

[eclipse-ocl-bot]

By Christian Damus on Jan 14, 2009 10:16

(In reply to comment #12)

Anyone transforming real models to the kind of Ecore that precisely models an XSD schema would have to be crazy, in my opinion :-)

LOL, per my experience people tend to do crazy things, OK, let's do not support their effort in this direction.

It may be a good idea to confirm with Ed that my understanding is correct ... in any case, an "unspecified multiplicity" is nonsense in modeling terms. A well-formed model specifies a multiplicity; in is not variable.

As for the automatic coersion idea, I can imagine a runtime value coersion, but I'm not sure I understand how it can be supported at compilation time as they are not related by type conformance, as mentioned in this bugzilla.

Well, evaluation support should already be there, as both types are implemented by Java's Integer and we do explicit coercion of various numeric types.

I actually meant parse-time coercion. Since EMOF doesn't provide a means to model conformance relationships between data types, anyway, we may as well invent the type coercion semantics that the OCL spec forgot. I don't see how the language, as it stands now, can be viable without it.

[eclipse-ocl-bot]

By Radomil Dvorak on Jan 14, 2009 11:21

It may be a good idea to confirm with Ed that my understanding is correct ... in any case, an "unspecified multiplicity" is nonsense in modeling terms.

In any case, not a big problem for QVTO as we can always escape setting it as integer in a blackbox operation.

Still, I know I'm annoying ;), even if not trying to set it, I suspect some strange situations to appear.\ Considering a valid ecore model, which may keep -1 or -2 integer values in upperBound, it might be of some interest to check for various upperBound values. \ So, a query to find all unspecifed values might be tricky to write, as I would try to check for a value which can never be there.\ I can imagine that someone may need to create a constraint to check for XSDness occurences ;). That should not be so crazy requirement, IMO.

I actually meant parse-time coercion.

If I get it right, integers and unlimited naturals would be mutually convertable at parsing time, while during evaluation, non-overlapping values would yield in OclValid?

[eclipse-ocl-bot]

By Christian Damus on Jan 14, 2009 12:31

(In reply to comment #14)

It may be a good idea to confirm with Ed that my understanding is correct ... in any case, an "unspecified multiplicity" is nonsense in modeling terms.

In any case, not a big problem for QVTO as we can always escape setting it as integer in a blackbox operation.

Cool.

Still, I know I'm annoying ;), even if not trying to set it, I suspect some strange situations to appear.

Not annoying. Just persistent. :-P

Considering a valid ecore model, which may keep -1 or -2 integer values in upperBound, it might be of some interest to check for various upperBound values. So, a query to find all unspecifed values might be tricky to write, as I would try to check for a value which can never be there.

Except that, sometimes, it magically would! A paradox. Actually, I blame Ecore for deviating from the "-1 indicates unlimited" convention by adding a -2 value. It wasn't always there, you know!

I suppose this query would be another blackbox? I don't know how to resolve the dual nature of Ecore as an implementation-oid of EMOF (which OCL understands) and a Java binding for XSD. I'm afraid I'm inclined to stick to the EMOF interpretation. Both MDT OCL and M2M QVTo provide users that really need the XSD support to define boolean helper queries, in Java, that will anwer whether an EStructuralFeature has unspecified multiplicity.

In fact, it's probably better just to recommend that they check whether the EStructuralFeature is a feature map and is a wildcard ... I think the characteristic of unspecified multiplicity can be derived :-D

I can imagine that someone may need to create a constraint to check for XSDness occurences ;). That should not be so crazy requirement, IMO.

I actually meant parse-time coercion.

If I get it right, integers and unlimited naturals would be mutually convertable at parsing time, while during evaluation, non-overlapping values would yield in OclValid?

Well, I was thinking actually of OclInvalid ... :-)

But, that is what I mean, yes.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Jan 14, 2009 18:08

Created attachment 122607 Final proposed patch

Hi all,

I hope this is the last one ;P.

• I have to upload a new one because I formatted the code, which pump up the number of lines of the contribution.

• I have also removed some unnecessary old commented code.

• I have stablished the 2009 year in the copyright header.

About the UnlimitedNatural issue... May I suggest opening a new bugzilla for it so we can go on the discussion there ? ;)

Cheers, Adolfo.

:notepad_spiral: ocl260403.txt

[eclipse-ocl-bot]

By Christian Damus on Jan 14, 2009 22:50

(In reply to comment #16)\

I hope this is the last one ;P.

Oh, so close!! The only problem is three occurrences of hyphen instead of comma in the copyright date ranges. :-)

Seriously, though, this is great. Thanks!

The patch is committed to HEAD (1.3 branch).

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Jan 15, 2009 08:10

(In reply to comment #17)

(In reply to comment #16)

I hope this is the last one ;P.

Oh, so close!! The only problem is three occurrences of hyphen instead of comma in the copyright date ranges. :-)

Seriously, though, this is great. Thanks!

The patch is committed to HEAD (1.3 branch).

Ouch !!! >.< . . . I really liked those hyphens :D

Cheers.

[eclipse-ocl-bot]

By Ed Willink on May 27, 2011 02:48

Closing after over 18 months in resolved state.