Hi,
That was good news that we were able to use this new feature also on the Mars track! Looks good, as you say the confusing "...not valid" at the ends of the messages are now gone! Great.
The normal expected case should be that both lowerValue and upperValue both have a LiteralString with the same value, i.e. basically "MAX"..."MAX" for fixed capsule parts, or 0.."MAX" for optional/plugin capsule parts, i.e. lowerValue is LiteralInteger and upperValue is a LiteralString.
The same cases should also be tested with an OpaqueExpression (since we have not yet really decided whether the tooling should use LiteralString or OpaqueExpressions as the legacy tooling is), specify lowerValuy and upperValue with an OpaqueExpression with some suitable language and a body with "MAX".
I guess for completeness we should test also the invalid cases where the symbolic string differs between lowerValue and upperValue, e.g. "MIN"..."MAX". But I guess that since the OCL constraint is based on the derived features lower and upper, the derived integer respectively natural unlimited values will be 1 in both cases.
I don't think it is needed and we probably should not bother about checking the string values (for the case of symbolic constants) of the LiteralString/OpaqueExpression always are the same.
/Peter Cigéhn