See also: IRC log
Richard gives possible regrets. Andrew gives regrets.
Nothing new to say; keep thinking about it.
Henry: I don't think I feel any
differently this week: it all ought to work.
... I ought to be able to write straight-through pipelines including both components and atomic steps.
Richard: I agree with Henry's aim, but I remain concerned that doing so will make it less natural to write fully elaborated pipelines.
Henry recalls off-line discussion with Richard
Henry: Suppose we add an
attribute to containers to specify how many output ports it
has. It defaults to 1.
... Because absence was being overloaded in the default syntax.
Norm: How about simply an attribute to say "this component has no outputs"
Henry: That works.
Richard: It does cover the only case where there was an ambiguity.
Norm asks about the defaulting story.
Alex: What about an input that becomes an output.
Proposal: The editor shall attempt to write up the defaulting story as we've described it here, with some mechanism for dealing with the single ambiguity we can see.
Norm: this is the use of xpath-context instead of input for the choose/when.
Alex: We have the issue that the
XPath works differently.
... In the examples that we have here, Henry matches against an attribute node where we have an input everywhere else.
... If you use input, you always get a document. On xpath-context, Henry's proposing that it's a node, not a document.
Norm: My inclination would be to
keep them the same, and wrap the matches that xpath-context
returns in a document node.
... This would make the XPath expression a little odd, but would be consistent.
Alex: But that's not what the author would expect.
Alex recounts an XSLT example.
Norm: Ok, the other alternative is to make it different.
Richard: I'm in favor of it being a document because apart from this, we pass documents everywhere.
Alex: If we go the document route, then this could be better if xpath-context would be a wrapper for input.
Henry: I'm happy with the resolution that it's a document.
Proposal: Describe the result of select expressions as a document.
<MSM> if I select //foo, how many documents do I get?
Henry: Parenthetically, it should be said that without the select expression the result is a document.
<MSM> count(//foo) ? or the number of //foo that don't have a foo ancestor?
Norm: Whatever you get for input, you should get here.
Richard: Isn't this supposed to be a context *node*"
Henry: I agree. There's no way to do unfolding or iteration at this level.
<alexmilowski> 4.2.2: "... Each matching node or set of nodes is wrapped in a document and provided to the input port."
Henry: I'd like to make it an error if the select expression doesn't match a single element node.
<alexmilowski> ...but later: "...provides a sequence of zero or more documents, one for each matching html:div in the document "
Norm: I'd be happy to impose that restriction.
<MSM> so: 'set of nodes' just means 'subtree' here, and if you have a div within a div, each of them gets wrapped as a document (so one of them goes through twice, once as root element and once as descendant)
<MSM> If getting zero is OK, I don't quite understand why getting n > 1 istn't ok
Henry: The results should be just like concatenating the two expressions, the select on xpath-context and the test on when. It follows that zero would fall through to the otherwise.
Alex: I think we have an issue about an empty sequence of documents.
Henry: That's the what does select=not(/) mean on input questoin.
Proposal: We'll say select on xpath-context must match exactly one element or document, otherwise it's an error.
<scribe> ACTION: Editor to clarify the text in 4.2.2 [recorded in http://www.w3.org/2007/02/08-xproc-minutes.html#action01]
<MSM> [I'd like to be sure I understand our rationale. If we want the kind of flexibility we'd get from allowing 0 or n, what we can do is not write a select on the xpath-context element, and write a longer test on the when ... is that right?]
<MSM> [I do wish the spec would talk about data sources and data sinks, insted of input and outputs ...]
<richard> that's what we considering michael: that both outputs of earlier components and inputs of ancestor components are data sources
MSM: the outputs property in the context are the set of data sources
<ht> ... inside a construct, the outputs of your siblings, and the construct's inputs, are available to you
Norm attempts to provide an example:
<p:pipeline name="pipe"> <p:input port="foo"> <p:step> <p:input port="xxx"> <p:pipe step="pipe" port="foo"/> ...
Norm: The first step can read from "foo" because it's exposed as an available input. Similarly:
<p:for-each name="iter"> <p:input port="source"> <p:step> <p:input port="xxx"> <p:pipe step="iter" port="source"/> ...
Norm: The first step of the for-each can read from "source" because it's exposed as an available input.
<ht> AM: The construct's contents can _already_ point to the same things that the inputs point to
<ht> NW: See above example, works because the pipeline's input are in the available inputs of the context for the step
<ht> AM: 'pipeline' is special, because there's no outer context
<ht> ... we don't _need_ this for for-each and viewport
<ht> RT: I think AM has a point, there would be no problem if we didn't do this, _except_ for pipeline
Henry: I like what Alex is saying. Pipeline inputs are different.
<ht> RT: we could provide some _other_ means for users to bind pipeline I/O
Richard: We could say that invoking a pipeline creates a context which must include certain things.
Alex: We discussed this last week, but I don't remember why this came up.
Norm tries to reconstruct how we got here
<ht> HST: Norm, I think your example would be clearer wrt Alex's point if it were completed (?) by having <p:input port="source"><p:pipe step="x" port="y"/></p:input>
<p:for-each name="iter"> <p:input port="source"> <p:pipe step="somewhereelse" port="someport"/> </p:input> <p:step> <p:input port="xxx"> <p:pipe step="iter" port="source"/> ... <p:step> <p:input port="yyy"> <p:pipe step="somewherelese" port="someport"/> ...
Norm: The first step doesn't have to be able to read from the source because, as shown in the second step, it could read directly from what the source port reads.
Norm: I hear a bunch of people who want to change the way we describe why inputs are visible in the pipeline.
Richard: One reason that the
current semantics are reasonable is by analogy with functions.
Functions parameters are available inside function.
... Rather than saying pipelines are an exception, it's really the components that are the exception.
Alex: If we switch the input to xpath-context of whatever for viewport/for-each, then we have this xpath-context thing doing something that it doesn't do in the case of choose.
<MSM> [Richard, I wonder, though. If we had a way to encapsulate constructs (e.g. in separate pipeline documents) and call them from multiple locations, the function analogy would be more persuasive. But do we have any such information-hiding mechanism?]
Alex: So that would be a change in how that works.
<ht> HST would find it clearer if we called the hypothetical parallel something such as p:iteration-source -- p:xpath-context is surely misleading here
<richard> [MSM, No, except for cut-and-paste in a graphical interface]
<MSM> [Or a general entity, I guess, for those of us who do that kind of thing]
<ht> [MSM, yes, for v.next we've several times talked about having a 'call-named-pipeline' component]
Norm: Following on Richard's observation, the current situation does make components more self-contained.
Alex: If you didn't allow inputs to be declared on for-each and viewport then this issue would go away.
Henry: that's just saying that
we'll allow you to treat for-each and viewport as a
... Aside from the name which is clearly broken, I'm inclined toward that proposal.
... I suggested "iteration-source"
Alex: You can still have inputs, they just have nothing to do with what you're iterating.
<scribe> ACTION: Editor to clarify how multiple inputs work---maybe this is just a note to the editor for his own understanding [recorded in http://www.w3.org/2007/02/08-xproc-minutes.html#action02]
Richard: You're saying that for-each and viewport no longer have an input used for iterating, there's a special element called iteration-source that specifies it.
Richard: How do the things inside viewport get their input?
Henry: References to "current" remain the same.
Richard: Maybe the name shouldn't be fixed, but be something that you can specify.
<ht> HST agrees we also set aside whether interation-source allows a 'select' attribute
Norm: Let's not.
<ht> +1 to having an attr on p:iteration-source which names the iteration port, possibly defaulting to 'current'
More support than opposition, editor will try.