From ichenp@ccs.neu.edu Thu Dec  3 02:08:22 1998
Received: from rigel.ccs.neu.edu (ichenp@rigel.ccs.neu.edu [129.10.116.151])
	by amber.ccs.neu.edu (8.9.1a/8.9.1) with ESMTP id CAA18742;
	Thu, 3 Dec 1998 02:07:53 -0500 (EST)
Date: Thu, 3 Dec 1998 02:07:52 -0500 (EST)
From: I-Chen Pan <ichenp@ccs.neu.edu>
To: Mira Mezini <mira@informatik.uni-siegen.de>
cc: Karl Lieberherr <lieber@ccs.neu.edu>, bdelav@hotmail.com,
        jayantha@ccs.neu.edu, lorenz@ccs.neu.edu
Subject: Re: Help (AP Lib tg)!
In-Reply-To: <199812021523.QAA10607@doors.informatik.uni-siegen.de>
Message-ID: <Pine.GSO.4.05.9812030116160.9925-100000@rigel.ccs.neu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: R

Dear Prof Mezini,
  Thanks for the explanation and making my task clear. I feel much clearer
and better now. I think what made me confused mostly was the abstract
way in which my task was being described and that some of the components
of APPCs were missing. I do have the big picture of how the APPCs work.
So I think I'll just follow your instructions and finish the Java code of
APPCBean. 

On Wed, 2 Dec 1998, Mira Mezini wrote:

> Hi all,
> 
> First, thanks to Karl for sending this mail to all of us.
> 
> Please send the questions always to the whole group, otherwise it
> is difficult to stay synchronized.
> 
> > >In the discussions I heard it wasn't clear but I believe there 
> > >will be 3 languages:
> > >1. APPC (very nearly described in the cd file from Prof.)
> > >2. CCG (essentially the same language as that used for cd files)
> > >3. Mapping (which will include associated refined strategies)
> 
> That's correct. The mapping language is not really defined yet.
> 
> > Bill is right. But lets make it simpler for I-Chen:
> > Let's make it a self-contaioned problem where input is text
> > and output is text. The text describes the event objects.
> > 
> > I-Chen: Write a program that does the following translation:
> > 
> > Example:
> > Class graph:
> > A = B C.
> > B = D.
> > C = E F.
> > D = G.
> > G = Z.
> > E = Z.
> > F = Z.
> > 
> > Object traversed: A-object (there is only one)
> > 
> > Strategy:
> > S1: A -> *
> > S2: A -> D D -> Z
> > S1			S2
> > before A		before A
> > before ->A,B		before ->A,D
> > before B
> > before ->B,D	
> > before D    		before D
> > before ->D,G		before ->D,Z
> > before G
> > before ->G,Z	
> > before Z    		before Z
> > after Z    		after Z
> > after ->G,Z
> > after G
> > after ->D,G		after ->D,Z	
> > after D			after D
> > after B
> > before C
> > ...			...	
> > after ->A,B		after ->A,D
> > after A			after A
> > 
> > The input and output language has a cd like:
> > 
> > Event = Kind NodeOrEdge.
> > Kind  : Before | After.
> > Before = "before".
> > After = "after".
> > NodeOrEdge : Node | Edge.
> > Edge = "->" <source> Node <target> Node.
> > Node = Ident.
> > 
> > You write a program:
> > 
> > Input: 	cd, s1 
> > 	e1 = List(Event) 
> > Output: e2 = List(Event)
> > e2 contains only the events at the s1 level.
> > 
> > Notice the simplification: only one strategy!
> > 
> > Let me know when you are done with this
> > self-contained problem. Then we can bringin the
> > beans if there is time left.
> > 
> > Let me know if this problem formulation is not clear.
> 
> 
> I think this reformulation of the problem should make I-Chen's
> responsibility clear. 
> 
> Let me, nevertheless, try to give you a big picture of how that
> all fits together, without getting into too much details. Bill is right
> when he writes that refined strategies (rsicg1 and rsicg2) are part of the
> mapping. Thus, what I-Chen is supposed to do (as Karl describes above)
> is part of the adaptation functionality that implements what is specified 
> in the maps that are written in the mapping language. 
> 
> Remember, part of the adaptation functionality
> had to do with translating CCG objects to ICG objects which I 
> have pseudo-implemented in the method traversalEvent in the class
> APPCBean. The following modification of Karl's
> description formulates what I mean by "the part that translates CCG objects 
> to ICG objects": 
> 
> > The input and output language has a cd like:
> >
> > Event = Kind NodeOrEdge.
> > Kind  : Before | After.
> > Before = "before".
> > After = "after".
> > NodeOrEdge : Node.
> > Node = Ident.
> >
> > You write a program:
> >
> > Input:        cd, s1
> >       e1 = List(Event)
> > Output: e2 = List(Event)
> > e2 contains only the events at the s1 level.
> 
> Note the cd above does not deal with edge events. 
> This part is more or less  what I have implemented in the pseudo-code
> for the method traversalEvent(NodeEvent) in the root class APPCBean.
> If you look at this implementation what it does is to 
> translate e1 to e2 when the languages for e1 and e2 is determined
> by my modified cd above (i.e., no edges). In fact my pseudo-implementation
> does a bit more. Instead of sumply giving out e2 as a text,
> I also construct the ICG object that will be passed along the
> output event e2 and invoke the generated e2 on the appc. 
> 
> But this is not relevant for I-Chen. 
> What I-Chen is supposed to do is to turn my pseudo-implementation
> in a real one and complete it for what is missing: dealing with
> edges. 
> 
> What does that mean in more concrete terms? If I consider
> Karl's example:
> 
> > S2: A -> D D -> Z
> > S1                    S2
> > before A              before A
> > before ->A,B          before ->A,D
> > before B
> > before ->B,D 
> > before D              before D
> > before ->D,G          before ->D,Z
> > before G
> > before ->G,Z 
> > before Z              before Z
> > after Z               after Z
> > after ->G,Z
> > after G
> > after ->D,G           after ->D,Z    
> > after D                       after D
> > after B
> > before C
> > ...                   ...    
> > after ->A,B           after ->A,D
> > after A                       after A
> 
> what I deal with are only pairs:
> 
> > S1                    S2
> > before A              before A
> >
> > before D              before D
> >
> > before Z              before Z
> > 
> > after Z               after Z
> >
> > after D               after D
> >
> > after A               after A
> 
> Here is what I do. 
> 
> 1- I get the NodeObject parameter of of the operation 
>    eventTraversal and "decode" it to  find out whether
>    it encodes a ``before A'', ``before D''
>    ``before Z'' ``after Z '' ``after D'' or ``after A''.
> 
> 2- if so, I construct the corresponding e2 events together with 
>    the ICG objects that are expected with e2 events. 
> 
> 3- finally the generated event is invoked on the appc. Remember,
>    in the last version of my pseudo-code, the adaptation functionality
>    is performed by the APPCs (it is implemented in teh class APPCBean 
>    rather than in AdapterBean as before). Thus the appc on which the
>    generated e2 is invoked is "this".
> 
> The rest is ignored. That is, nothing happens for nodes in s1 that are not
> in s2 as well as with all edges of s1. This part should be filled in by I-Chen.
> There are two main things you need to do I-Chen. I will give a skeleton
> of I-Chen is supposed to do:
> 
> 1- Complete my code. 
> 
> Why? 
> In order to get e2 events for edges such as e.g., ``before ->D,Z''
> we cannot simply ignore s1 node events such as ``before G'' (for nodes
> that are not in s2), as I do. 
> Indeed, we don't generate output events in this case, but 
> we need to somehow store nodes in the s1's path from A to D so that we can 
> generate ``before/after ->A,D'' events for s2. 
> One way I can think of implementing this, is to have a stack 
> as the storage medium. E.g., for the input ``before G'' we would simply
> push G on the stack. Note that also nodes like A that are both in
> s1 and s2 should be stored in the stack. In a similar way, after 
> node events we would pop from the corresponding node from the stack.
> 
> 2- Implement the method traversalEvent(EdgeEvent) in APPCBean. 
>    
> What happens here? 
> 
>       First, in a similar way as I do with node events, we would decode
>       EdgeEvent to get an e1 event. The decode will leave 
>       you with an event of the form: 
> 
>          before/after -> source1 target1
> 
>       Karl makes your life even simpler, by sayin that you don't
>       first need to decode. You simply assume someone else does the
>       decoding for you, let say an operation:
> 
>       decode: EdgeEvent -> E1, where E1 is the language defined by 
>       			       Karl's cd
> 
>       Once I have the e1 event ``before/after -> source1 target1'', 
>       I would check whether target1 is also one of the targets 
>       in e2. Let suppose I have the following event in e2:
> 
>         ``before/after ->  source2 target1''. 
> 
>       In this case, I would lookup the stack going backwards to find
>       the node ``source2''. If I find it I would emit the e2 above.
>       If there is no e2 with target1 as its target, or I don't find 
>       ``source2'' in the stack, nothing happens.
> 
> As I said this a skeleton of one of the ways to do your project. Is just 
> for giving you an idea. Please try to get this idea. If you get OK. If 
> not let me know and I will try to be more detailed, may write a pseudo-code. 
> Please don't hesitate to ask. Otherwise we cannot make progress.
> 
> > >>Q 
> > >>(3) The mapping process is still very confusing to me, when is it done?
> > >>I mean, like when the APPC beans are created or ...?
> > >
> > >During our discussion on Friday afternoon 11/20/98, I was told that the 
> > >traversal bean should traverse the objects of the CCG. So the events 
> > >that you recieve will be over the CCG. 
> 
> Exactly. Bill's implementation will call the tarversalEvent(EdgeEvent)
> and tarversalEvent(EdgeEvent) operations you are supposed to implement,
> respectively complete. 
> 
> > >This means the traversal bean must know about the icg, ccg & the 
> > >mapping. The strategy transducer needs to know about the ccg & the 
> > >refined strategy.
> > 
> > yes, that was the idea. Mira and David have pitched in quite a 
> > bit of code to start so that you can do some of the translation
> > with Demeter/Java. 
> 
> A small clarification here. My partial pseudo-implementation assumes
> that the traversal bean simply knows (a) the CCG, (b) 
> the CCG object to start the 
> traversing with, and (c) a strategy for for the CCG, ccg-str. 
> Having CCG and ccg-str the traversal bean gets the ccg-str 
> graph from the AP libraries, traverses the CCG object according te
> the ccg-str graph and in each node or edge of this graph 
> encodes the needed information in an NodeEvent or EdgeEvent
> (the structure of the latter is detrmined by Karl's cd above)
> and sends the operation traversalEvent(NodeEvent/EdgeEvent)
> to all APPC listeners. 
> 
> It is the adaptation functionality
> of the APPC listners that knows about the icg and the mapping
> Rremember an APPCBean has an instance variable of type MapObject.
> It also knows about the ICG objects. It is here that we encapsulate 
> the translation from CCG to ICG according to the map. So, to my
> understanding the traversal beans do not know about concrete 
> ICG's and maps. 
> 
> Is the point I am making here clear ?
> 
> > Maybe the best thing now is that Bill does the summing example
> > (with more help from Mira and David, if needed)
> > and I-Chen the transducer described earlier.
> 
> I also think so.
> 
> 
> Hope have clarified rather than confused with this long mail.
> 
> - Mira
> 
>