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

XProc Minutes 8 Feb 2007

From: Norman Walsh <Norman.Walsh@Sun.COM>
Date: Thu, 08 Feb 2007 12:13:53 -0500
To: public-xml-processing-model-wg@w3.org
Message-ID: <87zm7o373i.fsf_-_@nwalsh.com>
See http://www.w3.org/XML/XProc/2007/02/08-minutes.html


                                   - DRAFT -

                            XML Processing Model WG

Meeting 54, 8 Feb 2007


   See also: IRC log[3]


           Norm, Richard, Rui, Henry, Andrew, Alex, Mohamed, Alessandro,
           Michael, Murray





     * Topics
         1. Accept this agenda?
         2. Accept minutes from the previous meeting?
         3. Next meeting: telcon 15 Feb 2007
         4. Face-to-face in 2007?
         5. Is the defaulting story right?
         6. Is the choose/when story right?
         7. Do we want to do something similar about for-each/viewport?
         8. Use "environment" for "context"?
         9. Any other business?
     * Summary of Action Items


  Accept this agenda?

   -> http://www.w3.org/XML/XProc/2007/02/08-agenda.html


  Accept minutes from the previous meeting?

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


  Next meeting: telcon 15 Feb 2007

   Richard gives possible regrets. Andrew gives regrets.

  Face-to-face in 2007?

   Nothing new to say; keep thinking about it.

  Is the defaulting story right?

   Henry: I don't think I feel any differently this week: it all ought to
   ... I ought to be able to write straight-through pipelines including both
   components and atomic steps.

   Richard: I agree with Henry's aim, but I remain concerned that doing so
   will make it less natural to write fully elaborated pipelines.

   Henry recalls off-line discussion with Richard

   Henry: Suppose we add an attribute to containers to specify how many
   output ports it has. It defaults to 1.
   ... Because absence was being overloaded in the default syntax.

   Norm: How about simply an attribute to say "this component has no outputs"

   Henry: That works.

   Richard: It does cover the only case where there was an ambiguity.

   Norm asks about the defaulting story.

   Alex: What about an input that becomes an output.

   Proposal: The editor shall attempt to write up the defaulting story as
   we've described it here, with some mechanism for dealing with the single
   ambiguity we can see.


  Is the choose/when story right?

   Norm: this is the use of xpath-context instead of input for the

   Alex: We have the issue that the XPath works differently.
   ... In the examples that we have here, Henry matches against an attribute
   node where we have an input everywhere else.
   ... If you use input, you always get a document. On xpath-context, Henry's
   proposing that it's a node, not a document.

   Norm: My inclination would be to keep them the same, and wrap the matches
   that xpath-context returns in a document node.
   ... This would make the XPath expression a little odd, but would be

   Alex: But that's not what the author would expect.

   Alex recounts an XSLT example.

   Norm: Ok, the other alternative is to make it different.


   Richard: I'm in favor of it being a document because apart from this, we
   pass documents everywhere.

   Alex: If we go the document route, then this could be better if
   xpath-context would be a wrapper for input.

   Henry: I'm happy with the resolution that it's a document.

   Proposal: Describe the result of select expressions as a document.

   <MSM> clarification?

   <MSM> if I select //foo, how many documents do I get?

   Henry: Parenthetically, it should be said that without the select
   expression the result is a document.

   <MSM> count(//foo) ? or the number of //foo that don't have a foo

   Norm: Whatever you get for input, you should get here.

   Richard: Isn't this supposed to be a context *node*"

   Henry: I agree. There's no way to do unfolding or iteration at this level.

   <alexmilowski> 4.2.2: "... Each matching node or set of nodes is wrapped
   in a document and provided to the input port."

   Henry: I'd like to make it an error if the select expression doesn't match
   a single element node.

   <alexmilowski> ...but later: "...provides a sequence of zero or more
   documents, one for each matching html:div in the document "

   Norm: I'd be happy to impose that restriction.

   <MSM> so: 'set of nodes' just means 'subtree' here, and if you have a div
   within a div, each of them gets wrapped as a document (so one of them goes
   through twice, once as root element and once as descendant)

   <MSM> If getting zero is OK, I don't quite understand why getting n > 1
   istn't ok

   Henry: The results should be just like concatenating the two expressions,
   the select on xpath-context and the test on when. It follows that zero
   would fall through to the otherwise.

   <alexmilowski> not(/)

   Alex: I think we have an issue about an empty sequence of documents.

   Henry: That's the what does select=not(/) mean on input questoin.

   Proposal: We'll say select on xpath-context must match exactly one element
   or document, otherwise it's an error.


   <scribe> ACTION: Editor to clarify the text in 4.2.2 [recorded in

  Do we want to do something similar about for-each/viewport?

   <MSM> [I'd like to be sure I understand our rationale. If we want the kind
   of flexibility we'd get from allowing 0 or n, what we can do is not write
   a select on the xpath-context element, and write a longer test on the when
   ... is that right?]

   <Norm> [Yes]

   <MSM> [I do wish the spec would talk about data sources and data sinks,
   insted of input and outputs ...]

   <richard> that's what we considering michael: that both outputs of earlier
   components and inputs of ancestor components are data sources

   MSM: the outputs property in the context are the set of data sources

   <ht> ... inside a construct, the outputs of your siblings, and the
   construct's inputs, are available to you

   Norm attempts to provide an example:

 <p:pipeline name="pipe">
   <p:input port="foo">

     <p:input port="xxx">
       <p:pipe step="pipe" port="foo"/>

   Norm: The first step can read from "foo" because it's exposed as an
   available input. Similarly:

 <p:for-each name="iter">
   <p:input port="source">

     <p:input port="xxx">
       <p:pipe step="iter" port="source"/>

   Norm: The first step of the for-each can read from "source" because it's
   exposed as an available input.

   <ht> AM: The construct's contents can _already_ point to the same things
   that the inputs point to

   <ht> NW: See above example, works because the pipeline's input are in the
   available inputs of the context for the step

   <ht> AM: 'pipeline' is special, because there's no outer context

   <ht> ... we don't _need_ this for for-each and viewport

   <ht> RT: I think AM has a point, there would be no problem if we didn't do
   this, _except_ for pipeline

   Henry: I like what Alex is saying. Pipeline inputs are different.

   <ht> RT: we could provide some _other_ means for users to bind pipeline

   Richard: We could say that invoking a pipeline creates a context which
   must include certain things.

   Alex: We discussed this last week, but I don't remember why this came up.

   Norm tries to reconstruct how we got here

   <ht> HST: Norm, I think your example would be clearer wrt Alex's point if
   it were completed (?) by having <p:input port="source"><p:pipe step="x"

   Norm: Right:

 <p:for-each name="iter">
   <p:input port="source">
     <p:pipe step="somewhereelse" port="someport"/>

     <p:input port="xxx">
       <p:pipe step="iter" port="source"/>

     <p:input port="yyy">
       <p:pipe step="somewherelese" port="someport"/>

   Norm: The first step doesn't have to be able to read from the source
   because, as shown in the second step, it could read directly from what the
   source port reads.

   Norm: I hear a bunch of people who want to change the way we describe why
   inputs are visible in the pipeline.

   Richard: One reason that the current semantics are reasonable is by
   analogy with functions. Functions parameters are available inside
   ... Rather than saying pipelines are an exception, it's really the
   components that are the exception.

   Alex: If we switch the input to xpath-context of whatever for
   viewport/for-each, then we have this xpath-context thing doing something
   that it doesn't do in the case of choose.

   <MSM> [Richard, I wonder, though. If we had a way to encapsulate
   constructs (e.g. in separate pipeline documents) and call them from
   multiple locations, the function analogy would be more persuasive. But do
   we have any such information-hiding mechanism?]

   Alex: So that would be a change in how that works.

   <ht> HST would find it clearer if we called the hypothetical parallel
   something such as p:iteration-source -- p:xpath-context is surely
   misleading here

   <richard> [MSM, No, except for cut-and-paste in a graphical interface]

   <MSM> [Or a general entity, I guess, for those of us who do that kind of

   <ht> [MSM, yes, for v.next we've several times talked about having a
   'call-named-pipeline' component]

   Norm: Following on Richard's observation, the current situation does make
   components more self-contained.

   Alex: If you didn't allow inputs to be declared on for-each and viewport
   then this issue would go away.

   Henry: that's just saying that we'll allow you to treat for-each and
   viewport as a group.
   ... Aside from the name which is clearly broken, I'm inclined toward that
   ... I suggested "iteration-source"

   Alex: You can still have inputs, they just have nothing to do with what
   you're iterating.

   <scribe> ACTION: Editor to clarify how multiple inputs work---maybe this
   is just a note to the editor for his own understanding [recorded in

   Richard: You're saying that for-each and viewport no longer have an input
   used for iterating, there's a special element called iteration-source that
   specifies it.

   Henry: yes.

   Richard: How do the things inside viewport get their input?

   Henry: References to "current" remain the same.

   Richard: Maybe the name shouldn't be fixed, but be something that you can

   <ht> HST agrees we also set aside whether interation-source allows a
   'select' attribute

   Norm: Let's not.

   <ht> +1 to having an attr on p:iteration-source which names the iteration
   port, possibly defaulting to 'current'

  Use "environment" for "context"?

   More support than opposition, editor will try.

  Any other business?


Summary of Action Items

   [NEW] ACTION: Editor to clarify how multiple inputs work---maybe this is
   just a note to the editor for his own understanding [recorded in
   [NEW] ACTION: Editor to clarify the text in 4.2.2 [recorded in
   [End of minutes]


   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2007/02/08-agenda.html
   [3] http://www.w3.org/2007/02/08-xproc-irc
   [6] http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Feb/0012.html
   [7] http://www.w3.org/2007/02/08-xproc-minutes.html#action01
   [8] http://www.w3.org/2007/02/08-xproc-minutes.html#action02
   [9] http://www.w3.org/2007/02/08-xproc-minutes.html#action02
   [10] http://www.w3.org/2007/02/08-xproc-minutes.html#action01
   [11] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   [12] http://dev.w3.org/cvsweb/2002/scribe/

    Minutes formatted by David Booth's scribe.perl[11] version 1.127 (CVS
    $Date: 2007/02/08 17:12:27 $

Received on Thursday, 8 February 2007 17:14:23 UTC

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