See also: IRC log
<scribe> Meeting: 289
<scribe> Scribe: Norm
<scribe> ScribeNick: Norm
-> http://www.w3.org/XML/XProc/2016/03/02-agenda
Accepted.
<ht> How was oxford
<ht> ?
-> http://www.w3.org/XML/XProc/2016/02/24-minutes
<ht> Ah, right, silly me
Accepted.
<alexmilowski> Norm Walsh, MI7
No regrets heard
<ht> Works for me -- I also am unavailable on 9 March
Alex: What about data literals from last week?
Henry: I think we reached violent
agreement; the situation wrt media types and literals is
complicated and isn't going to be simple no matter what we
do.
... I think some of the discussion was confused but that's ok,
we have enough on the record to proceed.
Alex: Good.
Discussion of expression language issues
<jfuller> the link Alex mentioned
<jfuller> https://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2016Feb/0022.html
Alex: The variables question is open and maybe it can be discussed somewhat separately.
Norm: But what about literals
Alex: If we make data literals
easy, then you just do that.
... That's a story we can explain and if it's sufficient then
it greatly simplifies our language.
Norm: But then all we're left with is conditionals.
Some discussion of making the expression language pluggable.
Alex: That's what I was thinking
about when I gave the quoted syntax at XML Prague.
... Like make using $(...) or something like that. What goes on
the inside can be different things.
<jfuller> I think this is an interesting direction ....
Alex: The immediate thing that follows is what do I do if I have different expression languages.
Norm: That's what I was saying earlier about the ability to declare the current expression language.
Alex: I think I'd prefer to have
a way to specify the default expression language and provide
another way to express a different one on a per-use
basis.
... Optionall, this one is "wonky CSV query language".
Murray: Two things: one is that
you want information about the current processor. The trace
output needs to say that the expression language has
changed.
... As soon as you allow this, you're going to have people who
want to have conditionals composed from several languages.
Norm: Yeah, I'm willing to say "no". I think the 95% case is one expression language throughout.
Jim: We could have our own minimal expression language: true/false, boolean conditionals...
Alex: That's what I'd propose for Murray's case.
Norm: Yeah, that could work.
Alex: if you're just going to
check the output of a step, then you could say that empty is
false and anything else is true.
... That covers a whole bunch of cases without introducing an
expression language.
Murray: What if the port doesn't exist? Does it spring into existence?
Alex: That's a good question. Is it an error is it just false.
Jim: How draconian or Postelian do we want to be.
Norm: Yeah, less draconion.
Jim proposes declared options; Alex muses about interoperability if we have too many of those.
Henry: I wonder if tumblers are
useful enough ... nah ... I just note that paths work for
JSON.
... It feels to me like 90% of my expressions are paths plus
equality and inequality.
Alex: Products like MarkLogic that can do XPath expressions over JSON are really powerful.
Norm: So should we take as a direction exploring making the expression language pluggable.
General agreement. No objections. Accepted.
<jfuller> https://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2016Feb/0023.html
Alex walks us through this thread.
Norm: We could make the separator "," or ";" required and then we wouldn't need an explicit placeholder.
Alex: We need a syntax, but
there's lots of room for innovation.
... Whatever we choose, we can use it in other places.
... Then we don't need '@', it's just port variables. If it's
on the RHS of ">>" we're assigning to it; if it's inside
a step chain it's an input.
... It's up to the processor to figure that out.
Norm: I'm sold on trying to explore this. I never liked $1 and @1.
Alex: You just have to declare them or you get a default.
Jim: I like this approach too. I observe that the underscore could just be "[]".
Alex: Yes, that's good.
... The only time this is a problem is if you have a generator
that has no inputs and produces output. They're common enough
that we want to support them.
Norm: This sounds like the direction we want to explore.
Alex: I'd like to explore the idea of using this compact syntax in lots of places and see what it does.
<scribe> ACTION: Alex to make a proposal for the syntax document with this grammar. [recorded in http://www.w3.org/2016/03/02-xproc-minutes.html#action01]
<ht> https://github.com/xproc/notes/tree/master/design
Henry explains what's in this space.
Henry: I've been working on an
example that may or may not be useful to anyone else.
... I'm trying to work my way through an understanding of what
we're calling the API syntax.
... I'm not ready to go very far through this yet. But if you
follow the link in the README.
... This works in XProc 1. I'd like to understand what an XProc
not-XML version of the pipeline would look like.
<jfuller> great stuff Henry - give me an action Norm
<scribe> ACTION: Jim to attempt to cast this task in the current compact syntax. [recorded in http://www.w3.org/2016/03/02-xproc-minutes.html#action02]
Norm: Very cool. Thank you, Henry.
<jfuller> my eyes hurt reading xproc v1 now ....
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/thta/that/ Found Scribe: Norm Inferring ScribeNick: Norm Found ScribeNick: Norm Present: Norm Alex Henry Jim Murray Agenda: http://www.w3.org/XML/XProc/2016/03/02-agenda Found Date: 02 Mar 2016 Guessing minutes URL: http://www.w3.org/2016/03/02-xproc-minutes.html People with action items: alex jim[End of scribe.perl diagnostic output]