See also: IRC log
-> http://www.w3.org/XML/XProc/2007/10/11-agenda
Accepted.
-> http://www.w3.org/XML/XProc/2007/10/04-minutes
Accepted.
Richard gives regrets.
A-86-01: Continued
A-86-02: Completed.
A-86-03: Continued
A-86-04: Continued
A-86-05: Completed.
A-86-06: Completed.
-> http://www.w3.org/XML/XProc/2007/09/lastcall/comments#029
<scribe> Continued to the next meeting.
-> http://www.w3.org/XML/XProc/2007/09/lastcall/comments#001
-> http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2007Oct/0018.html
Also: the wrap-*-lines options
Norm: Any discussion?
Richard: What about the syntax of cwd?
Norm: Like command, it ought to accept either form of slash
Proposal: Adopt this as a new optional step?
Accepted.
Richard: Given that it's optional; some platform might only implement it partially, is that allowed?
Norm: What sort of optional?
Richard: As a fictitious example, imagine an example where cwd doesn't make any sense.
Alex: If that's the case, we should make it a dynamic error.
Richard: Yes, but that's probably already the case.
Alex: I think this is a broader quesiton about partial implementation of optional steps.
Norm: I think the broader question of partially implemented optional steps is different.
Richard: An impl could provide a "conformant" flag that didn't offer the partially implemented steps.
-> http://www.w3.org/XML/XProc/2007/09/lastcall/comments#006
-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Oct/0058.html
That's Norm's example of why he wants this; at least two folks were supportive.
Richard: I had plans to have the primary input to a pipeline come from stdin; if I have to provide a default if its not there, I don't see how to do that.
Murray: If the input binding comes from an input decl and you override it on the command line, what do you do inside the pipeline to designate that?
Norm: I use the port name on the command line.
Henry: I think that's the way we intended to do the bindings from the outside.
Murray: The other way to think of it is to say that the pipeline binds to something passed on the command line.
Some confusion about the distintion between a default binding for a named port and a defaulted port.
Murray: I'm confused by the use of the word default. You want a binding for a port name to a source on the command line.
Richard: The impl. has to provide
that.
... This defaulting is a way for a pipeline author to say what
happens if the user *doesn't* provide the binding.
Norm: Coming back to Richard's question, if your implement always binds stdin to the p:pipeline's primary input port.
Richard: Ok. So in my case, the pipeline author's default would never come into play.
Henry: My impl works the same way
wrt the stdin binding to the primary input.
... This just means implementations have to have syntax
(command line, or whatever) to specify all three possibilities:
bind to a document, bind to stdin, or use the
pipeline-specified default.
... AFAICS, the only occasion I can see for using this is to
have a pipeline with a fixed input. And we already have a
mechanism for supporting that.
Norm: The other need is pipeline configurations.
Henry: Yes, I can imagine feeling different about this for secondary inputs than primary ones.
Murray: I'm increasingly
confused. It seems like you're trying to put a lot of process
control on the command line.
... Putting stuff outside the pipeline when it could be inside
seems to defeat the purpose of a pipeline language.
... You can do all this in your pipeline.
Richard: How do you implement the conditionality?
Murray: I thought I could examine if I've got content on an input port.
Some discussion of how XProc and XSLT differ...
Further discussion about how bindings should be done on the command line or whether the spec should say.
Alex: Would it help to
distinguish between the top-level invocation of a pipeline and
calling the pipeline as a step?
... So the default bindings could be considered separate from
the declaration.
Norm: Perhaps...
<richard> this seems to be even further opposed to what murray wants
Alex: This is metadata about the pipeline defaults.
<Zakim> ht, you wanted to say "OK"
Henry: With the clarification
that this story only applies to top-level pipelines, not to
pipelines being run as steps, (with some complication about
what it means if this is used in a library)
... I think we've thrashed this to death; I think it may be
more trouble than it's worth, but let's see. So I'm cautiously
in favor.
Alex: I'm confused: in favor of what?
Henry: In favor of clarifying
that this is allowed and what the spec intended.
... And it only means that when being invoked as a primary
pipeline and ignored when invoked as a step.
Norm: Is the next logical step for me to attempt to clarify this in the spec and see if we like the results?
Alessandro: I think this would lose a lot of its utility if you could only do this at the top level.
Henry: The interaction between that and the unbound primary input would be very unclear.
Norm attempts to suggest that it can never occur, but Richard points out that the default binding is only for primary input ports.
Richard: I'd be happier with it
if defaults were only allowed on non-primary input ports. That
would resolve the issue for steps that were never called. It
would resolve the unnaturalness wrt stdin/stdout.
... The point of an input port being primary is that it's the
one that gets connected up by default.
Murray: I'd like to observe that XProc doesn't need to do everything. What you're trying to do with processing foo.xml intead of langspec.xml could be done with a shell script.
<scribe> ACTION: Norm to take a stab at reconsidering the feature applying it only to ports that are not primary. [recorded in http://www.w3.org/2007/10/11-xproc-minutes.html#action01]
-> http://www.w3.org/XML/XProc/2007/09/lastcall/comments#018
Norm: I'm tempted to adopt Richard's text and see how it goes.
<ht> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Oct/0049.html
Richard: Pipelines are scopes
unto themselves, they never export things outside them.
... Pipeline libraries do export their internals.
Murray: I think it'll be useful to have a trivial example that shows the scoping.
Richard: One of my messages did have some examples.
<richard> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Oct/0017.html
Some question of circularity of imports.
<scribe> ACTION: Alex to propose some text about imports and circularity [recorded in http://www.w3.org/2007/10/11-xproc-minutes.html#action02]
Richard: This isn't literally circularity, it's a place where the tree joins up again.
<scribe> ACTION: Norm to attempt to incorporate Richard's draft text. [recorded in http://www.w3.org/2007/10/11-xproc-minutes.html#action03]
None.
Adjourned