See also: IRC log
-> http://www.w3.org/XML/XProc/2008/03/06-agenda
Accepted.
-> http://www.w3.org/XML/XProc/2008/02/14-minutes
Accepted.
Mohamed gives probably regrets, perhaps until our respective daylight savings times align
Andrew gives regrets for next week
-> http://www.w3.org/XML/XProc/2007/09/lastcall/comments.html
-> http://www.w3.org/XML/XProc/2007/09/lastcall/comments#C058
Norm attempts to summarize his message 66.
Richard: So options obscure inherited options immediately.
Norm: Yes.
Richard: How is this like XSLT?
Norm: The solution I conclude
with in message 66 is the same.
... Anyone think more time on the list will help?
Mohamed: No, I don't think so.
Richard: There are three
different situations in which you use p:option:
... 1. When calling an atomic step
... 2. When declaring an atomic step
... 3. In a compound step where it counts as both.
Norm: Yes.
Richard: In the calling of an atomic step, does it bind it in there as well? If you bind 'a' on atomic step, does that get used immediately.
Norm: No. That's the subtle distinction, options in atomic steps aren't declarations.
Richard: Right. So that's the expected behavior. I think that sounds like the best we can do.
Norm: Anyone else?
Alex: Could we just start over?
Some discussion of getting rid of the current parameter mechanism and using p:param and p:with-param here.
Richard: The case of options on a
subpipeline, that's more like variable than parameters.
... We're left with option on an atomic step decl is like
xsl:param, option on an atomic step is like xsl:with-param, and
option on a compound step is like xsl:variable
Norm: Yes, I think so.
... There's a sense in which I'd like to add p:variable, but
I'm reluctant.
The analogy in XSLT would be:
<xsl:param name="match" select="'MATCHSTUFF'"/>
<xsl:call-template name="...">
<xsl:with-param name="match" select="'//a[@foo]'"/>
<xsl:with-param name="attribute-value" select="$match"/>
</xsl:call-template>
<PGrosso> ac
Richard: Renaming the things is
something we can do or not do regardless of how we decide the
scoping quesiton.
... We should do this now and deal with renaming later.
... I agree with Michael in principle that it would be easier
if we renamed things.
Michael: Why do we not have a single name proposed for all instances of calling things?
Norm: We have the design we arrived at by consensus :-)
Richard/Michael discuss how this is related to ALGOL and Lisp
Proposed: we finesse the problem and say that the options that are in scope are all of those *declared* by preceding-siblings or *declared* by ancestors.
Michael: I like that, and I'd like to call 1 and 3 option and 2 with-option.
Richard: I think what I'd like is to rename options to parameters, so we have param, with-param and variable and the things we currently call parameters we call something else.
Norm: Absent a proposal that replaces our current parameter mechanism, I don't think that's practical.
Michael: Our existing parameters are things we hand off to black boxes. Right?
Norm: yes.
Michael: They are the name/value
pairs I give to XSLT ot initialize xsl:params at the top-most
level of the stylesheet.
... I don't know how this relates to one stylesheet calling
another.
... I'd be happy to use with-param for all of them
Norm: We have options and parameters and we need to keep those two bags separate
Some discussion of options and paramters and namespaces and lions and tigers and bears
<MSM> my firefox has decided to launch a background process; i've got to kill it
Richard: Is it productive to continue talking about this here? If someone can come up with a better ansewr, I'd be delighted, but I doubt it's going to happen in the next 20 minutes.
Proposed: we finesse the problem and say that the options that are in scope are all of those *declared* by preceding-siblings or *declared* by ancestors.
Accepted.
<MSM> so they are unprefixed in practice, but qualified in theory -- analogy to the QT function namespace
-> http://www.w3.org/XML/XProc/2007/09/lastcall/comments#C083
Norm: We really need to work this
one out. I'm not sure we can do it in 20 minutes,
though...
... Perhaps someone would take an action to come back with a
proposal.
Richard proposes Henry.
<scribe> ACTION: Norm to try to get Henry to tell us the right answer. [recorded in http://www.w3.org/2008/03/06-xproc-minutes.html#action01]
<scribe> ACTION: Alex to fix p:directory-list [recorded in http://www.w3.org/2008/03/06-xproc-minutes.html#action02]
http://www.w3.org/XML/XProc/2007/09/lastcall/comments#C124
Norm: I'm not inclined to go there, it requires solving the mixing several streams of XML into a single document problem.
Proposed: Reject.
Accepted.
Norm: The commenter wonders why we call things that aren't hypertext references "href". The answer is precedent. So why not on xsl-formatter?
Richard: I don't think href is used for places that you're going to write *to*
Norm: Anyone feel strongly that we should resolve this inconsistency?
<MSM> Norm (and MSM, silently): yes, it is, at least for XSLT 2.0 result documents.
Alex: Is this really inconsistent?
Mohamed: I think we should use href everywhere.
Alex: I agree.
Proposed: Rename uri on p:xsl-formatter to href
Accepted.
Norm isn't sure he understands the question
Richard: We did talk about this before, if you wanted to name it for some purpose other than calling it, you might want to give it a name.
Mohamed: You could use the p:declare-step form if you wanted to name it, right?
Norm: yes
... I'm not sure if that means we should allow a name on
p:pipeline or not.
<scribe> ACTION: Norm to point out p:declare-step to the commenter and see if they're satisfied. [recorded in http://www.w3.org/2008/03/06-xproc-minutes.html#action03]
Norm: Alex, this is on your radar?
Alex: I already have an action to
fix this.
... There's nothing to do there accept remove the content-type
restriction.
Norm: Ok, reply to the message when you check in the changes.
None. Adjourned.
<scribe> ACTION: Norm to investigate parameters to sha1 for p:hash [recorded in http://www.w3.org/2008/03/06-xproc-minutes.html#action04]