See also: IRC log
-> http://www.w3.org/XML/XProc/2016/04/20-agenda
<jfuller> might add to the agenda discussing xproc day at CWI
Accepted.
-> http://www.w3.org/XML/XProc/2016/04/13-minutes
Accepted.
No regrets heard.
<scribe> Continued.
-> 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"
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.
None heard.