10 134 2007-11-29T13:30:47-05:00 $Date$ NormanWalsh 2007Norman Walsh The XML Processing Model Working Group has published a new Working Draft of XProc: An XML Pipeline Language. I was pretty confident that XProc: An XML Pipeline Language would get through the process with a single Last Call. Confidence misplaced, as it turns out. The working group has not yet finished its review of all the comments received, but has already been persuaded to make a number of changes. A few of them are significant enough that a new last call will be necessary. Having concluded that a second last call will be necessary, we decided to immediately publish a new working draft which exposes the big changes (and, incidentally, a few smaller ones that had also been implemented). The changes in the XProc working draft published today are: Attempt to support both XPath 1.0 or XPath 2.0 as the expression language. Support both XSLT 1.0 and XSLT 2.0 in a single p:xslt step. Removed implicit pipeline inputs and outputs. Attempt to support default bindings on p:input. Added a Security Considerations section. Added a p:language system property. Added p:hash, p:uuid, p:www-form-urldecode, and p:www-form-urlencode. Added fixup-xml-base and fixup-xml-lang options to p:xinclude. Renamed c:http-request to c:request and c:http-response to c:response. The first two are the big ones. Where we used to say that all of the XPath expressions in the XProc language were XPath 1.0 expressions, we now give pipeline authors and implementors the freedom to use either XPath 1.0 or XPath 2.0. Yes, this introduces some possible interoperability issues. But, yes, it's also more forward looking. The decision to wrap both versions of XSLT up into a single step makes the signature for the step a little odd in the XSLT 1.0 case, but workable. Pipeline authors can choose the version they want, implementors can choose the version automagically if authors don't. Implicit pipeline inputs and outputs were designed to make very simple, straight through pipelines as short as possible (syntactically). But they added significant complexity to the analysis of pipelines that call pipelines. So now we require all the inputs and outputs of a p:pipeline to be explicit. The rest of the items probably wouldn't have driven us back to last call. Read and review! Comments on these items, in particular, please.