Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 190150

Summary:	[library,validator,evaluator] The type of TypeExp should be classifier (C)
Product:	[Modeling] OCL	Reporter:	Adolfo Sanchez-Barbudo Herrera <adolfosbh>
Component:	Core	Assignee:	OCL Inbox <mdt-ocl-inbox>
Status:	CLOSED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	alexander.igdalov, ed
Version:	1.1.0	Keywords:	plan
Target Milestone:	3.1.0	Flags:	ed: indigo+
Hardware:	PC
OS:	Windows XP
Whiteboard:	OCL 2.1 Compliance
Bug Depends on:
Bug Blocks:	156363

Description Adolfo Sanchez-Barbudo Herrera

2007-05-31 04:08:24 EDT

Newsgroup discussion about the issue:

http://dev.eclipse.org/newslists/news.eclipse.modeling.mdt.ocl/msg00322.html

Comment 1 Christian Damus

2007-06-13 16:59:43 EDT

Investigate in the 1.2 release.

Comment 2 Ed Willink

2007-12-24 12:19:48 EST

ValidationVisitor.visitTypeExp checks that

1) eType is a TypeType
2) referredType is not null

The first is just an implementation practice.
The second is an OCL constraint.

The first incorrectly diagnoses QVT operation calls for which the
implicit source is the Transformation which is both a Package and a Classifier.
For QVT it is unnecessary to wrap the Transformation up in a TypeType to
provide the TypeExp eType argument. Please remove the MDT-specific TypeType validation.

[The implementation of ValidationVisitor is very inflexible:

The private constructor prohibits derivation to mend derived semantics.

The direct passing of this to child validations, prevents re-use by a wrapper delegating to the ValidationVisitor instance.]

[The internal validation traversal of composed content seems to conflict
with the EValidator policy making it a bit awkward to use a ValidationVisitor
where an OCLValidator was wanted.]

[Visitor is documented as an OCLExpression visitor. However it also
supports Constraint which is not an OCLExpression. But it does not support
TypeType. Surely there should be some validation class that realises all
OCL classes?]

Comment 3 Ed Willink

2009-09-27 11:51:02 EDT

Adolfo: Two years later, a change of team and a change of OCL specification.

My comment #2 was a Validator winge.

Christian's newgroup comment seemed to suggest a TypeType change to OclAny or Classifier.

Your original newsgroup posting seemed to be about library extensibility.

Could you review the original newsgroup posting and give this Bugzilla a clear focus. Perhaps one or two of the above themes should be new bugs, or merge with other bugs.

Comment 4 Adolfo Sanchez-Barbudo Herrera

2009-09-28 04:56:39 EDT

(In reply to comment #3)
> Adolfo: Two years later, a change of team and a change of OCL specification.
> 
> My comment #2 was a Validator winge.
> 
> Christian's newgroup comment seemed to suggest a TypeType change to OclAny or
> Classifier.
> 
> Your original newsgroup posting seemed to be about library extensibility.
> 
> Could you review the original newsgroup posting and give this Bugzilla a clear
> focus. Perhaps one or two of the above themes should be new bugs, or merge with
> other bugs.

Hi Ed. I think that this bugzilla exposes one of cases which may have helped to change the 2.1 specification in favour of removing TypeType and oclType.

What about stating this bug as the TypeType/oclType removal ?.

Bug 259031 could depend on this one.

Cheers,
Adolfo.

Comment 5 Ed Willink

2011-02-01 02:23:48 EST

New evaluator has more coherent treatment of TypeExp and official parsing of type expressions.

Comment 6 Ed Willink

2011-05-27 06:41:10 EDT

Resolved for Indigo is 3.1.0 not 3.2.0.

Comment 7 Ed Willink

2012-05-29 13:23:32 EDT

Closing all bugs resolved in Indigo.