XML Processing Model WG

Meeting 57, 1 Mar 2007


See also: IRC log


Norm, Alex, Paul, Alessandro, Michael, Rui, Murray, Mohamed, Andrew, Henry


Accept this agenda?

-> http://www.w3.org/XML/XProc/2007/03/01-agenda.html


Accept minutes from the previous meeting?

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


Next meeting: telcon 8 Mar 2007

Mohamed gives regrets

New draft

Norm: I published a new draft yesterday: http://www.w3.org/XML/XProc/docs/ED-xproc-20070228/.

Norm summarizes.

Norm: There's no reasonable diff.

Norm outlines the current dichotomy between QName and NCName and p:pipeline and everwhere else.

Henry: We never need to refer to p:pipelines yes?

Norm: No, the p:pipe elements have to point to them.

Henry: That's inside a pipeline, so we'd like that to be an NCName.

Norm: We also need to be able to refer to pipelines.

Henry: My vague memory was that we won't have a run-pipeline component in V1.

Norm: My understanding was that we wouldn't provide a mechanism for running a dynamically constructed pipeline but that we would provide a mechanism for running static pipelines from libraries

Alex: I don't see why we made the names NCNames. It should be just like the names of templates in XSLT.

Henry: The major confusion factor that I've observed in that context is that you have to worry about names getting captured by the default namespace declarations.

Alex: It should be up to the user. If you don't want to use QNames, you don't have to.

Norm: Agenda item for next week: how to call static pipelines in an imported library.

Henry: If you've defined a named pipe, then you should be able to invoke it by writing its name as a start tag in a subpipeline.


Norm: The problem as I see it is what, if anything, we do about the case of parameter for step invokation vs parameters for the invoked component.

Henry: Saxon 8, for example, distinguishes between options and parameters.

Norm: Jeni brings in lists of strings which I'd like to overlook for the moment.

Alex: What we have now is good enough.
... Our current parameter story is simple and I don't think we need anything else. We can say which things are significant to the configuration of the step.

Norm: Works for me.
... Does anyone think there's anything wrong with Alex's approach?

Henry: I haven't read the thread, but it sounds right.

Alessandro: I think I agree. But I still think that Jeni's answer has some merit. In particular, I like the third proposal.

Norm: What problem is she solving?

Alessandro: Well, it addresses the case of different classes of parameters. XSLT has two classes, but other components might have more classes.

<alexmilowski> it is the open content model for documentation problem...

<alexmilowski> That's the problem.

Norm: I'm worried about determining the difference between subpipelines and parameters.

Henry: We've said that user-defined steps are atomic.

<alexmilowski> e.g. the component's element can have ignorable children ...

<MoZ> alexmilowski, p:documentation

Alex: The problem is our steps have an open content model in order to allow documentation.
... For these crazy components that have all these problems with weird lists and values, this is XML, you can pass those as an *input*

Henry: That's a helpful observation. It almost leads me back to the minimalist position to which I'd originally been inclined.
... First I was going to say that my understanding of Jeni's use case is that it relies on sub-symbol spaces. But as Alex observed earlier, namespaces are the XML solution to this problem.

<alexmilowski> Oh... no... we need QNames on parameters for simple setting of things like XSLT parameters...

Henry: I didn't notice that parameters were named with QNames. I think we should rely on here documents.

Murray: There are options that I type on the command line, like -o, and then there's information that we pass into the application. It's going to use that information to do its job. A stylesheet is one example
... Although we've talked about competing name tokens, it seems to me that they're competing in different environments.
... It seems as though the conflict is happening in two different environments.

<ht> Whew! saxon uses {uri}localname=value to bind parameters in namespaces to values on the command line

<ht> MoZ just said he likes p:option and p:parameter, and I think that's worth thinking about

Norm: We don't have a mechanism for dynamically generating a document.

<ht> <p:parameter name="xsl:initial-mode" select="$p:initialMode"/>

Henry: I think the options of the builtin component should be in the pipeline namespace or in the appropriate namespace for the component.

<ht> Yeah, I guess I agree -- we're calling it p:xslt, not xsl:doit. . .

Norm: I think it would be fair to just not pass the parameters in the p: namespace through

Henry: I'm not sure about thta.

Norm: Well, it's not clear that there's a right answer.

Alessandro: We could use prefixes just like I outlined in email.

Henry: I think namespaces are the prefixing mechanism to use in XML.
... I come back to the other proposal that we have p:option and p:parameter.

Norm: Can mortals be expect to tell the difference?

Henry: But few components have options so it doesn't seem to be a problem.

Murray: We just have to explain it in the spec.

<alexmilowski> xquery does too...

Henry: Only XSLT, of all the components we've discussed so far, makes this distinction.

Mohamed: Jeni's remark was about configuration parameter vs. parameter that was difficult to distinguish, but maybe option and parameter will be more obvious.
... I think it would be interesting to go further.

Norm: It seems like we're coming to consensus that we should use p:option and p:parameter.

<scribe> ACTION: Norm will type up a proposal for p:option and p:parameter. [recorded in http://www.w3.org/2007/03/01-xproc-minutes.html#action01]

Any other business



Summary of Action Items

[NEW] ACTION: Norm will type up a proposal for p:option and p:parameter. [recorded in http://www.w3.org/2007/03/01-xproc-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.128 (CVS log)
$Date: 2007/03/08 17:24:09 $