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

Minutes for the XML Processing Model WG f2f 2006 August 3 morning

From: Richard Tobin <richard@inf.ed.ac.uk>
Date: Thu, 3 Aug 2006 18:47:54 +0100 (BST)
To: "public-xml-processing-model-wg" <public-xml-processing-model-wg@w3.org>
Message-Id: <20060803174754.C39007100B9@macintosh.inf.ed.ac.uk>

Thursday morning.


  describes non-controversial aspects of parameters
  components can have both required and optional parameters
  xslt: two kinds of parameter:
    parameters to the component (e.g start template)
    stylesheet parameters
    use a pipeline namespace to identify the (standard) processor parameters
    maybe have a different element (in implementation namespace) for
      implementation-specific processor parameters

Henry: need to bind namespace prefixes for parameter values
Alex: more generally need a component context

Discussion of whether using namespaces to identify component parameters,
or a different element (eg <cparam>).

Is XSLT a special case because it has user-defined parameters?

Jeni: passing stylesheet parameters in to XSLT
  <param name="sectNo" select="$sectNo"/>
but also want params passed through with knowing them in advance.

Henry and Norm: in that case should have a single parameter binding
element and use qnames.  That way components can inherit a "pool"
of parameters.

Alex: would have too many parameters getting passed to everything

Perhaps have a way to import some or all parameters from the pool

Henry: have <param> in a component definition make the parameter
be required (required to appear in the <step>).  Can use
<param name="x" select="$x"/> to pass them through.

More discussion of whether we should have <cparam>.

Most think required parameters must appear explicitly, not be
inherited from the pool.

... more discussion not captured ...

Are parameter values strings? - discuss later

Murray: can we define defaults for parameters?  - probably


A component is passed a set of qname-value pairs provided by <param>
(explicit) and <import-param> (which takes them from the current

Pipelines and component definitions have <declare-param> which may
make a parameter required (there must be a <param> for it), optional,
or give it a default.  If optional and not provided or imported no
such parameter is passed to the component.

End decision.

Are parameters strings?  Yes.
can get them using ref= and select= to extract them from documents.

Alex argues that we should not allow access to arbitrary ports in
parameter computations for a step, but should have a mechanism for
binding parameters to computed values within a scope.  But we agree to
allow ref= and select=.

Should we have a value= to avoid having to doubly-quote in select=
(or use content <param name="foo">text</param>).  For now, have all
three: select=, value=, and content.

========== break for coffee

Murray asked it to be recorded that at least two people thought
that <param ref=> was really just a variant of <input>.  We discussed
this further but agreed to continue with <param ref=>.


Jeni suggests variables bound to nodes, e.g. for common long paths
into a config file.  But we can do this with a step that produces a
document containing the node.  That is, output ports are like
variables containing documents.

Mohamed: if you could have extra (undeclared) inputs on steps, you
could do the selection there and use the input port as a variable.

more discussion of extra inputs
Alex points out three uses: 
 component that uses an arbitrary number of inputs known at compile time
 component that runs an unknown pipeline
 to establish dependencies

Richard+Henry: pipelines can give you both document and string "variables".

Proposal: that there be an "nlambda" mechanism that allow an arbitrary
number of known-at-compile-time inputs (eg aggregator).

discussion of whether it's necessary for all components to accept
arbitrary issue.


 It will possible to declare that a components takes arbitrary inputs
 in addition to its declared ones.  (like &rest rather than nlambda)

 The question of identifying dependencies is deferred.
 The question of optional inputs is deferred.


  Can pipeline inputs have default values?  If so can they depend on
  other inputs? (e.g. to extract a subtree of a config file)
Murray asks about the mapping from command line arguments.  It's
implementation-defined (i.e. implementations must document it).

More discussion of for-each.  Jeni produces simpler syntax by starting
with a for-each containing a single pipeline and gradually deleting
unnecessary parts.  Richard imagines pseudo-component-definition for
for-each using <allow-other-outputs>.  No decision.

========== break for lunch
Received on Thursday, 3 August 2006 17:48:04 UTC

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