See also: IRC log
Reorder items 2 and 3
Mohamed: I'd like to talk about p:pack.
Norm: Ok, we'll make that item 5
Probably regrets from Mohamed
Norm: I think it's pretty good except for the namespace bindings.
Richard: The diffs are pretty amusing.
Mohamed: What happend to err:?
Norm: I took it out for
err:errors and err:error because we can use c: for that.
... Then I remembered error QNames, so I put it back.
... Everyone ok with that?
Norm: Are we going to define one
and do we want one?
... Having a MIME type lets us identify pipeline documents; having a fragid syntax would let us describe how to point to important parts of a pipeline.
Norm describes his attempt at a fragid syntax.
Richard: We need to get this right before Last Call, right?
Norm: Yeah, I guess so.
Alex: Do we need to have a fragid syntax?
Murray: What would we identify
Norm: We would identify steps,
ports, and options.
... We don't have a need, it's a question of whether we want to provide hooks for others.
Murray: I'm some author outside a
group of pipelines; so I might write an RDF statement that
talks about these things; I might create a hypertext link to
... Can I invoke a step this way?
... You could also use it for error messages.
Richard: Seems strange to do this when we don't use them.
Norm: I get the impression that we're leaning towards a MIME type but not the fragment identifier.
<richard> the xpath xpointer scheme doesnt exist
Murray: I can see the value in being able to refer to steps from the outside. I'm not sure I get the value in having fragids for the ports.
Norm: So I propose that we define a MIME type, application/xml+xproc, but not a fragment identifier syntax.
Murray: How hard is it to point to steps?
Norm: Easy, if they have names and the names are unique.
Richard points out that pipelines in a library could easily have steps with the same names
Alex: There's not a lot of precedent here, lots of recent specs don't have MIME types.
Richard: I haven't heard any compelling arguments for a fragid syntax.
Norm: So it seems like the consensus is MIME type yes, fragids no.
<MoZ> <p:documentation xml:id="foo" />
Murray: If we think pipelines are going to be popular, which I think we do, it seems like there will be lots of people who want to talk about them.
Alex: One rational position is to
not require to sprinkle xml:id over their documents. If you
want to point to something, you have to name it.
... Then we can do something like what Norm proposed and provide a mechanism for pointing to them.
Richard: Though I see that you might want to talk about these things, without tools, it's not terribly useful to point to them.
Murray: That's a chicken and egg thing, isn't it?
Norm: I'd like to set this aside for a moment and go on to the next item.
Norm outlines his message
Murray: I like the idea.
Mohamed: I'm not sure I like the defaulting of inputs to the p:pipeline.
Norm: Yeah, but that's not really the issue here.
Alex muses about the syntax Norm proposed.
Richard: The presence of named ports wouldn't changed the names, would it?
Norm: We could actually use "source" and "result" for manufactured port names.
Murray: Would we have to use the section symbol in the URI?
Norm: Yes, that's the price you pay for not having put your own name on the step.
Norm: Is anyone in principle against this proposal?
Mohamed: It's giving more possibilities for users to not use names.
<alexmilowski> mark = "-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")"
Alex: It'd be nice if we picked a character name that doesn't require URI encoding.
Norm: Ok, how about "!"
Mohamed: I'm ok with naming steps.
Norm: One of the goals is to remove a concept from the spec, I don't anything to be anonymous.
Richard: You think you're going to use these in some hypothetical fragment syntax?
Alex: I like the idea that you can't use the manufactured name in the syntax.
Richard: We're going to specify that the things have these names. Are implementations going to have to use them?
Norm: In a running pipeline, you'll never see them.
Richard: So this has no normative effect.
Norm: True, but the spec will still be simpler because it has one less concept.
Norm: I propose that we direct the editor to give this a try and see if we like it.
Norm: Drat. We won't get through namespaces in 10 minutes, let's return to MIME type/fragid.
Alex: I'm all for using the manufactured names in a fragid syntax.
Norm: Anyone opposed to having a
fragid syntax for steps.
... I propose we direct the editor to give that a whack too.
Mohamed: Take care that we don't overlap with the use of xml:id.
Norm describes the problem
Alex: Have you looked at what XSLT does with xsl:element
Norm: Yes, but that doesn't work for us.
Richard: Suppose you just construct arbitrary strings in options, you expect those to go through.
Norm: Then you need the union of all the bindings on all the variables used
Alex: What about the opposite
case, where you don't want the bindings from the
... XSLT avoided all this magic
Norm: So the proposal is, the namespace bindings you get on the match option passed to the delete step are the ones that are in scope for that p:option. If they don't match up, you lose.
Richard: XSLT gives you a workaround for these cases.
Some discussion of the options
Alex: We could give another attribute on p:delete that could point to an element on which to find the namespace bindings for this expression.
Richard: There'd be security considerations here, yes?
Alex: I still think "you lose" is the simplest answer.
Norm: Would anyone be uncomfortable wit the "you lose" proposal?