Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default connection of input ports #544

Closed
xml-project opened this Issue Sep 21, 2018 · 4 comments

Comments

Projects
None yet
3 participants
@xml-project
Copy link
Contributor

commented Sep 21, 2018

As @ndw stated rightly in yesterdays discussion on issue #542 , the specs (last paragraph) say:

A default connection does not satisfy the requirement that a primary input port is automatically connected by the processor, nor is it used when no default readable port is defined. In other words, a p:declare-step can define defaults for all of its inputs, whether they are primary or not, but defining a default for a primary input usually has no effect. It's never used by an atomic step since the step, when it's called, will always connect the primary input port to the default readable port (or cause a static error). The only case where it has value is on a p:declare-step when that pipeline is invoked directly by the processor. In that case, the processor must use the default connection if no external connection is provided for the port.

This paragraph is taken from the 1.0 specification. I think we can completely remove it and state the new rule

that a step that has an input port that's unbound, if there is no default readable port, will use the declared default for that port.

With regard to 1.0 compatibility I think this change of concept shouldn't be a problem: A pipeline, that had a static error in 1.0 (unconnected input port) will now run in XProc 3.0 if there is a default binding for the port. A 1.0 pipeline that executed correctly will also do so in 3.0 because it has an actual binding, so the default binding is newer used.

@ndw

This comment has been minimized.

Copy link
Contributor

commented Nov 1, 2018

I'm ambivalent.

<p:sink/>
<p:identity/>

will always be an error because p:identity has an unbound primary input port.

<p:sink/>
<ex:step/>

Will be an error if ex:step has an unbound primary input port unless it has a default in which case the default will be used.

I can imagine an author editing a pipeline, replacing ex:step with ex:alternate and being surprised by the sudden introduction of a static error in the pipeline.

But I'm not going to fight hard against it if that's where consensus falls.

@eriksiegel

This comment has been minimized.

Copy link
Contributor

commented Nov 1, 2018

Didn't we decide that input ports no longer have to be connected?

@ndw

This comment has been minimized.

Copy link
Contributor

commented Jan 6, 2019

I don't recall that we said input ports could be unconnected. I assume that an unconnected input would act as if it was connected to p:empty; I think that "empty" inputs are uncommon enough that it would be a usability mistake to silently create them. I think it's more likely that an unconnected input is an error than should be empty.

With respect to @xml-project 's proposal above, I assume that it's an error if the unconnected port has no default.

@eriksiegel

This comment has been minimized.

Copy link
Contributor

commented Jan 7, 2019

I was mistaken. Yes:

it's an error if the unconnected port has no default.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.