first comment from yax implementors perspektive

Dear WG Members,
 
Again a great work! Thank you very much.
 
I was been very nosey for the changes concerning the port issue. So my
first question refers to this point. Why do you define for p:pipeline
input and output ports but for all other containers only output ports?
Although the current version of yax can treat both variants of
containers (only the visualisation has to be adapted) I see the
following consequences if containers have no input ports:
1.	The default case will be that the user has to branch
(imaginative or real) the input port of contained steps with the output
port container of the preceding container. The user has to connect ports
of steps from different levels. Though it's only a question of
convenience and clarity, it has influence on user's acceptance I guess.
2.	Figure 2 "A validate and transform pipeline"  depicts a 'Choose'
which is contained by another compound step (probably a 'Pipeline'
because it has an input port). In this case the input ports of the
contained steps of the 'Choose' step are connected to the input port of
the next higher level. What to do if the compound step if for example a
'Group'?
3.	An empty container stops the process flow because there is no
input port to bridge an empty container. To avoid such a stop some
helping rule as 'empty containers will be discardes', 'by default the
output port(s) of an empty container will be connected to the output
port(s) of the preceding container' or something else.
So if there are no substantial reason(s) to avoid input ports for
containers I suggest the definition of the containers with input ports.
 
It would be nice hearing from you.
 
 
Best Regards
 
Joerg Moebius
OPS Design GmbH, Hamburg
(Implementor of YAX, http://yax.sourceforge.net/)