XML Processing Model WG

Meeting 52, 25 Jan 2007


See also: IRC log


Norm, Henry, Rui, Richard, Alex, Andrew
Alessandro, Mohamed, Paul


Accept this agenda?

-> http://www.w3.org/XML/XProc/2007/01/25-agenda.html


Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2007/01/11-minutes.html


Next meeting: telcon 1 Feb 2007

No regrets given.

Choose/When syntax

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.



<ht> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Dec/0022.html

Henry: Yes. I had in mind going back to the threads that started in December.

<ht> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Dec/0041.html

<ht> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Dec/0056.html

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.

Any other business


Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2007/02/07 15:32:47 $