- From: Norman Walsh <Norman.Walsh@Sun.COM>
- Date: Thu, 08 Feb 2007 12:13:53 -0500
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <87zm7o373i.fsf_-_@nwalsh.com>
See http://www.w3.org/XML/XProc/2007/02/08-minutes.html
W3C[1]
- DRAFT -
XML Processing Model WG
Meeting 54, 8 Feb 2007
Agenda[2]
See also: IRC log[3]
Attendees
Present
Norm, Richard, Rui, Henry, Andrew, Alex, Mohamed, Alessandro,
Michael, Murray
Regrets
Chair
Norm
Scribe
Norm
Contents
* Topics
1. Accept this agenda?
2. Accept minutes from the previous meeting?
3. Next meeting: telcon 15 Feb 2007
4. Face-to-face in 2007?
5. Is the defaulting story right?
6. Is the choose/when story right?
7. Do we want to do something similar about for-each/viewport?
8. Use "environment" for "context"?
9. Any other business?
* Summary of Action Items
----------------------------------------------------------------------
Accept this agenda?
-> http://www.w3.org/XML/XProc/2007/02/08-agenda.html
Accepted.
Accept minutes from the previous meeting?
-> http://www.w3.org/XML/XProc/2007/02/01-minutes.html
Accepted.
Next meeting: telcon 15 Feb 2007
Richard gives possible regrets. Andrew gives regrets.
Face-to-face in 2007?
Nothing new to say; keep thinking about it.
Is the defaulting story right?
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.
Accepted.
Is the choose/when story right?
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.
<alexmilowski>
http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Feb/0012.html[6]
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> clarification?
<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.
<alexmilowski> not(/)
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.
Accepted.
<scribe> ACTION: Editor to clarify the text in 4.2.2 [recorded in
http://www.w3.org/2007/02/08-xproc-minutes.html#action01[7]]
Do we want to do something similar about for-each/viewport?
<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?]
<Norm> [Yes]
<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>
Norm: Right:
<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 group.
... 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[8]]
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.
Henry: yes.
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'
Use "environment" for "context"?
More support than opposition, editor will try.
Any other business?
Adjourned.
Summary of Action Items
[NEW] 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[9]]
[NEW] ACTION: Editor to clarify the text in 4.2.2 [recorded in
http://www.w3.org/2007/02/08-xproc-minutes.html#action01[10]]
**
[End of minutes]
----------------------------------------------------------------------
[1] http://www.w3.org/
[2] http://www.w3.org/XML/XProc/2007/02/08-agenda.html
[3] http://www.w3.org/2007/02/08-xproc-irc
[6] http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Feb/0012.html
[7] http://www.w3.org/2007/02/08-xproc-minutes.html#action01
[8] http://www.w3.org/2007/02/08-xproc-minutes.html#action02
[9] http://www.w3.org/2007/02/08-xproc-minutes.html#action02
[10] http://www.w3.org/2007/02/08-xproc-minutes.html#action01
[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: 2007/02/08 17:12:27 $
Received on Thursday, 8 February 2007 17:14:23 UTC