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

Choose and related issues

We then spent a fair amount of time discussing how to structure and refer to inputs/outputs of chooses.

At least for the present, we have decided that:

1. we will have two attributes:
   • source which will be a URI reference to a web resource
   • ref which will point to a port within the current pipeline
2. we will use compound names to reference ports, and the character separating step names from ports will be something like ! (but possibly some other non-name, ascii character).
3. choose has a number of when's and an otherwise, and each when and the otherwise includes declare-output statements for the outputs it creates, and the all the branches declare the same set of output ports.

Port names and references are scoped by the component that defines them.

We decided that we would allow ref/source on choose to specify the context for the when tests; one can also have ref/source on when's that override that (if any) on the choose; finally one doesn't need to specify a context at all if the xpath tests on the when's don't require a context. (Henry would like, in the future, to be able to have the output of the last step be the default context, but we are holding defaulting to later.)

It is an error for any choose or when to have both ref and source assigned. It is an error for the ref attribute to return zero or more than one document.

for-each and related issues

We had an extended discussion that seguéed into other questions such as whether inputs can have selects.

We decided (at least for the moment):

1. we would stick with declare-input, input, and add iteration-input
2. a for-each would have exactly one input, zero or more declare-output, exactly one iteration-input, and one iteration-output for each declare-output
3. we would allow select on input
4. for-each would have input, output, iteration-input, iteration-output per something like the following example:

   <for-each name="x">
     <input port="primary" ref="..." [select="..."]/>
     <declare-output port="result"/>
     <iteration-input port="chap"/>
     <iteration-output ref="b!c" aggregation-ref="result"/>
     <step name="b" kind="xxx">
       <input port="document" ref="x!chap"/>
       . . .
     </step>
   </for-each>

   where “c” is some output port declared on components of type xxx.

We then agreed that the declare-output above is obvious and can be omitted (and, therefore, we will perhaps require it to be omitted in the final syntax).

Let the minutes record that about half the august assembly felt the above was terribly gross, but some (including your faithful scribe) felt this was the most understandable proposal discussed during the day.

Though we had previously decided (based on Richard's suggestion) that steps don't need output statements, Norm suggested we allow (optionally) the (appropriate) output statement on which we'd allow some attribute(s) to indicate that the given output is tossed (without error) and/or how to serialize it.

Issue: It is unclear how to provide the documents produced by other steps in your pipeline to an xquery or xslt component as a collection. (It is unclear whether we need to solve this in V1.0 of the pipeline language.) This led to a discussion of a possible “resource” element that mapped URIs to ports and to issues of running the pipeline in document order.