See also: IRC log
Norm proposes that we don't need to meet in January since we will have met in August.
We'll revisit if it actually happens, it's still just in the planning stages today.
1. A-13-01: MSM to draft a complete table; ETA: 15 June 2006
Norm opens the floor for discussion.
Alex: Can you provide a synopis?
Norm mumbles a bit
We seem to be reaching consensus on the non-directed syntax as our first WD syntax
Henry: You mean the generic syntax, right? Names like p:process and p:input and p:output.
Variables/parameters/inputs/outputs share a single symbol space
Parameters are strings
References in one direction, which Norm describes badly
Richard: I'd been thinking that outputs defined labels and input referred to them
Some discussion, poorly recorded by the hapless scribe
The outstanding issue is XPath references to input documents
Can an XPath expression refer to multiple in-scope input documents? Or only to a single document.
Alessandro: We also seem to have consensus on p:input/p:with-input, etc.
Richard: If all the inputs are
available as documents that you can refer to by name in XPath
expressions, this results in a hidden dependency within
... In order to determine which components have to have been evaulated, you have to peek into the XPath to see what inputs it relies on.
... That seems to be a minor implementation annoyance but a good way of hiding dependencies.
... which is a bad thing.
... It means that two things in apparently unrelated branches of the pipeline may have to wait for each other because of the XPath expression one uses.
... It really is just a syntax issue on one level in that you could draw all the lines in explicitly. It's just that it's burried deep down in the syntax.
<MoZ> could we uses a "uses=" attributes
Alex: Are we assuming that the
variables and parameters share the same symbol space.
... If they share the same symbol space, then there are conversion issues. What happens if you attempt to select a node from a string?
Richard: I think the issue of
strings is a red herring. Though I agree that we should
restrict them to strings now, that doesn't mean we can't make
them more complex in the future.
... If the functionality that's needed is the ability to refer to multiple documents, it could be done more explicitly. There could be a syntax that bound variables to the names of outputs of other steps. That at least would make it expicit which ones were being used.
Mohamed: The idea (uses= from before) is to make it explicit. If they are defined on other points in the document, then maybe they are not visually explicit even if they're technically explicit.
Alex: In XSLT, variables and parameters can be bound to a variety of things and that's useful. The typing issues come into play. I might want to bind inputs to parameters, for example.
Norm: That comes back to the point earlier about parameters being strings.
Richard: I agree that it would be nice to go beyond strings for parameters, but we can stick with strings for now.
Alex: Do we need this distinction of variables and parameters?
Richard: I don't think we've agreed that there are any variables yet.
Alex describes his p:let proposal
Richard: Is this different in any way from a sub-pipeline?
Alex: No, not really. The
distinction between variables and parameters seems just not
useful to me.
... You need to be able to manipulate parameters just like you can manipulate inputs and outputs in the pipeline
... Let provides a scope
... Let is also hierarchical, it has inputs and outputs.
Richard: It seems to me that the advantage isn't the scoping as such, put a place to do some calculation on some existing parameters to get a new one.
Alex: If you're calculating a parameter with an input, you need to know what its dependent on.
<MoZ> for me let is a class definition
Alex: I'm quite happy if it can be done as a sub-pipeline, but I don't want to have to call out to some other file.
Norm: I don't think we've discussed that at all.
Alex: This could easily be some variation of a sub-pipeline call.
Richard: In lisp, let is
implemented as a macro. It expands into a lambda that's passed
... We've been saying that a let in our pipeline might be equivalent to a sub-pipeline and provides a place to bind some new input parameters.
... It would be nice if this were really true and if you could say that let was equivalent to this pipeline construct.
<MoZ> +1 for using few keywords in Xproc (for p:let to become a p:subpipeline or rich-subpipeline)
Richard: I hadn't imagined that sub-pipelines would be transparent, so let would bind to a sub-pipeline with the right declarations for inputs and outputs.
Norm: I see.
... Let's try to come back around to XPaths over input documents.
... I have reservations about the refer-to-inputs-as-variables style and Richard has given some good technical reasons why it makes analysis harder. Does anyone want to argue in favor of it?
No one speaks.
<MoZ> using namespaces "io:foo" and "p:foo"
<MoZ> will this be a solution ?
Alex: What if we had parameter bindings as children of the p:input?
<scribe> ACTION A-22-01: Norm to record the open issue about what an XPath expression over a document sequence means [recorded in http://www.w3.org/2006/05/25-xproc-minutes.html#action01]
Proposal: XPath expressions will be evaluated over exactly one input, syntactic details unresolved.
Alessandro: I think it's hard to
record a consensus on that because Jeni isn't here.
... Personally, this is what we've implemented, so I kind of like XPath expressions evaluated over a single document.
Norm: I'll postpone the question for a week.
Norm expresses a desire to have a completed first WD before the f2f.