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

Parameters and options

From: Norman Walsh <Norman.Walsh@Sun.COM>
Date: Mon, 16 Apr 2007 11:39:26 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <87odlopbv5.fsf@nwalsh.com>
Consider:

  <p:declare-step type="px:debug">
    <p:parameter name="*"/>
    <p:option name="opt1"/>
    <p:option name="opt2"/>
  </p:declare>

Then, I believe our intent is that the following is legal:

  <p:load name='loader'>
    <p:input port="source">
      <p:inline>
        <doc/>
      </p:inline>
    </p:input>
  </p:load>

  <px:debug>
    <p:parameter name="elemcountplus1" select="$elemcount+1"/>
    <p:parameter name="elemcount" select="count(//*)">
      <p:pipe step="loader" port="result"/>
    </p:parameter>
  </px:debug>

And it's up to implementations to make sure that parameters get
evaluated in the right order and that there are no circular
dependencies. (In this case, elemcount=1 and elemcountplus1=2.)

I assume that options and parameters are in entirely different
namespaces, so:

  <px:debug>
    <p:parameter name="opt1" value="3"/>
    <p:parameter name="opt2" select="$opt1+1"/>
    <p:option name="opt1" value="5"/>
    <p:option name="opt2" value="$opt1+1"/>
  </px:debug>

Means the px:debug component gets two parameters, opt1 and opt2, with
the values 3 and 4, respectively, and two options, opt1 and opt2, with
the values 5 and 6, respectively.

Right?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh
XML Standards Architect
Sun Microsystems, Inc.

Received on Monday, 16 April 2007 15:39:37 GMT

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