- From: Norman Walsh <Norman.Walsh@Sun.COM>
- Date: Fri, 09 Jun 2006 15:26:47 -0400
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <878xo63zbc.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2006/06/08-minutes.html
W3C[1]
- DRAFT -
XML Processing Model WG
Meeting 24, 8 Jun 2006
Agenda[2]
See also: IRC log[3]
Attendees
Present
Rui, Norm, Mohamed, Alessandro, Paul, Andrew, Alex
Regrets
Michael
Chair
Norm
Scribe
Norm
Contents
* Topics
1. Accept this agenda?
2. Accept minutes from the previous teleconference?
3. Next meeting: 15 June telcon
4. Face-to-face: 2-4 Aug 2006.
5. Review of open action items
6. XProc syntax
7. Issue 3306: XPath over a sequence of documents
8. Any other business?
* Summary of Action Items
----------------------------------------------------------------------
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[6]]
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[7]
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[8]]
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[9]]
[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[10]]
**
[End of minutes]
----------------------------------------------------------------------
[1] http://www.w3.org/
[2] http://www.w3.org/XML/XProc/2006/06/08-agenda.html
[3] http://www.w3.org/2006/06/08-xproc-irc
[6] http://www.w3.org/2006/06/08-xproc-minutes.html#action01
[7] http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Jun/0020.html
[8] http://www.w3.org/2006/06/08-xproc-minutes.html#action02
[9] http://www.w3.org/2006/06/08-xproc-minutes.html#action01
[10] http://www.w3.org/2006/06/08-xproc-minutes.html#action02
[11] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[12] http://dev.w3.org/cvsweb/2002/scribe/
Minutes formatted by David Booth's scribe.perl[11] version 1.127 (CVS
log[12])
$Date: 2006/06/09 19:25:26 $
Received on Friday, 9 June 2006 19:26:59 UTC