- From: Norman Walsh <ndw@nwalsh.com>
- Date: Tue, 26 May 2009 08:35:16 -0400
- To: XProc Dev <xproc-dev@w3.org>
- Message-ID: <m2hbz86nzv.fsf@nwalsh.com>
I've been working on a cx:zip step. <p:declare-step type="cx:zip"> <p:input port="source" sequence="true" primary="true"/> <p:input port="manifest"/> <p:output port="result"/> <p:option name="href" required="true" cx:type="xsd:anyURI"/> <p:option name="compression-method" cx:type="stored|deflated"/> <p:option name="compression-level" cx:type="smallest|fastest|default|huffman|none"/> <p:option name="command" select="'update'" cx:type="update|freshen|create|delete"/> <p:option name="byte-order-mark" cx:type="xsd:boolean"/> <p:option name="cdata-section-elements" select="''" cx:type="ListOfQNames"/> <p:option name="doctype-public" cx:type="xsd:string"/> <p:option name="doctype-system" cx:type="xsd:anyURI"/> <p:option name="encoding" cx:type="xsd:string"/> <p:option name="escape-uri-attributes" select="'false'" cx:type="xsd:boolean"/> <p:option name="include-content-type" select="'true'" cx:type="xsd:boolean"/> <p:option name="indent" select="'false'" cx:type="xsd:boolean"/> <p:option name="media-type" cx:type="xsd:string"/> <p:option name="method" select="'xml'" cx:type="xsd:QName"/> <p:option name="normalization-form" select="'none'" cx:type="NormalizationForm"/> <p:option name="omit-xml-declaration" select="'true'" cx:type="xsd:boolean"/> <p:option name="standalone" select="'omit'" cx:type="true|false|omit"/> <p:option name="undeclare-prefixes" cx:type="xsd:boolean"/> <p:option name="version" select="'1.0'" cx:type="xsd:string"/> </p:declare-step> Here's how it might be used: <cx:zip href="/tmp/myzip.zip" command="update"> <p:input port="source"> <p:inline xml:base="pipe.xpl"> <doc/> </p:inline> </p:input> <p:input port="manifest"> <p:inline> <c:zip-manifest> <c:entry name="new.xpl" href="pipe.xpl" comment="Hi mom" compression-method="stored" compression-level="default"/> <c:entry name="new.xpl" href="h6.xml" compression-method="deflated" compression-level="smallest"/> </c:zip-manifest> </p:inline> </p:input> </cx:zip> The idea is that the manifest says what to do. The step takes the documents identified by the @href's in the manifest and puts them in the zip file with the names specified by the @name's. If one of the source documents has the same base URI as one of the @href's, then that document gets serialized and stored in the zip. Otherwise, the specified @href gets read and stored. For 'create', the zip file is replaced by the new contents. For 'update' and 'freshen', entries in the zip file not mentioned in the manifest are left unchanged. For 'freshen', the entry in the zip file is replaced only if the entry in the manifest is newer (or if the entry will come from the source port, which is always assumed to be newer). For 'delete' the source port is ignored and matching entries are simply deleted from the zip file. I'm sure there are still a bunch of edge cases I haven't considered. I did try to make the manifest accept a the output of cx:unzip and p:directory-list, but I found the semantics of zip @name values, document @href values, and the documents on the source port too problematic. I figure we can provide steps to turn those documents in to c:zip-manifest's instead. Be seeing you, norm -- Norman Walsh <ndw@nwalsh.com> | Never contend with a man who has http://nwalsh.com/ | nothing to lose.-- Gracián
Received on Tuesday, 26 May 2009 12:36:00 UTC