XProc Minutes 3 May 2007

Sigh. Let's try again, with the right subject.

See http://www.w3.org/XML/XProc/2007/05/03-minutes.html

W3C[1]

                                   - DRAFT -

                            XML Processing Model WG

3 May 2007

   Agenda[2]

   See also: IRC log[3]

Attendees

   Present
           Norm, Mohamed, Alessandro, Paul, Henry, Andrew, Michael, Alex

   Regrets
           Richard, Rui

   Chair
           Norm

   Scribe
           Norm

Contents

     * Topics
         1. Accept this agenda?
         2. Accept minutes from the previous meeting?
         3. Next meeting: telcon 10 May 2007
         4. Open action items
         5. Options vs parameters
         6. p:tee proposal or alternate debugging proposal
         7. Any other business
     * Summary of Action Items

     ----------------------------------------------------------------------

  Accept this agenda?

   -> http://www.w3.org/XML/XProc/2007/05/03-agenda.html

   Accepted.

  Accept minutes from the previous meeting?

   -> http://www.w3.org/XML/XProc/2007/04/04/26-minutes.html

   Accepted.

  Next meeting: telcon 10 May 2007

   We have regrets from Rui, Alessandro, Michael

  Open action items

   Henry to propose a debugging alternative to p:tee

   <scribe> Completed.

   Alex to craft a proposal on serialization

   <scribe> Continued.

  Options vs parameters

   ->
   http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007May/0023.html

   Henry: I think Richard and I are alike in being sympathetic to Jeni's use
   cases, we're getting things out of proportion here.
   ... XSLT is the only step that uses parameters at all.
   ... The simplest possible mechanism which allows them to work is therefore
   the best solution.
   ... I propose:
   http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007May/0061.html[7]
   ... Amended with the ability to unbind parameters.

   http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007May/0061.html[8]

   Henry: p:parameter is the only thing there is to do with parameters.
   ... All you can do is give them a value or ungive them a value. No
   namespace changing; no importing, no declaring. Nothing.
   ... The analogy Richard draws is with the environment and shell scripts.
   ... They're a single, global space and you can give them values and take
   them away and that's it.
   ... All the proposals about options are correct, I'm only arguing for a
   radically simpler parameter story.

   Alex: We have three steps that use parameters: XQuery and both XSLT's.
   ... I've been thinking about serialization parameters; we could use
   parameters for that.
   ... I think there are a lot of things where parameters are going to be
   useful.
   ... Including step types that we aren't defining.

   Henry: I agree with the position that Norm and Jeni agreed with is that
   the crucial thing about them is that you don't know much about them
   ... The difference between what we have today and my proposal is get rid
   of import-parameter and parameter declarations.

   Alessandro: So import-parameters is done automatically?

   Henry: Yes, all the in-scope parameters are always availble.

   Alessandro: Why?

   Henry: Because all of the examples we've seen so far have
   import-parameters = "*"

   Alex: And your implementation always has all the parameters available.

   Norm: And how does undeclare work?

   Henry: Making sure a parameter doesn't have a value seems like a marginal
   case, but I'd read <p:parameter name="foo"/> as an unbinding.

   Alex: That's a little weird.

   Henry: But value="" is perfectly sensible.

   Norm: My concern is that one of the things I think XProc is going to be
   used for quite a bit is chaining together multiple XSLT steps. And most
   stylesheet authors put all their parameters in no namespace. So the
   proposal you're making, Henry, begs for collisions.

   Alex: Looking at your example, the select="$per-page" will still be legal.

   Henry: I think packaging up lots of XSLT steps is something we're going to
   do a lot, but I almost never use parameters from the command line for any
   of my XSLT stylesheets.
   ... Doing so is a dodgy business. If you're writing a carefully
   constructed pipeline to do a task, you'll know what the parameters are.

   Alex: You can solve the random parameters from the command line use case
   with options or by massaging the stylesheet as part of the pipeline.

   Norm: I'm in favor of simple, and I'm willing to float Henry's proposal to
   the public and see what they say.

   Henry: What I think this will also really help our users. The way we were
   headed, with all this duplication, looked parallel but wasn't. Users were
   going to be baffled by the question of when do I use which.

   Norm: I'm convinced that this proposal is sufficiently simple that we
   should try it.

   Alex: Me too.

   Alessandro: Me too, but I'm concerned about this automatic import of
   parameters.
   ... Why not just make users list all the parameters explicitly?

   Henry: What could possibly go wrong from passing all the parameters?
   ... The only case that we're worried about is the case where you know that
   there's a collision between two stylesheets in the same pipeline.
   ... Alex pointed out that you can protect them if you know that's the
   case.

   <alexmilowski>
   http://www.w3.org/XML/XProc/docs/langspec.html#dt-in-scope-parameters[9]

   Alex: You already have a set of parameters in the environment. Then
   there's a derivation done to compute the actual parameters for each step.
   ... The actual parameters are the same as the in-scope parameters and
   you're done.
   ... The worst case is that you have to bind a bunch of extra parameters.

   Alessandro: I guess I'm not worried about implementation, I'm just
   thinking about programming languages.
   ... Generally when you call a function, you enumerate the parameters that
   you're passing.

   Henry: Exactly, that's what options are for.

   Alessandro: You don't usually have all the parameters. It could be a
   security issue, there are lots of reasons.

   Henry: You have to declare the options that you accept, you have to pass
   them explicitly, etc. Parameters are this funny business that we only have
   because of XSLT and its friends.

   <Zakim> MoZ, you wanted to remind why we split options and parameters

   Mohamed: I think we missed the point about why we split options and
   parameters in the first place.
   ... We were thinking about collisions between parameters that were for
   steps and options that were for the pipeline processor.

   Henry: Options are in a separate space; we've solved that problem.

   Mohamed: I'm speaking options declared in the spec.

   Henry: But they're in a separate space from the names of parameters;
   that's not going to change.
   ... If there's a stylesheet that takes a parameter named "filename", no
   option can collide with that.

   Mohamed: Consider this example: I have a pipeline with two XSLT steps. I
   want to make a parameter that called "filename" for the two steps.

   Henry: Then you write in each step:

   <ht> <p:parameter name='filename' value='$o1'/>

   <ht> <p:parameter name='filename' value='$o2'/>

   Henry: where o1 and o2 are *options* that you pass to your pipeline.

   <ht> and say runipipe o1=x.xml o2=y.xml

   Mohamed: The second point was that one day in import parameter we might
   have an "except" attribute.

   <alexmilowski> The only feature we don't have is the one that Norm
   mentioned: Pass all options in namespace A as parameters to XSLT A and all
   options in namespace B as parameters to XSLT B.

   <alexmilowski> ...which is OK by me.

   <ht> <p:unbind-parameter name='foo'/>

   Henry: if you really, really want to make sure that no parameter named foo
   gets into a particular step, then you write something like
   p:unbind-parameter.
   ... I'd be happier if a I saw a use case.

   Norm: I'd be happier to write it up without that feature and see if the
   world demands it.

   Henry: It's clear how we could add it.

   Norm summarizes the proposal.

   Alex: And sibling options cannot refer to each other.

   Norm: I understood that we have no forward references.
   ... Let's make that a separate issue.
   ... Anyone not understand our current proposal wrt options/parameters?

   No.

   Accepted.

   Norm: I propose to skip item 2; Alex has an open action to propose
   something about serialization; I think we should just put all these things
   in that proposal.

   Alex: I think we've accepted the names unescape-markup and escape-markup,
   so I think we can drop that issue.

   Norm: good.

  p:tee proposal or alternate debugging proposal

   ->
   http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Apr/0138.html

   ->
   http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007May/0060.html

   <ht> HST suggests that the right strategy wrt the 'sibling options'
   question is to a) be sure that wherever we allow an XPath expression in
   the spec., we specify the XPath context and b) the answer wrt options is
   "the options in the inherited environment"

   Henry: I raised the question of whether a component was the right way to
   do this.
   ... Or to think of it more as an annotation.
   ... I offered two proposals.
   ... The question is, at which end do you want to do the
   logging/journaling.
   ... One answer is: you do it at the place where the document comes from.
   ... So you could add <p:journal port="result" href="someURI"/>
   ... That doesn't require any changes, you just add that.
   ... The alternative is to go to the other end; on the input binding you
   could add a journal attribute.

   <p:pipe step="s1" port="result" journal="someURI"/>

   Henry: The disadvantage is that it requires you to put in a p:input with
   explicit names and things because it can't all be defaulted.
   ... On balance, I think I favor the first over the second.
   ... So there are three proposals: a new component, p:tee or something;
   p:journal element in a step; or the journal attribute which you can add to
   pipes.

   Norm: Anyone else have an opinion?

   Alex: The advantage of the builtin solution is that makes solving the
   sequence problem easier.

   Henry: The thing that swung me to option 1 is that you have to add two
   elements and maybe a name to use a journal attribute in a fully defaulted
   pipeline.

   Norm: Does anyone favor Henry's option 2 over his option 1?

   No one.

   Straw poll: Which do you prefer, the builtin journaling solution or a
   letting a component do it?

   Journaling: 6; Step: 1; 1 Abstain (2 concur)

   Norm: Anyone who can't live with the journaling element?

   No.

   Norm: And sequences?

   <MoZ> $p:position

   Henry: I think we should provide options that are always bound in an
   iteration and use attribute value templates to let the user specify how to
   deal with it.

   Norm: We don't have AVTs. Do you really want to add them for this?

   <ht> href="'foo.xml'"

   Henry: I'd be perfectly happy to say that the value of the href is an
   XPath expression, but then the 90% case is "'xxx'".

   <ht> href="concat('foo',$p:position,'.xml')"

   Norm: I have another: implementation defined.

   Henry: I can live with that, but I think that having iteration and
   sequence number variables in the environment is going to turn out to be
   hugely useful.

   Norm: This is Mohamed's p:position everywhere right?

   Henry: Yes, but I think we're also going to need named index iterations
   for nested for-eaches.
   ... we need both.

   <ht> for iteration step name='foo', then an option p:foo_i is bound

   Norm: I'm starting to feel like functions are a better way to do this than
   automatic variable bindings.

   Mohamed: We have to figure out what it means to evaluate an XPath
   expression on a sequence.

   <ht> <p:input select="foo">

   <ht> <p:pipe step='s' port='p'/>

   <ht> </p:input>

   Mohamed: If we say that it's the same as evaluating the expression over
   each document in the sequence, then functions and variables are the same.

   Norm: I'm still not sure I understand.

   Henry: At the end of the day, what I want is a third variable or function
   which is unique per pipeline evaluation episode.

   <scribe> ACTION: Henry to write up all the variables/functions he wants.
   [recorded in http://www.w3.org/2007/05/03-xproc-minutes.html#action01[12]]

  Any other business

   Henry: Are we meeting in November?

   Norm: I think we said yes, but I'll double check.

   Adjourned.

Summary of Action Items

   [NEW] ACTION: Henry to write up all the variables/functions he wants.
   [recorded in http://www.w3.org/2007/05/03-xproc-minutes.html#action01[13]]
   **
   [End of minutes]

     ----------------------------------------------------------------------

   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2007/05/03-agenda.html
   [3] http://www.w3.org/2007/05/03-xproc-irc
   [7] http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007May/0061.html
   [8] http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007May/0061.html
   [9] http://www.w3.org/XML/XProc/docs/langspec.html#dt-in-scope-parameters
   [12] http://www.w3.org/2007/05/03-xproc-minutes.html#action01
   [13] http://www.w3.org/2007/05/03-xproc-minutes.html#action01
   [14] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   [15] http://dev.w3.org/cvsweb/2002/scribe/

    Minutes formatted by David Booth's scribe.perl[14] version 1.128 (CVS
    log[15])
    $Date: 2007/05/03 16:08:28 $

Received on Thursday, 3 May 2007 16:26:47 UTC