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

XProc Minutes 25 Jan 2007

From: Norman Walsh <Norman.Walsh@Sun.COM>
Date: Thu, 25 Jan 2007 15:29:57 -0500
To: public-xml-processing-model-wg@w3.org
Message-ID: <87lkjqg88q.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2007/01/25-minutes.html


                                   - DRAFT -

                            XML Processing Model WG

Meeting 52, 25 Jan 2007


   See also: IRC log[3]


           Norm, Henry, Rui, Richard, Alex, Andrew

           Alessandro, Mohamed, Paul




     * Topics
         1. Accept this agenda?
         2. Accept minutes from the previous meeting?
         3. Next meeting: telcon 1 Feb 2007
         4. Choose/When syntax
         5. Defaulting
         6. Any other business
     * Summary of Action Items


  Accept this agenda?

   -> http://www.w3.org/XML/XProc/2007/01/25-agenda.html


  Accept minutes from the previous meeting?

   -> http://www.w3.org/XML/XProc/2007/01/11-minutes.html


  Next meeting: telcon 1 Feb 2007

   No regrets given.

  Choose/When syntax

   Status quo: http://www.w3.org/XML/XProc/docs/alternate/[6]

   Richard: Does the status quo allow you to override the context on each

   Norm: Yes, by using an input named "source".

   Henry: I prefer option 2, but I'm not sure I'm happy with the name
   ... But I'm increasingly unhappy with any aspect of our design that uses
   builtin port names.

   Norm: Tying this back to for-each and friends, the name "context" was
   ... I think the context element is oddly named in the for-each case, but I
   could get used to it.

   Richard: What I find unpleasant is that the test is lexically outside the
   context binding element.
   ... The context ought to be provided for things inside it or at the same
   level, not for things outside it.

   Norm: I see your point, but I don't know what to do about it.

   Michael: I have a question of comprehension: I thought that context was
   another name for a sole input.

   Henry: That's not right: it's been an aspect of our choose/when design for
   a long time that the input to the branches is distinct from the input
   which is tested.
   ... You can test one document and process on each of the branches
   different documents.

   Michael: I think the draft should say that, I don't think it currently

   Alex: This context has the feature that we don't have to name the port.
   ... I would be really happy with a different name.

   Norm repeats his earlier comments about the name "context"

   Henry: I'm less sure that I want to treat this the same way that we treat
   for-each and viewport.
   ... In those cases, the input there really is the input to the component.
   ... I really do want to stay with some consistent notion of what "the
   input" is.
   ... I'm not sure we should fold them together.
   ... I like option 2 and I think calling it "context" is better than

   Michael: I was with you up to the last part about the name.

   Alex: For-each and viewport are exactly like choose/when.
   ... Viewport and for-each do something with the context.

   Norm: Jeni made the point that having source in for-each and viewport is a
   little odd.

   Richard: I'm wishing that I'd taken a completely different approach and
   using, for example, variables to refer to the documents in scope instead
   of all the complexity of tests.

   <MSM> +1 to HT's argument that the XPath context of a Choose/When is
   conceptually quite different from the single input of a viewport or

   Richard: It was suggested that XPaths be able to refer to inputs through
   variables. So the test could be "$source/something" or

   Alex: We chould have an extension function to do this.

   Norm muses "source(step,name)"

   <ht> p:source(step,name)

   <ht> p:pipe(step,name)

   Alex: It has the consequence that it means you can't use an off-the-shelf
   XPath implementation.

   Richard: The problem with an extension function is that it means you can
   dynamically construct the step and port names.

   Henry: If that was the only thing in the way, we could just rule that out.

   Richard: I disliked this before because it made it harder to see the flow
   of documents through the pipeline.
   ... As long as you can figure out where the pipes go at compile time, I
   could live with it.

   Henry: What I like about this is that it invites a natural default which
   is that the context of when defaults to context of choose which defaults
   to the primary input of choose.

   Norm: With my chair's hat on, I have to question the size of this change?

   Richard: I think that over the last few months, this nagging problem of
   the syntax and how to bind things for XPaths has been dragging us back.
   ... Maybe it is a big enough problem that we really do need to reconsider

   Henry: Opening XPaths in general to being able to attract input from any
   in-scope output port inside square brackets, etc. really does change the
   power of the language as it appears.
   ... It effectively changes your ability to read off the data flow of a
   pipeline from its input port elements.
   ... Extension functions have semantics that go way beyond the problem we
   were trying to solve.
   ... I'm back to thinking we should go with option 2 and discuss the name
   of the element at another time.

   Michael: My problem with option 2 is for the same information it requires
   a more complicated and elaborate XML structure. You're adding element
   structures that don't seem to be doing much. The term context is already
   taken in our spec.
   ... We're going to have different names for these things.

   Alex: Couldn't we just have an input without a port attribute?

   Henry: That's just too complex for users.
   ... Option 2 spells a special case with a special element name instead of
   spelling it "input port='source'"

   Michael: Looking at the example more carefully, I think you're right. The
   second option isn't more complex.
   ... I withdraw the argument.

   Micheal: My dislike of adding a new GI was based on the misaprehension
   given by the note in the November draft that said that context was
   analogous with the input of for-each which I'm now learning is not what
   people intend.
   ... I still stick at the term "context"

   <MSM> Henry, your argument does not support the use of the term "context"
   to mean something that the XPath spec calls by a different name

   <ht> 'context-node' works for me

   Norm: I think that option 2, if we stick with something like the current
   syntax, is a consensus position. Does anyone disagree?

   No one did.

   Norm: So the question is then, what name? We can always revisit it later.

   <MSM> if we find a different name for what is now called 'context', we can
   revisit the name of this element.

   Norm: The name is left to the editor's discretion, except that "context"
   is off the table.

   Proposed: We will adopt option 2 as described above for the next draft.




   Henry: Yes. I had in mind going back to the threads that started in



   Henry: I would like to say something like where we ended up in that
   discussion, editor please draft :-)

   Norm: The editor might like somewhat more direction.

   Alex: The real crux seems to be dealing with the preceding sibling case.

   Henry: A crucial question is, is it names or is it arity? I started out
   thinking that I didn't care what a step's port was called if it only had

   Norm: I think the draft will be easier to understand if we do it in terms
   of names.

   Henry: I think it's easier to talk about the single input port, regardless
   of name.

   Richard: We could certainly say that if the component only has one input,
   that's it's default.

   Alex: Or we could say that a component declaration indicated its default

   Richard: I like that.

   Some discussion of input ports

   Richard: I think you could just say that any unconnected input port is
   connected to the default.

   Alex: In the case of building tools, I can imagine that having a
   declaration of which one is usually defaulted would be useful.

   Richard: I can see Alex's point that this would be useful for a graphical

   <ht> I'm now convinced that the only thing we need to do is provide a rule
   for which output provides the default input binding for its following
   sibling in the case where there is more than one output port

   Richard: We could say that you designate one input as primary but that
   it's not used by the language.

   <alexmilowski> +1

   Norm: I think we're saying that, component declarations should be allowed
   to specify a single primary output, they should be allowed to specify a
   single primary input (but the language doesn't care) and that any
   unconnected input is automaticly connected to the default input.
   ... Where the default input is the default output of the preceing sibling
   or the preceding sibling of the container.
   ... Recursively.

   Richard: I would say that each container component should specify what
   it's default input is and that's in the context.
   ... I also think we should say explicitly that a component only has one
   output, that is it's default output regardless of what we say in the

  Any other business


Summary of Action Items

   [End of minutes]


   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2007/01/25-agenda.html
   [3] http://www.w3.org/2007/01/25-xproc-irc
   [6] http://www.w3.org/XML/XProc/docs/alternate/
   [7] http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Dec/0022.html
   [8] http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Dec/0041.html
   [9] http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Dec/0056.html
   [10] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   [11] http://dev.w3.org/cvsweb/2002/scribe/

    Minutes formatted by David Booth's scribe.perl[10] version 1.127 (CVS
    $Date: 2007/01/25 20:18:58 $

Received on Thursday, 25 January 2007 20:33:08 UTC

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