See also: IRC log
-> http://www.w3.org/XML/XProc/2007/03/01-agenda.html
Accepted.
-> http://www.w3.org/XML/XProc/2007/02/22-minutes.html
Accepted.
Mohamed gives regrets
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]
None.
Adjourned.