- 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
W3C[1]
- DRAFT -
XML Processing Model WG
Meeting 56, 22 Feb 2007
Agenda[2]
See also: IRC log[3]
Attendees
Present
Michael, Rui, Mohamed, Norm, Alessandro, Alex, Murray, Richard
Regrets
Paul, Henry
Chair
Norm
Scribe
Norm
Contents
* 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
Accepted.
Accept minutes from the previous meeting?
-> http://www.w3.org/XML/XProc/2007/02/15-minutes.html
Accepted.
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
"p:xslt")
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
applications?
Results: 6:1 against.
Norm: We will not have components that act as interfaces to multiple
applications.
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
p:step.
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
name.
... 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
sub-elements.
... 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
p:xslt.
Norm: Does anyone think that these configuration parameters have to be
dynamic?
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
element?
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
component.
... 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
running.
... Right so far?
Yes.
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
filenames.
... 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
cases.
... I wonder if we want to use that kind of mechanism to solve this
problem.
... We're circling around this issue but we haven't considered
import-parameter
... 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
make.
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?
None
Adjourned.
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
log[7])
$Date: 2007/02/22 17:07:14 $
Received on Thursday, 22 February 2007 17:08:19 UTC