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

XProc Minutes 4 October 2007

From: Norman Walsh <ndw@nwalsh.com>
Date: Thu, 04 Oct 2007 12:16:07 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <m2641mvos8.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2007/10/04-minutes


                                   - DRAFT -

                            XML Processing Model WG

Meeting 86, 4 Oct 2007


   See also: IRC log[3]


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





     * Topics
         1. Accept this agenda?
         2. Accept minutes from the previous meeting?
         3. Next meeting: telcon 11 October 2007
         4. Review of XSLT streaming requirements
         5. Comment 30: Parameter inputs as strings
         6. Comment 28: Determining whether a pipeline has a (defaulted)
         7. Comment 1: An unfulfilled requirement maybe? (p:exec)
         8. Comment 6: Bindings for pipeline inputs
         9. Comment 23: p:add-xml-base with relative=true
        10. Any other business?
     * Summary of Action Items


  Accept this agenda?

   -> http://www.w3.org/XML/XProc/2007/09/27-agenda


  Accept minutes from the previous meeting?

   -> http://www.w3.org/XML/XProc/2007/09/27-minutes


  Next meeting: telcon 11 October 2007

   Mohamed gives regrets.

  Review of XSLT streaming requirements

   Murray reviewed it, but suggested that someone with more implementation
   experience should also take a look.

   <scribe> ACTION: Alex to review before the face-to-face. [recorded in

   Paul: Discounted hotel reservations for the face-to-face expired

   Norm: Yes, and hotel rooms are ahrd to come by that week; good luck!
   ... Who's coming?

   Henry, Norm, Paul, Alex, Richard is tentative

   Richard: Comments to the comments list, but many of them turn into long

   Norm: I think it's ok if we only have admin on the WG list. New last call
   comments should go on the ocmments list, I think.

   Mohamed: Where are we on the test suite?

   Norm: I'm generating new ones as I work through my impl; I encourage
   others to send them in using the test format.

   Some discussion of the test suite.

   <scribe> ACTION: Norm to arrange for the tests on tests.xproc.org to be in
   Subversion so that anyone can update them. [recorded in

  Comment 30: Parameter inputs as strings

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

   Norm describes the issue. Is symphathetic.

   Henry: I'm not sympathetic. I wish we could undo some of the architecture
   changes that XSLT has *already* imposed on us.
   ... I think parameters have ended up swamping what was otherwise a fairly
   clean design.

   Henry: Basically, my view is that this problem is the thin edge of a long
   and complicated issue dealing with inputs of an unknown arity.
   ... I can think of at least three ways to solve it and we'll need to do it
   in V.next. I'd rather not do it at the last minute for XSLT when we'll
   need to do it later.
   ... I'm just skeptical of the whole thing; the cost-benefit ratio is
   hugely out of whack.

   Alex: What XSLT really needs is a way to associate a name with a arbitrary
   ... We've removed arbitrary inputs so we'd have to invent some much more
   heavyweight mechanism to do that.
   ... I'm with Henry in some ways; I wonder if we should consider the
   ability to bind some number of documents with some number of names.

   Henry: I think we can do it in V.next in any one of at least three ways as
   I outlined in email.
   ... It'll take time to think them through.

   Norm and Henry discuss how some implementors allow for XSLT parameters to
   be bound to files.

   Norm: You can work around this with a generated stylesheet, of course.

   Henry: I don't think now is the time to design the general solution.

   Alex: It allows documents in under the covers.

   Norm: I don't know what you mean by under the covers.

   Richard: XSLT says that its implementation defined how parameters get
   passed in from outside. AFAICT, there's no requirement accept any kind of
   ... Mine only allows you to pass in strings. For things that you run from
   the command line, there's no obvious way to pass in anything else.
   ... If we say this is going to work, that means you're saying your XSLT
   implementation has to be able to accept things that aren't strings.
   ... Otherwise you'll get interoperability problems.

   <Zakim> ht, you wanted to ask about the api issue

   Henry: At the moment if I write parameter name=foo
   select=.//pset[@foo=baz] I get an element node which gets stringed and I
   get a string.
   ... How will I tell if there's an attempt to pass something other than a

   Richard: We'd have to change the language, saying that things selected
   don't get turned into strings so you have to use string(). There are
   several possibilities.

   Straw poll: Do you support allowing non-string parameters?

   Results: Y 4, N 4, C: 1

   Norm: I don't see a consensus to make a change to the spec.

   Propose: Not in V1.

   No objections.

   <scribe> ACTION: Henry to reply to the commenter. [recorded in

  Comment 28: Determining whether a pipeline has a (defaulted) output

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

   Scribe notes that the numbers got messed up.

   Richard: Like Henry, I'd like very simple pipelines to be simple. So I
   don't want to have to put in input and output statements in those cases.
   ... I constructed a hard case, but I don't really want to throw out the

   Norm: I can see that, but I want a solution that doesn't require the depth
   of analysis that Richard's example would require.

   There's some question of whether this only applies to pipelines in

   Richard: Henry suggested that you might only be allowed to do this in the
   top-level pipeline. But that doesn't really help.

   Alex: Couldn't we just outlaw circularity?

   Richard: Yes, we could say that the only circumstance where you can't do
   it is the one where you can't figure it out.
   ... But simple recursion is allowed.

   PGrosso, we could hear you :-)

   Alex: We could say that circularities must be explicitly broken. It's not
   straightforward to detect, but we coudl have a blanket statement about it.

   Henry: The way it ends up working is that we revise the statement about
   how pipeline outputs default to say that they default to the output of the
   last contained step provided that that can be uniquivocally determined
   ... Expanded slightly if necessary to make it clear.

   Richard: If the last step isn't a call to a pipeline that doesn't have
   explicit outputs.

   Henry: I don't think that stating that carefully will take more than two
   or three sentences.

   Richard: I'm not sure that this will turn out to be the case.

   Alex: Yeah, I'm not sure it can be done locally.

   Henry: My proposal is fairly radical: maybe it'll be confusing but, I
   would say: you have to have explicit not-calling-other-pipeline steps in
   every place where you have to look.

   Richard: It mustn't be a pipeline.

   Henry: Yes. That's the minimum to declare victory.

   Alex: I'm confused. Every step has a declaration...
   ... Think about a processor that's building step declarations. You'd have
   to flag the ones that come from pipelines.

   Richard: But you haven't determined the declaration of another pipeline

   Alex: In this case, yes, but ...

   <scribe> ACTION: Henry to craft the prose to cover this case. [recorded in

  Comment 1: An unfulfilled requirement maybe? (p:exec)

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

   Norm: In principle, do we want to do this?

   Richard: This is something who's effect is completel system dependent.

   Norm: Yes.

   <Zakim> ht, you wanted to talk about / conversion

   Henry: I think there are two or three details here, but I'm happy to wait
   until we have a draft.
   ... What about serialization?
   ... What about the working directory?
   ... We need to do / conversion in file paths

   <scribe> ACTION: Norm and Alex to craft a proposal. [recorded in

   <richard> this is an optional step, right?

   <Norm> yes

  Comment 6: Bindings for pipeline inputs

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

   Norm summarizes the thread.

   Henry: I think the defaulting semantics is a little tricky to specify
   clearly. But I do absolutely want to have pipelines with fixed inputs.

   Richard: That's quite different from defaulting input then you don't need
   any syntax at all. You just make the first step read from a constant

   Henry: That inclines me even further towards the position that this is
   more confusion that it's worth. We don't have any use cases for it.
   ... I'm particuarly unhappy with Norm's answer to Richard's question about
   how it works when you call a named pipeline.

   Norm isn't sure if he was clear

   Alex: I can see this going either way.
   ... Do we say what happens in the pipeline case. You can have a step that
   has an unbound input. But pipelines can have bindings that go with them.
   When you use a named pipeline, it can use that binding.

   Richard: If you put a call to a pipeline in, and you don't ...

   Norm: Maybe it's too confusing.

   Richard: The only trace where this even arises is in the place where it
   says that pipeline inputs can be defaulted.

   Norm: I suggest we take this one to email and leave it for a week.

   Henry: I encourage Alex to write up what he saw as the use for that.

   Alex: Now that I think about it some more, I don't think we need this at

  Comment 23: p:add-xml-base with relative=true

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

   Norm: Do you change an absolute xml:base to relative?

   Anyone think we should change xml:base attributes?


   Some discussion of whether or not a step with an xml:base attribute can
   have a different base URI.

   Alex: I think this step should make this explicit.

   <scribe> ACTION: Henry to attempt to improve the prose for p:add-xml-base
   [recorded in http://www.w3.org/2007/10/04-xproc-minutes.html#action06[16]]

  Any other business?


Summary of Action Items

   [NEW] ACTION: Alex to review before the face-to-face. [recorded in
   [NEW] ACTION: Henry to attempt to improve the prose for p:add-xml-base
   [recorded in http://www.w3.org/2007/10/04-xproc-minutes.html#action06[18]]
   [NEW] ACTION: Henry to craft the prose to cover this case. [recorded in
   [NEW] ACTION: Henry to reply to the commenter. [recorded in
   [NEW] ACTION: Norm and Alex to craft a proposal. [recorded in
   [NEW] ACTION: Norm to arrange for the tests on tests.xproc.org to be in
   Subversion so that anyone can update them. [recorded in
   [End of minutes]


   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2007/10/04-agenda
   [3] http://www.w3.org/2007/10/04-xproc-irc
   [6] http://www.w3.org/2007/10/04-xproc-minutes.html#action01
   [7] http://www.w3.org/2007/10/04-xproc-minutes.html#action02
   [9] http://www.w3.org/2007/10/04-xproc-minutes.html#action03
   [11] http://www.w3.org/2007/10/04-xproc-minutes.html#action04
   [13] http://www.w3.org/2007/10/04-xproc-minutes.html#action05
   [16] http://www.w3.org/2007/10/04-xproc-minutes.html#action06
   [17] http://www.w3.org/2007/10/04-xproc-minutes.html#action01
   [18] http://www.w3.org/2007/10/04-xproc-minutes.html#action06
   [19] http://www.w3.org/2007/10/04-xproc-minutes.html#action04
   [20] http://www.w3.org/2007/10/04-xproc-minutes.html#action03
   [21] http://www.w3.org/2007/10/04-xproc-minutes.html#action05
   [22] http://www.w3.org/2007/10/04-xproc-minutes.html#action02
   [23] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   [24] http://dev.w3.org/cvsweb/2002/scribe/

    Minutes formatted by David Booth's scribe.perl[23] version 1.128 (CVS
    $Date: 2007/10/04 16:15:01 $

Received on Thursday, 4 October 2007 16:16:25 UTC

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