See also: IRC log
Date: 26 Oct 2006
<scribe> Meeting: 41
<scribe> Scribe: Norm
<scribe> ScribeNick: Norm
-> http://www.w3.org/XML/XProc/2006/10/26-agenda.html
Accepted.
-> http://www.w3.org/XML/XProc/2006/10/12-minutes.html
Accepted.
-> http://www.w3.org/XML/XProc/2006/10/19-minutes.html
Accepted.
No regrets given.
Note that the meeting next week will be shifted one hour as the US moves to standard time.
A-13-01: Continued
-> 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: Norm to remove flow-graph language [recorded in http://www.w3.org/2006/10/26-xproc-minutes.html#action01]
<scribe> ACTION: 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: 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.
Accepted.
-> 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.
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: Alex to post some examples each way. [recorded in http://www.w3.org/2006/10/26-xproc-minutes.html#action04]
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.
Adjourned.
<ht> MSM, I suggested to Norm you might not make next week's call, but we agreed we weren't sure either way --- you might want to let him know
<MSM> Norm, no, I will be in XML Query / XSL meetings in San Jose next week, so regrets from me for next week's call
Ok
This is scribe.perl Revision: 1.127 of Date: 2005/08/16 15:12:03 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/example/example?/ Succeeded: s/are allowed on pipelines/are allowed on pipelines and signatures/ Succeeded: s/of changing/in favor of changing/ Found Scribe: Norm Inferring ScribeNick: Norm Found ScribeNick: Norm Default Present: Norm, Ht, [IPcaller], Alex_Milowski, Alessandro, PGrosso, rlopes, AndrewF, MSM Present: Norm Paul Henry Alessandro Alex Rui Andrew Regrets: Richard Agenda: http://www.w3.org/XML/XProc/2006/10/26-agenda.html Found Date: 26 Oct 2006 Guessing minutes URL: http://www.w3.org/2006/10/26-xproc-minutes.html People with action items: alex norm[End of scribe.perl diagnostic output]