About the HighWire Express Marker File (go.xml)

Contents

What is a "marker" file, and what is it for?
Documentation for marker.dtd
Sample Marker File for Single-issue Delivery
Sample Marker File for Multi-issue Delivery
Questions?

What is a "marker" file, and what is it for?

A HighWire Express "marker" file is a minimal XML file whose presence in a HighWire Express ftp directory triggers automated validation and processing of the journal content accompanying that file.

By convention (and system expectation), the name of the marker file is always go.xml.

The minimal information required to be in the marker file is:

  1. Metadata uniquely identifying the publication event(s).
  2. An indication of publication event "type", and
  3. (for multi-issue batches only) An indication of the format type.

In the case of issue and supplement submissions, the publication event metadata consists of sitecode, volume and issue designations; in the case of ahead-of-print submissions, sitecode and a unique batch id are expected.

For multi-issue batches, volume and issue information for each component issue is required, as well as a format designation that determines the mode of processing.

Optionally, the marker file may contain a HighWire Express userid. (Contact [email protected] with questions about HWX accounts.)

Documentation for marker.dtd (current version)

Element Description/Usage Notes
<HWExpress> Top-level parent element, required.

Available HWExpress type values are are follows:
  1. type="issue" -- for issues and supplements
  2. type="pap" -- for ahead-of-print batches

Available format values are are follows:

  1. type="hps1" -- for multi-issue content delivered in the arthw.dtd (deprecated)
  2. type="hps2" -- default
* Contact the HighWire Production staff for a list of presently supported DTDs.

<PEID> Publication Event ID; PEIDs are HWX-internal system designations, so while not expected or required in a go.xml file, a PEID may be included in lieu of site, volume, issue, and/or batchid designations, if the user has queried the system to discover the PEID of an established issue or batch.

(Check with your HighWire Production representative to see if this option is appropriate for your content.)

<site> The HighWire sitecode, a.k.a. "journal code".

(Check with your HighWire Production representative if you don't know the HighWire sitecode associated with the content you are responsible for.)

<volume> The volume designation for an issue or supplement batch.
For issue and multi-issue type publication events, the volume designation in the go.xml file should match the volume designation(s) in the XML or SGML files for the issue.

N.B. Volume designations should not contain leading zeroes, e.g.,
<volume>02</volume> (bad)
<volume>2</volume> (good)

<issue> The issue designation for an issue or supplement batch.
For issue and multi-type publication events, the issue designation in the go.xml file should match the issue designation(s) in the XML or SGML files for the issue.
<batchid> Arbitrary batch id string, used to identify PAP or CP batches which lack volume and issue designations.
N.B. The batchid string must not contain spaces or slashes.
<user> HighWire Express userid. Optional.

Sample Marker File for Single-issue Delivery

Here's an example of the marker file accompanying a single issue (32/3) for a single journal (sitecode "sppas"): 


<?xml version="1.0"?>
<!DOCTYPE HWExpress PUBLIC "-//HIGHWIRE//DTD HighWire Express Marker DTD v1.1.2HW//EN" "marker.dtd">
<HWExpress type="issue">
  <site>sppas</site>
  <volume>32</volume>
  <issue>3</issue>
</HWExpress>

Sample Marker File for Multi-issue Delivery

Here's an example of the marker file accompanying a multi-issue delivery (12 issues, volumes 14-16, four issues in each volume) of content for a single journal (sitecode "jognn"): 


<?xml version="1.0"?>
<!DOCTYPE HWExpress PUBLIC "-//HIGHWIRE//DTD HighWire Express Marker DTD v1.1.2HW//EN" "marker.dtd">
<HWExpress type="multiple" format="hps2">
	<multiple>
		<site>jognn</site>

		<volume>14</volume><issue>1</issue>
		<volume>14</volume><issue>2</issue>
		<volume>14</volume><issue>3</issue>
		<volume>14</volume><issue>4</issue>

		<volume>15</volume><issue>1</issue>
		<volume>15</volume><issue>2</issue>
		<volume>15</volume><issue>3</issue>
		<volume>15</volume><issue>4</issue>

		<volume>16</volume><issue>1</issue>
		<volume>16</volume><issue>2</issue>
		<volume>16</volume><issue>3</issue>
		<volume>16</volume><issue>4</issue>
	</multiple>
</HWExpress>

Questions?

What if my marker file isn't valid?
Only valid XML marker files trigger automated processing. In the event that an invalid marker file is detected, an email warning will be sent to the appropriate person designated for that journal indicating a validation and intake failure, and an error in the "Preintake" phase will appear on the HighWire Express summary.

What if I forget to deliver the marker file?
HighWire Express will ignore files in any ftp directory unaccompanied by a marker file, so if the marker file isn't present, files will not be processed. This allows file providers to deliver files incrementally at their convenience, but defers automated processing until all files are in place.

What if I deliver the marker file before the rest of the files for my batch?
The marker file triggers automated processing, so the presence of a marker file will register an active publication event, but if no content files are present when the marker is detected, no files will be processed. The system will not check back later for orphaned content files, so it's important that the marker file always be delivered only after all other files for that delivery are in place.

What if I need to deliver additional or replacement files after the initial delivery?
Not a problem! HighWire Express is happy to accept files in asynchronous batches, although pre- and post-production redeliveries are handled differently. (Post-production resupplies require an additional level of authorization/approval.)

For example:

Day 1: XML and PDF files + go.xml delivered. Initial processing begins, and issue is paused for evaluation.

Day 2: During review of the staged issue, it's discovered that an article was missing from the original shipment. The missing XML and PDF files are delivered, along with a new instance of the original go.xml file. The system identifies the publication event to which both deliveries pertain from the metadata elements in the go.xml file, so newer files are merged with files from the previous delivery. When the issue is deemed complete and final, it is released for production.

Last updated 6 Sep 2004 by henniss