17:03:19 RRSAgent has joined #xproc 17:03:19 logging to http://www.w3.org/2016/04/20-xproc-irc 17:03:46 rrsagent, set logs world-visible 17:03:46 Meeting: XML Processing Model WG 17:03:46 Date: 20 Apr 2016 17:03:46 Meeting: 293 17:03:47 Chair: Norm 17:03:47 Scribe: Norm 17:03:49 ScribeNick: Norm 17:03:51 Agenda: http://www.w3.org/XML/XProc/2016/04/20-agenda 17:04:37 Present: Norm, Jim, Henry, Alex 17:04:43 Topic: Accept this agenda? 17:04:43 -> http://www.w3.org/XML/XProc/2016/04/20-agenda 17:04:46 alexmilowski has joined #xproc 17:04:48 Accepted. 17:04:51 Topic: Accept minutes from the previous meeting? 17:04:51 -> http://www.w3.org/XML/XProc/2016/04/13-minutes 17:04:57 jfuller has joined #xproc 17:05:06 Accepted. 17:05:13 Topic: Next meeting, 27 Apr 2016 17:05:20 No regrets heard. 17:05:24 Topic: Review of open action items 17:05:25 might add to the agenda discussing xproc day at CWI 17:05:46 Continued. 17:06:07 Topic: Considering port set expressions and block expressions 17:06:13 -> https://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2016Apr/0006.html 17:06:20 ht has joined #xproc 17:06:44 Norm: Anyone want to comment? 17:07:01 Henry: I was confused about the bindings for the primary input of the schema steps, but you got there first. 17:07:18 +[...] 17:07:22 += 17:07:29 [] 17:07:43 ... It occurs to me that adding to the bindings might be common enough to warrant its own syntax. 17:07:48 ... e.g., +[...] 17:08:45 Jim: No, I haven't read all the way through the thread yet. 17:09:06 ... 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. 17:09:17 ... It's fine to iterate on this one but what else is open? 17:09:42 Alex: I don't think that thread contains a lot of violent disagreement. 17:10:00 agree with Alex characterisation ... 17:10:52 ... There's a question of what are the bindings and where do they come from. 17:11:06 ... My intent was that readable ports was a setup to address block expression. 17:11:15 ... One of my goals now is to get rid of some of the inlined complexity. 17:11:52 ... We want to be able inline conditionals without having to carry forward all the complexity of bindings, etc. 17:12:20 ... We keep putting out examples that use closures but I don't think that's what users will actually do. 17:13:00 ... I wanted to look at how we put in a conditional without curly brackets. 17:13:40 Henry: I think the conditional thing is fine, but that's as far as I got. 17:13:44 I think its been useful to raise the func signature at this point, I am also keen to get block exp/conditionals untangled 17:13:54 The scribe realizes he pointed to the wrong message thread in the agenda :-( 17:14:32 Henry: The primary inputs will all work just fine. I think the declaration syntax still needs work. Norm and I have different problems. 17:15:17 ... 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. 17:15:32 ... I'm not sure about that, but anyway, what I have in the semantics at the moment is the notion of "gated flows". 17:15:47 ... At any point in the pipeline, you can attach a gate to the things on the right of arrows. 17:16:15 ... You're example in my semantics is just going to get translated into a set of gated flows. 17:16:38 ... That's just exposing my thinking, it can't immediately impact on the semantics. 17:16:53 ... Without some kind of delimiter we have the dangling else problem. 17:17:24 Alex: We can handle the else problem by always requiring else. 17:17:35 ... It's what XQuery does, but we don't have to do that. 17:18:07 Alex: 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. 17:18:15 ... If we could syntactically delete the else, it'd be a non-operation. 17:18:30 ... But if we have to have the else, we need to have an easy way of saying identity. 17:19:30 Some discussion about whether identity is actually the semantic you want for the "else". 17:19:38 Henry: Sometimes the flows produce nothing and just evaporate. 17:20:00 I can hear Henry 17:20:26 another moment, I wished we recorded webex 17:20:49 Why are you holding your 'phone in the air? 17:21:34 Alex: That big long email is a rough agenda of where my thinking has gone. 17:21:46 ... There's some radical stuff in there, but we need to be able to make conditionals inline without special syntax. 17:22:00 ... We need to address the whole question of variables. 17:22:16 Jim: That's the argument, right: what is a port and what is a variable. 17:22:24 I'm going to argue for ports _and_ pipes 17:22:40 ports are what we had in 1.0 17:22:45 Alex: You can imagine that this is a specification for something that runs on a cluster and data travels from place to place. 17:22:55 ... Variables are different. 17:22:55 pipes are what we have in the default readable [] 17:23:12 steps _and_ variables have ports 17:23:12 Alex: I really thing we need to keep that distinction. 17:23:40 Henry: There's no question that in the semantics, I need to be able to distinguish ports from pipes. 17:23:50 ... I think ports are like what they are in 1.0, but variables have ports too. 17:24:08 Jim: I don't mean to break in, but could we represent a port as a function with a type. 17:24:09 We’re conflating terms ... 17:24:14 pipe vs port ... 17:24:21 I’ve been talking more about “pipes" 17:24:25 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 17:24:47 ... 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 17:25:07 ... 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 17:25:19 ... of the graph gets constructed. I think it's actually useful to distinguish between the concept of 'port' and 17:25:29 ... the concept of 'data in flow'. Which isn't the same as what Alex has used 'flow' for. 17:25:34 Jim: I'd say a collection of functions. 17:26:00 ... I'm making a leap that we have a well known definition of xs:function and we can apply that notion. 17:26:10 ... Does that cleanly solve all of our problems, or do we need to go beyond that type. 17:26:22 Alex: I think to some extent Henry is making a good distinction and we're talking past each other. 17:26:22 steps have signatures, which makes them like functions 17:26:49 ... There are the names of things: ports, readable ports is a list of possibly named things, and chain sequences connect things together with pipes. 17:26:52 In 1.0 the default readable ports were output ports of steps 17:27:07 ... 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. 17:27:20 In what we're talking about 'ports' are an active entity 17:27:21 ... What flows over a pipe coming from a port in a particular context is not something that you can compute. 17:27:42 Alex: 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 17:27:52 ... of the sequence that could be generated from that pipe until you're done. 17:28:07 ... Whereas if you're holding onto a variable, you have to have that value entirely computed. 17:28:08 I disagree 17:28:16 Jim: I agree. 17:28:19 Henry: That's just wrong. 17:28:40 ... 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, 17:29:09 ... 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. 17:29:31 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. 17:29:37 ... Variables are very distinctly things that have values. 17:30:02 ... The purpose of variables generally is to compute options for steps or to use in expressions. 17:30:09 I don't see a useful difference between scoped names for pipes and variables. 17:30:58 What if I want the equivalent of ? 17:31:24 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. 17:32:38 Some discussion of the distinction between connections and variables. 17:34:27 [...] -> mypipe() >> myresult() 17:34:34 [...] -> mypipe() >> $myresult() 17:34:35 Norm: I think we can tell the two cases apart by context so we don't need to draw it out in the syntax. 17:35:27 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. 17:35:36 ... We call the first options and the second ports. 17:36:21 ... I ought to be able to have as outputs "cash on the barrel head" values and pipes. 17:36:37 ... Some things you want guarantees for and others you want firehoses. 17:37:18 [...] -> mypipe() >> $myresult(indent=true,content-type='application/html') 17:37:25 (sorry indulging mysefl) 17:37:40 I really haven't grokked what you mean by functions 17:38:00 Can we reserve a bit of time for a “meta discussion” ? 17:38:07 Henry: Back in the day when Richard was engaged, he always wanted to implement it with unix pipes. 17:38:12 (e.g. community involvement) 17:38:28 ... I think it should be possible to implement this in a way where everything stops between steps. 17:38:55 So keeping a 'naive' implementation in view as a sort of 'sanity check' is a good idea 17:39:11 Alex: I think we should take our technical discussion back to email. 17:39:36 ... meanwhile, I think wehave to talk about some other things. 17:39:37 Alex: Write up your thoughts -- HST puts his hand up "mea culpa" 17:39:52 Topic: Meta-discussion, community, XML Amsterdam/CWI 17:40:50 When would this be? 17:41:08 26 and 27 September 17:41:28 2016 TPAC is where? 17:41:40 Norm mutters on about the CWI thing. An XProc workshop day and an XForms workshop day, probably 26/27 of September in Amsterdam. 17:42:31 ... With an XProc face-to-face to follow? 17:44:51 Some mutterngs about the dates. 17:44:55 s/mutterngs/mutterings/ 17:45:49 General consensus that those dates would work. 17:46:06 +1 to all that 17:46:10 It follows that we *won't* meet at TPAC. 17:46:38 Alex: We have a community group that we're not leveraging very well. 17:47:21 Alex: I'm concerned that spending time on XProc 2 for a community that isn't engaged is risky. 17:47:39 Henry: I think that's why we need a FPWD so we can point to it. 17:48:00 Alex: The X is deadly. One thing that XProc could provide is an interface between something like Googles dataflow and users. 17:48:07 ... Those people will never look at our spec. 17:48:33 Alex: I have a lot of things I need to do and I still wonder if there's any value here. 17:49:13 ... Who's going to implement this besides Norm 17:49:28 Jim: I hear you. I don't know what to do about community 17:49:53 Jim: There are people with data flow problems. It keeps cropping up. A new spec could come out and it might fall on deaf ears. 17:50:09 ... I don't know if changing the name might help, or moving it to a new activity might help I just don't know. 17:50:27 ... We have a more compact, elegant language, that's a good start. 17:50:45 ... We don't have XProc embedded in XQuery. If you look at something like [???], it has something that looks like XQuery in it. 17:50:50 Jim: What was [???]? 17:50:56 jfuller: what was [???] 17:50:59 swift? 17:51:07 Jim: Maybe the data types from XML Schema is as far as we can go. 17:51:11 ... I really don't know what to do. 17:51:16 ... I've always had those concerns. 17:51:33 ... No one will look at it until there's an implementation of some version 1 spec. 17:52:07 Alex: Having a more generalized language means necessarily not making any format have special status. 17:52:18 ... I think that has and will continue to alienate the users who are using XProc to do XML processing. 17:52:24 ... Those are our only current users and they're very silent. 17:52:31 s/[???]/Swift/g 17:52:38 ... And they're very small. 17:53:12 Norm: What kind of guarantee would help? 17:53:24 Alex: I dunno, but the world has moved on. 17:53:42 ... I think I'm trying to solve a different problem and maybe it's not going to service our users. 17:53:59 [ a node.js implementation would interest a lot of people, true. Include solutions for some of the "traditional" XML/XProc use cases. ] 17:54:10 Jim: It's probably the case that our next language may not be as directly applicable to our current users. 17:54:38 Alex: I'm concerned about our ability to produce a good specification with limited resources and support. 17:55:07 ... Even within the XML community, half of our counterparts thing we're crazy. 17:55:26 ... I think we're doing good work, I enjoy it, but I think we could do that on our own time. 17:57:12 Topic: Any other business? 17:57:16 My depressing thoughts ... 17:57:18 None heard. 17:57:42 rrsagent, set logs world visible 17:57:47 rrsagent, draft minutes 17:57:47 I have made the request to generate http://www.w3.org/2016/04/20-xproc-minutes.html Norm