Accept this agenda?

-> http://www.w3.org/XML/XProc/2016/03/16-agenda

Accepted.

Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2016/03/02-minutes

Accepted.

Next meeting, 23 Mar 2016

Henry gives regrets.

Review of open action items

A-289-01: Alex to make a proposal for the syntax that uses explicit port names instead of ‘@’

<scribe> Continued.

<scribe> ACTION: A-290-01 Norm to fix the github repos [recorded in http://www.w3.org/2016/03/16-xproc-minutes.html#action01]

Henry: Are the slides from XProc day available/

Alex: I have an outstanding request to send those to Jirka

Norm: Ok, please let us know when you do, or post them somewhere

<scribe> ACTION: A-290-02 Alex to post slides/presentation from XProc day at XML Prague [recorded in http://www.w3.org/2016/03/16-xproc-minutes.html#action02]

A-289-02: Jim to attempt to write Henry's color pipeline in the new syntax.

<scribe> Completed.

Review of Jim’s rewrite of Henry’s pipeline and the discussion that followed.

<jfuller> https://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2016Mar/0001.html

Jim: I was shooting from the hip. I think the best version of this is later in the thread.

-> https://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2016Mar/0004.html

<jfuller> https://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2016Mar/0007.html

<ht> Is that dated 5 Mar 06:26:03 ?

<jfuller> nice it fits in one screen

Alex: Related to the proposal to get rid of @ notation and $1, $2, etc. the matched subtree needs an output port reference.
... The output, the replacement, needs a variable as well.
... In the example we have $result being used but there's an implicit input port.
... The subtree that's matched isn't matched in this example.

Jim: That's what I did, but I'm not sure that's what we want.

Alex: The inner step chain needs a $source.

Moving on to Alex's message, 0008

-> https://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2016Mar/0008.html

Alex: If we're going to get rid of @ and $1, $2, we need ways to declare things and a default declaration.
... In the case of replace, there's a single referencable port that is the matched entry. And a single output port.

Jim walks through the example in 0007.

<alexmilowski> In the original proposal, we had $source/*/@foo

Jim: The use of projection() and template() feels like a rough edge.

Alex: Yes, dynamic projection is a bit funky, but it's also a more advanced case.
... The follow-up email from me talks about the fact that the input isn't named.

Jim: I think it's a good starting point to name variables.

Alex: There are a couple of questions here: one is whether or not there's any concept of a default input.
... I started from the position that there isn't; you have to name them.
... The reason for that is simply that some step chains start with generator steps. We want it to be clear that there is no input in that case.

Jim: My proposal is that we stick with naming ports for now, we can make a late decision about defaults.

Moving on to message 0008

Norm: Where did $source come from?

Murray: $source is the name for the primary input to any step.
... I think projection() should just be called select()

Alex: I think that would be fine.

Some discussion of the confusion caused by $match in replace() which has the semantics of p:viewport.

Suppose $source = <doc><div1/><div1><div2/></div1></doc>

replace("/doc/div1") => processes <div1/> and <div1><div2/></div1> in the body

<alexmilowski> viewport: $source →for $x in subtree $match replace with $y { … }

<ht> Alex, why $y

Murray: I'm now all kind of weirded out about the $source in side the curly braces.

<alexmilowski> THat’s the name of the output port

<alexmilowski> No default names

<ht> What, so inside the curly braces there must be a >> $y somewhere?

<alexmilowski> viewport with no output: $source →for $x in subtree $match { … }

<alexmilowski> Yes

<ht> OK

Jim: We'd talked about [] as an anonymous name.

<ht> I still prefer to see that on the other side

<alexmilowski> iteration: $source →for $x in subtree $match *output* $y { … }

<alexmilowski> where we need a better syntax for output

Jim: If you replaced $source and $result with [], then you avoid the naming confusion.

<jfuller> fixed version

<jfuller> https://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2016Mar/0012.html

<jfuller> with [] proposal

Alex: I feel like we could do a better job with viewports and iteration.

<ht> I.e. viewport: $source →for $x in subtree $match replace with { ... } $y

Alex: In both cases, it's running a projection and doing something over that sequence.
... It's just what you do with the result, do you put it back in the tree or do you produce a sequence.

<ht> So this is the anonymous step problem

<ht> Also

Alex: Or maybe you do nothing. In XProc1, I found it annoying to viewport and discard the results.
... It seems like replacement could just be some additional options to iteration.
... Then we get one syntax that people understand, iteration over stuff.
... If we give the user a way to name the thing being iterated, then they can choose meaningful names and we're done.

<ht> So this is just filtered function application

Norm: We do have the option of differentiating steps from language features.

Henry: I'm still trying to construct the semantics of these things. The curly braces, and this goes back to the square bracket syntax
... of three or four weeks ago; it would be simpler to think about this and about conditionals if we restricted ourselves to named steps.

<alexmilowski> $source ! step()

Henry: Iterate is just step application to a set of selected subtrees.
... If we had a simple, clean syntax for applying a named step to every paragraph in the incoming document and replacing it with the result of the named step.

<jfuller> replace could be implemented with xslt step as a drop in replacement

Henry: That would be very similar to the one that said iterate over them and so on. We'd then be in a better position to come up with a general purpose simplification.
... We could then add anonymous steps later.
... This is just like adding lambda to Python.

Alex: I think that's a great observation. If we borrow the ! operator for iteration, we need to think along those lines where the RHS is a step invocation over a sequence of things.
... We have two use cases, one is simple iteration, the other is replace or viewport. The reconstruction version of it.
... If we had one syntax that let us do both, I think we'd win.
... Maybe we should try to make every syntax that we propose as a step invocation and then we can think of the anonymous case later.
... What that leads to then is the ability to call a flow in any point in the pipeline. Flows become interchangeable with named steps and anonymous steps.
... The current syntax doesn't allow that which is really unfortunate.

Norm: That seems reasonable.

Murray: Are there any other steps, besides replace, that operation the document instead of running a filter on the document?

Alex: No, I think replace is unique in that respect.

<jfuller> observation- what comes out of replace could be a copy ... immutability is king

Murray: It seems to me that this is a sharp distinction. It's not the same. In terms of computing power, does replace put more of a burden on the processor?

Norm: No, not really.

Alex: I think projection is also something that we want to make easy.

Some discussion of the cost of holding onto documents "when they're not necessary"

Any other business

Jim: In doing this exercise, I think the flow became crisper which I think is good validation of our direction.

Henry: I remain unconvinced that we don't need a simpler way to bind variables.

Jim: I agree there's more work to be done.
... I was surprised we got down from two pages to one.

Adjourned.