Bug 576662 - Support strict/effective ModelType ConformanceKind
Summary: Support strict/effective ModelType ConformanceKind
Status: NEW
Alias: None
Product: QVTo
Classification: Modeling
Component: Engine (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows 10
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-10-16 04:04 EDT by Ed Willink CLA
Modified: 2021-10-16 04:04 EDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ed Willink CLA 2021-10-16 04:04:33 EDT
There appears to be no support other than parsing/unparsing for the ModelType.conformanceKind field that results from a "strict" keyword in a modeltype declaration.

https://www.eclipse.org/forums/index.php/mv/msg/1109220/1847144/#msg_1847144 suggests that there may be a problem with multiple strict modeltypes prompting me to wonder what the specified semantics and implementation are.

Implementation appears to be zero, so we are probably implementing only strict as both strict and effective which is the default. (So no compatibility problem adding the richer default.)

Specified semantics are a bit woolly, but in so far as only names are matched they are sound. Problems lie in inheritance. A plausible interpretation is that the class and features of the actual metamodel are the name-wise intersection of the inheritance flattened declared/input metamodels (augmented by declared aliases). 

Type conformance is perhaps more challenging.

The closure of conformant superclasses can similarly be determined by name-wise intersection allowing compatible superclasses to be used for virtual mapping dispatching.

For type matching there may be an anomally.

If the declared metamodel matches using A::b of type B and if the actual metamodel has a name-compatible A::b but of type C one will match and the other may not. This is perhaps what a well-crafted suite of aliases might fix up.

There probably needs to be an effectiveness report for all matching opportunities for which the actual and declared metamodels may lead to inconsistencies.

Simplistically, it would seem that the name-wise intersection analysis can create a (bidirectional) map between declared and actual classes, and on a per actual class basis between declared and actual features. For a strict execution the map is a trivial self-no-op. For effective execution the map (de-)normalizes/inhibits.

Some ambiguities may not be resolveable. e.g if distinct functions/queries are declared, is it guaranteed that an effective usage will not convert distinct to ambiguous?