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

XProc Minutes 1 Mar 2007

From: Norman Walsh <Norman.Walsh@Sun.COM>
Date: Thu, 01 Mar 2007 13:41:05 -0500
To: public-xml-processing-model-wg@w3.org
Message-ID: <87d53sbyda.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2007/03/01-minutes.html


                                   - DRAFT -

                            XML Processing Model WG

Meeting 57, 1 Mar 2007


   See also: IRC log[3]


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





     * Topics
         1. Accept this agenda?
         2. Accept minutes from the previous meeting?
         3. Next meeting: telcon 8 Mar 2007
         4. New draft
         5. Parameters
         6. Any other business
     * Summary of Action Items


  Accept this agenda?

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


  Accept minutes from the previous meeting?

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


  Next meeting: telcon 8 Mar 2007

   Mohamed gives regrets

  New draft

   Norm: I published a new draft yesterday:

   Norm summarizes.

   Norm: There's no reasonable diff.

   Norm outlines the current dichotomy between QName and NCName and
   p:pipeline and everwhere else.

   Henry: We never need to refer to p:pipelines yes?

   Norm: No, the p:pipe elements have to point to them.

   Henry: That's inside a pipeline, so we'd like that to be an NCName.

   Norm: We also need to be able to refer to pipelines.

   Henry: My vague memory was that we won't have a run-pipeline component in

   Norm: My understanding was that we wouldn't provide a mechanism for
   running a dynamically constructed pipeline but that we would provide a
   mechanism for running static pipelines from libraries

   Alex: I don't see why we made the names NCNames. It should be just like
   the names of templates in XSLT.

   Henry: The major confusion factor that I've observed in that context is
   that you have to worry about names getting captured by the default
   namespace declarations.

   Alex: It should be up to the user. If you don't want to use QNames, you
   don't have to.

   Norm: Agenda item for next week: how to call static pipelines in an
   imported library.

   Henry: If you've defined a named pipe, then you should be able to invoke
   it by writing its name as a start tag in a subpipeline.


   Norm: The problem as I see it is what, if anything, we do about the case
   of parameter for step invokation vs parameters for the invoked component.

   Henry: Saxon 8, for example, distinguishes between options and parameters.

   Norm: Jeni brings in lists of strings which I'd like to overlook for the

   Alex: What we have now is good enough.
   ... Our current parameter story is simple and I don't think we need
   anything else. We can say which things are significant to the
   configuration of the step.

   Norm: Works for me.
   ... Does anyone think there's anything wrong with Alex's approach?

   Henry: I haven't read the thread, but it sounds right.

   Alessandro: I think I agree. But I still think that Jeni's answer has some
   merit. In particular, I like the third proposal.

   Norm: What problem is she solving?

   Alessandro: Well, it addresses the case of different classes of
   parameters. XSLT has two classes, but other components might have more

   <alexmilowski> it is the open content model for documentation problem...

   <alexmilowski> That's the problem.

   Norm: I'm worried about determining the difference between subpipelines
   and parameters.

   Henry: We've said that user-defined steps are atomic.

   <alexmilowski> e.g. the component's element can have ignorable children

   <MoZ> alexmilowski, p:documentation

   Alex: The problem is our steps have an open content model in order to
   allow documentation.
   ... For these crazy components that have all these problems with weird
   lists and values, this is XML, you can pass those as an *input*

   Henry: That's a helpful observation. It almost leads me back to the
   minimalist position to which I'd originally been inclined.
   ... First I was going to say that my understanding of Jeni's use case is
   that it relies on sub-symbol spaces. But as Alex observed earlier,
   namespaces are the XML solution to this problem.

   <alexmilowski> Oh... no... we need QNames on parameters for simple setting
   of things like XSLT parameters...

   Henry: I didn't notice that parameters were named with QNames. I think we
   should rely on here documents.

   Murray: There are options that I type on the command line, like -o, and
   then there's information that we pass into the application. It's going to
   use that information to do its job. A stylesheet is one example
   ... Although we've talked about competing name tokens, it seems to me that
   they're competing in different environments.
   ... It seems as though the conflict is happening in two different

   <ht> Whew! saxon uses {uri}localname=value to bind parameters in
   namespaces to values on the command line

   <ht> MoZ just said he likes p:option and p:parameter, and I think that's
   worth thinking about

   Norm: We don't have a mechanism for dynamically generating a document.

   <ht> <p:parameter name="xsl:initial-mode" select="$p:initialMode"/>

   Henry: I think the options of the builtin component should be in the
   pipeline namespace or in the appropriate namespace for the component.

   <ht> Yeah, I guess I agree -- we're calling it p:xslt, not xsl:doit. . .

   Norm: I think it would be fair to just not pass the parameters in the p:
   namespace through

   Henry: I'm not sure about thta.

   Norm: Well, it's not clear that there's a right answer.

   Alessandro: We could use prefixes just like I outlined in email.

   Henry: I think namespaces are the prefixing mechanism to use in XML.
   ... I come back to the other proposal that we have p:option and

   Norm: Can mortals be expect to tell the difference?

   Henry: But few components have options so it doesn't seem to be a problem.

   Murray: We just have to explain it in the spec.

   <alexmilowski> xquery does too...

   Henry: Only XSLT, of all the components we've discussed so far, makes this

   Mohamed: Jeni's remark was about configuration parameter vs. parameter
   that was difficult to distinguish, but maybe option and parameter will be
   more obvious.
   ... I think it would be interesting to go further.

   Norm: It seems like we're coming to consensus that we should use p:option
   and p:parameter.

   <scribe> ACTION: Norm will type up a proposal for p:option and
   p:parameter. [recorded in

  Any other business



Summary of Action Items

   [NEW] ACTION: Norm will type up a proposal for p:option and p:parameter.
   [recorded in http://www.w3.org/2007/03/01-xproc-minutes.html#action01[8]]
   [End of minutes]


   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2007/03/01-agenda.html
   [3] http://www.w3.org/2007/03/01-xproc-irc
   [6] http://www.w3.org/XML/XProc/docs/ED-xproc-20070228/
   [7] http://www.w3.org/2007/03/01-xproc-minutes.html#action01
   [8] http://www.w3.org/2007/03/01-xproc-minutes.html#action01
   [9] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   [10] http://dev.w3.org/cvsweb/2002/scribe/

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

Received on Thursday, 1 March 2007 18:41:42 UTC

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