- From: Norman Walsh <ndw@nwalsh.com>
- Date: Wed, 20 Apr 2016 13:18:14 -0500
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <87oa94gn4p.fsf@nwalsh.com>
See https://www.w3.org/XML/XProc/2016/04/20-minutes
[1]W3C
- DRAFT -
XML Processing Model WG
Meeting 293, 20 Apr 2016
[2]Agenda
See also: [3]IRC log
Attendees
Present
Norm, Jim, Henry, Alex
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, 27 Apr 2016
4. [8]Review of open action items
5. [9]Considering port set expressions and block expressions
6. [10]Meta-discussion, community, XML Amsterdam/CWI
7. [11]Any other business?
* [12]Summary of Action Items
* [13]Summary of Resolutions
--------------------------------------------------------------------------
Accept this agenda?
-> [14]http://www.w3.org/XML/XProc/2016/04/20-agenda
<jfuller> might add to the agenda discussing xproc day at CWI
Accepted.
Accept minutes from the previous meeting?
-> [15]http://www.w3.org/XML/XProc/2016/04/13-minutes
Accepted.
Next meeting, 27 Apr 2016
No regrets heard.
Review of open action items
<scribe> Continued.
Considering port set expressions and block expressions
->
[16]https://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2016Apr/0006.html
Norm: Anyone want to comment?
Henry: I was confused about the bindings for the primary input of the
schema steps, but you got there first.
<ht> +[...]
<ht> +=
<ht> []
Henry: It occurs to me that adding to the bindings might be common enough
to warrant its own syntax.
... e.g., +[...]
Jim: No, I haven't read all the way through the thread yet.
... The only observation that I'd make is that it's good to talk about
signatures in parallel. I don't have a good sense of what else is open.
... It's fine to iterate on this one but what else is open?
Alex: I don't think that thread contains a lot of violent disagreement.
<jfuller> agree with Alex characterisation ...
Alex: There's a question of what are the bindings and where do they come
from.
... My intent was that readable ports was a setup to address block
expression.
... One of my goals now is to get rid of some of the inlined complexity.
... We want to be able inline conditionals without having to carry forward
all the complexity of bindings, etc.
... We keep putting out examples that use closures but I don't think
that's what users will actually do.
... I wanted to look at how we put in a conditional without curly
brackets.
Henry: I think the conditional thing is fine, but that's as far as I got.
<jfuller> I think its been useful to raise the func signature at this
point, I am also keen to get block exp/conditionals untangled
The scribe realizes he pointed to the wrong message thread in the agenda
:-(
Henry: The primary inputs will all work just fine. I think the declaration
syntax still needs work. Norm and I have different problems.
... The only thing I'd say is that I think 'case' is going to be more
useful than 'if'. At least, I'd rather start there, because I think more
than two paths is commonplace.
... I'm not sure about that, but anyway, what I have in the semantics at
the moment is the notion of "gated flows".
... At any point in the pipeline, you can attach a gate to the things on
the right of arrows.
... You're example in my semantics is just going to get translated into a
set of gated flows.
... That's just exposing my thinking, it can't immediately impact on the
semantics.
... Without some kind of delimiter we have the dangling else problem.
Alex: We can handle the else problem by always requiring else.
... It's what XQuery does, but we don't have to do that.
... The thing about chains that we need to keep in mind is that the
expression we stick in the middle always needs to have some operation
that's insertable.
... If we could syntactically delete the else, it'd be a non-operation.
... But if we have to have the else, we need to have an easy way of saying
identity.
Some discussion about whether identity is actually the semantic you want
for the "else".
Henry: Sometimes the flows produce nothing and just evaporate.
<alexmilowski> I can hear Henry
<jfuller> another moment, I wished we recorded webex
<ht> Why are you holding your 'phone in the air?
Alex: That big long email is a rough agenda of where my thinking has gone.
... There's some radical stuff in there, but we need to be able to make
conditionals inline without special syntax.
... We need to address the whole question of variables.
Jim: That's the argument, right: what is a port and what is a variable.
<ht> I'm going to argue for ports _and_ pipes
<ht> ports are what we had in 1.0
Alex: You can imagine that this is a specification for something that runs
on a cluster and data travels from place to place.
... Variables are different.
<ht> pipes are what we have in the default readable []
<ht> steps _and_ variables have ports
Alex: I really thing we need to keep that distinction.
Henry: There's no question that in the semantics, I need to be able to
distinguish ports from pipes.
... I think ports are like what they are in 1.0, but variables have ports
too.
Jim: I don't mean to break in, but could we represent a port as a function
with a type.
<alexmilowski> We’re conflating terms ...
<alexmilowski> pipe vs port ...
<alexmilowski> I’ve been talking more about “pipes"
Henry: The logic of what Alex has done is just fine, but what we were
close to saying at the end of the call last time
... is that it's data flow that's in the default readable X; you want to
think of being in the connections. The pipes themselves are full
... of stuff. What you get from the square brackets is a collection of
stuff which you then plug into ports. That's how the topology
... of the graph gets constructed. I think it's actually useful to
distinguish between the concept of 'port' and
... the concept of 'data in flow'. Which isn't the same as what Alex has
used 'flow' for.
Jim: I'd say a collection of functions.
... I'm making a leap that we have a well known definition of xs:function
and we can apply that notion.
... Does that cleanly solve all of our problems, or do we need to go
beyond that type.
Alex: I think to some extent Henry is making a good distinction and we're
talking past each other.
<ht> steps have signatures, which makes them like functions
Alex: There are the names of things: ports, readable ports is a list of
possibly named things, and chain sequences connect things together with
pipes.
<ht> In 1.0 the default readable ports were output ports of steps
Alex: What I'm suggesting is that variables are the values that we can
compute. Once a value is computed, it has that value in scope and we're
done.
<ht> In what we're talking about 'ports' are an active entity
Alex: What flows over a pipe coming from a port in a particular context is
not something that you can compute.
... What I'm suggesting is that at a particular point in execution, if
you're holding onto a pipe, you don't know the value
... of the sequence that could be generated from that pipe until you're
done.
... Whereas if you're holding onto a variable, you have to have that value
entirely computed.
<ht> I disagree
Jim: I agree.
Henry: That's just wrong.
... My contention is different. Going back to the example that Norm gave
in the email. If I double arrow into a variable and then arrow out of a
variable,
... that's just a convenience for naming what's coming down the pipe. The
semantics of the fact that I don't know the size of the value doesn't
matter.
Alex: I contend that the thing that appears on the right hand of >> is the
name of a pipe and we shouldn't call it a variable.
... Variables are very distinctly things that have values.
... The purpose of variables generally is to compute options for steps or
to use in expressions.
<ht> I don't see a useful difference between scoped names for pipes and
variables.
<ht> What if I want the equivalent of <p:variable name="xyzzy"
select="/body/paragraph"/> ?
Norm attempts to explain how he sees the distinction: connecting a pipe
from an append operator vs. passing that to an XSLT step as a parameter.
Some discussion of the distinction between connections and variables.
<jfuller> [...] -> mypipe() >> myresult()
<jfuller> [...] -> mypipe() >> $myresult()
Norm: I think we can tell the two cases apart by context so we don't need
to draw it out in the syntax.
Henry: If I was putting forward a syntax for step declarations, I'd use
something much closer to the xpath function syntax and have a divider that
says in the arguments a way to distinguish the static values and the
flows.
... We call the first options and the second ports.
... I ought to be able to have as outputs "cash on the barrel head" values
and pipes.
... Some things you want guarantees for and others you want firehoses.
<jfuller> [...] -> mypipe() >>
$myresult(indent=true,content-type='application/html')
<jfuller> (sorry indulging mysefl)
I really haven't grokked what you mean by functions
<alexmilowski> Can we reserve a bit of time for a “meta discussion” ?
Henry: Back in the day when Richard was engaged, he always wanted to
implement it with unix pipes.
<alexmilowski> (e.g. community involvement)
Henry: I think it should be possible to implement this in a way where
everything stops between steps.
<ht> So keeping a 'naive' implementation in view as a sort of 'sanity
check' is a good idea
Alex: I think we should take our technical discussion back to email.
... meanwhile, I think wehave to talk about some other things.
<ht> Alex: Write up your thoughts -- HST puts his hand up "mea culpa"
Meta-discussion, community, XML Amsterdam/CWI
Norm mutters on about the CWI thing. An XProc workshop day and an XForms
workshop day, probably 26/27 of September in Amsterdam.
scribe: With an XProc face-to-face to follow…
Some mutterings about the dates.
General consensus that those dates would work.
<jfuller> +1 to all that
It follows that we *won't* meet at TPAC.
Alex: We have a community group that we're not leveraging very well.
... I'm concerned that spending time on XProc 2 for a community that isn't
engaged is risky.
Henry: I think that's why we need a FPWD so we can point to it.
Alex: The X is deadly. One thing that XProc could provide is an interface
between something like Googles dataflow and users.
... Those people will never look at our spec.
... I have a lot of things I need to do and I still wonder if there's any
value here.
... Who's going to implement this besides Norm
Jim: I hear you. I don't know what to do about community
... There are people with data flow problems. It keeps cropping up. A new
spec could come out and it might fall on deaf ears.
... I don't know if changing the name might help, or moving it to a new
activity might help I just don't know.
... We have a more compact, elegant language, that's a good start.
... We don't have XProc embedded in XQuery. If you look at something like
Swift, it has something that looks like XQuery in it.
Jim: Maybe the data types from XML Schema is as far as we can go.
... I really don't know what to do.
... I've always had those concerns.
... No one will look at it until there's an implementation of some version
1 spec.
Alex: Having a more generalized language means necessarily not making any
format have special status.
... I think that has and will continue to alienate the users who are using
XProc to do XML processing.
... Those are our only current users and they're very silent.
... And they're very small.
Norm: What kind of guarantee would help?
Alex: I dunno, but the world has moved on.
... I think I'm trying to solve a different problem and maybe it's not
going to service our users.
<liam> [ a node.js implementation would interest a lot of people, true.
Include solutions for some of the "traditional" XML/XProc use cases. ]
Jim: It's probably the case that our next language may not be as directly
applicable to our current users.
Alex: I'm concerned about our ability to produce a good specification with
limited resources and support.
... Even within the XML community, we get little support.
... I think we're doing good work, I enjoy it, but I think we could do
that on our own time.
Any other business?
None heard.
Summary of Action Items
Summary of Resolutions
[End of minutes]
--------------------------------------------------------------------------
Minutes formatted by David Booth's [17]scribe.perl version 1.144 ([18]CVS
log)
$Date: 2016/04/20 18:03:42 $
References
1. http://www.w3.org/
2. http://www.w3.org/XML/XProc/2016/04/20-agenda
3. http://www.w3.org/2016/04/20-xproc-irc
4. http://www.w3.org/XML/XProc/2016/04/20-minutes.html#agenda
5. http://www.w3.org/XML/XProc/2016/04/20-minutes.html#item01
6. http://www.w3.org/XML/XProc/2016/04/20-minutes.html#item02
7. http://www.w3.org/XML/XProc/2016/04/20-minutes.html#item03
8. http://www.w3.org/XML/XProc/2016/04/20-minutes.html#item04
9. http://www.w3.org/XML/XProc/2016/04/20-minutes.html#item05
10. http://www.w3.org/XML/XProc/2016/04/20-minutes.html#item06
11. http://www.w3.org/XML/XProc/2016/04/20-minutes.html#item07
12. http://www.w3.org/XML/XProc/2016/04/20-minutes.html#ActionSummary
13. http://www.w3.org/XML/XProc/2016/04/20-minutes.html#ResolutionSummary
14. http://www.w3.org/XML/XProc/2016/04/20-agenda
15. http://www.w3.org/XML/XProc/2016/04/13-minutes
16. https://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2016Apr/0006.html
17. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
18. http://dev.w3.org/cvsweb/2002/scribe/
Received on Wednesday, 20 April 2016 18:18:42 UTC