- From: Norman Walsh <Norman.Walsh@Sun.COM>
- Date: Wed, 01 Nov 2006 10:24:23 -0500
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <877iyfjil4.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2006/10/26-minutes.html
W3C[1]
- DRAFT -
XML Processing Model WG
Meeting 41, 26 Oct 2006
Agenda[2]
See also: IRC log[3]
Attendees
Present
Norm, Paul, Henry, Alessandro, Alex, Rui, Andrew
Regrets
Richard
Chair
Norm
Scribe
Norm
Contents
* Topics
1. Accept this agenda?
2. Accept minutes from the previous meetings?
3. Next meeting: telcon 2 Nov 2006
4. Review of open action items
5. Review of 13 Oct draft
6. Review of the alternate draft
7. Discussion of normalizing the syntax of for-each/viewport with
choose/when
8. Any other business
* Summary of Action Items
----------------------------------------------------------------------
Accept this agenda?
-> http://www.w3.org/XML/XProc/2006/10/26-agenda.html
Accepted.
Accept minutes from the previous meetings?
-> http://www.w3.org/XML/XProc/2006/10/12-minutes.html
Accepted.
-> http://www.w3.org/XML/XProc/2006/10/19-minutes.html
Accepted.
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[8]]
<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[9]]
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[10]]
Anyone object to parameter shadowing?
No objections.
We'll use the language of the 13 Oct draft moving forward.
Accepted.
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[12]]
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.
Adjourned.
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[13]]
[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[14]]
[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[15]]
[NEW] ACTION A-41-04: Norm to remove flow-graph language [recorded in
http://www.w3.org/2006/10/26-xproc-minutes.html#action01[16]]
**
[End of minutes]
----------------------------------------------------------------------
[1] http://www.w3.org/
[2] http://www.w3.org/XML/XProc/2006/10/26-agenda.html
[3] http://www.w3.org/2006/10/26-xproc-irc
[8] http://www.w3.org/2006/10/26-xproc-minutes.html#action01
[9] http://www.w3.org/2006/10/26-xproc-minutes.html#action02
[10] http://www.w3.org/2006/10/26-xproc-minutes.html#action03
[12] http://www.w3.org/2006/10/26-xproc-minutes.html#action04
[13] http://www.w3.org/2006/10/26-xproc-minutes.html#action04
[14] http://www.w3.org/2006/10/26-xproc-minutes.html#action03
[15] http://www.w3.org/2006/10/26-xproc-minutes.html#action02
[16] http://www.w3.org/2006/10/26-xproc-minutes.html#action01
[17] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[18] http://dev.w3.org/cvsweb/2002/scribe/
Minutes formatted by David Booth's scribe.perl[17] version 1.127 (CVS
log[18])
$Date: 2006/11/01 15:19:19 $
Received on Wednesday, 1 November 2006 15:24:59 UTC