http://norman.walsh.name/2009/12/28/xproc-lc 12 43 2009-12-28T09:20:52-05:00 Norman Walsh 2009 Norman Walsh Early in January, a new XProc draft will appear. It will be a Last Call Working Draft, a step backwards in the process, or maybe just a half-step. The reason is important though: versioning. The XProc WG has been making steady progress on XProc: An XML Pipeline Language. We saw the start of wide adoption of XProc in 2009 and I think there's every reason to expect more of the same in 2010. This makes it all the more disappointing to report that we're going back to Last Call. On a personal note, as a TAG alum, it's a bit embarrassing to admit why: versioning. We received significant and persuasive criticism of our versioning story. In particular, we were pesuaded that requiring a processor to download the declarations for V.next steps in order to process them in a “forwards compatible” manner was too burdensome. In redrafting the story, we added a version attribute, “compile-time” use-when functionality à la XSLT, and extension functions for more precisely identifying the environment in which the pipeline is running. We also took the opportunity to fix decisions that were, in retrospect, mistakes, but not in-and-of themselves sufficient to motivate us to return to last call: we changed the rules for connections in option, parameter, and variable bindings so that an explicit p:empty isn't required when there's no default readable port, and we changed the rules for parameter input ports so that a binding isn't required when there's at least one explicit p:with-param. Users are already thanking us. I didn't get the document through the publication process before the end-of-year publishing moratorium, but you can read the staged draft, if you wish. Will this really be our last Last Call? I sincerely hope so! I also hope that we can move directly from Last Call to Proposed Recommendation without the formality of another Candidate Recommendation phase in between. There's precedent for doing this, and we've got active implementors. I'm sometimes frustrated by how long the process takes, but I console myself with the observation that the language is better for our efforts. Rising usage suggests the early adopters, at least, agree with us.