- From: Norman Walsh <Norman.Walsh@Sun.COM>
- Date: Thu, 01 Mar 2007 13:41:05 -0500
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <87d53sbyda.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2007/03/01-minutes.html
W3C[1]
- DRAFT -
XML Processing Model WG
Meeting 57, 1 Mar 2007
Agenda[2]
See also: IRC log[3]
Attendees
Present
Norm, Alex, Paul, Alessandro, Michael, Rui, Murray, Mohamed,
Andrew, Henry
Regrets
Richard
Chair
Norm
Scribe
Norm
Contents
* Topics
1. Accept this agenda?
2. Accept minutes from the previous meeting?
3. Next meeting: telcon 8 Mar 2007
4. New draft
5. Parameters
6. Any other business
* Summary of Action Items
----------------------------------------------------------------------
Accept this agenda?
-> http://www.w3.org/XML/XProc/2007/03/01-agenda.html
Accepted.
Accept minutes from the previous meeting?
-> http://www.w3.org/XML/XProc/2007/02/22-minutes.html
Accepted.
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/[6].
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.
Parameters
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[7]]
Any other business
None.
Adjourned.
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[8]]
**
[End of minutes]
----------------------------------------------------------------------
[1] http://www.w3.org/
[2] http://www.w3.org/XML/XProc/2007/03/01-agenda.html
[3] http://www.w3.org/2007/03/01-xproc-irc
[6] http://www.w3.org/XML/XProc/docs/ED-xproc-20070228/
[7] http://www.w3.org/2007/03/01-xproc-minutes.html#action01
[8] http://www.w3.org/2007/03/01-xproc-minutes.html#action01
[9] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[10] http://dev.w3.org/cvsweb/2002/scribe/
Minutes formatted by David Booth's scribe.perl[9] version 1.128 (CVS
log[10])
$Date: 2007/03/01 17:16:23 $
Received on Thursday, 1 March 2007 18:41:42 UTC