Closed narudocap closed 4 years ago
Yes, you should be able to map them if they're in the interface like in the case below.
Ok, I got the right syntax now. Perhaps you can mention it in the documentation: "NACs or PACs are currently not yet supported and neither are attributes, or other forms of constraints.", "This is achieved through a list of mapping statements that map either a class or a reference.", ...
I'm still confused: attributes are supported, though other forms of constraints aren't.
In a type mapping, you can say
attribute <qualified name of source attribute> => <qualified name of target attribute>
In a rule mapping, you can say
slot <qualified source slot name> => <qualified target slot name>
This will check that the expressions attached to the slot (attribute in a node in a rule) are syntactically the same in the source and target role (and of course that the underlying attributes have actually been mapped by the type mapping). When I bring in parameter morphisms via #36, the check will extend to renaming any variables used in the expressions.
I notice that this specific syntax isn't documented, so needs to be added to the documentation.
Are you saying there is something wrong with how this is supported at the moment?
I've just added PR #40, which improves the documentation. @narudocap could you take a look please and confirm whether this addresses your question?
Yes, as I said, it works, I'm now using this in some of my examples, but it was not documented.
Great. Could you just do a quick review of PR #40 and approve that if you're happy with my changes so I can merge it in?
Can I have attributes in interfaces? I can mark them explicitly in the ecore model, but they cannot be mapped, right? vs.