Re: [henshin-dev] Proposal to remove direct creation of edges

[Enrico Biermann <enrico@xxxxxxxxxxxxxxx>]

Hi,

it would not be impossible to specify only required nodes in multi
rules. However it requires exposing current implementation details of
DomainSlots to the interpreter engine i.e. the Collection usedObjects.
This Collection contains all nodes that may not be used for the
instanciation of future DomainSlots by the Matchfinder.

Injectivity leads to non-deterministic nested rule construction
depending on the strategy (depth-first, breadth-first) and order of
matches. A fixed strategy will also hide certain constructions completly
(for example breadth-first will hide a constructed rule if other multi
rule matches cover the surrounding graph structure of a match that could
have been expanded in the next layer. This is relevant for the method
getAllMatches().

Dangling Condition should not be a problem. Each rule should be
consistent on their own, i.e. a kernel rule that deletes a node should
not be applicable if their are incoming or outgoing edges in the graph
from this node. Multi rules are not guaranteed to delete those edges,
therefore the constructed rule is likely to be not applicable.

I have not started implementation yet, so feel free to do it. However
these points should be considered for the implementation. My approach
would have been local injectivity (for a single match in a single layer
of one rule) and unique construction of the nested amalgamated rule
(even if the resulting rule is not applicable due to dangling or
identification conditions.

Regards,
Enrico

On 12.12.2011 12:15, Gregor Bonifer wrote:
> Heyhey,
>
> I discussed the issue with Stefan and we came up with the following
> solution. The necessity to force connected edges arose from the
> assumtion that multiRules have to include the complete kernel. The
> design rationale for AmalgamationUnits was based on the easy
> implementation of the application logic by means of RuleApplications.
> This can not be transfered to nested amalgamation, which requires a
> more laborious implementation. Therefore the discussion of editor
> features regarding the automatic synchronization of multiRules is
> moot. The editor continues to allow creation of unconnected and
> untyped Edges.
> Since there has been no feedback whether or not somebody is
> implementing the interpretation of nested amalgamation, I will start
> this now.
> @Enrico: Please let me know if you have already begun with the
> implementation!
> Some thoughts and open questions. Please comment as needed:
> - As mentioned above the multiRules have to contain only those nodes
> from the kernel which are required to define the connection between
> the graphs (as it is with NestedConditions).
> - How should injectiveMatching and checkDangling be handeled? Should
> the kernel define this transitive for all multiRules?
> - In contrast to AmalgamationUnits injective matching has to prevent
> overlapping matches of multiRules. So mutually impeding or
> self-impeding multiRules are allowed.
> - There are several strategies for unfolding a rule scheme resulting
> in different first matches. But as it is with rules, the first match
> counts. Are there any preferred strategies like depth-first or
> breadth-first?
> - Are we planning to integrate scheme formulas as proposed by
> Christian? ( http://journal.ub.tu-berlin.de/eceasst/article/view/260 )
> I think, current implementation should at least leave this option open.
>
> Regards,
> Gregor
>
> Am 11.12.2011 19:35, schrieb Christian Krause:
>> Hi all,
>>
>> the EMF editors basically follow a "free editing" paradigm, with
>> low-level and simple editing operations. What Gregor is planning is
>> more like syntax-directed editing with complex but very restrictive
>> editing operations.
>>
>> I think, we should not remove the basic editing operations of the EMF
>> editor. I think it is nice to have the advanced editing operations,
>> but users should not be forced to use them. EMF users simply expect
>> to have the basic editing operations. And it *is* allowed to produce
>> inconsistent models during the editing. The means for checking
>> consistency is validation (as e.g. in the GMF model editors).
>>
>> Cheers,
>> Christian
>>
>> On 12/11/2011 01:38 PM, Gregor Bonifer wrote:
>>> Hi,
>>>
>>> the problem does not concern the interpretation of the
>>> transformation models, but the creation process in the tree-based
>>> editor. I think I should illustrate this in more detail:
>>> Given a rule (here called kernel) with a multiRule. The multiRule
>>> has to mirror the structure of the kernel. I implemented a
>>> propagation mechanism for the creation of AddCommand. If a
>>> GraphElement is added to a rule, a corresponding element is created
>>> in every multiRule(for nodes this includes mapping). I also changed
>>> the creation of SetCommand for Nodes and Edges so they propagate the
>>> changes into the multiRules, e.g setting the type of a node will set
>>> the type of all dependent nodes in the multiRules. A node can only
>>> be edited in its defining context. This means that a node may only
>>> be edited if it is not dependent(but there may be nodes depending on
>>> it). To visualize this distictions I regenerated the edit-code to
>>> add IItemColorProviders.
>>> The same should be done for edges. To update dependent edges it is
>>> necessary to resolve them via the multiMapping of there nodes. This
>>> might also be done without nodes, but, as I said, this is a guessing
>>> game, which becomes a problem when one changes the ordering of a
>>> multiRule's edges. More importantly it is not possible to determine
>>> whether or not a multiRule's edge is dependent if it has no nodes.
>>> Assuming a kernel with only a single edge and a multiRule with two
>>> edges, one can see that there is no way to determine which of the
>>> multiRule's edges may be edited and which is the dependent one.
>>> This can easily be avoided if edges are created only in ways that
>>> already define the source and target.
>>> I think creating edges without nodes is really not a neccessary
>>> feature. I even think that it should be considered a bad habit,
>>> since in theory there are no edges without nodes (i.e edges with
>>> undefined src/trg functions). I can also imagine situations where
>>> one might want this. But I can neither imagine a goal whose
>>> feasibility relies on this, nor can I imagine a scenario which might
>>> become more cumbersome without this possibility.
>>>
>>> Regards,
>>> Gregor
>>>
>>> P.S.: Perhaps we should think about generating another editor(incl.
>>> edit) which will be kept unchanged, to provide lowest-level editing.
>>>
>>> Am 10.12.2011 21:55, schrieb Riegerf@xxxxxxxxxxxxxxxxxxxxxxx:
>>>> Hi Gregor,
>>>>
>>>> Quoting Gregor Bonifer <gregor.bonifer@xxxxxx>:
>>>>> If an edge is created directly in a graph it has neither source
>>>>> nor target. Therefore identifying the dependent edges of a kernel
>>>>> edge becomes kind of a guessing game.
>>>>
>>>> Is this a problem? I.e. will verifying the model create an error if
>>>> edges are not set correctly by the user or will the interpreter
>>>> just (mysteriously) not work correctly (although the model passed
>>>> the verification)?
>>>>
>>>>> I would like to exclude edges from the "Create Child" and "Create
>>>>> Sibling" menu. Edges should always be created by commands which
>>>>> imply setting the source and target references [...]
>>>>> Are there any objections?
>>>>
>>>> I strongly object; removing functionality is not a good idea at
>>>> all, especially when it comes to these rather primitive operations.
>>>> I can imagine situations where one might to create an edge before
>>>> its target Node is created, which would be made impossible.
>>>> Of course, the user will have a more comfortable editing experience
>>>> without needing to specify additional information if she chooses
>>>> the advanced editing functions.
>>>>
>>>> Felix
>>>>
>>>>
>>>
>>> _______________________________________________
>>> henshin-dev mailing list
>>> henshin-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/henshin-dev
>>
>> _______________________________________________
>> henshin-dev mailing list
>> henshin-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/henshin-dev
>>
>
> _______________________________________________
> henshin-dev mailing list
> henshin-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/henshin-dev