Accept this agenda?

-> http://www.w3.org/XML/XProc/2014/11/26-agenda

Accepted.

Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2014/11/19-minutes

Accepted.

Next meeting

Proposed: 3 December 2014 does anyone have to give regrets?

No regrets heard.

Review of open action items

Norm asserts completion of A-252-01

Norm asserts completion of A-258-01, moratorium is mid-December

<alexmilowski> Is there a new draft to proof read?

Consensus draft is always: https://xproc.github.io/specification/

Norm's proposal for value templates

-> https://ndw.github.io/specification/langspec/avt-tvt/head/xproc20/#value-templates

Alex: I think we're still reviewing a draft, we should merge it now and review it as the status quo.

Henry: I agree.

Norm: So do I.
... I'd like to incorporate today and say that we're going to publish the status quo draft next week unless we decide there are other changes that need to be made.

Proposal: Accept this revision as the new status quo

Accepted.

Issue 109

<jfuller> https://github.com/xproc/specification/issues/109

<jfuller> http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2014Feb/0001.html

Jim: This is a comment from the public comments list.
... I'm not sure about his proposal exactly, but I think the use cases are valuable.
... One side effect of the proposal is that it simplifies how to connect ports. The second thing is what he's looking for in reading ports.

<jfuller> http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2014Nov/0020.html

Jim: Here's my email summary.

<jfuller> https://github.com/xproc/specification/issues/36

Jim: Issue 36 suggests some things we could do to simplify things.

   <p:somestep>
     <p:input port="source">
       <p:pipe step="someotherstep" port="result">
    </p:input>
  </p:somestep>

Jim: This verbosity is the problem that's being hinted at.
... Maybe we could percolate that up to the step.

<jfuller> <p:somestep step="" port=""/>

<ht> <p:somestep pp:source="someotherstep>result"/>

<ht> Blech

Norm: I'm not sure I like the idea of putting the step/port on the step.

Jim: Any kind of iterative development on a pipeline winds up requiring explicit connections so making it simpler and less verbose would be better.

<p:input port="source" step="someotherstep"/>

<jfuller> source-input=""

<ht> How much more would we capture if we just said <p:somestep from="otherstep"/>

<alexmilowski> <p:input port="source" step="other" target-port="result"/>

<alexmilowski> analogous to <p:input port="source" href="foo.xml"/>

Jim: I like Henry's suggestion of 'from'.

Henry: Is most of the problem that you don't have linear flow? Otherwise the defaulting rules would work. If that's true, then all you need is what I've said.

Norm: So from makes 'otherstep' the step from which the default readable port is read.

Henry: Exactly.

Alex: You could add ports on the input as well.
... The only time you'd need to specify target-port is if you're reading from a non-primary port.
... If we're going to optimize from a common case, we should figure out what the common case is.

Henry: Unfortunately, it's hard to tell because you'd have to analyze the pipelines in some detail.

Alex: I think Henry's proposal would address most of my complexity.

Henry: I like the fact that this moves the default readable port, that would work for p:with-option, the default context for XPathis in AVTs, etc.

Norm: That's a good point.

Jim: I think that's a good proposal for the first bit. Obviously it needs to be thought through. The last point I'd make about verbosity is that it exposes more of the "sausage making" than most users want to see. A syntactic shortcut would be really nice.

<p:group>
  <p:variable name=“count” select=“count(//elem)”>
    <p:pipe step=“earlier-step” port=“result” />
  </p:variable>
  <px:my-step option=“fx:function($count)” />
</p:group>

Jim: What would happen if we allowed p:variable to occur in between steps in a pipeline.

<jfuller> <px:my-step><p:variable/></px:my-step>

<ht> Note that example (previous line) doesn't illustrate what you say????

Norm: The problem is that if the connections require you to reorder steps, where do you put the variables? Keeping the context and scope is really hard.
... No, I misunderstood. You're talking about putting variables inside atomic steps.

Alex: If you look at XSLT you can put variables in a template.

Jim: You'd have to use the p:with-option flavor after you declared the variable.

Henry: You couldn't reduce this example to a two-line example because we're using the option shortcut.

<ht> <px:my-step>

<ht> <p:variable name="count" select="count(//elem)"/>

<ht> <p:with-option name="option" select="fx:function(count)"/>

<ht> </px:my-step>

Why isn't this righjt:

<px:my-step>

<p:with-option name="option" select="count(//elem)">

<p:pipe step=“earlier-step” port=“result” />

</p:with-option>

</px:my-step>

<ht> select ="fx:function(count(//elem)))"

Norm: So we're assuming that several options use $count, not just one.

Alex: Are we chasing our tail in some way? The folks who want a compact syntax aren't necessarily going to be happy with the markup syntax for this.

<ht> <p:let c="count(//elem)"><px:my-step option="fx:function($c)"/></p:let>

Alex: The pipe example seems to just move the complexity around.

Jim: I think the solution is more compact and cognitively less of a load. It's not a magnitude better, but I think if we get several things into v.next, that'll help overall usability.

Henry: I have no objection to the four line example that I wrote above. You can mix variables and with-option. It's no cost and makes some things easier.
... I wish we'd done p:let from the beginning but it'sprobably a bridge too far.

Norm: Couldn't we allow the variables defined in an atomic step to be in scope for AVTs on option shortcuts?

Some consensus seems to be that we could.

option="{fx:function($count)}"

<ht> <px:my-step option="{fx:function($count)}">

<ht> <p:variable name="count" select="count(//elem)"/>

<ht> </px:my-step>

Henry: I'm a little unsure about this because it doesn't read from top to bottom.

Alex: You could rewrite this so that the p:with-option comes at the end.

Norm: I don't think you *have* to describe it that way.

Henry: We thought 'from' was maybe not a bad idea, maybe this is also maybe not a bad idea.

Alex: I'd like to really see if these things are going to help users.

Henry: Here's the thing that really worries me. We're going to have to say that in-step variables shadow inherited variables. And that means the fact that it doesn't run top-to-bottom is a real problem.

Norm: Oh, I see. Users are going to look at $count in the AVT and think it's the value that comes before.

<alexmilowski> +1 to Henry's position

Henry: I'm absolutely convinced that it makes sense to allow p:variable mixed with p:with-option, but whether they apply to AVTs or not is open to more discussion.

<scribe> ACTION: Jim to write a proposal for 'from' and the variable proposal. [recorded in http://www.w3.org/2014/11/26-xproc-minutes.html#action01]

Norm: Is there more?

Jim: No, I think those two things get us most of the way there.

Any other business?

None heard.

Norm summarizes the publication plan.

Adjourned.