- From: Achim Berndzen <achim.berndzen@xml-project.com>
- Date: Tue, 5 Sep 2017 17:17:28 +0200
- To: XProc Dev <xproc-dev@w3.org>
May be the easiest way to solve this, is to say, that it is a static error, to designate different ports as primary (either implicit or explicit). (Change XS0009 to „It is a static error if p:group, p:catch and p:finally pipelines designate different ports as primary.“ As Vojtech pointed out, it is not clear what the primary output port of p:try would be, so any connection to this port from a third step does not make sense. So in Vojtech’s example an error would be raised and pipeline authors will remember they have to say <p:output port="animal“ primary="false“ />. This will be a common mistake, so may be it is an idea to say that for p:group etc. @primary="false“ is default. > Am 05.09.2017 um 13:30 schrieb Toman, Vojtech <Vojtech.Toman@dell.com>: > > I think this would be a step in a good direction. But note that the subpipelines can designate different ports as primary, so there would have to be a mechanism to resolve/prevent that: > > <p:try> > <p:group> > <p:output port="animal"/> > … > </p:group> > <p:catch> > <p:output port="flower"/> > … > </p:catch> > </p:try> > > In the above example, both "animal" and "flower" are primary, so what would be the primary output of the p:try? > > Regards, > Vojtech > > -----Original Message----- > From: Norman Walsh [mailto:ndw@nwalsh.com] > Sent: Sunday, September 03, 2017 8:45 PM > To: XProc Dev > Subject: What if we were more relaxed about “matching signatures” > > We care about input and output ports in several places. > > 1. Uncontroversially, I think, atomic steps declare their ports and it’s a static error to attempt to write to a input port that doesn’t exist or read from an output port that doesn’t exist. (There’s a separate question of whether we should provide a mechanism for declaring steps that have a variable number of ports, let’s leave that aside for the moment.) > > 2. Pipelines can be declared to have any number of input or output ports. When you’re calling them, the constraints are the same as for atomic steps. I don’t think that’s controversial either. > > 3. Subpipeline containers (group, when, otherwise, catch), can declare any number of outputs, subject to consistency constraints. > > Suppose we relaxed those constraints. Consider: > > <p:try> > <p:group> > <p:output port="animal"/> > … > </p:group> > <p:catch> > <p:output port="animal"/> > <p:output port="plant"/> > … > </p:catch> > </p:try> > > Currently, that’s an error. What if we said it wasn’t an error. What if we said that the “try” has two outputs: “animal” and “plant”. In the case where the “group” succeeds, the output on “plant” is simply the empty sequence. > > Similarly, in the p:choose case: > > <p:choose> > <p:when test="…"> > <p:output port="animal"/> > <p:output port="plant"/> > … > </p:when> > <p:when test="…"> > <p:output port="plant"/> > <p:output port="mineral"/> > … > </p:when> > <p:otherwise> > <p:output port="animal"/> > <p:output port="mineral"/> > … > </p:otherwise> > </p:choose> > > We could say that this choose has three outputs, “animal”, “plant”, and “mineral”. One of them will produce the empty sequence, depending on which branch is chosen at runtime, but it’s still there. > > Users can make all the signatures the same, in which case they’ll get the same behavior as in 1.0. And of course, if you connect something to a port that will sometimes be empty, the thing you connect to it had better take a sequence. > > This came up in the course of thinking about a “finally” clause for > try/catch: > > <p:try> > <p:group> > <p:output port="result"/> > … > </p:group> > <p:catch> > <p:output port="result"/> > … > </p:catch> > <p:finally> > <p:output port="finally"/> > … > </p:finally> > </p:try> > > In the current try/catch and choose/when designs, exactly one branch will run, so the output you get is from whichever branch > (group/catch/when/otherwise) actually ran. > > But if we introduce finally, *two* branches will run. If finally has to put it’s output on “result” (to make the signatures match), then you’re going to get multiplexed results on the result output port. > > There are a few options: > > 1. Forbid the finally branch from having any output. That seems to limit finally pretty substantially. > > 2. Require that group/catch also have a “finally” output port to keep the signatures the same. That’s a real inconvenience for users. > > 3. Create a magic port: say that the “finally” port always exists and is magically plumbed to the finally branch. (Yuck.) > > 4. Relax the constraints as I’ve described above. > > On the whole, I think I prefer 4. But maybe I’m overlooking something. > > Be seeing you, > norm > > -- > Norman Walsh > Lead Engineer > MarkLogic Corporation > Phone: +1 512 761 6676 > www.marklogic.com
Received on Tuesday, 5 September 2017 15:17:57 UTC