Re: first comment from yax implementors perspektive

/ joerg.moebius@hamburg.de was heard to say:
| 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?

How else would you bind the external inputs and outputs to the
pipeline?

For all other containers, the ports that can be read are already
visible so it isn't necessary to declare inputs for them.

My original, personal view was that no container should be able to see
outside itself. Then the p:inputs would have been necessary for
binding all the external connections. But the WG shot that down, and
as soon as the rest of the ports became visible, it seemed redundant
to (re)declare them.

| 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.

Yeah. The consensus of the WG was that that was a feature.

| 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'?

The default input port is inherited by the group, but otherwise the
steps in the p:choose will have to have bindings back to the outputs
From which they wish to read.

| 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.

Yes. I don't think empty containers have really been considered
carefully enough.

| So if there are no substantial reason(s) to avoid input ports for
| containers I suggest the definition of the containers with input ports.

To what end? Consider:

  <p:identity name="foo">
    <p:input>
      <p:document href="foo.xml"/>
    </p:input>
  </p:identity>

  <p:group name="bar">
    <p:input port="myinput">
      <p:pipe step="foo" port="result"/>
    </p:input>

    <p:xslt>
      <p:input port="source">
        <p:pipe step="foo" port="result"/>
      </p:input>
      <p:input port="source">
        <p:pipe step="bar" port="myinput"/>
      </p:input>
  </p:group>

What has the addition of the p:input on group given you? The steps
inside can still reach outside.

| It would be nice hearing from you.

Sorry we've been a little slow about getting to comments. We'll try to
do a better job.

| (Implementor of YAX, http://yax.sourceforge.net/)

Very cool. I've been heads-down on my own implementation so I haven't
taken a look, but I'm happy to see more impls.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh
XML Standards Architect
Sun Microsystems, Inc.