08:24:36 RRSAgent has joined #xproc 08:24:36 logging to http://www.w3.org/2016/02/10-xproc-irc 08:25:40 trackbot has joined #xproc 08:30:00 We accept the draft agenda 08:30:46 https://www.w3.org/XML/XProc/2016/02/03-minutes 08:31:33 ht has joined #xproc 08:32:44 https://www.w3.org/XML/XProc/2016/01/27-minutes.html 08:33:03 alexmilowski has joined #xproc 08:33:12 https://www.w3.org/XML/XProc/2016/01/27-minutes 08:33:26 Henry: that agenda should include links to the draft 08:33:33 ACTION: add link to the draft 08:33:33 Sorry, but no Tracker is associated with this channel. 08:34:11 https://github.com/xproc/notes/tree/master/dataflows 08:36:04 ht_home has joined #xproc 08:36:22 Alex: good to spend time on the major conceptual issues 08:38:29 Do we accept meeting minutes from the Jan 27th 08:38:33 https://www.w3.org/XML/XProc/2016/01/27-minutes.html 08:38:47 none heard accepted 08:39:17 Do we accept meeting minutes from the Feb 3rd ? 08:39:18 https://www.w3.org/XML/XProc/2016/02/03-minutes 08:40:02 Henry: before tomorrow we need to have the link to the new doc 08:40:28 Alex: we have included link 08:40:34 Henry: no one will see it until tomorrow 08:41:01 Alex: will send email out to the list with link of draft proposal 08:41:01 https://github.com/xproc/notes/tree/master/dataflows 08:44:42 Jim: has sent agenda for today to the list 08:45:12 pause to read Henry comments 08:45:12 https://github.com/ndw/xproc-notes/blob/master/design/ht-notes.html 08:46:02 Henry: I would like to put further discussions about the syntax to one side 08:46:34 Henry: With all respect to the WG, we are not up for this job ... 08:46:59 Henry: We need more wo/manpower 08:47:05 Alex: agree we need more people 08:48:07 http://noflojs.org/documentation/fbp/ 08:48:22 http://www.nextflow.io/example1.html 08:48:46 Alex: goes on about some examples of dataflow languages 08:49:26 Alex: noflow is a javascript type thing - its a dataflow language that processes inputs/outputs 08:50:15 Jim: what about google dataflow 08:50:29 Alex: I looked at google dataflow its an api 08:51:07 Jim: its an important distinction api vs actual dataflow language, but I mention in the awareness of dataflow in general 08:51:42 Alex: There are lots of people working in data pipelining but there is no way to say 'here is my data pipeline' 08:52:21 Liam: that is (and gives me) an interesting insight - there is two kinds of (anything) of data flow language 08:53:25 Liam: First approach everything is done with dataflow, the second is where you have 'islands' that are steps 08:54:03 Henry: The way I understood, 'we now use right arrow operator' 08:54:25 Alex: the steps continue to be a blackbox 08:54:59 Alex: Gives examples of blackbox steps 08:55:57 [ pervasive dataflow language example - https://en.wikipedia.org/wiki/Lucid_%28programming_language%29 ] 08:56:02 Alex: if you look at the science workflows they are all dataflows 08:56:16 Alex: mentions Spark, pig in data science workflows 08:57:10 Alex: when I was teaching, my students started to draw data pipelines 08:58:14 Henry: XProc v1 is pretty good, but once you go into longer term doing anything other then linear flows are unreasonably harder 08:58:27 Alex: We have two fundamental problems, we focused on XML 08:59:05 Liam: I raised that in my reply to Henry's mail 08:59:33 Alex: The other part about xproc is we focused on steps 08:59:40 Alex: and everything became 'steps' 09:00:19 Alex: the design centre revolved around steps 09:00:39 Henry: I agree with the first part- not the rest 09:00:59 Alex: The syntax of the language focused on the stpes 09:01:20 Henry: maybe we are saying the same thing 09:01:34 Henry: the hard part is managing more then linear flow 09:02:09 Liam: We spent longer in XQuery because of XQuery scripting 09:03:19 Liam: describes experience with XQuery scripting, spent almost three years 09:03:38 Liam: we should avoid that kind of route 09:05:38 https://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2016Feb/0008.html 09:06:17 Alex: it should be easy, I want a tool to parse an instance of xproc v2 and draw dataflow graph 09:06:52 Henry: The data flow graph is a candidate - abstract semantics 09:07:02 Henry: something that is less detail 09:07:28 Henry: We need something that is more specific then the nice pictures of the xproc v1 spec 09:07:38 Henry: We only designed for the simple case 09:08:02 Henry: .we got blindsided because we were focused on the simple case 09:08:18 Henry: (pls do we have to do more UML diagrams) 09:08:58 Henry: Layering is going to be absolutely crucial - one of the things we need right was that the language that is the interface to the engine was lot lower then any sane human would use 09:11:32 Jim: thinks that xproc v1 was working with abstract syntax tree 09:12:19 Henry: It is implicitly there, the way we talked about xproc syntax ... there are a lot of defaulting rules 09:14:13 Henry: xproc own language is its own compilation target - its worth not assuming the authoring language is the same thing 09:14:38 Alex: we have operators now and we connect things by operators 09:14:42 Henry goes to the whiteboard 09:14:48 ... (then comes back) 09:15:07 Henry: We get to the heart, if it were my choice we should stop this discussion 09:15:44 Henry: The complexity that kills us is the non linear definition 09:15:49 Alex: I do not disagree with you 09:15:59 Henry: I want to see the syntax we will serialise 09:16:23 Alex: We have lots of use cases, we need to get more use cases (non xml, non epub) eg. from machine learning pipelines 09:16:24 [ graphical pipeline editor with real example - http://3.bp.blogspot.com/-codtjRuVW5I/T4qFXWkFMVI/AAAAAAAAAeo/EdEfvkVeun8/s1600/node4-exp.png ] 09:17:02 Alex: We need to be able draw a graph as dataflow 09:17:17 Alex: and so here is the ways you can write this down 09:17:35 Henry: That is the next step, take one of the examples and do that 09:17:51 Henry: I want to see what the problem is 09:18:02 Alex: We have a lot of experiences with pipelines, especially on the working group 09:18:08 Alex: What we do not have is enough use cases 09:18:41 Alex: I know where to get more 09:20:55 Alex: I would like to keep our next steps grounded, we take the use case, we push it through our new syntax and see if it works - we cannot go back to first principles 09:22:46 Alex: can a tool spit out a diagram, if it cannot then why ? 09:23:08 Alex: if its because its a difficult pipeline (strange, weird) fine 09:23:45 Liam: the reason this works (diagram) it is all single layer 09:24:00 Liam: Description is at the right level 09:25:07 Henry now at the whiteboard 09:26:35 Norm has joined #xproc 09:26:58 Henry: I would like to lay out my thinking 09:27:19 Alex: one point of consensus, we need better use cases ... 09:27:29 ACTION: re collate list of use cases 09:27:29 Sorry, but no Tracker is associated with this channel. 09:29:31 scribe distracted by getting Norm to join 09:29:32 hangout 09:30:18 break for 09:30:20 a few mins 09:35:53 The real chair has joined us via a video call. 09:36:45 Henry is at the board … 09:37:24 Henry: like to rethink what the basic elements of the flow ... 09:38:16 I'm listening. Heading to other room to check coffee 09:38:39 Henry: Build up the inventory of functionality that we need to map onto the language 09:38:44 Henry: starts with pipes ... 09:39:13 Henry: take the notion of pipeline and make it richer and simpler at the same time 09:39:35 Henry: what naturally flows together but also more at the architecture that actually runs 09:39:48 Henry: reserve the posibility of more explicit layering in the design 09:40:36 Henry: that there is a language not designed for human consumption and there are layers over that... 09:40:51 Henry: pipes that are very detailed and not really hand crafted 09:41:28 Henry: kinds of things: xdm objects, xml documents, other documents, metadata … 09:42:28 Henry: the notion of scope does not fit well with the notion of data flow (e.g. variables versus the data the flows) 09:42:58 Henry: where does the XPath static context come from … what does a variable resolve against in the data flow world? 09:43:08 Henry: maybe contexts flow along with data 09:44:08 Henry: gauges? instrumentation on the pipeline that gives you insight on what inside the pipe … sampling 09:44:21 Henry: viewport .. you can look inside 09:45:44 Henry: hindsight, we need to treat sets of documents (collections) as first class objects in the architecture … the need to move collections around 09:47:53 Alex: side note, the data science perspective is that you want to process a collection as if you have the whole thing but in actuality, you only have a subset that you can process on a particular computation node 09:48:31 Henry: there are two different related points … thinking about collections as something in the flow. 09:49:12 Henry: difference betwen compile time sets and runtime sets 09:50:15 Henry: example: splitting index terms by an alphabet (e.g. one output set for each letter) 09:51:16 Henry: at runtime a step can create an output stream for each letter 09:52:05 Alex: the runtime one is like map/reduce 09:53:23 Henry: steps have signatures, … still important. 09:53:49 Henry: they vary on three dimentions: item type, arity, and style 09:54:05 Henry: item type: what comes down the pipe 09:54:34 Henry: arity - how many on the input/output 09:54:49 Henry: style - events, sets, callbacks, etc. 09:55:52 Henry: every interface that data flows through has signatures 09:57:16 Henry: sinks have to deal with multiplexing, steps do not have to deal with that 09:57:33 Henry: sinks and sources do the ‘adaption' 09:58:06 Henry: the source has to do the assembly 09:59:03 Alex: In xproc v1, you have to put something in the middle 09:59:25 Alex: In xproc vnext you get that built into the language (do the meet) 09:59:39 Alex: easier to specify in xproc vnext 10:00:41 Alex: when you conceptualise dataflow process and go do it in the language and extract the graph, they are not going to be the same 10:00:55 Alex: the question are ‘how are they different' 10:01:29 Norm: I don't think meets were especially difficult in XProc1, you didn't need a step, but you did have to name all the steps that were meeting and build the p:pipe list for them. 10:01:49 Henry: Steps get configured at authoring time 10:02:21 Henry: We spent a while trying to get params and options right 10:02:36 Norm: Maps gave us a different and less obscure story to tell about paras 10:02:59 s/paras/params/ 10:03:57 scribe buffer full 10:04:17 ScribeNick: Norm 10:04:54 Henry: I want to reconsider the whole question of step configuration; it's easy in the simple case in XProc1, it's when you want to do something sophisticated where you fall off the complexity cliff. 10:05:07 ... Getting this into the language is going to be tricky. 10:05:14 Alex: What part of configuration isn't covered by maps? 10:05:26 Henry: That's just saying AVTs can represent everything. That's true, but... 10:05:56 ... Dependencies and ordering are a big part of the problem. How do you get at what you put on the right hand side of the arrows. 10:06:16 Alex: Config params for XSLT is easy 10:06:29 Henry: I disagree, it's about what you can *use* to construct those paramters that's important. 10:07:12 ... What is the XPath context? How do you specify the XPath context for variable references in the expressions which compute the map? 10:07:28 Alex: We have that mechanism now. 10:07:37 Henry: It's full of defaulting. 10:08:10 Some further discussion of maps and parameters. Room for additional understanding/discussion. 10:08:15 Jim: Is it time to move on? 10:08:26 Alex: There are lots of good points here, we need to consider them 10:08:39 ... We need to take configuration as you've described it and break it down into different silos. 10:09:03 Henry: Think of a data flow language and now tell me what are the dependencies by which (and where do expressions sit) in the data flow. 10:09:32 ... Steps/sinks/sources/adapters/pipes. Where does configuration fit in there? It doesn't have an obvious place to stand. 10:09:44 Alex: Right now that's an implicit input. 10:10:12 Henry: There's a bunch of defaulting going on that needs to be made explicit at this level. 10:11:02 Alex: The story we tell today makes the story more complicated because steps have variables and other implicit inputs 10:11:08 Henry: We're in violent agreement. 10:11:21 Jim: There are lots of languages that escape to Java properties and lots of specs stop at that point. 10:11:31 ... I think this is worth having an action. 10:12:23 Liam: It might be worth a few minutes on my responses to Henry. 10:12:32 scribeNick: jfuller 10:13:01 https://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2016Feb/0008.html 10:13:13 Go through Liam response to Henry 10:14:08 Liam: Has said we need more resources, which I think its true but when I look at successful languages they were done by 1 or 2 10:14:46 Liam: If we produce something 1% as successful as Perl, that would be not a bad thing 10:15:32 Liam: XQuery has lots of orthogonality ... 10:15:54 (Alex: we never want to go back to parameter entities ... ever again) 10:16:44 Liam: We could get some review with program design people 10:17:04 s/program design/programming language design/ 10:17:29 damn Norm 10:17:34 s/damn Norm// 10:18:09 Liam: Adoption of a language is about writing in a syntax 10:18:27 Liam: The biggest question - is how we know it succeeded ... what is the measure of success 10:19:52 Jim: 1000x more users is my metric 10:20:03 Norm: I would like to see more data science users 10:20:18 s/Norm: I would like to see more data science users// 10:20:33 Alex: I would like to see more data science users 10:20:42 s/X/J/g 10:20:57 Norm: I think we want to make a language that is less xml centric but more data agnostic but we do not need to drop the X 10:21:30 Alex: heritage works against us 10:21:47 Naming things is bloody difficult. You come up with a better name, I'll sign on. 10:22:12 Liam: I care that vnext is not v1.1 10:22:53 W3C DFL 10:23:03 Jim: What other WG groups would have a dataflow 10:24:31 some discussion about where dataflow may emerge in other W3C WG. 10:25:02 Alex: Relying on xquery makes a lot of sense and easily shoehorn json 10:25:27 Zakim has left #xproc 10:25:42 Zakim has joined #xproc 10:26:07 Alex: its more xpath 10:26:19 Henry: You cannot use xpath unless you specify how you embed it 10:26:56 Alex: xpath is possibly too much for what we need ... 10:27:32 ACTION: discuss about xpath vs xquery and minimal size of exp language 10:27:32 Sorry, but no Tracker is associated with this channel. 10:27:58 sigh 10:29:50 ACTION: identify metric of success 10:29:50 Sorry, but no Tracker is associated with this channel. 10:30:50 Norm: tomorrow we say 100x more users, all in agreement ? 10:31:04 Jfuller: none heard 10:35:37 s/>/>=/ 10:36:35 https://github.com/xproc/notes/tree/master/dataflows 10:36:46 take a 10 min break 10:53:15 back from break 10:53:21 Alex will take us through doc 10:56:18 Alex: Will email ebnf to the list 10:56:55 Norm: Might be premature to go through EBNF 10:57:34 Alex: The spec does not describe the story as it needs to describe 10:57:42 Norm: Story will change 10:58:49 Alex has problem with definition of step chain 11:05:55 Henry: I find usage of bind slightly awkward 11:06:18 Henry: means exact opposite of what I was thinking 11:11:17 Alex: as we find these things we should be more permissive 11:11:26 Henry: I dislike having it on the left hand side 11:11:48 Henry: What I would like is $in => source@xslt 11:12:51 Henry: [$in,$style]=>[source,stylesheet]@xslt 11:15:23 Alex: discussing output binding 11:16:10 Norm: if we chain xslt to something else ... 11:16:25 Alex: we are talking about >> 11:17:44 Output bindings may be defined at the end of a step chain with the ">>" operator. 11:19:25 Henry: You can dump an output into a variable and then stuff that variable into any number of inputs 11:20:06 Henry: but... are things more symmetrical if you have a document or a seq of docs, dumped into a var ... you may stuff them into an input 11:20:57 Alex: you use the append operator and bind the output to a var 11:21:20 we use >> to mean 'append' 11:21:30 https://github.com/xproc/notes/issues/5 11:28:32 jfuller: brings up the issue of default context 11:28:44 jfuller: we are going to have problem with $1 in xpath 11:29:23 Liam: version could be distracting 11:29:59 jfuller: As long as we can explain it then I think we are ok 11:30:26 [$source,$manifest] → { … } 11:30:37 Henry: add an example source frag 11:32:03 Henry: if we were embedding in python it would be easier 11:32:12 (in response to block expr) 11:33:37 Henry: Overloading of square bracket is an issue 11:35:04 Henry likes Norm's musing, so moves it to the record: [$source,$manifest] -> [source,manifest]{ if ($source/*/@version) ... } 11:35:50 Alex: we left off append operators 11:36:14 jfuller: Do we need to illustrate options now ? 11:36:25 s/append operators/append operators in the early discussion of step chains on purpose./ 11:36:44 Henry: Its about the flow stupid ... 11:37:32 Liam: I do not like the unnamed inputbinding form 11:37:53 ["document.xml","style.xsl"] => xslt() 11:37:55 s/=>/->/ 11:38:28 Norm: They will be all the same in xproc 11:39:47 So why aren't we just using python syntax: 11:39:53 Norm: In the middle of a chain you have to name them all 11:40:10 -> xslt(source=$1, stylesheet="style.xsl") 11:40:16 s/have to name them all/have to use the anonymous forms/ 11:40:59 Henry: why not allow pythonic approach 11:41:33 Alex: Norm has a solution to this .... 11:42:37 ... -> [$source,$secondary]@xslt(...) 11:43:45 Oops. ... -> [source,secondary]@xslt(...) 11:44:12 Henry: Why are we making a distinction ? 11:44:22 Liam: Can you write a function that returns a step ? 11:44:48 Henry: The last point I made on the whiteboard was about 'reflection' 11:45:47 discussion about dynamically creating steps 11:47:52 Liam: I think I understand the last example before Inputs section 11:49:17 Liam: Its really hard to handle messages from XSLT 11:50:16 Norm: in xproc vnext we might define a new output port fot xslt messages 11:51:03 Liam: Its unclear 11:51:32 Norm: We don't have many steps that have two outputs which in the general case feed into steps with two inputs 12:39:29 alexmilowski has joined #xproc 12:45:21 jfuller has joined #xproc 12:59:03 picking up where we left off at Inputs 12:59:23 Alex: We build up what a port is bound too 13:00:33 Jim: new issues are at 13:00:34 https://github.com/xproc/notes/issues 13:00:39 jfuller: older issues at 13:00:49 Jfuller: Norm helpfully elects to migrate them 13:01:28 Norm: for presentation - we know xinclude step does not take a sequence 13:01:38 Norm: Maybe think about automatically accept sequences 13:01:50 Norm: but that would be confusing for existing users 13:02:42 Alex: some feedback I got from a non xml person, suggested that we make our examples more neutral and less xml centric 13:03:32 Alex: We need to think about all other data formats 13:03:45 Jfuller: we already identified that right ? 13:05:25 jfuller: we should define minimal flow language, this just means we can push this out or in when we spec it out 13:05:54 Alex: same feeling about literals 13:06:18 Alex: obvious things that are missing are triples (json-ld, turtle?) 13:06:49 Alex: some things like SPARQL are easier 13:07:19 Norm: we are going to have to say something about extensibility of data model ... need to describe how AVT work 13:08:27 Norm: The only rational description of the data constructor is what is between the delimiters 13:08:45 Norm: and then you interpret that sequence as html, etc 13:08:56 Alex: we may want to go farther then that for other media types 13:10:14 Alex and Norm discuss the finer points of data constructor 13:13:07 Liam: what happens here if we do AVT inside data like json 13:13:14 https://github.com/xproc/notes/issues/11 13:13:16 Alex: the syntax here is incomplete 13:14:51 Alex: we need to carefully craft a story ... 13:16:51 Henry: we remove it for now, 13:16:54 Alex: we will skip it 13:17:50 Henry: Its not a USP of this proposal 13:17:56 Alex: we know we need literals 13:18:07 , we need to do AVT, etc 13:18:34 [ my quasiquoting proposal fro 2013 - https://lists.w3.org/Archives/Member/w3c-xsl-query/2013Nov/0017.html (there was also a version with user-specified delimiters, more like here-documents) ] 13:18:42 Norm: Take it out of the linear flow and put into appendix 13:18:44 s/fro /from / 13:19:48 jfuller: now onto output bindings 13:20:24 Alex: essentially 'where you are sending the output' 13:21:21 Alex: Using this generally to send things to output ports by reference 13:21:45 Alex: depends on how it is predeclared and I wonder how it will be received 13:22:20 Norm: I am ok with right hand usage (for now) 13:23:41 Alex: $included is effectively being declared, but it is implicit 13:23:44 Mmmm. ... >> [$out=result, $chunks=secondary] 13:24:19 jfuller: we are just giving a primary output a name 13:24:26 3 + 4 >> $sum7 13:25:17 Alex: it has nice semantics, in that you can build indendant flows 13:25:32 (like my previous 'meet' example) 13:25:53 Zakim has left #xproc 13:26:05 Zakim has joined #xproc 13:27:30 Alex: we know that ordering is an issue 13:28:05 jfuller: do we have sort ? 13:28:16 Norm: we have an RFP for p:sort 13:29:16 Henry: Sorting is useful and we should cater for the 80% case 13:30:30 Alex: step declarations are rough at the moment 13:32:10 $in → [source]{ if ($source/*/@version eq "v1.0") 13:32:10 then [$source,"crummy.xsl"] → xslt() ≫ @1 13:32:10 else [$source,"better.xsl"] → xslt() ≫ @1 } 13:32:10 ≫ $out 13:32:35 https://github.com/xproc/notes/blob/master/dataflows/examples/database-import.xpl 13:33:55 now discussing block expressions 13:38:18 Henry: At the flow level we have variables 13:41:02 jfuller: was if then intentional vs if then else 13:41:06 Alex: it was intentional 13:41:47 Liam: then there is ambiguity 13:42:36 Liam reminds us of the dangling else problem 13:43:09 Norm: we can have a step that produces nothing ... we can finesse it if we need too 13:44:22 Alex: We need conditionals 13:44:41 Alex: We already variables do we need let binding ? 13:45:44 Alex: Projects can be a step 13:45:53 Norm: I think its an antipattern 13:46:23 Norm: We should have a step for each kind 13:46:56 Alex: projections is a nice to have 13:47:18 Alex: iteration is a necessary piece 13:47:28 Alex: replacement is a nice to have 13:48:41 Norm: I think we need viewport 13:49:17 Alex: Do folks use this ? 13:49:27 Norm: I absolutely use it 13:50:23 Alex: tee is neat probably a nice to have 13:52:39 jfuller: raises implicit iteration 13:53:23 Liam: is there order implied ? 13:53:36 Norm: it is a mapping operator 13:53:55 Henry: It must output them in that order 13:54:19 Liam: the term iteration implies ordering 13:55:11 Henry: do we answer this question in xproc v1 13:55:28 Norm: We probably do, but we wanted to allow parallism 13:56:02 Henry: xproc v1, it says 'each document in turn' 13:57:40 |- 13:57:44 -| 13:57:57 Alex points some meta thoughts for lang design 13:59:28 Murray: I do not quite understand the Tee example 13:59:37 $in -> xinclude() >> $temp 13:59:37 $temp -> "included.xml" 13:59:37 [$temp,"stylesheet.xsl"] -> xslt() 13:59:38 >> $out 13:59:39 Alex attempts to explain 14:00:28 $temp >> "included.xml" 14:00:57 $in -> xinclude() >> $temp 14:00:58 $temp >> "included.xml" 14:00:58 [$temp,"stylesheet.xsl"] -> xslt() 14:00:58 >> $out 14:02:52 Murray: you can use Tee as a manifold 14:05:04 Henry: Murray is right 14:05:12 jfuller: Murray's arguments convince me 14:05:28 Norm: I think we should remove it 14:06:49 Alex: If you have a problem with that then we have a problem with iteration 14:07:20 Alex: They are all operators 14:08:38 ("x1.xml","x2.xml") { | xinclude() } 14:09:00 Henry: If I could do that, then I would be happy 14:09:51 ("x1.xml", "x2.xml") -> { foreach xinclude() } 14:10:22 [$in,”chop.xq”] → xquery() ! { [$1,”chunk.xsl”] → xslt() → @1 } → $out 14:11:55 [$in,”chop.xq”] → xquery() ! { [$1,”chunk.xsl”] → xslt() >> @1 } >> $out 14:12:31 [$in,”chop.xq”] → xquery() → { foreach [$1,”chunk.xsl”] → xslt() >> @1 } >> $out 14:14:39 [$in,”chop.xq”] → xquery() ! xinclude() ≫ $out 14:17:40 [$in,”chop.xq”] → xquery() → { if ($1) then $1 → xslt() >> @1 else () } >> $out 14:22:09 Alex: block expressions nest 14:22:19 Norm: curly brackets ought to be lexically scoped 14:23:00 moving on 14:23:11 Alex: we need a way to name flows, reuse htem 14:23:16 s/htem/them/ 14:23:58 Henry: Literal strings as inputs or outputs translates to GET/PUT what about string variable references 14:25:01 Alex: You can call your xproc with an option 14:25:23 Norm: externally bound yes, but what about when I want to choose 14:27:19 Henry: Norm is solving a simpler problem 14:27:22 Alex: use let 14:28:05 xs:int($1/*/@version) >> $version 14:28:06 Alex and Henry discussing let 14:29:50 let $imode := "string" "doc.xml" -> xslt(initial-mode=$imode) 14:30:31 () -> { let $imode := "string" "doc.xml" -> xslt(initial-mode=$imode) } 14:31:15 () -> { let $imode := "string" { "doc.xml" -> xslt(initial-mode=$imode) } | 14:31:56