W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > November 2006

XProc Minutes 26 Oct 2006

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


                                   - DRAFT -

                            XML Processing Model WG

Meeting 41, 26 Oct 2006


   See also: IRC log[3]


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





     * 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
         8. Any other business
     * Summary of Action Items


  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

   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

   <scribe> ACTION A-41-01: Norm to remove flow-graph language [recorded in

   <scribe> ACTION A-41-02: Norm to make sure that the scope of component
   names discusses uniqueness [recorded in

   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.


  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

   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
   ... 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

   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

   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

   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

   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

   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

   Alex: We have a bunch of use cases, I wonder if we could try some of
   ... 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

  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
   [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
   [NEW] ACTION A-41-04: Norm to remove flow-graph language [recorded in
   [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
    $Date: 2006/11/01 15:19:19 $

Received on Wednesday, 1 November 2006 15:24:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:41 UTC