W3C

XML Processing Model WG

Meeting 24, 8 Jun 2006

Agenda

See also: IRC log

Attendees

Present
Rui, Norm, Mohamed, Alessandro, Paul, Andrew, Alex
Regrets
Michael
Chair
Norm
Scribe
Norm

Contents


Accept this agenda?

-> http://www.w3.org/XML/XProc/2006/06/08-agenda.html

Accepted.

Accept minutes from the previous teleconference?

-> http://www.w3.org/XML/XProc/2006/06/01-minutes.html

Accepted.

Next meeting: 15 June telcon

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

Face-to-face: 2-4 Aug 2006.

Fill out the registration form; tell Murray where you're staying

Review of open action items

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

XProc syntax

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.

Issue 3306: XPath over a sequence of documents

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.

Any other business?

None

Summary of Action Items

[NEW] ACTION: Norm to correct minutes for 01 June [recorded in http://www.w3.org/2006/06/08-xproc-minutes.html#action01]
[NEW] 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]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2006/06/15 16:17:59 $