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

XProc Minutes 14 Feb 2008

From: Norman Walsh <ndw@nwalsh.com>
Date: Thu, 14 Feb 2008 13:43:17 -0500
To: public-xml-processing-model-wg@w3.org
Message-ID: <m2bq6jtm4a.fsf@nwalsh.com>
See also: http://www.w3.org/XML/XProc/2008/02/14-minutes


                                   - DRAFT -

                            XML Processing Model WG

Meeting 102, 14 Feb 2008


   See also: IRC log[3]


           Henry, Mohamed, Norm, Richard, Andrew, Alex, Michael





     * Topics
         1. Accept this agenda?
         2. Accept minutes from the previous meeting?
         3. Next meeting: telcon 21 February 2008?
         4. Rename p:declare-step to p:step?
         5. #58, Scope of options
         6. Any other business
     * Summary of Action Items


  Accept this agenda?

   -> http://www.w3.org/XML/XProc/2008/02/14-agenda


  Accept minutes from the previous meeting?

   -> http://www.w3.org/XML/XProc/2008/02/07-minutes


  Next meeting: telcon 21 February 2008?

   Possible regrets from Mohamed

  Rename p:declare-step to p:step?

   Henry: I'm a little bit opposed.
   ... Only in so far as it has a side effect that none of the other elements

   Norm: Yes, I see your point.

   <richard> i'm opposed to <step>

   Henry: Maybe p:step-type would be ok, but it's a little rarified.

   Resolved: No change.

  #58, Scope of options

   -> http://www.w3.org/XML/XProc/2007/09/lastcall/comments.html#C058

   Norm outlines the situation; states a strong preference for changing to
   the XSL style.

   Henry: I don't feel as strongly as I used to, but I thought Richard had a
   counter example.

   Richard: I don't recall it.
   ... Order is important

   Norm: Yes.
   ... I should also say that I imagine this only applies to compound steps.

   Mohamed: I'm not sure about the counter example, but the fact that option
   can read its value from a port and that some ports may be reorganized may
   make some problems.
   ... There may be some implied circularity.
   ... Suppose we have a step that appears before the following step, but the
   ... [scribe lost the example]

   Norm: I don't think that's the case, but I could be wrong...

   Richard: These are defaults, right, on p:pipeline? So in addition to the
   order question, there's the question of which ones are provided and not

   Alex: I don't think this adds any more complexity, except that you have to
   keep track of the document order of options.

   Richard: In the case of pipeline, the values given to options are default
   values. In the case of p:group, they're not defaults, they're always

   Some discussion of compound versus group.

   Norm observes that XSL does have the distinction between p:param and

   <ht> HST thinks Norm's point is a good one


   <p:option name="a" value="5">


   <p:option name="a" value="7"/>

   <p:option name="b" select="$a + 1"/>


   Richard: Option creates a new value in the called step, you don't get a
   new scope in the *calling* step. That would just be strange.


   <p:option name="a" value="5">


   <p:with-option name="a" value="7"/>

   <p:with-option name="b" select="$a + 1"/>


   Henry: If we say that only p:option binds, then that would resolve the

   Alex: I'm wondering why we can't leave things the way they are.

   Norm: See my first example from #58
   ... You can't pass a and b if you put b in a group, it's no longer an
   option of the pipeline

   Alex: Then I think we have to rename one of them, it's too confusing
   ... I don't see why we don't make it the same for compound and atomic

   Richard: The reason why they behave differently is that it's a default
   value in one case and a value in another.
   ... If we're going to rename things, I'd prefer to rename the value
   ... We could use default-value and default-select.
   ... It's only in default-select that the binding becomes visible.

   Alex: When you're invoking the option, you're setting the value. If that
   happened to be a pipeline then it would set the value.

   <MoZ> what about p:let ?

   Richard: If instead you've got p:pipeline, then you'd use default-select
   and then it would use the local binding.

   Alex: Invoking a pipeline is special.

   <Zakim> Moz, you wanted to talk about p:let

   Mohamed: Maybe instead of renaming p:option to p:with-option, changing the
   "outer" option to p:let
   ... So this way we can make the difference between the option and the
   variable clearer.

   Norm mumbles a bit.

   Mohamed: The problem with p:pipeline is inside pipeline, I don't see how
   to fix that.

   Henry: Following Mohamed's lead, we could introduce p:variable.
   ... We don't need a new scoping mechanism
   ... Pipelines can have options and variables, compound steps can have
   variables, and atomic steps can have options.

   Richard: If you've got some builtin step type, you could have different
   declarations for it.

   Some discussion of our backards compatibility story


   <p:option name="a" value="1"/>

   <p:option name="b" select="$a"/>


   Norm: I don't think adding p:variable helps. Because I still want two

   Henry: That works in XSLT?

   Norm: I think so.

   Norm confirms that XSLT works they way he thought.

   Richard: That's to be expected because xsl:param is pretty much like an

   <MSM> [I am not able to follow the details here, but on the surface AM's
   position sounds plausible and orthogonal and good. I could be wrong.]

   Some discussion continues. Perhaps compound steps have variables not

   Henry: Suppose we said that p:option can only occur with default values is
   in a declare-step.
   ... You use p:option whenever you invoke something that's declared with
   declare step
   ... And in the latter case, the scope is uniform across all of them.
   ... But that for evaluating variable references in defaults, XSLT scoping
   rules apply.
   ... And we have a new thing, p:variable, that is very similar to
   xsl:variable, except that we use a value vs. select attribute.
   ... It may appear in any compound step, including declare-step.
   ... I'd like to also consider abandoning @value and using only @select.

   <MSM> including declare-step? doesn't that open up issues of lexical vs
   dynamic scoping?

   Norm: Given that we don't allow options/parameters/etc. to have compound
   values, I'd be reluctant to allow content.

   Scribe got lost

   Henry: I don't think we've every said you're not allowed to have defaults
   on the options of declared steps.
   ... We should exclude p:import and p:declare-step from p:declare-step when
   an atomic step is declared. We could do the same thing for p:variable.

   Richard: Now that we declare pipelines with declare-step, declare-step can
   occur inside itself. Can it's options see the values of options outside

   Henry: I don't know, but it doesn't matter with respect to variables.

   Richard: I think p:declare-step should be totally opaque.

   Norm: I agree.

   <MSM> [so I can't write a sort of generic declaration that I could
   parameterize ?]

   Henry asserts some sort of dynamic scoping of options.

   Norm and Richard balk.

   Henry: is broken with respect to this, the XPath processor context
   for the default value is uninterpretable.

   Richard: The answer should be in 2.x, the environment which specifies the
   optoin environment.
   ... What it says so far is right at the moment

   <MoZ> but visible is not defined !!

   Henry: But declare step is not a step. Following your nose from
   leads to somewhere that says it doesn't apply to you.

   Run out of time

  Any other business



Summary of Action Items

   [End of minutes]


   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2008/07/14-agenda
   [3] http://www.w3.org/2008/02/14-xproc-irc
   [7] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   [8] http://dev.w3.org/cvsweb/2002/scribe/

    Minutes formatted by David Booth's scribe.perl[7] version 1.133 (CVS
    $Date: 2008/02/14 18:42:08 $

Received on Thursday, 14 February 2008 18:43:34 UTC

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