Question on the prose of p:run

[xml-project]

The spec says:

The default readable port of the p:run step becomes the default readable port of the pipeline.

I do not understand this sentence. The notion of a "default readable port of a step" seems odd and is not used in the steps anywhere. Since p:run has no declared input ports, none of them is primary, so connecting to the default readable port makes no sense to me here.

Apart from that, how is an implementation of p:run supposed to know that the processor connected some port to the default readable port.

Could somebody tell me, what I missed? Or may be its just legacy and should simply be deleted.

[ndw]

Consider:

<p:identity name="xyz">...</p:identity>
<p:run name="abc">...</p:run>

I think what that sentence about the DRP is trying to say is that the primary output port of the xyz step (the DRP for the p:run step) should be connected to the primary input port of the pipeline that abc runs, irrespective of its name.

Does that make sense?

[xml-project]

@ndw Thanks for explaining. But I am not sure that the p:run implementation is able to known, which of it's ports was connected by the DRP-mechanism and which not. The documents are just there. Did I miss something?

[ndw]

It's possible that explanation makes no sense today, the XProc language has changed some and the p:run step has changed some since it was written. If you don't think it makes sense, feel free to delete it!

[gimsieke]

I’d expect that the primary input port of the dynamically executed pipeline will be connected to the DRP. I think we need to discuss this in the next call.

[xml-project]

The problem is, that p:run does not have a primary input port, as it has no declared ports at all. If we give p:run a declared port (say source) which is primary, the processor would know, that the DRP has to be connected to source of p:run. And then the implementation of p:run knows which is its primary input port and can supply the respective documents to the primary input port of the pipeline to run. Does that make any sense?

[xatapult]

@xml-project I'm not sure I follow you completely, so maybe this is a copy of what you were saying? But I would prefer:

I think p:run should have a primary input and output port (both sequence="true"). These ports will always be connected to the primary input and output ports of the step that is run, whatever their names.

If the step that is run has no primary input port, what is flowing into the primary input port of p:run disappears into the big black void.

If the step that is run has no primary output port, the result of the primary output port of p:run will always be empty.

[xml-project]

I wonder whether we confuse authors when all inputs to p:run are delivered to the input port with the same name in the pipeline to be run except p:run/p:source which is connected to the port declared as primary (what ever its name is). But may be its only an edge case and p:run is tricky anyway.

[ndw]

Going back to my previous example:

<p:identity name="xyz">...</p:identity>
<p:run name="abc">...</p:run>

Whatever pipeline is run, if it has a primary input port, I expect that primary input port to be connected to the result output of p:identity regardless of the port's name. (Unless there's a different binding for it in the p:run, of course.)

Does that make sense, or am I confused?

[xml-project]

@ndw Hhm, not sure. As I understand the proposal you and @gimsieke made, the idea is that p:run has no fixed signature, but that the signature of p:run is dynamically created by p:with-input and p:with-option. Those inputs/options are then mapped to the pipeline document appearing on one of these ports. Right? But then in your example: The output of p:identity is first connected to one of the (virtual) input ports of p:run and the documents delivered to this port are delivered to the pipeline as p:run runs. Right? If I understood your proposal right, then p:run does not have a primary input port the processors knows of. And therefor it can not connect p:identity's primary output port automatically. The way around that I proposed (and @xatapult seems to have a similar idea) is that p:run has one declared input port which is the primary input port. All other ports are declared on the fly as described above. Was I able to make my point?

[gimsieke]

I’d rather prefer that we add @sequence, @primary, and @content-types as attributes to p:run/with-input so that we can inform the processor about the signature of the pipeline that it can expect to receive. If these attributes seem odd on p:run/p:with-input, we can rename it p:input.

[xml-project]

What is better with p:input then with p:with-input? What about p:run-input. If we invent a new element for this we do not need to change the syntax of p:with-input (for all the other steps in the spec) or the semantics of p:input.

I am not sure we really need @sequenceand @content-types on p:run/p:with-input. [deleted] The check of cardinality and content type can be done when the pipeline is called in p:run. And there you can declare whatever you want without overloading (or hijacking) existing constructs.

So the only thing we need (from my perspective) is primary if you want primary connections. I am not sure about this. I would prefer not to have default connections at all if it come with such a price as your last suggestion. P.S: Do you propose to add @required p:with-option (or p:option)?

[gimsieke]

overtaken by events