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

Re: XProc Minutes 26 Oct 2006

From: Innovimax SARL <innovimax@gmail.com>
Date: Wed, 1 Nov 2006 22:42:48 +0100
Message-ID: <546c6c1c0611011342x5fb0c45byf8f34e3446cdcca1@mail.gmail.com>
To: "Norman Walsh" <Norman.Walsh@sun.com>
Cc: public-xml-processing-model-wg@w3.org
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:49 GMT