- From: Norman Walsh <ndw@nwalsh.com>
- Date: Fri, 28 Nov 2014 10:38:44 -0600
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <87egsn8eln.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2014/11/26-minutes
[1]W3C
- DRAFT -
XML Processing Model WG
Meeting 259, 26 Nov 2014
[2]Agenda
See also: [3]IRC log
Attendees
Present
Norm, Jim, Loren, Alex, Henry
Regrets
Chair
Norm
Scribe
Norm
Contents
* [4]Topics
1. [5]Accept this agenda?
2. [6]Accept minutes from the previous meeting?
3. [7]Next meeting
4. [8]Review of open action items
5. [9]Norm's proposal for value templates
6. [10]Issue 109
7. [11]Any other business?
* [12]Summary of Action Items
--------------------------------------------------------------------------
Accept this agenda?
-> [13]http://www.w3.org/XML/XProc/2014/11/26-agenda
Accepted.
Accept minutes from the previous meeting?
-> [14]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: [15]https://xproc.github.io/specification/
Norm's proposal for value templates
->
[16]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> [17]https://github.com/xproc/specification/issues/109
<jfuller>
[18]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>
[19]http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2014Nov/0020.html
Jim: Here's my email summary.
<jfuller> [20]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
[21]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.
Summary of Action Items
[NEW] ACTION: Jim to write a proposal for 'from' and the variable
proposal. [recorded in
[22]http://www.w3.org/2014/11/26-xproc-minutes.html#action01]
[End of minutes]
--------------------------------------------------------------------------
Minutes formatted by David Booth's [23]scribe.perl version 1.140 ([24]CVS
log)
$Date: 2014-11-28 16:35:18 $
References
1. http://www.w3.org/
2. http://www.w3.org/XML/XProc/2014/11/26-agenda
3. http://www.w3.org/2014/11/26-xproc-irc
4. http://www.w3.org/XML/XProc/2014/11/26-minutes.html#agenda
5. http://www.w3.org/XML/XProc/2014/11/26-minutes.html#item01
6. http://www.w3.org/XML/XProc/2014/11/26-minutes.html#item02
7. http://www.w3.org/XML/XProc/2014/11/26-minutes.html#item03
8. http://www.w3.org/XML/XProc/2014/11/26-minutes.html#item04
9. http://www.w3.org/XML/XProc/2014/11/26-minutes.html#item05
10. http://www.w3.org/XML/XProc/2014/11/26-minutes.html#item06
11. http://www.w3.org/XML/XProc/2014/11/26-minutes.html#item07
12. http://www.w3.org/XML/XProc/2014/11/26-minutes.html#ActionSummary
13. http://www.w3.org/XML/XProc/2014/11/26-agenda
14. http://www.w3.org/XML/XProc/2014/11/19-minutes
15. https://xproc.github.io/specification/
16. https://ndw.github.io/specification/langspec/avt-tvt/head/xproc20/#value-templates
17. https://github.com/xproc/specification/issues/109
18. http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2014Feb/0001.html
19. http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2014Nov/0020.html
20. https://github.com/xproc/specification/issues/36
21. http://www.w3.org/2014/11/26-xproc-minutes.html#action01]
22. http://www.w3.org/2014/11/26-xproc-minutes.html#action01
23. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
24. http://dev.w3.org/cvsweb/2002/scribe/
Received on Friday, 28 November 2014 16:39:19 UTC