W3C

XML Processing Model WG

Meeting 103, 06 Mar 2008

Agenda

See also: IRC log

Attendees

Present
Norm, Rui, Mohamed, Alex, Paul, Richard, Murray, Andrew, Michael[xx:20-]
Regrets
Chair
Norm
Scribe
Norm

Contents


Accept this agenda?

-> http://www.w3.org/XML/XProc/2008/03/06-agenda

Accepted.

Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2008/02/14-minutes

Accepted.

Next meeting: telcon 13 March 2008?

Mohamed gives probably regrets, perhaps until our respective daylight savings times align

Andrew gives regrets for next week

Last call comments

-> http://www.w3.org/XML/XProc/2007/09/lastcall/comments.html

58. Scope of options

-> http://www.w3.org/XML/XProc/2007/09/lastcall/comments#C058

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2008Feb/0066.html

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

#83 Handling of system IDs

-> http://www.w3.org/XML/XProc/2007/09/lastcall/comments#C083

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2008Feb/0022.html

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]

#119 (editorial) p:directory-list

<scribe> ACTION: Alex to fix p:directory-list [recorded in http://www.w3.org/2008/03/06-xproc-minutes.html#action02]

#124 p:log feels clunky

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.

#125 The 'href' attribute

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.

Comment #126 p:pipeline name attribute

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]

#109 Response headers in p:http-request

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.

Any other business?

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]

Summary of Action Items

[NEW] ACTION: Alex to fix p:directory-list [recorded in http://www.w3.org/2008/03/06-xproc-minutes.html#action02]
[NEW] ACTION: Norm to investigate parameters to sha1 for p:hash [recorded in http://www.w3.org/2008/03/06-xproc-minutes.html#action04]
[NEW] 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]
[NEW] 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]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2008/03/20 16:01:44 $