See also: IRC log
Date: 22 Oct 2009
<scribe> Meeting: 157
<scribe> Scribe: Norm
<scribe> ScribeNick: Norm
Norm: Can we talk about the meaning of an unavailable binding on p:with-option and p:with-param?
Paul gives regrets.
Norm: Telcon of 5 November is cancelled.
Norm: Three clearly open
questions: where is @version allowed, does use-when count
inside a p:inline, do we do any static analysis on p:when/p:try
blocks when they contain invalid steps.
... Any other questions or comments?
Vojtech: What about the importing of the standard step library.
Norm: I think we should not allow importing of declarations for the builtin steps.
Henry: I think that's
... On a larger scale, I'm uncomfortable with the upward percolating invalid story.
... I worry that it isn't complete or correct. I would like to identify that aspect of this proposal as a feature at risk.
... so that we can jettison it without going back to last call again again if we remove it.
Norm: I'm perfectly happy to do that, but I can't think of any static meaning for a subpipeline with an invalid step that will absolutely be executed.
Henry: Right. I think use-when is the only thing that will work and I want to be able to jettison all the invalid stuff without going back to last call.
Vojtech: I agree with Henry, I think the results are going to be unpredictable.
Norm: Ok. I'm happy with that. Or we could just pull it all out now.
Vojtech: There's still this story
about the unknown ports. You have steps that you recognize but
they have unknown ports.
... We could say you have to use use-when there, or we could keep the new story about defaults.
Henry: The motivation for doing our best here came from Jeni.
Norm: Jeni is happy with the proposal: http://twitter.com/JeniT/status/4898625357
Norm mumbles about some folks wanting to be able to use pipelines without changing them.
Norm uses the "messages" output port on p:xslt as an example.
Henry: That use case is
interesting because it doesn't need a p:choose. You don't get
the messages, but maybe you're willing to live with that.
... I can just about see that. But I think as far as the steps I've never heard of story, that's never going to work.
... There's never going to be a graceful fallback.
... If we're not going to do the whole thing, I think the new ports case is worth keeping, but lose all the "upward percolation" of invalid p:* steps.
Vojtech: If the processor sees an
unknown step from the p: namespace, I think you just can't know
what it means. I would force the pipeline author to use
use-when in that case.
... But if the pipeline contains only known steps with new ports, then I think the simple defaulting story can be made to work there.
... It's not hard to implement and it's predictable.
Norm: Does anyone want to argue for the more complicated story on this call right now.
Henry: I think the fact that you can't tell if the first child of a p:declare-step is a new step or some sort of new name for p:variable makes it very hard to decide what to do.
Vojtech: There may be unknown elements that effect the dependency graph.
Norm: Ok. I'm willing to concede
that use-when and the more complicated invalidation store are
two ways to do the same thing.
... so maybe we should just do the simpler thing. You *have* to change the pipeline in some way, so you might as well change it in the way that's completely predictable.
... So the proposal on the table now is the one I made, modified to remove the "upwards percolating" invalid story for unknown step types.
Vojtech: For unknown XProc elements.
Norm: Is anyone unhappy with that change?
Mohamed: I think I still have to
go through. My former proposal was to try to get rid of
use-when. My understanding is that use-when is pretty hard for
users to understand.
... So I think I just cannot agree without knowing what we're going to say about use-when.
Henry: In almost any case, the outcome of this discussion is going to be a new draft.
Mohamed: My idea is that the
use-when should not be used everywhere. It should have another
name. And it should only be used on when or try/catch.
... A use-when is way more poweful than the problem we have to solve.
Norm: We could do that, but I'm not sure it's necessary.
Mohamed: I think we should just say that if the attribute "must-understand" is provided on p:when, then this branch shouldn't be analyzed in V.x. It's use-when but it's less powerful and solves just the use case we have.
Vojtech: One problem with this story is, suppose in V2 we introduce a new element for an option or something and that one you can't put in a p:choose. You can do that only with steps.
Henry: If we go back to the
original observation that we're trying to handle the
unexpected, a simple, general mechanism is probably the best
... The other thing is, there's a lot to be said for leveraging experts understanding of difficult material and use-when is already there.
Norm: I think that's a good point.
Vojtech: What I like about the
use-when proposal is that it's something that will be valid in
... We could ask on xproc-dev
Mohamed: I want to have an explicit mechanism, but I think use-when is a real nightmare for tools that help users build their pipeline.
Henry: I don't have much
experience with use-when in XSLT, but the semantics seem quite
clear to me.
... It's the opposite of XInclude, "this tree isn't here."
... I can see where some some complexity might arise in XSLT with templates and literal constructors, but we don't have that problem.
Mohamed: My problem is that we can make pipelines that will have completely different connections depending on the version of XProc that you're using: consider putting use-when on a p:pipe inside a p:source.
Norm: I think Mohamed's point is that you can nest two effectively completely different pipelines in the same file.
Vojtech: It's true that use-when is a tool for forwards-compatibility, but it's also a much more general tool: you can use it to make pipelines that are compatible across different implementatins. I don't know if that's good or bad.
Norm: I appreciate that Mohamed
has reservations, but I don't hear consensus moving away from
use-when on this call.
... I'd like to say that the consensus of the wG seems to be that they want to see a draft with use-when, so let's try to move forward that way.
... So let's close the open questions. Where is a version attribute allowed?
... Proposal: On p:pipeline, p:library, and p:declare-step. No where else. And required on the document element of a pipeline document.
... I can live with that.
Norm: Second question: what are
the semantics of use-when inside a p:inline?
... Proposal: it's treated just like any other attribute and has no special semantics.
Vojtech: So take the http-request step, suppose we add something to the c:request element.
Norm: You wouldn't be able to do that all in p:inline, you'd have to build it up in some explicit way.
Norm: We're throwing out the whole backwards-chaining invalidation story, so the last question no longer applies.
Vojtech: We already decided that importing the standard library is not allowed.
... Anyone object to that?
<scribe> ACTION: Editor to write this up as a new draft. [recorded in http://www.w3.org/2009/10/22-xproc-minutes.html#action01]
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/31 Oct/29 Oct/ Succeeded: s/thnk/think/ Succeeded: s/becauase/because/ Found Scribe: Norm Inferring ScribeNick: Norm Found ScribeNick: Norm Default Present: Norm, MoZ, Ht, PGrosso, Vojtech Present: Norm Mohamed Henry Paul Vojtech Agenda: http://www.w3.org/XML/XProc/2009/10/15-agenda Found Date: 22 Oct 2009 Guessing minutes URL: http://www.w3.org/2009/10/22-xproc-minutes.html People with action items: editor[End of scribe.perl diagnostic output]