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

XProc Minutes 22 Feb 2007

From: Norman Walsh <Norman.Walsh@Sun.COM>
Date: Thu, 22 Feb 2007 12:07:40 -0500
To: public-xml-processing-model-wg@w3.org
Message-ID: <87wt2am883.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2007/02/22-minutes.html


                                   - DRAFT -

                            XML Processing Model WG

Meeting 56, 22 Feb 2007


   See also: IRC log[3]


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

           Paul, Henry




     * Topics
         1. Accept this agenda?
         2. Accept minutes from the previous meeting?
         3. Next meeting: telcon 1 Mar 2007
         4. Components that act as interfaces to multiple applications
         5. Step names
         6. Pre-defined vs. arbitrary application parameters
         7. Any other business?
     * Summary of Action Items


  Accept this agenda?

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


  Accept minutes from the previous meeting?

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


  Next meeting: telcon 1 Mar 2007

   No regrets given

  Components that act as interfaces to multiple applications

   Mohamed: Today we have p:xslt and p:validate. Do we want to have one for
   each technology or one for all? The problem I see is that the answer won't
   be so simple.

   <MSM> "one for each" vs. "one for all" - nice formulation of the choice.

   Mohamed: Suppose we say we have p:validate, then we can defer the fact
   that some may be core and some may not.
   ... But if we say we have to have specific names, then we need to fix the
   list as soon as possible.
   ... It will be difficult to come to it later.

   Norm: What's "it"?

   Mohamed: The question of the list of what is in the core and what is not.

   <alexmilowski> (currently, we don't have "p:transform"... we have

   Mohamed: We'll be able to defer the specifics to later.
   ... I fear that the fact we will have to define each element in detail
   will make us lazy.

   <MSM> [so we'll end up with a much smaller set of components, just to
   reduce our own work load]

   Alex: I think that the problem is the same. Either the names are available
   as step types or they're available as step names. Either way we have to
   define them all. And pipeline library developers can always add more. We
   need to enumerate our list of components in either case.

   Straw poll: Shall we have components that act as interfaces to multiple

   Results: 6:1 against.

   Norm: We will not have components that act as interfaces to multiple

   Mohamed: In the examples there is a p:validate, so what is it's meaning in
   the spec.

   Norm: Do you think that component does multiple kinds of validation?

   Mohamed: Yes, I think so. We at least infer multiple interfaces.

   <alexmilowski> (anyone can write a custom component that supports multiple
   schema languages at once)

  Step names

   Norm: Any further discussion before I attempt a straw poll?

   None heard

   Straw poll: Shall we identify steps with the form "<p:step type='p:xslt'>"
   or with the form "<p:xslt>"

   Mohamed: So we'll have both?

   Norm: No

   Murray: Oh, I thought we'd further allow p:xslt but we'd still have

   Norm: Why two ways?

   Murray: That's a deeper question. I thought we'd still want the p:step
   way, but I take it back.

   Alex: I think in the spec we'll define some sort of abstract p:step type
   in the spec.

   Richard: I hadn't previously considered the possibility of allowing both.

   Richard: We're assuming that we have a construct that allows you to call
   another pipeline. Given the goal of interoperability then it seems quite
   plausible that whatever allows you to call pipelines would allow you to
   call single components.

   Norm: Yes, probably.

   Richard: But if we were going for the element names as step types, you
   could just call it by name.

   Alex: Right now our spec says that you'd put it in a library and it
   becomes as a component type.
   ... Now it would be available as a name.

   Richard: So the new proposal means that you'd call a pipeline by using its
   ... that sounds plausible to me.

   Straw poll: Shall we identify steps exclusvely with the form "<p:step
   type='p:xslt'>" or with the form "<p:xslt>"

   Straw poll: Shall we identify steps exclusively with the form "<p:step
   type='p:xslt'>" or exclusively with the form "<p:xslt>"

   Results: 7:1 in favor of p:xslt

   5 yes, 1 no, 2 concur

  Pre-defined vs. arbitrary application parameters

   Norm: This is <p:parameter name="initial-mode"> vs. <p:initial-mode>
   ... The one hard problem I see is that we don't have a mechanism for
   making the value of <p:initial-mode> dynamic.

   Alex: I'm torn in a number of directions. Now that we have p:xslt, we can
   have attributes to set the initial mode, etc.
   ... That's very nice syntactically.
   ... The values that are not easy to put into attributes are easy to put in
   ... So I'm torn on the syntax.
   ... Then there's the question of what things need to be known statically.
   ... There's application parameters vs. stylesheet parameters.
   ... Perhaps we could separate the questions?
   ... It seems unfortunate not to take advantage of the attributes on

   Norm: Does anyone think that these configuration parameters have to be

   Alessandro: Yes, I think pretty strongly that they have to be dynamic.

   Murray: What's the issue with dynamic parameters?

   Norm: We'd need new syntax.

   Alessandro: Couldn't we just allow select and value on the p:initial-mode

   Norm: Yes that seems the simplest answer.

   Alex: Is it really an issue of p:initial-mode is both an application
   parameter and a configuration parameter?

   Norm: I could certainly live with that.

   Richard: I'm uncertain whether it's a problem or not.
   ... For XSLT it's not a problem, but maybe some other language is expects
   to be able to do things like enumerate parameters which means that extra
   ones could be a real problem.

   Alex: We don't have a use case for that.

   Richard: That's true, but we don't want there to be something that's more
   difficult for people to make arbitrary existing tools into components.

   Murray: I'm an XProc processor and there are some parameters being set
   inside of my pipeline; foo=1, bar=2, etc.
   ... Then I invoke a component. I see myself as a shell wrapped around that
   ... The component may want to be able to get at the values of foo and bar.
   ... Now the component is a shell wrapped around a component that it's
   ... Right so far?


   Murray: Up in the pipeline processor, I'd have thought that all we'd have
   to do is assign values to tokens and then be able to refer to them.
   ... Then components should be able to get at them.

   Richard: But there are also programs that take arbitrary parameters.
   ... Can someone give an example?

   Norm: How about 'make-manifest'

   Richard: That's one it wants, what about ones it doesn't want.

   Norm: Well, I could want make-manifest to be set or unset on two different
   stylesheets in the same pipeline.

   Scribe attempts to keep up, but fails

   Murray: So you should be able to say the name of the parameter and either
   its value or a reference to another value.

   Norm attempts to describe the problem...

   Richard: In the unix command 'ls', you give it a bunch of flags and some
   ... If the way that the mechanisms worked meant that the component got
   both the filenames and the flags so that the flags were printed out, that
   would be a problem.
   ... In the xslt case, since you always look for parameters by name, there
   are no problems.
   ... But if your component prints out all the parameters that it gets, then
   you'll have extra things you don't want.
   ... But if p:initial-mode is recognized by the processor, why not simply
   not pass it through?

   Alex: We also have import param that was meant to handle some of these
   ... I wonder if we want to use that kind of mechanism to solve this
   ... We're circling around this issue but we haven't considered
   ... For general things, you could have the inverse of import-parameter.

   <richard> <p:without-param ...> ?

   Mohamed: I think the problem is we have to identify parameters that are
   for or not for the component.
   ... I think we need to separate them or we need to exclude them by names
   or namespaces.
   ... I think we need this kind of distinction. But we have to lower the
   heavy difficulty of users.
   ... I propose that we have p:parameter with names and if there's nothing
   specified then it's passed through.
   ... If we have something like a target, like target on <a>, then we can
   use that.

   Norm: I think if we need something that complicated, I think I'd rather
   have <p:initial-mode>

   Alessandro: Now that we have p:xslt, we can have code-completion and
   syntax checking on those parameters that are predefined.
   ... It makes the code clearer and solves the distinction that we need to

   Alex: I'm still questioning whether or not we need to go here.
   ... We have a bag of parameters and you can set them, components do what
   they will. If you have a strange component that can't sort things out then
   you have a problem in V1. I'm ok with that.

   Norm: It's the point Alessandro made that makes me favor slightly the
   <p:initial-mode> approach

   Alex: Can't those things be solved in the component definitions?

   Norm: Yes, probably.

   Straw poll: Shall we allow pre-defined configuration parameters like
   <p:initial-mode> (which can have value and select attributes)?

   Result: 6 yes, 1 Abstain, 1 No, but it's 2 Yes and 4 concurs

   No real conclusions here. Try again next week.

  Any other business?



Summary of Action Items

   [End of minutes]


   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2007/02/22-agenda.html
   [3] http://www.w3.org/2007/02/22-xproc-irc
   [6] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   [7] http://dev.w3.org/cvsweb/2002/scribe/

    Minutes formatted by David Booth's scribe.perl[6] version 1.127 (CVS
    $Date: 2007/02/22 17:07:14 $

Received on Thursday, 22 February 2007 17:08:19 UTC

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