XML Processing Model WG

Meeting 22, 25 May 2006


See also: IRC log


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


Accept this agenda?

-> http://www.w3.org/XML/XProc/2006/05/25-agenda.html


Accept minutes from the previous teleconference?

-> http://www.w3.org/XML/XProc/2006/05/18-minutes.html


Next meeting: 1 June telcon

Any regrets?

None given.

Face-to-face: 2-4 Aug 2006.

-> http://www.w3.org/2002/09/wbs/38398/XProcFTF2/

-> http://www.w3.org/XML/XProc/2006/08/02-04-f2f.html

Mini "Technical Plenary" in January?

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.

Review of open action items

1. A-13-01: MSM to draft a complete table; ETA: 15 June 2006

<scribe> Continued.

XProc syntax

Email threads:

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006May/0087.html

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006May/0072.html

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006May/0041.html

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006May/0039.html

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 XPaths.
... 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 some parameters.
... 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.

Any other business?



Summary of Action Items

[NEW] ACTION: 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]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2006/06/01 18:44:22 $