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 ). Is XSLT a special case because it has user-defined parameters? Jeni: passing stylesheet parameters in to XSLT 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 in a component definition make the parameter be required (required to appear in the ). Can use to pass them through. More discussion of whether we should have . 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 (explicit) and (which takes them from the current context). Pipelines and component definitions have which may make a parameter required (there must be a 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 text). 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 was really just a variant of . We discussed this further but agreed to continue with . 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 . No decision. ========== break for lunch