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

Thursday morning.

Parameters

Norm:
  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

Decision:

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

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=>.

Variables

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.

Decision:

 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.

Question:

  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