> If I use Set(String) instead, the error dissapears. So it seems that
> the EValidator via the use of TypeUtil.exactTypeMatch method, expects
> to recieve the same type (property and value).

Well, that is how the constraint is specified by the OCL. From 8.3.7
(p. 55):

[1] The type of the attribute is the type of the value expression.
context TupleLiteralPart
inv: attribute.type = value.type

Either OCL intentionally requires exact correspondence, or the
specification of this constraint is in error and should use
Classifier::conformsTo(Classifier).
> It seems that it's a bug, isn't it?.

Well, IMHO the conformsTo() semantics would be more appropriate.
However, with the EValidator I am being careful to implement as much
as possible the OCL Specification's constraints to the letter.
Obviously, where the actual OCL expressions in the text are not
well-formed, I have to make a correction, but there is no such
problem, here.

I have submitted an issue to the OCL RTF proposing an amendment to
conforms-to semantics.
> Does this constraint implemented by EValidator have the same
> behaviour than the ValidationVisitor one?....it should...

No, it does not. The ValidationVisitor is not simply delegating to
the EValidator for a number of reasons, this being but one.
> Could you put some light on my doubts?

Thank you for the aclaration. Definetely, I have understood the problem
and I agree with you that conformsTo is more appropriate. That's the
origin of my confusion.

Cheers,
Adolfo.

Christian W. Damus escribió:
> Hi, Adolfo,
>
> Find some replies in-line, below.
>
> HTH,
>
> Christian
>
>
> On Tuesday 05-13-2008 (01:02), Adolfo Sánchez-Barbudo Herrera wrote:
>> Hi Christian,
>
>> In M7,
>
>> The following TupleLiteralExp throws the following error:
>
>> Tuple {a: Collection(String) = Set{"aString"}, b: String =
>> "aString"};
>
>> Error: Validator-ERROR in org.eclipse.ocl.expressions;
>> testQVTo.qvto:22 : Tuple literal part (a) type does not match
>> property type: (Tuple{a : Collection(String) = Set {'aString'}, b :
>> String = 'aString'})
>
>> If I use Set(String) instead, the error dissapears. So it seems that
>> the EValidator via the use of TypeUtil.exactTypeMatch method, expects
>> to recieve the same type (property and value).
>
> Well, that is how the constraint is specified by the OCL. From 8.3.7
> (p. 55):
>
> [1] The type of the attribute is the type of the value expression.
> context TupleLiteralPart
> inv: attribute.type = value.type
>
> Either OCL intentionally requires exact correspondence, or the
> specification of this constraint is in error and should use
> Classifier::conformsTo(Classifier).
>> It seems that it's a bug, isn't it?.
>
> Well, IMHO the conformsTo() semantics would be more appropriate.
> However, with the EValidator I am being careful to implement as much
> as possible the OCL Specification's constraints to the letter.
> Obviously, where the actual OCL expressions in the text are not
> well-formed, I have to make a correction, but there is no such
> problem, here.
>
> I have submitted an issue to the OCL RTF proposing an amendment to
> conforms-to semantics.
>> Does this constraint implemented by EValidator have the same
>> behaviour than the ValidationVisitor one?....it should...
>
> No, it does not. The ValidationVisitor is not simply delegating to
> the EValidator for a number of reasons, this being but one.
>> Could you put some light on my doubts?
>
> I hope I did.
>> Cheers,
>> Adolfo
>
>
>
>
>
>