Hi,

by accident, I saw this discussion.
(20:07:51) mbriskar: lincolnthree: but if you plan to have classification in one rule and it's decorators in the another rules, there is no other way then to save it in the graph
(20:07:57) LincolnBaxter: mbriskar: meta-model == windup's java in-memory representation of the project…. look at the code
(20:08:35) LincolnBaxter: mbriskar: why would classifications and decorators be in separate rules?
(20:08:42) mbriskar: lincolnthree, jsightler, ozizka: sorry but I just feel all of you have a different thinking of how to migrate that makes me confused as ...
(20:08:57) mbriskar: never
(20:09:15) mbriskar: lincolnthree: that's what Ondra thinks
(20:13:33) LincolnBaxter: mbriskar: i don't think they should be in separate rules either

So, why should it be in separate rules?
Not sure if you (whoever) have really seen what those classification and decorator does.
Probably you think it compares to WHEN and PERFORM.  It does not.
At least not always.

I'll gladly remind what was decided on the F2F (correct me if I misunderstood) :
We will store the intermediate information into the graph, making the rules decoupled.
E.g. we will go through the files, using rules, and examine what they are.
Then, with another rules, we will query the graph and process the files in some other way.
In other words, we already do classify using some rules, and decorate using others.

The limitation of the legacy Windup rules is that they are a tree. The context of one classifier is lost after it's processed.
If you want to do the same operation in other classifier, you have to copy it.
For example: If you classify FooBar XML file A) by namespace http://foo.com/bar B) by finding an /foo-bar element in it, then whatever you do with them has to be coded twice.
We do not want to mimick this limitation. Therefore, we want one rule for A, other rule for B, and third rule for whatever is done with them next.

Regards, Ondra