See also: IRC log
-> http://www.w3.org/XML/XProc/2006/06/08-agenda.html
Accepted.
-> http://www.w3.org/XML/XProc/2006/06/01-minutes.html
Accepted.
Any regrets?
Paul gives regrets for 15 and 22 June
<scribe> ACTION: Norm to correct minutes for 01 June [recorded in http://www.w3.org/2006/06/08-xproc-minutes.html#action01]
Norm: I suspect Henry to give regrets for 15 June
Norm gives regrets for 22 June
Fill out the registration form; tell Murray where you're staying
A-13-01: MSM to draft a complete table; ETA: 15 June 2006
<scribe> Continued
A-23-01: Henry to describe an alternate proposal in email
<scribe> Completed
A-23-02: Richard to write a syntax proposal
<scribe> Continued
Norm to write a syntax proposal
<scribe> Continued
Norm: Henry's proposal was quite
simple and I thought it might be good jumping off point.
... Alex reports that simple pipes will handle most of our use
cases
Norm invites Alex to discuss his "flows" and "pipes" mail
Alex: Far more than the majority
are really simple uses cases.
... They're straight pipes with some sub-resources that you
need.
... If we had a simple way of expressing the straight through
cases, that would be good. Especially if we could extend
that.
... We could envision "pipes" as reusable bits that are used in
more complex flows
... I just sent an example to the list.
... The processing is actually driven by the parsing of the
document itself that drives the pipeline.
See Alex's mail: http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Jun/0020.html
Alex: Pipes are simple, they just process a primary input
Alex describes his example
Norm: How might we address Jeni's
questions about Henry's example in this framework?
... How do you do conditionals based on documents other than
the primary input
Alex: You'd have a construct in
the flow, outside of the pipes.
... You'd be choosing which pipes to execute? I'm a little
fuzzy on the concrete use case.
... The choices in our use cases document seem to be relative
to a particular input which could be the primary input to a
pipe.
Norm: I was going to suggest that the use of multiple pipes would allow you to make the conditionals be on the primary input and the output of those pipes could be used later.
Alex: Based on which documents occur in a collection, you might want to do one set of pipes or another. It might become combinatorial, but maybe there are better ways to orchestrate that.
Norm: What about conditionality
on the number of documents in the default input?
... It seems to me that if we expose the documents a set then a
simple count() expression will do it. If we don't, then we can
provide a component that will return the number, and then you
can do simple tests on that number.
Alex: I think collections can be handled at the flow level
Norm: What about steps that are
conditional on two inputs: Is the xml:base attribute on this
element the same as the superDoc attribute on that other
document's root element.
... I guess in this flow-and-pipe arrangement that we've been
talking about, you'd have to combine those two elements into a
single document somehow and then pass that to a pipe that could
evaluate the condition.
Alex: We also have the ability to
put something into the flow-level that could evaluate it
... A natural consequence of this is that you still need to
build a graph of inputs and outputs. You might have mutually
exclusive pipes that you have to deal with in the graph.
There's still some complexity here in the flow language.
Norm: I'm not sure what you mean by "adding things to the flow language"
<MoZ> +1 for expliciting flow level
Alex: In the example I sent, the flow graph of where the inputs and outputs go is straightforward. If you had conditionals at the level of the flow, then you have this issue of whether or not some steps execute and produce outputs that are inputs to other things.
Norm: I want to keep the conditionals tightly bound so that we don't get that complexity in the graph
Richard: We all concluded that it
was to complex if conditionals could spread. Everything related
to the conditional, I think we agreed, belong inside the
conditional.
... I'm not convinced that the distinction between flow and
pipe is the right idea.
... I take the analogy of unix pipes; there aren't two syntaxes
there but it still makes the simple case simple. I'm not
immediately agreeing that this is a good idea. But I haven't
looked at it closely yet.
... What I ideally want is a syntax that handles the
complicated case but where it just falls out that the simple
case looks simple.
Norm: Perhaps we should turn our attention to something else and see if we get some more complete syntax proposals before next week.
Norm: Anyone know what the right
answer is?
... No, I guess not.
Norm explores what it means to process an XPath expression over a sequence of documents.
Richard: Jeni proposed that we could make the node set have a document order that corresponded to the sequence of documents.
Alessandro: My understanding is
that the concept of nodeset is fully baked. If we only allow
the expression to be evaluated over a single document, then
that would seem to be an arbitrary restriction.
... it seems natural to map sequence of documents to node sets
of document nodes
Richard: I think that's the most reasonable thing to do. If we do that and provide a component that can aggregate nodes togther, then you could cover both cases (the case where order didn't matter and the case where it did)
Norm: It sounds like we're approaching consensus.
Proposal: if an XPath expression is evaluated over an input that is a sequence of documents, the expressions is in fact evaulated over a nodeset that consists of the document nodes of that input sequence. We accept the limitation that the relative order of the documents in the sequence is lost.
Mohamed: We must add that the relative order is lost, and we must also handle duplicates.
Norm: I don't think that situation arises. In XPath duplication is about node identity.
Richard: One consequence of making the context node be a set of documents: what would be the meaning of "/" in that situation?
Norm: That's a good question.
Richard: If the context nodeset is a set of document nodes, what is the context node?
<scribe> ACTION: Norm to record the issue of "/" in an input sequence context [recorded in http://www.w3.org/2006/06/08-xproc-minutes.html#action02]
Norm repeats the proposal.
Accepted.
None