<?xml version="1.0" encoding="UTF-8"?>
<essay xml:lang="en" version="5.0" xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:dcterms="http://purl.org/dc/terms/" xmlns:gal="http://norman.walsh.name/rdf/gallery#" xmlns:foaf="http://xmlns.com/foaf/0.1/">
<info>
    
    
    
    
    
    
    
    
    
    
    
<title>Perhaps the penultimate XProc draft</title><biblioid class="uri">http://norman.walsh.name/2009/05/28/xproc</biblioid>
<volumenum>12</volumenum>
<issuenum>18</issuenum>
<pubdate>2009-05-28T12:44:39-04:00</pubdate>
<author>
      <personname>
<firstname>Norman</firstname>
	<surname>Walsh</surname>
</personname>
    </author>
<copyright>
      <year>2009</year>
      <holder>Norman Walsh</holder>
    </copyright>
<abstract>
<para>Today, the XML Processing Model Working Group published a new
working draft. Not the very last working draft, but possibly very close.</para>
</abstract>
<dc:subject rdf:resource="http://norman.walsh.name/knows/taxonomy#W3C"/>
<dc:subject rdf:resource="http://norman.walsh.name/knows/taxonomy#XML"/>
<dc:subject rdf:resource="http://norman.walsh.name/knows/taxonomy#XProc"/>
</info>

<para xml:id="p1">For the past few months, the
<link xlink:href="http://www.w3.org/XML/Processing/">XML Processing Model
Working Group</link> has been busily resolving 
<link xlink:href="http://www.w3.org/XML/XProc/2008/11/cr-comments/">issues</link>
raised during the
<link xlink:href="http://www.w3.org/2005/10/Process-20051014/tr.html#cfi">CR</link>.
So busy with <wikipedia page="XML_pipeline">XProc</wikipedia>, in fact,
that we forgot about our
<link xlink:href="http://www.w3.org/2005/10/Process-20051014/groups.html#three-month-rule">heartbeat requirement</link>.</para>

<para xml:id="p2">Today, we published
<link xlink:href="http://www.w3.org/TR/2009/CR-xproc-20090528/">a new
working draft</link> of
<citetitle xlink:href="http://www.w3.org/TR/xproc/">XProc: An XML Pipeline
Language</citetitle>.
In addition to editorial improvements and clarifications,
this draft contains a small number of significant changes:</para>

<orderedlist>
  <listitem>
    <para xml:id="p3">Changed <tag>p:choose</tag> and <tag>p:try</tag>. An output
    port produces a sequence if that port produces a sequence in any
    subpipeline.</para>
  </listitem>
  <listitem>
    <para xml:id="p4">Changed <tag>p:error</tag>. Added primary output port
    <literal>result</literal>.
    </para>
  </listitem>
</orderedlist>

<para xml:id="p5">Taken together, these two changes make it much easier for pipeline
authors to write <tag>p:choose</tag> steps where one of the branches
uses a <tag>p:error</tag>.</para>

<orderedlist continuation="continues">
  <listitem>
    <para xml:id="p6">Changed <tag>p:exec</tag>. Added
    <option>arg-separator</option>, <option>path-separator</option>,
    and <option>failure-threshold</option>. Input can be zero or one
    document only. Added support for a result code.
    </para>
  </listitem>
</orderedlist>

<para xml:id="p7">Implementor experience revealed that our design for <tag>p:exec</tag>
was insufficient. These changes fix problems with platform-specific 
path separators and dealing with arguments that contain spaces.
</para>

<orderedlist continuation="continues">
  <listitem>
    <para xml:id="p8">Clarified <tag>p:http-request</tag>. Interaction with HTTP
    redirects and cookies is now explicit; the interaction of media
    types and serialization, several aspects of multipart messages,
    and a number of other areas have been clarified as well.</para>
  </listitem>
</orderedlist>

<para xml:id="p9">The <tag>p:http-request</tag> step was the subject of
<emphasis>a lot</emphasis> of discussion. We made quite a few changes,
almost exclusively clarifications.</para>

<orderedlist continuation="continues">
  <listitem>
    <para xml:id="p10">Clarified the interpretation of base URIs and the <tag class="attribute">xml:base</tag> attribute.</para>
  </listitem>
</orderedlist>

<para xml:id="p11">This last change clarifies that the inherent base URI of a node
can exist independent of an <tag class="attribute">xml:base</tag> attribute.
In particular, removing the <tag class="attribute">xml:base</tag> attribute
does not change the inherent base URI. (Though adding one does change the
base URI, of course, so perhaps “independent” wasn't exactly the right
word.)</para>

<section xml:id="almost">
<title>We're almost done</title>

<para xml:id="p12">The bottom line is that we really are almost finished. The test suite
still needs to be fleshed out, and our implementors need to get to complete
coverage, but I think that language evolution is coming to an end.</para>

<para xml:id="p13">Ironically, in the time between requesting publication of
today's draft and today, the WG identified and corrected <emphasis>one
more</emphasis> issue. We added a
<function>p:value-available()</function> function to allow pipeline
authors to identify options that have no specified value.</para>

<para xml:id="p14">Clearly, we can't absolutely promise nothing else will change, but
the chair is setting the bar pretty high.</para>
</section>
</essay>

