- From: Norman Walsh <ndw@nwalsh.com>
- Date: Thu, 03 May 2007 12:26:33 -0400
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <874pmtvpom.fsf@nwalsh.com>
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