Re: manifest based processing

Input and output ports can't have the same name (at least in v1, and I
think it should be kept that way for v2 as well). So the kind attribute (or
some other mechanism) would be the way to go here.


Using the kind attribute for automatically connecting multiple ports is
quite the "low-hanging fruit" (in lack of a more creative term). There is
already two kinds of ports in XProc v1; "document" and "parameter".
"document" is the default. The primary input port of kind="document" by
default automatically connects to the primary output port of
kind="document" on the preceding step. Likewise, the primary input port of
kind "parameter" by default automatically connects to the primary output
port of kind="parameter" on the preceding step.

Ports with kind="parameter" behave slightly differently than ports with
kind="document", which I believe will be somehow fixed in
v2<http://www.w3.org/TR/xproc-v2-req/#simplify-parameters>.
For instance, parameter ports always accept sequences of documents (you
can't force it by setting sequence="false"). The syntax of the documents
arriving on a parameter port are not strictly enough defined (imho); you
have to use p:parameters to expose them in a predictably structured
document. p:with-param can be used to modify parameter set documents, but
only on ports with kind="parameter". I hope (and believe) that some of
these peculiarities with parameter ports will be ironed out in v2.

Anyway, simply allowing any string (QName?) in the kind attribute when
declaring steps would be a minor modification to the spec which would help
a lot.


Jostein


On 19 February 2014 17:58, Romain Deltour <rdeltour@gmail.com> wrote:

> Using "in-memory.in" and “in-memory.out" as port names are just
> conventions we (Jostein and I are working on the same project) use to keep
> our port names consistent and readable, but other than that I agree with
> Florent that port names should not be involved in implicit connections.
> That would be too brittle and too limited IMO.
>
> Romain.
>
>
> On 19 févr. 2014, at 17:50, Olivier JEULIN <olivier.jeulin@gmail.com>
> wrote:
>
> > Sorry,  I wanted to reply Jostein
> >
> > About the naming, instead of connecting in-memory.in to in-memory.out,
> > you could name in/out ports "in-memory", and they would connect.
> >
> > 2014-02-19 17:33 GMT+01:00 Olivier JEULIN <olivier.jeulin@gmail.com>:
> >> If I understood correctly,  you want to automatically connect an
> >> output named "A" to an input named "A"?
> >>
> >> Given that the spec v2 proposes in §2.7
> >> “Change all steps with a single non-primary output to have a single
> >> primary output”
> >> could we remove the notion of primary port, and say that, by default,
> >> input ports connect to the first previous (preceding-sibling::*[1])
> >> port of the same name?
> >> We can still define explicitly the binding when we need to connect to
> >> another port or step.
> >
> > --
> > Envoyé depuis Firefox et analysé grâce à Hadoop par la NSA (via
> Gmail©®™) 😏
> >
>
>
>