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

Re: defaulting

From: Norman Walsh <ndw@nwalsh.com>
Date: Mon, 25 Jun 2007 10:43:32 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <87myyogkmj.fsf@nwalsh.com>
/ Richard Tobin <richard@inf.ed.ac.uk>, Henry Thompson <ht@inf.ed.ac.uk> was heard to say:
| Further to discussion during yesterday's telcon, herewith a proposal
| about input and output defaulting for pipelines.
| It basically adopts Richard's suggestion that a pipeline's inputs/outputs
| default if there is a need for them to do so, because their first
| component needs an input/final component produces an output.
| Here's how this works in detail:
| 1) We make defaulting more symmetrical for p:input and p:output, by
|    adding a 'default' attribute to p:input, allowed only in
|    declaration contexts (as there already is one on p:output).  An
|    input to a step is _the_ default input iff
|   a) it is the only declared input and it was not declared with
|      default='no';
| or
|   b) it is declared with default='yes'.
|   It is an error to declare more than one input as default='yes'.
|   It is _not_ an error to have no default inputs.
|   It is _not_ an error to have no default outputs (this is a change).

I don't think that's a change. Unless you meant to write "It _is_ an
error to have no default outputs."

|   The default input of a step is bound to the default readable port if
|   it is not otherwise bound;
|   Non-default inputs are only bound to the default readable port if
|   you call for that to happen by writing
|    <p:input port="not-the-default-input-port"/>

So it's an error to leave a non-default input unspecified? What's the
value of this change?

| 2) Pipelines w/o a declared default input get an un-named default
|    input iff their first contained step has an unbound default input.


| 3) Pipelines w/o a declared default output get an un-named default
|    output iff their last contained step has an unbound default output.


| This means that not only does
|  <p:pipeline>
|   <p:identity/>
|  </p:pipeline>
| do the obviously right thing, but so does
|  <p:pipeline name='top'>
|   <p:input port='stylesheet' default='no'/>
|   <p:xslt>
|    <p:input port='stylesheet'>
|      <p:pipe step='top' port='stylesheet'/>
|    </p:input>
|   </p:xslt>
|  </p:pipeline>
| To construct a pipeline which has no input, just start it with a step
| which needs no default input, e.g.
|  <p:pipeline>
|   <p:identity>
|    <p:input port='source'>
|     <p:document href="http://www.example.org/fixedInput.xml"/>
|    </p:input>
|   </p:identity>
|   .  . .
|  </p:pipeline>
| This is the obvious case for a pipeline with no input, that is, a
| pipeline with a fixed input.


| Exactly parallel, to construct a pipeline which produces no output,
| just end it with a step which produces no default output.
| We currently don't have an easy way to do this, but by analogy with
| the previous (pipeline with fixed input) example, a pipeline with
| fixed output _ought_ to be such a case:
|  <p:pipeline>
|   . . .
|   <p:store href="http://www.example.org/fixedOutput.xml"/>
|  </p:pipeline>
| To accomplish this, we propose two additional related changes:
| 4) The declaration for p:store should change to look like this:
|  <p:declare-step type="p:store">
|   <p:input port="source"/>
|   <p:output port="result" default="no"/>
|   . . .
|  </p:declare-step>
|  That is, p:store _has_ no default output.

Bleh. I suppose I can live with it, but I'd be happier, personally, if
pipeline authors creating pipelines with no output were required to
end with a p:sink step.

| 5) It _is_ an error for the _default_ output of a step to fall on the
| floor.


                                        Be seeing you,

Norman Walsh <ndw@nwalsh.com> | The trip doesn't exist that can set you
http://nwalsh.com/            | beyond the reach of cravings, fits of
                              | temper, or fears. If it did, the human
                              | race would be off there in a body.--
                              | Seneca

Received on Monday, 25 June 2007 14:43:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:43 UTC