XML Processing Model WG

Meeting 33, 31 Aug 2006


See also: IRC log


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


Accept this agenda?

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


Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2006/08/17-minutes.html


Next meeting: telcon 7 Sep 2006

No regrets given.

Comments on the draft

Four things: add a description for p:declare-parameter

scribe: Document select on p:param (we need to determine the context)
... Remove the special case in 4.1.1 for a source w/o step
... Add text about extension attributes and elements
... Do we allow p:declare-input on for-each, choose, etc.

Henry: We've talked about components and steps as quite different things
... in the draft, you've moved the other way. Now there are just classes of components.
... I think that's a good idea, but I don't think we decided it.

<alexmilowski> I've always thought of it that way too...

Henry: In that case, we need to speak of allowing users to create classes of components

Richard: I think the draft is confusing, it speaks of a graph of components, but choose and for-each aren't described as components.

<ht> HST likes 'construct' for the language constructs

<ht> and 'component' for XSLT and user-defined stuff

<ht> and 'step' for the union of the two

Norm describes how in fact he thinks "for-each" is now in fact a component

Micheal: I'm a little concerned about losing the distinction between steps and components.
... Personally, I believe that people have a tendency to get confused about class/instance distinctions.

Norm describes pipelines as a graph of components and steps as a mechanism for instantiating those components.

Michael: I've got a pipeline with three XSLT stylesheets applied in sequence. I think I have three XML constructs in the XML description of the pipeline. I think I have three steps/stages in an abstract description of the pipeline.
... and three control blocks in memory, but perhaps only one copy of the processor if it's renetrant. But I have one of something, what is that?
... I had thought that that was a component.

Richard: A shell script may run a sequence of two or three programs and two of them may be the same.
... The fact that in the first case I meant programs and in the second I meant executable file doesn't seem confusing.

Michael: In some contexts, I can certainly imagine getting confused if we didn't have conventions for distinction between those things.

Richard: One reason I don't want to elaborate a whole set of names is because there is in fact at least a third case for each one. Suppose you run a pipeline twice. Now, not only are there are the layers we already had, there's also the instances of them running.

Henry: And this is entirely parallel to any description of an OO system.

Richard: There's also the fact that we have constructs that run a component repeatedly within the same pipeline.

Alex: Do we have to dig that deep?

Richard: Let's look at it from the other end.
... We seem generally happy with the term "step" for the things that aren't built into the language.
... We need something for both language constructs and things not built into the language.

Michael: You'd rather say we plug the output ports of the X component into the input ports of the Y component. Why not step?

<MSM> one syllable vs three syllables

Richard: The only reason I don't want to use step there is because we have a step element in the language.

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

Norm describes his situation where components are synthesised sometimes

<ht> See above for the diagram Richard just referred to

Richard: I also want to be able to be able to have steps in the document correspond to single components in the semantics

Henry: The only thing worth noting right now about the diagram is that it goes backwards wrt the current discussion. It uses step for the union.

Michael: I continue to be a little concerned about the absence of a term for the abstraction who's most obvious instantiation is a software module that a user might add to an available library
... what I'm hearing people say is that they want to use "component" for one of the constiuent parts of the pipeline
... I don't have a particular desire to use component in a slightly different way. I just don't think of invocations as instances of programs.

Richard: Defining a component, writing a component, is like defining a function. So XSLT would be a function that you called.
... A line of the program that called that function would be a "function call"
... And there would be other constructs that weren't function calls like conditionals and loops.
... In our language, "steps" are like function calls because we don't call the conditional things steps.

Henry: The problem with "step" for "statement" is that we have have an element named "step" which is the equivalent of "function call"

Norm proposes to try to use step and component consistently in the document and see if that helps

Michael: When CMS pipelines were introduced, the authors thought hard about the terminology.
... They used the term "stage" for the things that go between the pipeline characters.
... and for the processes that get connected up.
... I think in the abstract that step would be nicer, but stage does not have the collision with the usage of step as something which invokes something like XSLT

The select attribute on p:param

Norm summarizes the current state of the document

Norm: I think we need to allow source/href/here on p:param

Alex: I thought we agreed to do that, even though it gives me heartburn.
... I was surprised not to see that in the document.
... I think we should be clear that if you create a param that uses an input that isn't otherwise an input to the step, you're creating a new input dependency.

Richard: It's easy to statically determine what the dependencies are.

Norm will update the document to allow p:param elements to specify a context for the select attribute.

Henry: I expect in due course that we'll have a shortcut for this.

Norm asks about allowing declare-input on p:choose, p:for-each, etc.

Richard: What about a declare-input that you don't use?

Norm: Uhm

Richard: It doesn't seem to usefully document anything if you can't prevent dangling inputs.

Norm: Does anyone else want to be able to declare those inputs?

Murray: I don't see any reason not to

Richard: But unless we have rules that say that if you declare one, you must declare them all.

<ht> MSM, see http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Aug/0096.html for an attempt to follow up your suggestion wrt 'Stage'

Richard: The effect of declare input is simply to alias an existing name. So how come you're only allowed to use it in these particular places.
... My inclination is not to allow it unless we work out what's allowed.

Norm: My middle ground is to say that a declare-input that you don't use is an error.

Henry: I feel that you should minimize the amount of work on the draft in this area.

Norm: Ok, we'll leave it alone, but not record that as a decision.

Norm proposes revising the draft before next week in an effort to get FPWD out

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2006/09/12 17:39:42 $