W3C home > Mailing lists > Public > xproc-dev@w3.org > May 2009

Thoughts on cx:zip

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 26 May 2009 12:36:01 GMT