someone thought that the order of arguments was still significant in the XSLT binding example with explicit names.

q. about $in -> xinclde() -> [...] -> xslt(), is the [...] itself a step?

nick - does this mean you no longer to delare whether something is a sequence? GOOD!

Weill we include try/catch? - yes

q. about dynamic evaluation (yes but not yet sure how)

q: under Projections, what is the result?

<scribe> scribenick: liam

<scribe> scribe: liam

Stefan Ryba'r from Czech bank, using IBM integration bus/server, not XProc. but it may do something XProc can do

not only with XSLT, also SQL etc

jfuller: who is authoring the components?

Stefan Ryba'r: we have a department of about 15 people making the pipelines.

jfuller: anything XProc must do, for you to use it?

Stefan Ryba'r: 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]

scribe: also timer, scheduler, and parallel as well as serial processing.

[produces diagram]

and can't do http response

or control http headers

We use XSLT and the IBM GUI for the integration bus, which outputs XML

yyy: we developed our own language to define sequential workflows, with data adapters, and use XSLT for data manipulation

Our customers made a lot of applications which are basically declaratively made, there's a model, no code

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

[yyy is in Czech Republic]

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

yyy: that's what we did ourselves.

ht: also, e.g. renaming an attribute, lighter weight in XProc than in XSLT

jfuller: anyone using publishing?

[yes]

Gerrit Imsieke: I'm managing director for a 110-person company in Leibzig, possibly the largest user of XProc in the world,

scribe: e.g. we make IBMHELP from XML, we convert european standards, all with XProc pipelines

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

we;ve also got some extention steps for calabash for image processing; recently we implemented a custom spell checker.

Solid 7-figure revenue based on XProc

I'm going to make a github project for converting to [scribe missed; various XML formats, possibly DOCX and JATS for pubMed]

jfuller: do your clients see xproc or is that hidden away?

Gerrit: no, people from outside just file bugs but don't necessarily know the bugs are related to XProc pipelines

most customers don't know we're using xproc.

jfuller: [asks if we need zip-like packaging?]

Gerrit: we're trying to convert binary stuff to xml representations, e.g. image resolution, and data URI schemes.

Ari: I've been using XProc for years, in publisher systems, using XForms to make a UI to create a custom pipeline

Norm created some extensions for me and I was surprised they weren't in the spec before, have to wait for the user input...

Second thing was how to group resources used by XProc

and to do versioning [of a pipeline with the resources it uses]

yyy: I have an input, e.g. list of invoices, on each piece of the doc run a separate flow

ht: this is no longer a simple, linear example, so it's exactly the sort of use case we need.

Nic Gibson: threading documents through a sequence of transformations, i think the new syntax will do that easily.

Another is processing all files in the directory, so something like Saxon's collection("*.xml") would be very useful.

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.

Nic: I also use Norm's extension to let variables be any XDM type, not just a string.

Alex: that's a requirement for 2.0, yes.

Emil Siegel: I use XProc with publishers [in Germany?], thousands of input documents, thousands ofoutput documents, some in zip files, with relationships beteen them.

1. I need to work with zip files

jfuller: yes, that's part of our v2 requirements

Emil: 2nd, gigabytes of XML (Calabash does fine) but I think that's the implementation

ht: [we need to] make sure the spec leaves space for streaming.

Emil: 3, formatting with XSL-FO, which we do in 1.0;

4, support for binary files; right now all we do is copy them.

zzz: may want to be able to declare whether a step can stream

Alex: annotations maybe

liam: whether xslt 3 is streamable depends on the stylesheet as well as the implementation, may not be known statically.

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

I'm not tied to the XML syntax. Prefer programming in terser syntax, so I welcome the new syntax.

Can we model the [graph] as an API so we can program directly in another language?

[Henry talks about multiple threading and deadlock issues]

<alexmilowski> Oh, that xproc basement…

aaa: we have multiple people writing pipelines

For the ccore XProc devs we have, they just have to use it, but it's a headache to learn for newcomers

That's not specific to v1, more to the dataflow aspects

Also hard was all the implicits from v1, and the errors you got e.g. if something wasn't connected

bbb: we have use case to provide documentation for customers, so we developed XProc pipeline that iterates over files in a project

We can use inline HTML, and make nice docs

This automatic processing of XML files is really good for us.

[long story about difficulty with errors]

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]

<ht_home> Requirment we just heard: Still want to use XML toolchain for XProc

<ht_home> ... We use XML templating to help author XProc pipelines

Alex: I use XProc to run my Web site

[shows example for filtering weather reports]

ccc: my customers want their angle brackets and don't want to do any "programming" so this won't fly to me

they are XSLT people.

they don't do XQuery.

My people use my XProc templates. Users can modify the pipelines. They love it.

Standard problem is error messages, implementations give incomprehensible messages.

[discussion of resource problem in the WG]

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

We use XSLT and/or regular expressions, and it ws quite easy for us to use XPath to make these changes

We can verify using some validation, too.

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.

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

and then maybe generate an XML format

ht: We gave people XML, people wrote toolchains to exploit that, we have to hear that.

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?

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

Those are compile target for an impl'n of XProc

In XProc 1 we focussed on steps, but it's the flows that are important.

Horst: nature of XML syntax allows for things that compact syntax doesn't; could look at relaxng for inspiration.

I like the high level operators that you add.

<alexmilowski> scribenick: alexmilowski

Liam Quin is up now.

(XProc’s W3C staff member)

Need more resources … going to take several years to get to anything

First way: join the working group

in order to join you either work for a member organization

…funded by membership fees…

Individual may be involved by being an Invited Expert

Another way: Comment via the issues list…

Yet another way: a community group

The big red button: should we consider renaming XProc?

12+ people are interested in a community group.

We will create a community group and 5 people need to join to get it started.

<liam> [no-one objected to a different X-less name]

We should use a symbol like Prince. The spec formerly known as XProc

<ht> People I was speaking to afterwards were using 'dataproc'

<jfuller> give me a shout when we can webex/hangout