Project Tracker Artifact XML Format

Because each artifact type can be different in structure, a somewhat verbose xml description is needed. The format is also prescribed to a point by the technology choice used to parse the xml. For example, several activity elements are wrapped in an activities element, when the latter element would appear unnecessary since the activity elements are already contained within an activity-set element.

Note: The dtd for artifact xml uses the term 'issue' where much of the PT documentation uses 'artifact'. The two should be considered synonymous in this context.

In the XML, you have the following tree:

There is an <issues> element containing a series of <issue> elements. On export, there is one <issue> element per exported artifact. On import, there should be one <issue> element per artifact you wish to insert or update.
Each artifact contains <activity-sets>, containing one or more <activity-set> elements. An activity-set represents a set of actions applied at one time. You can think of an <activity-set> as representing one operation using the web user interface for editing an artifact.
Each activity-set contains <activities>, containing one or more <activity> elements. Each activity represents a change to a single attribute of the artifact, whether that attribute be a regular data attribute, a user attribute, an attached file, etc.

The following table documents each of the discrete bits of information stored in the XML. Use this table to support the analysis of your own artifact types' XML, so you can understand how the XML is assembled.

Where an ellipsis (...) is shown in the XPath, that is shorthand for /scarab-issues/issues/issue/activity-sets/activity-set. Where a double ellipsis (.../...) is shown, that is shorthand for /scarab-issues/issues/issue/activity-sets/activity-set/activities/activity.

XPath	Description	Sample Value
/scarab-issues/import-type	Should be create-different-db for import from another PT installation or when converting an IZ project to PT. update-same-db should be used to modify artifacts in an existing PT installation.	create-different-db
/scarab-issues/module/name	Name of Project Tracker module into which this artifact should go	training
/scarab-issues/module/domain	Domain name of Project Tracker site into which this artifact should go	example.com
/scarab-issues/module/code	Artifact prefix used by the project for this artifact. The value is not used by import.	TRN
/scarab-issues/issues/issue/id	A unique id representing the artifact. For artifacts exported from PT this will be the usual artifact id made of of the project code and integer count. For artifact xml being generated by other means such as when converting legacy data it can be whatever identifier is used by that other system. For example, IZ uses a simple integer.	SC12
/scarab-issues/issues/issue/artifact-type	Name of artifact type this artifact is formatted in	Issue Tracker artifact
.../type	Should be 'Create Issue' for the first activity-set for an artifact insert. The most common is 'Edit Issue' which is used for all modifications to an artifact. There are several types related to moving or copying artifacts: Move Issue, Move Within Project, Copy Issue, and Copy Within Project	Create Issue
.../created-by	Username of person who did these activities	mmurphy
.../created-date/format	Format used for the created-date/timestamp element. "yyyy-MM-dd HH:mm:ss z" is known to work.	yyyy-MM-dd HH:mm:ss z
.../created-date/timestamp	Timestamp of when this activity-set occurred. This timestamp will be used in artifact imports, not the actual time the import occurred. For the update-same-db type dates in the future will be converted to time of import. Also for update-same-db type activity-sets with created-date prior to the last modified time of an existing artifact will be ignored.	2003-03-22 10:01:46 PST
.../.../attribute	Name of the attribute being set or modified. The global name of the attribute should be used. Project level aliases will not work.	Component
.../.../new-value	Sets the value for any data attribute. For list attribute types, the name of the option using either the project alias or global name. For user attributes, the username is used. Text and integer values are free form	Component 1
.../.../attachment/name	For comments, should be "comment". For attached files/URLs, should be the natural language label for the attachment.	Yahoo! home page
.../.../attachment/type	One of: COMMENT, URL, ATTACHMENT (latter for attached files)	ATTACHMENT
.../.../attachment/data	For comments, the text of the comment. For attached URLs, the URL itself. For attached files, the name of the attached file.	http://www.example.com
.../.../attachment/mimetype	MIME type to use for the attached data. Use text/plain for comments and URLs	text/plain
.../.../attachment/created-date/format	Format used for the created-date/timestamp element. "yyyy-MM-dd HH:mm:ss z" is known to work.	yyyy-MM-dd HH:mm:ss z
.../.../attachment/created-date/timestamp	Timestamp of when this attachment was attached. This timestamp will be used in artifact imports. This timestamp is ignored.	2003-03-22 10:01:46 PST
.../.../attachment/modified-date/format	Format used for the modified-date/timestamp element. "yyyy-MM-dd HH:mm:ss z" is known to work.	yyyy-MM-dd HH:mm:ss z
.../.../attachment/modified-date/timestamp	Timestamp of when this attachment was last modified. This timestamp is ignored.	2003-03-22 10:01:46 PST
.../.../attachment/created-by	Username of person who attached the attachment	mmurphy
.../.../attachment/deleted	false, indicates that this has not been deleted	false