09:46:26 RRSAgent has joined #xproc 09:46:26 logging to http://www.w3.org/2016/02/11-xproc-irc 09:47:09 someone thought that the order of arguments was still significant in the XSLT binding example with explicit names. 09:49:12 q. about $in -> xinclde() -> [...] -> xslt(), is the [...] itself a step? 10:01:04 nick - does this mean you no longer to delare whether something is a sequence? GOOD! 10:11:54 Weill we include try/catch? - yes 10:13:36 q. about dynamic evaluation (yes but not yet sure how) 10:14:14 q: under Projections, what is the result? 11:05:59 scribenick: liam 11:06:03 scribe: liam 11:06:45 alexmilowski has joined #xproc 11:06:54 [unknown person] from Czech bank, using IBM integration bus/server, not XProc. but it may do something XProc can do 11:07:01 not only with XSLT, also SQL etc 11:07:16 jfuller: who is authoring the components? 11:07:51 [unknown person]: we have a department of about 15 people making the pipelines. 11:08:19 jfuller: anything XProc must do, for you to use it? 11:09:23 [unknown person]: handling of input/output of different types, e.g. based on http response, it's about interaction with another environment. We have not only XML, but also text, [csv, etc] 11:09:50 ... also timer, scheduler, and parallel as well as serial processing. 11:10:20 [produces diagram] 11:11:21 and can't do http response 11:11:26 or control http headers 11:12:43 We use XSLT and the IBM GUI for the integration bus, which outputs XML 11:13:24 s/[unknown person]/Stefan Ryba'r/g 11:14:21 yyy: we developed our own language to define sequential workflows, with data adapters, and use XSLT for data manipulation 11:14:43 Our customers made a lot of applications which are basically declaratively made, there's a model, no code 11:15:18 So I was wondering, we didn't use XProc before ,just XSLT, if it'd be possible to convert our flows that we have defined, to XProc, and see if it matches, and learn where are the gaps 11:15:32 [yyy is in Czech Republic] 11:16:46 jfuller: right now we use make, ant etc., to control the execution, so XProc lets XSLT be good at what it's for, and manages the execution 11:17:01 yyy: that's what we did ourselves. 11:17:34 ht: also, e.g. renaming an attribute, lighter weight in XProc than in XSLT 11:18:02 jfuller: anyone using publishing? 11:18:19 [yes] 11:18:59 Gerrit Imsieke: I'm managing director for a 110-person company in Leibzig, possibly the largest user of XProc in the world, 11:19:19 ...e.g. we make IBMHELP from XML, we convert european standards, all with XProc pipelines 11:19:47 We also ingest HTML 5 and jSON files describing a book structure, so we are also using some of the "fringe" (not the main) use cases 11:20:13 we;ve also got some extention steps for calabash for image processing; recently we implemented a custom spell checker. 11:20:25 Solid 7-figure revenue based on XProc 11:21:39 I'm going to make a github project for converting to [scribe missed; various XML formats, possibly DOCX and JATS for pubMed] 11:22:12 jfuller: do your clients see xproc or is that hidden away? 11:22:30 Gerrit: no, people from outside just file bugs but don't necessarily know the bugs are related to XProc pipelines 11:22:38 most customers don't know we're using xproc. 11:24:05 jfuller: [asks if we need zip-like packaging?] 11:24:36 Gerrit: we're trying to convert binary stuff to xml representations, e.g. image resolution, and data URI schemes. 11:25:39 Ari: I've been using XProc for years, in publisher systems, using XForms to make a UI to create a custom pipeline 11:26:44 Norm created some extensions for me and I was surprised they weren't in the spec before, have to wait for the user input... 11:27:01 Second thing was how to group resources used by XProc 11:27:48 and to do versioning [of a pipeline with the resources it uses] 11:29:53 yyy: I have an input, e.g. list of invoices, on each piece of the doc run a separate flow 11:30:45 ht: this is no longer a simple, linear example, so it's exactly the sort of use case we need. 11:32:06 Nic Gibson: threading documents through a sequence of transformations, i think the new syntax will do that easily. 11:32:35 Another is processing all files in the directory, so something like Saxon's collection("*.xml") would be very useful. 11:33:40 Alex: we'd also like to support processing strings, so when is it a string literal and when a URI? So we have work to do. 11:34:00 Nic: I also use Norm's extension to let variables be any XDM type, not just a string. 11:34:06 Alex: that's a requirement for 2.0, yes. 11:36:23 Emil Siegel: I use XProc with publishers [in Germany?], thousands of input documents, thousands ofoutput documents, some in zip files, with relationships beteen them. 11:36:34 1. I need to work with zip files 11:36:50 jfuller: yes, that's part of our v2 requirements 11:38:38 Emil: 2nd, gigabytes of XML (Calabash does fine) but I think that's the implementation 11:39:03 ht: [we need to] make sure the spec leaves space for streaming. 11:40:31 Emil: 3, formatting with XSL-FO, which we do in 1.0; 11:40:45 4, support for binary files; right now all we do is copy them. 11:41:15 zzz: may want to be able to declare whether a step can stream 11:42:20 Alex: annotations maybe 11:43:12 liam: whether xslt 3 is streamable depends on the stylesheet as well as the implementation, may not be known statically. 11:44:09 aaa: we work with collections of documents in XProc 1, represented as a single XML document, so ability to associate metadata with docs, and to run xpath more easily on the output 11:44:30 I'm not tied to the XML syntax. Prefer programming in terser syntax, so I welcome the new syntax. 11:44:46 Can we model the [graph] as an API so we can program directly in another language? 11:46:24 [Henry talks about multiple threading and deadlock issues] 11:47:25 Oh, that xproc basement… 11:47:28 aaa: we have multiple people writing pipelines 11:47:52 For the ccore XProc devs we have, they just have to use it, but it's a headache to learn for newcomers 11:48:04 That's not specific to v1, more to the dataflow aspects 11:48:27 Also hard was all the implicits from v1, and the errors you got e.g. if something wasn't connected 11:49:44 bbb: we have use case to provide documentation for customers, so we developed XProc pipeline that iterates over files in a project 11:49:56 We can use inline HTML, and make nice docs 11:50:06 This automatic processing of XML files is really good for us. 11:51:06 [long story about difficulty with errors] 11:51:56 The new syntax is very clean and smart, I think I would like it, but we also need to generate & analyze the pipelines [e.g. with XSLT] 11:52:40 Requirment we just heard: Still want to use XML toolchain for XProc 11:53:08 ... We use XML templating to help author XProc pipelines 11:53:52 Alex: I use XProc to run my Web site 11:54:48 [shows example for filtering weather reports] 11:59:51 ccc: my customers want their angle brackets and don't want to do any "programming" so this won't fly to me 11:59:57 they are XSLT people. 12:00:14 they don't do XQuery. 12:00:49 My people use my XProc templates. Users can modify the pipelines. They love it. 12:01:22 Standard problem is error messages, implementations give incomprehensible messages. 12:03:40 [discussion of resource problem in the WG] 12:04:59 ddd: we are using 1,300 XPRoc pipelines [???]; I can't imagine maintaining this text format, because from time to time we need to refactor 12:05:29 We use XSLT and/or regular expressions, and it ws quite easy for us to use XPath to make these changes 12:05:57 We can verify using some validation, too. 12:06:39 This looks fast to write, easy to read, easy to do everything, but if you have a very large number of flows, and very deep subflows, may be hard to maintain. 12:07:06 Also, if the people will always write this by hand or if there will be some toolkit for eclipse (say) to generate the XProc code 12:07:31 and then maybe generate an XML format 12:07:43 ht: We gave people XML, people wrote toolchains to exploit that, we have to hear that. 12:12:22 ddd: So I have the option of using Scala to build pipelines. If I have lots of frameworks in Scala for processing XML in Scala why use XProc? 12:12:55 Alex: there's a whole bunch of APIs, and as a programmer you cobble things together , but it's low level, and yuo need a certain set of skills 12:13:08 Those are compile target for an impl'n of XProc 12:13:38 In XProc 1 we focussed on steps, but it's the flows that are important. 12:15:13 Horst: nature of XML syntax allows for things that compact syntax doesn't; could look at relaxng for inspiration. 12:15:27 I like the high level operators that you add. 12:16:39 alexmilowski has joined #xproc 12:17:11 Liam Quin is up now. 12:17:51 (XProc’s W3C staff member) 12:18:28 Need more resources … going to take several years to get to anything 12:18:34 First way: join the working group 12:19:09 in order to join you either work for a member organization 12:19:18 …funded by membership fees… 12:19:50 Individual may be involved by being an Invited Expert 12:21:41 Another way: Comment via the issues list… 12:22:10 Yet another way: a community group 12:22:34 The big red button: should we consider renaming XProc? 12:25:58 12+ people are interested in a community group. 12:26:10 We will create a community group and 5 people need to join to get it started. 12:26:33 [no-one objected to a different X-less name] 12:27:17 We should use a symbol like Prince. The spec formerly known as XProc 12:30:51 alexmilowski has joined #xproc 13:27:20 jfuller has joined #xproc 13:40:21 ht has joined #xproc 13:40:49 People I was speaking to afterwards were using 'dataproc' 14:20:53 alexmilowski has joined #xproc 14:57:50 give me a shout when we can webex/hangout 15:34:54 alexmilowski has joined #xproc 16:32:47 alexmilowski has joined #xproc 16:46:38 jfuller has joined #xproc 17:04:23 ht has joined #xproc 17:53:13 liam has joined #xproc