XML Processing Model WG

Meeting 78, 9 Aug 2007


See also: IRC log


Alessandro, Mohamed, Andrew, Norm, Alex, Richard
Paul, Henry, Michael


Accept this agenda?

-> http://www.w3.org/XML/XProc/2007/08/09-agenda

Reorder items 2 and 3

Mohamed: I'd like to talk about p:pack.

Norm: Ok, we'll make that item 5

Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2007/08/02-minutes


Next meeting: telcon 16 August 2007

Probably regrets from Mohamed

Comments on the new draft

-> http://www.w3.org/XML/XProc/docs/langspec.html

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?

Seems so.

Question of MIME type/fragid

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Aug/0076.html

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 one.
... Can I invoke a step this way?

Norm: No
... 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.

Question about anonymous steps or defaulted names.

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Aug/0077.html

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.

<alexmilowski> xyzzy-nn

Murray: Would we have to use the section symbol in the URI?

<MoZ> <p:pipeline>

<MoZ> <p:for-each>

<MoZ> <p:xinclude/>

<MoZ> </p:for-each>

Norm: Yes, that's the price you pay for not having put your own name on the step.

<MoZ> <p:for-each>

<MoZ> <p:xinclude/>

<MoZ> </p:for-each>

<MoZ> </p:pipeline>

Norm: Is anyone in principle against this proposal?

Mohamed: Yes.

Norm: Why?

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.

<alexmilowski> +1

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 document?
... 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?

None heard

Any other business?



Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.128 (CVS log)
$Date: 2007/08/16 18:02:09 $