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

Re: XProc Minutes for Technical Plenary f2f, 8/9 Nov 2007

From: Norman Walsh <ndw@nwalsh.com>
Date: Mon, 12 Nov 2007 11:45:11 -0500
To: public-xml-processing-model-wg@w3.org
Message-ID: <m28x53mmzs.fsf@nwalsh.com>
/ Norman Walsh <ndw@nwalsh.com> was heard to say:
| Comment 29
|
| Much discussion of the various options...
|
|   <p:input no-input=true no-output=true
|
|   Input and output declarations are required on p:pipeline
|
|   1. Always require the declarations
|
|   2. Add a new 'stdio' attribute, defaults to true, and if true:
|
|     a. You get primary input and output declarations, if necessary
|
|     b. There must be no declarations of any kind and you get one stdin
|        and one stdout
|
|   3. Add new attributes to allow the author to suppress stdin/stdout
|
| Proposed resolution: You must declare them on p:pipeline; no magic
| defaulting of stdin and stdout.

I believe that deleting the following text from Section 2.3 implements
this decision:

  Additionally, if a p:pipeline has no declared inputs and the first
  step in its subpipeline has an unbound primary input, then an
  implicit primary input port (named “source”) will be added to the
  p:pipeline (and consequently bound to the first step's primary input
  port). If a compound step has no declared outputs and the last step
  in its subpipeline has an unbound primary output, then an implicit
  primary output port (named “result”) will be added to the compound
  step (and consequently the last step's primary output will be bound
  to it).
  
  The practical consequence of these rules is that straightforward,
  linear pipelines are much simpler to read, write, and understand.
  The following pipeline has a single input which is transformed by
  the XSLT step; the result of that XSLT step is the result of the
  pipeline:
  
  <p:pipeline xmlns:p="http://www.w3.org/ns/xproc">
  <p:xslt>
    <p:input port="stylesheet">
      <p:document href="docbook.xsl"/>
    </p:input>
  </p:xslt>
  </p:pipeline>
  
  It is semantically equivalent to this pipeline:
  
  <p:pipeline name="main" xmlns:p="http://www.w3.org/ns/xproc">
  <p:input port="source"/>
  <p:input port="parameters" kind="parameter"/>
  <p:output port="result">
    <p:pipe step="transform" port="result"/>
  </p:output>
  
  <p:xslt name="transform">
    <p:input port="source">
      <p:pipe step="main" port="source"/>
    </p:input>
    <p:input port="stylesheet">
      <p:document href="docbook.xsl"/>
    </p:input>
    <p:input port="parameters">
      <p:pipe step="main" port="parameters"/>
    </p:input>
  </p:xslt>
  
  </p:pipeline>
  
  (Parameter input ports are a special case discussed in Section 2.5, “Parameters”.)

As a consequence, p:pipeline elements must declare all of their
inputs. and all compund steps, including p:pipeline, must declare all
of their outputs. The special case of default parameter inputs remains
unchanged.

Anyone disagree?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Everything should be made as simple as
http://nwalsh.com/            | possible, but no simpler.

Received on Monday, 12 November 2007 16:45:40 GMT

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