p:archive-manifest (3.1) 

Overriding content-types

One of the things the p:archive-manifest step does is determining the content-type (MIME type) of the archive entries. This is usually done based on the filename/extension. It is recorded in the manifest c:entry/@content-type attribute.

Sometimes it is useful to override this mechanism and assign specific content-types to some of the entries. For instance, the files Microsoft Office produces (.docx, .xlsx, etc.) are archives with a lot of XML documents inside. Some of these documents have the extension .rels and would therefore not be recognized as XML documents. The override-content-types option makes it possible to adjust this behavior.

The value of the override-content-types option must be an array of arrays. The inner arrays must have exactly two members:

• The first member must be an XPath regular expression.

• The second member must be a valid a MIME content-type.

Determining an archive entry’s content-type is now as follows:

• The inner arrays of the override-content-types option value are processed in order of appearance (so order is significant).

• The XPath regular expression (in the first member of the inner array) is matched against the full path of an entry in the archive (as in matches($path-in-archive, $regular-expression)).

• If a match is found, the content-type (the second member of the inner array) is used as the entry’s content-type.

• If no match was found for all the inner arrays, the normal mechanism for determining the content-type is used.

For example: setting the override-content-types option to [ ['.rels$', 'application/xml'], ['^special/', 'application/octet-stream'] ] means that all files ending with .rels will get the content-type application/xml. All files in the archive’s special directory (including sub-directories) will get the content-type application/octet-stream. See also the Overriding content types example.

Basic usage

Assume we have a simple ZIP archive with two entries:

• An XML file in the root called reference.xml

• An image in an images/ sub-directory called logo.png.

The following pipeline creates an archive manifest for this ZIP file:

<p:declare-step xmlns:p="http://www.w3.org/ns/xproc" version="3.0">

  <p:input port="source"/>
  <p:output port="result"/>

  <p:archive-manifest/>

</p:declare-step>

Resulting archive manifest:

<c:archive xmlns:c="http://www.w3.org/ns/xproc-step">
   <c:entry name="images/logo.png"
            content-type="image/png"
            href="file:/…/…/test.zip/images/logo.png"
            method="deflated"
            size="86656"
            compressed-size="85694"
            time="2024-07-04T11:12:22.4+02:00"/>
   <c:entry name="reference.xml"
            content-type="application/xml"
            href="file:/…/…/test.zip/reference.xml"
            method="deflated"
            size="78"
            compressed-size="77"
            time="2024-07-09T19:58:50.75+02:00"/>
</c:archive>

As you can see, the XProc processor I’m using to process this example (MorganaXProc-III) adds a few extra attributes to the <c:entry> elements: size, compressed-size and time.

Also note the contents of the c:entry/@href attributes: they are a combination of the full path/filename of the archive and the path of the entry within the archive (as in the c:entry/@name attribute). The c:entry/@href attribute plays an important role when creating archives using p:archive.

Overriding content types

This example uses the same ZIP archive as in Basic usage. The following pipeline explicitly sets the content type for .png files to application/octet-stream:

Pipeline document:

<p:declare-step xmlns:p="http://www.w3.org/ns/xproc" version="3.0">

  <p:input port="source"/>
  <p:output port="result"/>

  <p:archive-manifest>
    <p:with-option name="override-content-types" select="[ ['\.png$', 'application/octet-stream'] ]"/>
  </p:archive-manifest>

</p:declare-step>

Resulting archive manifest:

<c:archive xmlns:c="http://www.w3.org/ns/xproc-step">
   <c:entry name="images/logo.png"
            content-type="application/octet-stream"
            href="file:/…/…/test.zip/images/logo.png"
            method="deflated"
            size="86656"
            compressed-size="85694"
            time="2024-07-04T11:12:22.4+02:00"/>
   <c:entry name="reference.xml"
            content-type="application/xml"
            href="file:/…/…/test.zip/reference.xml"
            method="deflated"
            size="78"
            compressed-size="77"
            time="2024-07-09T19:58:50.75+02:00"/>
</c:archive>

Using the relative-to option

This example uses the same ZIP archive as in Basic usage. It sets the relative-to to file:///test/. This is reflected in the c:entry/@href attributes:

Pipeline document:

<p:declare-step xmlns:p="http://www.w3.org/ns/xproc" version="3.0">

  <p:input port="source"/>
  <p:output port="result"/>

  <p:archive-manifest relative-to="file:///test/">
  
  </p:archive-manifest>

</p:declare-step>

Resulting archive manifest:

<c:archive xmlns:c="http://www.w3.org/ns/xproc-step">
   <c:entry name="images/logo.png"
            content-type="image/png"
            href="file:///test/images/logo.png"
            method="deflated"
            size="86656"
            compressed-size="85694"
            time="2024-07-04T11:12:22.4+02:00"/>
   <c:entry name="reference.xml"
            content-type="application/xml"
            href="file:///test/reference.xml"
            method="deflated"
            size="78"
            compressed-size="77"
            time="2024-07-09T19:58:50.75+02:00"/>
</c:archive>