XML Processing Model WG

Meeting 41, 26 Oct 2006


See also: IRC log


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


Accept this agenda?

-> http://www.w3.org/XML/XProc/2006/10/26-agenda.html


Accept minutes from the previous meetings?

-> http://www.w3.org/XML/XProc/2006/10/12-minutes.html


-> http://www.w3.org/XML/XProc/2006/10/19-minutes.html


Next meeting: telcon 2 Nov 2006

Regrets from Michael.

Note that the meeting next week will be shifted one hour as the US moves to standard time.

Review of open action items

A-13-01: Continued

Review of 13 Oct draft

-> http://www.w3.org/XML/XProc/docs/langspec.html

Alex: Everything looks pretty good, but I'm still confused about why there's still "flow-graph"

Norm: I'm willing to try to remove the flow-graph language, if that's what we like.

Henry: The "Scoping of Names" section is an orphan now, isn't it?

Norm: Yes

Alex: We need to say somewhere that the scope of names is determined by the context.

Norm: I don't think we defined "context"

Henry: Removing "flow-graph" will probably require using subpipeline, but there's some circularity.

<Zakim> ht, you wanted to support change, but comment about context contents

Henry: The context contains input ports that are never used or defined.

Norm: I noticed, but didn't remove them.

Henry: I think we should remove them until we need them.

Norm: I agree.

Alex: One more small thing: when we put the output ports into the context, they're a two-part name. There's the step name and the port.
... So there's a two-part key and we need to talk about uniqueness.

Norm: I think it should be an error to have two steps with the same name in the same context.

Alex: We need to make sure that the scope of the component name is specified.

<scribe> ACTION A-41-01: Norm to remove flow-graph language [recorded in http://www.w3.org/2006/10/26-xproc-minutes.html#action01]

<scribe> ACTION A-41-02: Norm to make sure that the scope of component names discusses uniqueness [recorded in http://www.w3.org/2006/10/26-xproc-minutes.html#action02]

Henry: What about the parallel question for parameters?
... I think for parameters, it's perfectly alright to have duplicate names and they shadow.

<scribe> ACTION A-41-03: Norm to make scope of parameter names clear. [recorded in http://www.w3.org/2006/10/26-xproc-minutes.html#action03]

Anyone object to parameter shadowing?

No objections.

We'll use the language of the 13 Oct draft moving forward.


Review of the alternate draft

-> http://www.w3.org/XML/XProc/docs/alternate/

Henry: I think we can get there, but I want to separate the question of inputs/outputs and parameters.
... We distinguished between obligatory and optional parameters, and there's no place to say that now.

Norm: I thought parameter on declare-step-type could specify required=yes|no

Henry: I think I'd like to keep the names separate for that.
... In any event, that attribute is missing.
... And parameters are either obligatory or optional in signatures.
... There's a similar problem in inputs and parameters when wildcards are used in names.
... It just doesn't make any sense to use the input name="*" on an XSLT step.
... There's a bunch more work needed there.

Alex: Norm, you said that import-param was available at the pipeline level. Isn't that needed only in the declaration of a component.

Norm: Maybe a pipeline just has param name='db:*' and not import-param

Henry: We do have this class of top-level pipelines and signatures.

Alex: If you want to support 532 parameters, you can import them (or declare them?)
... One way to say it is that parameters that don't have values are declarations, end of story.

Henry: I'm not happy with that because I want to be able to express defaults in the declaration case.

Alex: Wildcards only apply when there's a declaration.
... If we had a different name, then we wouldn't have to have complex co-constraints for a single element name.

Henry: I'm teetering back and forth two, but it is in part because parameters aren't schiziophenic in quite the same way as inputs/outputs.
... Sometimes inputs are declarations *and* uses at the same time. But that's not true of parameters.
... It's always clear from the context.

Alex: Could we break declarations out as their own example?
... You can't use select/source/etc. with wildcards.
... Describe parameter declarations and parameter uses separately.

Norm: I can give that a try.

Henry: And we agreed that you won't be able to have computed defaults for parameters, right?

Norm: Uhm, I think so.

Henry, Norm, and Alex try to make sense of this, scribe fails to capture details

Alex: if you have a group, a computed parameter can't point into the output of the steps

Henry: Norm needs to add a story for what's in context for computed parameters.

Alex: href is the other issue, but maybe that's not an issue.
... If you want to compute a parameter at the pipeline level then you have to use a group.

Norm: Why aren't the inputs to the component available for computation of parameters?

Henry: There are two possibilities: across the board, for v1, no computed defaults; not for parameter declarations in signatures or pipelines.
... Or to say that computed defaults are allowed on pipelines and signatures and the only inputs available for computation are the inputs to the pipeline.

Norm: I think there's a third case which is about computed values in components.

Henry: I want to keep the story about computed defaults and computed values very separate.

Alex: Maybe we should describe the contained pipeline as a group.
... The context is defined by some aspect of the declarations that occur at the top level of the pipeline.

Henry: That's again blurring the distinction.

Alex: I'm not blurring, I'm trying to separate them entirely.

Henry: Shall we ask the editor to write a new draft that clarifies the distinction between parameter declarations and parameter uses/bindings?
... Allowing only static defaults.

Norm: The chair suggests moving on until we get a new draft.

Discussion of normalizing the syntax of for-each/viewport with choose/when

Norm: I suggested changing choose/when; Jeni suggested changing for-each/viewport.

Henry: I think we made the wrong choice in Ontario; but given that choice, we should distinguish between the special input from other inputs.
... I'm reluctantly in favor of changing for-each/viewport.

Alex: I kind of like having the elements on choose/when
... It's not a big deal to me.

Henry: Nor me.

<MSM> Yes, I'm listening, but I do not have a well founded opinion on this, except that surface syntax matters.

<MSM> so it's a big deal to me, but I don't know what to do

Henry: I'd like Norm to write it up all attributes and see if it makes me gag.

Alex: We have a bunch of use cases, I wonder if we could try some of those.
... It's not a clarity issue as much as a consistency issue that you could see by example better.

<scribe> ACTION A-41-04: Alex to post some examples each way. [recorded in http://www.w3.org/2006/10/26-xproc-minutes.html#action04]

Any other business

Henry: According to W3C process, if I want to give a paper at XML 2006, I need permission of the WG.
... I've been working on an ontology and some software to manipulate it.

Norm: As chair, yes, feel free.
... In fact, our discussions are public and I'm happy to give all members carte blanche to discuss anything we've discussed provided that they do not represent as consensus that which isn't.


Summary of Action Items

[NEW] ACTION A-41-01: Alex to post some examples each way. [recorded in http://www.w3.org/2006/10/26-xproc-minutes.html#action04]
[NEW] ACTION A-41-02: Norm to make scope of parameter names clear. [recorded in http://www.w3.org/2006/10/26-xproc-minutes.html#action03]
[NEW] ACTION A-41-03: Norm to make sure that the scope of component names discusses uniqueness [recorded in http://www.w3.org/2006/10/26-xproc-minutes.html#action02]
[NEW] ACTION A-41-04: Norm to remove flow-graph language [recorded in http://www.w3.org/2006/10/26-xproc-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2006/11/03 12:02:54 $