[furcas-discussion] Query/lookupScope/referencedBy/prefix/postfix

[Uhl, Axel]

Hi all,

I updated OCLQueryPropertyUpdater to use the new forms lookupScope/referencedBy/prefix/postfix. It seems to work for the existing test cases already. In particular I was able to un-ignore one of Sebastian's cases which is green now.

A bunch of open issues that I can use your help with:

 - What to do if the result of the lookupScope expression is invalid? Should we break a so far resolved reference then? See TODO in OCLQueryPropertyUpdater.notify

 - If a multi-valued feature is to be updated by such a query, we should require such features to be ordered. Then, we can infer the position at which the element identified by the query needs to be placed and looked-up. Two TODOs derive from this:

   * Implement OCLQueryPropertyUpdater.getPosition(). It would be cool if someone who knows the TCS metamodel better than me could do this. I even wonder if it would be possible in all cases to uniquely determine a position for a Property using such a query. Based on optional elements in the mapping this may not always be possible. What should we do in such cases? Should there be an invariant that requires there to be a unique order of sequence elements populating the same feature in case that feature is multi-valued? I'm for it.

   * Add the necessary OCL constraints to the TCS metamodel

 - We need a strategy for when to update tokens affected by a rename activity. I've declared OCLQueryPropertyUpdater.shallUpdateReferencingTokenInTextBlockModel(LexedToken token, String newValue) with a TODO in its body. Currently, it always returns true. However, I don't think this is the optimal strategy. We already discussed that this may even be a user preference. One of the things I could imagine is that we decide based on whether the token's resource is already dirty. Opinions?

Cheers,
-- Axel