See also: IRC log
-> http://www.w3.org/XML/XProc/2007/01/25-agenda.html
Accepted.
-> http://www.w3.org/XML/XProc/2007/01/11-minutes.html
Accepted.
No regrets given.
Status quo: http://www.w3.org/XML/XProc/docs/alternate/
Richard: Does the status quo allow you to override the context on each when?
Norm: Yes, by using an input named "source".
Henry: I prefer option 2, but I'm
not sure I'm happy with the name xpath-context.
... But I'm increasingly unhappy with any aspect of our design
that uses builtin port names.
Norm: Tying this back to for-each
and friends, the name "context" was proposed.
... I think the context element is oddly named in the for-each
case, but I could get used to it.
Richard: What I find unpleasant
is that the test is lexically outside the context binding
element.
... The context ought to be provided for things inside it or at
the same level, not for things outside it.
Norm: I see your point, but I don't know what to do about it.
Michael: I have a question of comprehension: I thought that context was another name for a sole input.
Henry: That's not right: it's
been an aspect of our choose/when design for a long time that
the input to the branches is distinct from the input which is
tested.
... You can test one document and process on each of the
branches different documents.
Michael: I think the draft should say that, I don't think it currently does.
Alex: This context has the
feature that we don't have to name the port.
... I would be really happy with a different name.
Norm repeats his earlier comments about the name "context"
Henry: I'm less sure that I want
to treat this the same way that we treat for-each and
viewport.
... In those cases, the input there really is the input to the
component.
... I really do want to stay with some consistent notion of
what "the input" is.
... I'm not sure we should fold them together.
... I like option 2 and I think calling it "context" is better
than "xpath-context"
Michael: I was with you up to the last part about the name.
Alex: For-each and viewport are
exactly like choose/when.
... Viewport and for-each do something with the context.
Norm: Jeni made the point that having source in for-each and viewport is a little odd.
Richard: I'm wishing that I'd taken a completely different approach and using, for example, variables to refer to the documents in scope instead of all the complexity of tests.
<MSM> +1 to HT's argument that the XPath context of a Choose/When is conceptually quite different from the single input of a viewport or for-each
Richard: It was suggested that XPaths be able to refer to inputs through variables. So the test could be "$source/something" or "$whatever/something".
Alex: We chould have an extension function to do this.
Norm muses "source(step,name)"
<ht> p:source(step,name)
<ht> p:pipe(step,name)
Alex: It has the consequence that it means you can't use an off-the-shelf XPath implementation.
Richard: The problem with an extension function is that it means you can dynamically construct the step and port names.
Henry: If that was the only thing in the way, we could just rule that out.
Richard: I disliked this before
because it made it harder to see the flow of documents through
the pipeline.
... As long as you can figure out where the pipes go at compile
time, I could live with it.
Henry: What I like about this is that it invites a natural default which is that the context of when defaults to context of choose which defaults to the primary input of choose.
Norm: With my chair's hat on, I have to question the size of this change?
Richard: I think that over the
last few months, this nagging problem of the syntax and how to
bind things for XPaths has been dragging us back.
... Maybe it is a big enough problem that we really do need to
reconsider it.
Henry: Opening XPaths in general
to being able to attract input from any in-scope output port
inside square brackets, etc. really does change the power of
the language as it appears.
... It effectively changes your ability to read off the data
flow of a pipeline from its input port elements.
... Extension functions have semantics that go way beyond the
problem we were trying to solve.
... I'm back to thinking we should go with option 2 and discuss
the name of the element at another time.
Michael: My problem with option 2
is for the same information it requires a more complicated and
elaborate XML structure. You're adding element structures that
don't seem to be doing much. The term context is already taken
in our spec.
... We're going to have different names for these things.
Alex: Couldn't we just have an input without a port attribute?
Henry: That's just too complex
for users.
... Option 2 spells a special case with a special element name
instead of spelling it "input port='source'"
Michael: Looking at the example
more carefully, I think you're right. The second option isn't
more complex.
... I withdraw the argument.
Micheal: My dislike of adding a
new GI was based on the misaprehension given by the note in the
November draft that said that context was analogous with the
input of for-each which I'm now learning is not what people
intend.
... I still stick at the term "context"
<MSM> Henry, your argument does not support the use of the term "context" to mean something that the XPath spec calls by a different name
<ht> 'context-node' works for me
Norm: I think that option 2, if we stick with something like the current syntax, is a consensus position. Does anyone disagree?
No one did.
Norm: So the question is then, what name? We can always revisit it later.
<MSM> if we find a different name for what is now called 'context', we can revisit the name of this element.
Norm: The name is left to the editor's discretion, except that "context" is off the table.
Proposed: We will adopt option 2 as described above for the next draft.
Accepted.
Henry: Yes. I had in mind going back to the threads that started in December.
Henry: I would like to say something like where we ended up in that discussion, editor please draft :-)
Norm: The editor might like somewhat more direction.
Alex: The real crux seems to be dealing with the preceding sibling case.
Henry: A crucial question is, is it names or is it arity? I started out thinking that I didn't care what a step's port was called if it only had one.
Norm: I think the draft will be easier to understand if we do it in terms of names.
Henry: I think it's easier to talk about the single input port, regardless of name.
Richard: We could certainly say that if the component only has one input, that's it's default.
Alex: Or we could say that a component declaration indicated its default port.
Richard: I like that.
Some discussion of input ports
Richard: I think you could just say that any unconnected input port is connected to the default.
Alex: In the case of building tools, I can imagine that having a declaration of which one is usually defaulted would be useful.
Richard: I can see Alex's point that this would be useful for a graphical tool
<ht> I'm now convinced that the only thing we need to do is provide a rule for which output provides the default input binding for its following sibling in the case where there is more than one output port
Richard: We could say that you designate one input as primary but that it's not used by the language.
<alexmilowski> +1
Norm: I think we're saying that,
component declarations should be allowed to specify a single
primary output, they should be allowed to specify a single
primary input (but the language doesn't care) and that any
unconnected input is automaticly connected to the default
input.
... Where the default input is the default output of the
preceing sibling or the preceding sibling of the
container.
... Recursively.
Richard: I would say that each
container component should specify what it's default input is
and that's in the context.
... I also think we should say explicitly that a component only
has one output, that is it's default output regardless of what
we say in the declaration.
None