W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > July 2007

Parameters and pipelines proposal

From: Norman Walsh <ndw@nwalsh.com>
Date: Wed, 11 Jul 2007 12:04:10 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <877ip79bb9.fsf@nwalsh.com>
The following proposal is essentially Henry's revised proposal with
the amendments that seemed to garner support in email. I believe it
provides a concrete answer for all of the open questions.

 1) We add the concept of a 'primary parameter input port'. By analogy
    with "ordinary" primary input ports: a step can have at most one;
    if it has exactly one parameter input then that's the primary by
    default.

 2) If a pipeline contains a step which has a parameter input port and
    if the pipeline has no parameter input ports declared, then it gets
    an anonymous, primary parameter input port by default.

 3) We add an optional 'port' attribute to p:parameter. If the port is
    specified, then the parameter goes to the named parameter input
    port. It's an error if no such parameter input port is declared. If
    the port is not specified, then the parameter goes to the primary
    parameter input port. It is an error if the step has no primary
    parameter input port.

 4) How an implementation determines what parameters are passed to the
    initial pipeline is implementation defined.

 5) Normal binding rules apply to the use of a step (including a
    named pipeline step)

 6) If a step has a primary parameter input port and if no binding is
    specified for that port then the default binding is to the
    primary parameter input port of the pipeline which contains it.

    If the pipeline which contains it has no PPI, then it is bound
    to p:empty. This can only arise in cases like this:

    <p:pipeline ...>
      <p:input port="parameters" primary="no"/>
      ...

    Alternatively, we could make it an error to leave an unbound PPI
    on a step in this case.

 7) If a binding is manufactured for the primary parameter input port,
    it occurs logically "last" among the bindings on the step. In
    other words, parameters specified on that parameter port will
    override explicit p:parameter elements on that step.

 8) If a step has a parameter input port that is not primary and if no
    binding is specified for that port then the default binding is to
    p:empty.

 9) Allow p:parameter elements on p:pipeline.

10) The declaration of a parameter input port must be empty. It is a
    static error to attempt to define a default input.

Have I missed anythin?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | An ill-humoured man is a prisoner at
http://nwalsh.com/            | the mercy of an enemy from whom he can
                              | never escape.-- Sa'di

Received on Wednesday, 11 July 2007 16:04:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:53 GMT