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

XProc Minutes 19 Oct 2006

From: Norman Walsh <Norman.Walsh@Sun.COM>
Date: Thu, 19 Oct 2006 15:13:07 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <871wp46rwc.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2006/10/19-minutes.html


                                   - DRAFT -

                            XML Processing Model WG

Meeting 40, 19 Oct 2006


   See also: IRC log[3]


           Norm, Paul, Alessandro, Alex, Rui, Andrew, Mohamed, Richard





     * Topics
         1. Accept this agenda?
         2. Accept minutes from the previous meeting?
         3. Next meeting: telcon 26 Oct 2006
         4. Review of action items
         5. Review of 13 Oct draft
         6. Dynamically computed parameters
         7. GRDDL
         8. Syntactic irregularity of choose
         9. Any other business
     * Summary of Action Items


  Accept this agenda?

   -> http://www.w3.org/XML/XProc/2006/10/19-agenda.html

   Norm proposes to add "syntactic irregularity in choose"


  Accept minutes from the previous meeting?

   -> http://www.w3.org/XML/XProc/2006/10/12-minutes.html

   Delayed until next week; scribe failed to post minutes.

  Next meeting: telcon 26 Oct 2006

   Mohamed gives regrets for 26 Oct.

  Review of action items

   A-13-01 continued

   A-39-01 completed

  Review of 13 Oct draft

   Norm: Continued to next week.

  Dynamically computed parameters

   Alex: I wonder if I'm off in a corner by myself.

   Murray: Yes, I think so.

   Alex: Ok, but I note that we don't have any use cases in our requirements
   document that require computed parameters.

   Norm: Any volunteers to produce some?

   <scribe> ACTION: A-40-01 Richard to construct some use cases for computed
   parameters. [recorded in

   <scribe> ACTION: A-40-02 Norm to construct some use cases for computed
   parameters. [recorded in

   Murray: It seems to me that you can pick a use case that exists and add a
   sentence that says you get the parameters from a configuration file.

   Alex: I think we need something much more complex in order to justify
   adding this large a feature.

   Richard: We should have them as use cases so that we can say we don't need
   computed parameters for them.

   <ht> Henry joins the call at 14 past the hour

   Alex: I think the manifest case is covered by 5.6.

   <richard> can someone paste in the url for the use cases

   Norm: I concede that the alternative works but is perhaps more complex
   than most users would think of.

   XProc use cases and requirements:

   Murray: Alex has asked us to add to the use cases document, in terms of
   process do we need to do that?

   Norm: No, we don't have to.
   ... but we should

   Richard: How seriously do we have to take these use cases?

   Alex: I think we should have a non-normative note that shows solutions to
   all of them.

   Norm: I agree
   ... I propose that the editor be directed to add support for computed
   parameters to the language document.


   <scribe> ACTION: A-40-03 Norm to update the language document to describe
   computed parameters [recorded in

   Alex: We don't have the ability to compute a parameter on group.

   Norm: We have declare parameter on group.

   Alex: So that's going to allow step/source too?

   Norm: Yes, I think so.

   Henry: I'd be perfectly happy if we used parameter *everywhere* except
   declare-step-type (or whatever we called it)

   Alex: Declare-parameter makes sense on pipeline.

   Richard: There are three different things: 1. saying that some step has
   parameters; 2. saying what they are for some instance; 3. places where you
   have to do them both at once.
   ... Pipelines are in that third case.
   ... The same is true for group, for-each, and so one.
   ... We seem to have decided that you use declare-parameter for 1 and 3 and
   parameter for 2.

   Norm: I think that's confusing, it means some things have declare and some

   Richard: Why do we have declare anywhere except component definitions?

   Henry: You need to declare outputs that are then bound to inputs. You
   declare things that you can refer to elsewhere, then there are certain
   aspects of for-each and when that need to be declared.
   ... Input/output and declare-input/declare-output are much different than
   ... I think the false parallelism that's there at the moment is already

   Richard: What is the false parallel?

   Henry: When you say declare-output on a when, that's there so that
   somewhere else some input can reference it. The source is always a
   declare-output. The only parallel for parameter would be to say that
   parameter has to refer to a declare-parameter.
   ... That's not true for group/when/for-each and such things.
   ... That seems very misleading.

   Richard: Declare things declare either inputs, outputs or parameters.
   ... There are two things you then do, give values to them and the other is
   that use those values somewhere else. Parameters you use in XPath
   expressions. Output ports you use in declarations of input ports where you
   say where they came from. You declare them, assign to them, and use them.
   That's true of all three.

   Henry: In the case of group, you declare a parameter but don't every seem
   to use it.

   Alex: No that we've gone down this tangent; it seems like a number of
   people would like declare- to go away.
   ... At the f2f, I recall that there was an uncomfortable feeling about
   declare vs. use. We went around in circles and left it that way.

   Henry: There are distinctions, I think we should reflect them, we don't
   have it quite right, I'm not in favor of removing them.

   Richard: There are three things: I think it would be better to have 1 name
   for all three. Having 2 is bad and having 3 would be too verbose.

   Alex: How many people on this call would prefer to drop declare-?

   Richard: Is there any place where it would cause ambiguity?

   Murray: Henry voiced his concern. As I recall Paul was the other person.

   Paul: Which distinction?

   Murray: I proposed an input element everywhere, things spread out, and
   when we contracted it back, that distinction remained.

   Henry: I favor the distinction being preserved.

   Straw poll: who's in favor of dropping the "declare-" prefix throughout.

   Results: 8 in favor, 1 against, and 2 abstentions.

   Paul: Why have things changed?

   Norm: I think we struggled with the model at the f2f; many of us there
   were unhappy with the distinction. The best I can say is, time has passed.

   Henry: I think part of the issue was that there were a lot of other
   alternatives on the table at the f2f.

   We wonder what Jenni's position is? Norm recalls her being in favor of
   dropping the distinction.

   Norm: I propose to produce a branch draft that loses the distinction and
   give folks a chance to see how it feels "in situ" as it were.

   <scribe> ACTION: A-40-04: Norm to produce a draft that loses the
   distinction (and a diff) [recorded in

   Murray: Can we discuss GRDDL at the end?

   Norm: Yes.


   Murray: I think there's some confusion based on the responses I've been
   ... I'm asking about something not related to pipelines.
   ... An agent grabs a document and sees an GRDDL transformation. It also
   sees XInclude.
   ... Should it expand the XIncludes or not?
   ... I know we haven't talked about the other half of our charter much yet,
   but the GRDDL chair keeps asking me this question.
   ... Do we have anything to say.

   Norm: I agree it's in our charter, so from a process point of view, I
   think the answer is "wait, we'll get to that as soon as we can".
   ... I think the spec should answer the question.

   Murray: The problem is that the spec isn't written in terms of agents,
   only in terms of encoding.

   Alex: Murray, how is this any different than someone saying that my
   transformation relies on the PSVI?
   ... That's a presupposition of XML Schema validation.

   Henry: I think the answer is clear: in the absense of an answer about the
   default pipeline, there is no basis for GRDDL to take that question on.

   <Zakim> MSM, you wanted to ask whether the right way to rephrase Norm's
   suggestion is "they say whether the GRDDL transformation gives the RDF
   meaning of the document as it exists or of

   Michael: I understood Murray to say that Norm's answer is hard because the
   spec isn't written to talk about processors.
   ... I'm assuming that the spec says something like "the pointer to the
   GRDDL transformation is a pointer to a transformation that gives an RDF
   encoding of the meaning of this document"
   ... I think Norm's suggestion can be translated: "Does that transformation
   give the meaning of that document as it stands or the meaning of the
   document that can be obtained from the application of XInclude to this
   ... I'm with Norm in thinking you might want it one way or another, but
   I'm with Henry about the simplest thing that could be said.

   Murray: What is the document as it stands?

   Michael: If we're talking about any case where serialization/infoset isn't
   in the normal many-to-one relationship, that would need to be stated.

   <ht> Murray: see http://dret.net/projects/xipr/[11] (a promissory note)

   Richard: If you talk about the Infoset of the document, it seems to me
   that are referring to the output of the parser (no other processing).

   Murray: In my mind, what you get after XInclude is part of the meaning of
   the document.

   Alex: If you start with "the document as it stands" then when we answer
   part 2 of our charter, then you can say that "the document as it stands"
   is the output from that default processing.

   <MSM> Murray, I would agree with you if you were talking about entity
   expansion. But the example we are talking about is XInclude, which gets
   used by people who want to be able to have, and work with, two different

  Syntactic irregularity of choose

   Straw poll: does the syntactic irregularity of chooes/when bother you?

   Results: 5 yes, 1 no, and 4 abstain

   Norm: useful information.

  Any other business



Summary of Action Items

   [NEW] ACTION: A-40-01 Richard to construct some use cases for computed
   parameters. [recorded in
   [NEW] ACTION: A-40-02 Norm to construct some use cases for computed
   parameters. [recorded in
   [NEW] ACTION: A-40-03 Norm to update the language document to describe
   computed parameters [recorded in
   [NEW] ACTION: A-40-04: Norm to produce a draft that loses the distinction
   (and a diff) [recorded in
   [End of minutes]


   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2006/10/19-agenda.html
   [3] http://www.w3.org/2006/10/19-xproc-irc
   [6] http://www.w3.org/2006/10/19-xproc-minutes.html#action01
   [7] http://www.w3.org/2006/10/19-xproc-minutes.html#action02
   [9] http://www.w3.org/2006/10/19-xproc-minutes.html#action03
   [10] http://www.w3.org/2006/10/19-xproc-minutes.html#action04
   [11] http://dret.net/projects/xipr/
   [12] http://www.w3.org/2006/10/19-xproc-minutes.html#action01
   [13] http://www.w3.org/2006/10/19-xproc-minutes.html#action02
   [14] http://www.w3.org/2006/10/19-xproc-minutes.html#action03
   [15] http://www.w3.org/2006/10/19-xproc-minutes.html#action04
   [16] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   [17] http://dev.w3.org/cvsweb/2002/scribe/

    Minutes formatted by David Booth's scribe.perl[16] version 1.127 (CVS
    $Date: 2006/10/19 19:10:28 $

Received on Thursday, 19 October 2006 19:13:22 GMT

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