- From: Zearin (Tony) <zearin@gonk.net>
- Date: Mon, 17 Feb 2014 10:30:36 -0500
- To: XProc Dev <xproc-dev@w3.org>
On Feb 17, 2014, at 8:40 AM, James Fuller <jim@webcomposite.com> wrote: > I) People know and love pipelines and have a set of preconceptions 'in > wetware', before they come to XProc, about how pipelines should work. > > II) XProc balances off many engineering choices to handle the vagaries > of managing pipelines big and small; its not trivial dealing with > pipelines that go beyond simple 'piping output from input' between > steps. # Let’s learn from mistakes. IMO, together these statements highlight one of the **greatest** mistakes XProc ever made. ## Regarding I XProc promises "pipelines". People know and love "pipelines". It is reasonable, therefore, for people to assume that their existing skills with pipelines will be portable to XProc--at least in some appreciable way. That is not the case. ## Regarding II I think it was a mistake for XProc v1 to attempt anything beyond “simple 'piping output from input'“ pipelines. UNIX-based tools are nothing more than this, and people are still using them 30+ years after the fact. By taking on the task of managing more complex pipelines, XProc damned itself to a hell of complexity: complexity for the implementors, and complexity for the users. That could have all been avoided if XProc v1 stuck with simple pipelines instead. At the very LEAST, the spec authors could have reserved the more complex pipelines for v2. Starting with a simpler design and *iterating* towards more complex processing is better for everyone--implementors and users. XSLT followed this path. It began with a smaller, simpler toolset for authors to work with. As a result, *valuable information* was learned about the future direction that XSLT needed to go. And the following versions were significant improvements. # XProc v.next Whatever the next version of XProc is, I believe it should: * focus on **removing complexity** * make it easier (as much as possible!) for users to leverage existing familiarity with "pipelines" * don't try to solve everything at once; it’s perfectly acceptable (and sometimes, wise) to leave truly perplexing problems for the v.next specification
Received on Monday, 17 February 2014 15:31:07 UTC