(again) make defining connections easier

(ignore the previous version of this sent earlier)

Recently we floated an optimisation [1] to help make life easier
defining defining connections between steps.

The problem could be summarised;

* rationalising pipeline to take advantage of default flow gets more
expensive over time

* a single 'break' in the flow begets multiple explicit connections

* nesting down three elements (px:stepname->p:input->p:pipe) is
tedious and produces cognitive load

Herewith the distillation from subsequent list comments and discussions;

We now propose the definition of a new attribute named 'pipe, which
semantically maps with existing p:pipe element (and redolent of unix |
). The pipe attribute value, in its simplest form, would contain a
step name. So the following pipeline (using pipe attribute) looks like

        <p:pipeline>
           ...
           <p:identity name="mystep"/>
           <p:wrap-sequence name="otherstep" ... />
           <p:count pipe="mystep"/>
           ...
        </p:pipeline>

and would act as if the following.

        <p:pipeline>
           ...
           <p:identity name="mystep"/>
           <p:wrap-sequence name="otherstep" ... />
           <p:count>
              <p:input port="source">
                  <p:pipe step="mystep" port="result"/>
              </p:input>
           </p:count>
           ...
        </p:pipeline>

We need to provide an addressing schema which clearly shows that this
is not xpath ... but its difficult. I have assembled a few thoughts
below;

* not-matched@mystep seems ok but unsure about the usage of 2 ncnames
as localpart@(FQ)DN ... I like it

* otherwise the alternatives are slippery slope
      * avoid dot style, eg. clashes with our default step naming !1.1.1
      * avoid colon and usage w/ 2 ncnames, clashes with definition of
qualified name
      * xml:id (idrefs) ... #mystep:not-matched has its merits, but unattractive
      * xlink equally unattractive

We can hash this out in todays meeting.

The following is a list of usage scenarios;

* pipe attribute contains step name, will take default readable port
from that step, into default primary input port
        <p:pipeline>
           ...
           <p:identity name="mystep"/>
           <p:wrap-sequence name="otherstep" ... />
           <p:count pipe="mystep"/>
           ...
        </p:pipeline>

* pipe attribute contains multiple step names, will take default
readable port from each step and equiv to multiple p:pipe,  into
default primary input port
        <p:pipeline>
           ...
           <p:identity name="mystep"/>
           <p:wrap-sequence name="otherstep" ... />
           <p:count pipe="mystep otherstep"/>
           ...
        </p:pipeline>

* pipe attribute contains step/port reference, to access some other
port (other then default readable), into default primary input port
        <p:pipeline>
           <p:split-sequence name="mystep" .../>
           <p:count pipe="not-matched@mystep"/>
           ...
        </p:pipeline>

* pipe attribute could be defined on p:input
        <p:pipeline>
           <p:split-sequence name="mystep" .../>
           <p:count>
            <p:input port="source" pipe="not-matched@mystep"
select="/*[@valid]"/>
           </p:count>
           ...
        </p:pipeline>


seeking comments from the WG for discussion today.

J

[1] http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2014Nov/0025.html

Received on Wednesday, 3 December 2014 10:57:12 UTC