XProc Minutes 20 Apr 2016

[ Reposting with correct subject for findability in the archives. ]

See https://www.w3.org/XML/XProc/2016/04/20-minutes


                                - DRAFT -

                         XML Processing Model WG

Meeting 293, 20 Apr 2016


   See also: [3]IRC log


           Norm, Jim, Henry, Alex





     * [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


  Accept minutes from the previous meeting?

   -> [15]http://www.w3.org/XML/XProc/2016/04/13-minutes


  Next meeting, 27 Apr 2016

   No regrets heard.

  Review of open action items

   <scribe> Continued.

  Considering port set expressions and block expressions


   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
   ... My intent was that readable ports was a setup to address block
   ... 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

   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
   ... 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

   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

   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

   <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

   <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
   ... 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
   ... 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

   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

   <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
   ... 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() >>

   <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
    $Date: 2016/04/20 18:03:42 $


   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:19:23 UTC