- From: Innovimax SARL <innovimax@gmail.com>
- Date: Wed, 1 Nov 2006 22:42:48 +0100
- To: "Norman Walsh" <Norman.Walsh@sun.com>
- Cc: public-xml-processing-model-wg@w3.org
- Message-ID: <546c6c1c0611011342x5fb0c45byf8f34e3446cdcca1@mail.gmail.com>
Norm, I presented regrets in 19 Oct Minutes Regards, Mohamed On 11/1/06, Norman Walsh <Norman.Walsh@sun.com> wrote: > > 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 $ > > > -- Innovimax SARL Consulting, Training & XML Development 9, impasse des Orteaux 75020 Paris Tel : +33 8 72 475787 Fax : +33 1 4356 1746 http://www.innovimax.fr RCS Paris 488.018.631 SARL au capital de 10.000 €
Received on Wednesday, 1 November 2006 21:43:18 UTC