content/ns/2008/xml/t2flow/t2flow.xsd

<?xml version="1.0" encoding="UTF-8"?>
<!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements.  See the NOTICE file
distributed with this work for additional information
regarding copyright ownership.  The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License.  You may obtain a copy of the License at

  http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied.  See the License for the
specific language governing permissions and limitations
under the License.
-->

<schema targetNamespace="http://taverna.sf.net/2008/xml/t2flow"
	elementFormDefault="qualified" xmlns="http://www.w3.org/2001/XMLSchema"
	xmlns:tav="http://taverna.sf.net/2008/xml/t2flow" xml:lang="en">

	<annotation>
		<documentation>
			<p xmlns='http://www.w3.org/1999/xhtml'>
				This is a descriptive, informative XML Schema
				describing
				the serialisation format of Taverna 2 workflows, as of
				Taverna 2.0.
				Such workflows are commonly served with the extension
				.t2flow and
				served using the content-type
				application/vnd.taverna.t2flow+xml
			</p>
			<p xmlns='http://www.w3.org/1999/xhtml'>
				Stable as of 2009-09-11 by Stian Soiland-Reyes, should correctly
				describe workflows as saved from Taverna 2.0, 2.1 b1 and 2.1 b2, but
				as this schema has been made in retrospect no guarantees are made.
				To test the schema against the examples, try xmllint:
				<code>xmllint --noout --schema t2flow.xsd examples/*t2flow</code>
			</p>
		</documentation>
	</annotation>
	<element name="workflow" type="tav:Workflow">
		<annotation>
			<documentation>The container element for a .t2flow workflow
				definition. Future versions of Taverna may support other kinds of
				flows, like control flows, but currently only Dataflows are
				supported. The Dataflow with role="top" is the main workflows.
			</documentation>
		</annotation>
	</element>

	<complexType name="Workflow">
		<annotation>
			<documentation>
				The container of a workflow definition. This schema
				specifies workflow definitions where version="1" (as
				used by Taverna
				2.0) - although this schema also permits
				any future minor versions
				like "1.1".

				At least one dataflow must be present, and it must have
				role="top". Other dataflows would typically be
				referenced by their id
				from the nested workflow
				activity.
			</documentation>
		</annotation>
		<sequence>
			<element name="dataflow" type="tav:Dataflow" maxOccurs="unbounded"
				minOccurs="1">
			</element>
		</sequence>
		<attribute use="required" name="version" type="tav:Version1">

		</attribute>
		<attribute name="producedBy" type="string" use="optional">
			<annotation>
				<documentation>Application that produced (ie. saved/serialised) this
					workflow.

					Example: taverna-2.1-beta-1

					Introduced in Taverna 2.1 Beta
					1 - if the value is missing it's safe to
					assume 'taverna-2.0' -
					although it might also be a workflow saved
					through another
					application using the pre 2.1 APIs, such as the
					Taverna Platform.
				</documentation>
			</annotation>
		</attribute>
	</complexType>

	<complexType name="Dataflow">
		<annotation>
			<documentation>A dataflow, that is a workflow that is data-driven.
				When running a dataflow, data is pushed onto the inputPorts, leading
				through the datalinks to the input ports of processors. The output
				ports of these processors again have datalinks to other processors,
				and to outputPorts, which are the results of the workflow.
				Additional control links can be listed under 'conditions', and
				annotations (descriptions) about the Dataflow under 'annotations'.
				The "role" attribute should be "top" for the main dataflow, and
				"nested" for nested dataflows. The uuid-s in "id" can be referenced
				from a nested dataflow activity.
			</documentation>
		</annotation>
		<sequence>
			<element name="name" type="string">
				<annotation>
					<documentation></documentation>
				</annotation>
			</element>
			<element name="inputPorts" type="tav:AnnotatedGranularDepthPorts">
				<annotation>
					<documentation>List of dataflow input ports. Input ports are the
						"parameters" or inputs to running a workflow and must be described
						with depth and granular depth.
					</documentation>
				</annotation>
			</element>
			<element name="outputPorts" type="tav:AnnotatedPorts">
				<annotation>
					<documentation>List of output ports of the dataflows. Results are
						delivered to the output ports, the depth of the output port is
						calculated at runtime.
					</documentation>
				</annotation>
			</element>
			<element name="processors" type="tav:Processors">
				<annotation>
					<documentation>List of processors. Processors receive, process and
						produce data and are linked with each other using datalinks.
					</documentation>
				</annotation>
			</element>
			<element name="conditions" type="tav:Conditions">
				<annotation>
					<documentation>List of conditional control link. A control link
						between processor A and B means that processor B will not run
						until processor A has finished all it's iterations.
					</documentation>
				</annotation>
			</element>
			<element name="datalinks" type="tav:Datalinks">
				<annotation>
					<documentation>List of datalinks. A datalink goes between ports,
						for instance from a processor output port to a processor input
						port. The "source" end of the link can also come from a dataflow
						input port, and the "sink" end can go to a dataflow output port. A
						processor output port and a dataflow input port can have several
						links to different ports, but a processor input port or a dataflow
						output port can't have several incoming links. However, a
						processor input port can have several incoming links through a
						'merge', which will wrap the inputs into an ordered list.
					</documentation>
				</annotation>
			</element>
			<element name="annotations" type="tav:Annotations" maxOccurs="1"
				minOccurs="0">
				<annotation>
					<documentation>List of annotations, ie. descriptions and metadata
						about the dataflow such as "title" and "author".
					</documentation>
				</annotation>
			</element>
		</sequence>
		<attribute name="id" type="tav:uuid" use="required">
			<annotation>
				<documentation>A unique identifier for this dataflow (UUID). This id
					should change whenever a structural change has been done to the
					dataflow.
				</documentation>
			</annotation>
		</attribute>
		<attribute name="role" type="tav:role" use="required">
			<annotation>
				<documentation>The role of this Dataflow within the Workflow
					container. The "top" dataflow is the main one, while "nested"
					dataflows might be referenced by id from activities.
				</documentation>
			</annotation>
		</attribute>
	</complexType>

	<simpleType name="uuid">
		<annotation>
			<documentation>A hex-formatted UUID. (Universial Unique IDentifier).
				UUIDs should be generated using a random algorithm so that they
				can't identify the machine who saved the dataflow.
			</documentation>
		</annotation>
		<restriction base="string">
			<pattern
				value="[a-f0-9]{8}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{12}">
			</pattern>
		</restriction>
	</simpleType>

	<simpleType name="role">
		<annotation>
			<documentation>The role of a dataflow within a workflow.
			</documentation>
		</annotation>
		<restriction base="string">
			<enumeration value="top"></enumeration>
			<enumeration value="nested"></enumeration>
		</restriction>
	</simpleType>

	<complexType name="Ports">
		<annotation>
			<documentation>List of ports.</documentation>
		</annotation>
		<sequence>
			<element name="port" type="tav:Port" maxOccurs="unbounded"
				minOccurs="0"></element>
		</sequence>
	</complexType>

	<complexType name="Processors">
		<annotation>
			<documentation>List of processors.</documentation>
		</annotation>
		<sequence>
			<element name="processor" type="tav:Processor" maxOccurs="unbounded"
				minOccurs="0"></element>
		</sequence>
	</complexType>

	<complexType name="Conditions">
		<annotation>
			<documentation>List of conditional control links.
			</documentation>
		</annotation>
		<sequence>
			<element name="condition" type="tav:Condition" maxOccurs="unbounded"
				minOccurs="0"></element>
		</sequence>
	</complexType>

	<complexType name="Datalinks">
		<annotation>
			<documentation>List of datalinks between dataflow ports and
				processors in a workflow.
			</documentation>
		</annotation>
		<sequence>
			<element name="datalink" type="tav:DataLink" maxOccurs="unbounded"
				minOccurs="0"></element>
		</sequence>
	</complexType>

	<complexType name="Port">
		<sequence>
			<element name="name" type="tav:PortName"></element>
		</sequence>
	</complexType>

	<complexType name="Processor">
		<annotation>
			<documentation>A processor of a dataflow. A processor is a dataflow
				unit that receives input to its input ports, iterates over it using
				the iteration strategy stack, and pushes it down the dispatch stack
				to reach the activities that invokes the actual services. The
				outputs from the services buble up through the dispatch stack and is
				pushed out on the output ports, indexed according to the iteration
				strategy.
			</documentation>
		</annotation>
		<sequence>
			<element name="name" type="tav:ProcessorName">
				<annotation>
					<documentation>Name of processor within the dataflow. This name is
						used to describe datalinks. The name of a processor must be
						locally unique within a dataflow. (However the name can be reused
						in a nested dataflow)
					</documentation>
				</annotation>
			</element>
			<element name="inputPorts" type="tav:DepthPorts">
				<annotation>
					<documentation>List of processor input ports. Inputs are described
						with depth. Inputs served at a lower depth will be wrapped, if it
						is served at a higher depth the iteration strategy stack will be
						involved to do the iteration over the input. "Depth" means the
						granularity of data, single strings are depth 0, a list of strings
						are depth 1, lists of such lists are depth 2, etc.
					</documentation>
				</annotation>
			</element>
			<element name="outputPorts" type="tav:GranularDepthPorts">
				<annotation>
					<documentation>List of processor output ports. Output ports must be
						described with both depth and granular depth, although in most
						cases the two are equal. The "depth" describes the granularity of
						the final output produced by a data port (assuming no iteration,
						the additional depth from this is added at runtime). If a
						processor (and its activity) produces intermediate outputs at
						lower granularity than the granularDepth can be set to describe at
						which level the intermediate outputs will be produced. (Note that
						such a processor would still need to produce the final list of the
						defined depth in the end).
					</documentation>
				</annotation>
			</element>
			<element name="annotations" type="tav:Annotations" maxOccurs="1"
				minOccurs="0">
				<annotation>
					<documentation>List of processor annotations, describing this
						processor. For instance a description could say what is the role
						of this processor in the dataflow.
					</documentation>
				</annotation>
			</element>

			<element name="activities" type="tav:Activities">
				<annotation>
					<documentation>List of activities that is to be invoked by this
						processor. It is down to the dispatch stack to do the activity
						selection (typically by the Failover layer) so that in the bottom
						a single activity is invoked at a time. The activities must have
						output mapping to be able to populate all of this processors
						outputPorts, and can have input mapping to use one or more of the
						input ports. Note that the depth of the mapped activity ports must
						match the defined depths in the Processor ports.
					</documentation>
				</annotation>
			</element>
			<element name="dispatchStack" type="tav:DispatchStack">
				<annotation>
					<documentation>The dispatch stack. The stack is made out of layers
						that send jobs down and receive job results (or failure) from
						below. The typical stack takes care of parallelizing, retries on
						failure, failover to alternative activities, and handling errors.
						The elements of the stack can be reordered and replaced for
						individual processors, for instance if one wants to do failover
						before retries, or do a customized layer that does service
						selection at runtime by doing a lookup in a service repository
						like BioCatalogue.
					</documentation>
				</annotation>
			</element>
			<element name="iterationStrategyStack" type="tav:IterationStrategyStack">
				<annotation>
					<documentation>The stack of iteration strategies. The iteration
						strategies takes care of iterating when a processor is served with
						inputs of higher granularity than what it expects. The typical
						usecase is a single iteration strategy in the stack, and by
						default a single cross product of all the input ports (meaning
						all-to-all iteration).
					</documentation>
				</annotation>
			</element>
		</sequence>
	</complexType>

	<complexType name="Annotations">
		<annotation>
			<documentation>List of annotation chains</documentation>
		</annotation>
		<choice maxOccurs="unbounded" minOccurs="0">
			<element name="annotation_chain" type="tav:AnnotationChain">
			</element>
			<element name="annotation_chain_2_2" type="tav:AnnotationChain">
			</element>
		</choice>
	</complexType>

	<complexType name="Activities">
		<annotation>
			<documentation>List of activities. The list can be empty, used for
				"abstract" processors, placeholders until a matching activity is
				found.
			</documentation>
		</annotation>
		<sequence>
			<element name="activity" type="tav:Activity" maxOccurs="unbounded"
				minOccurs="0" />
		</sequence>
	</complexType>

	<complexType name="Activity">
		<annotation>
			<documentation>An activity is the link between a processor and the
				actual service. Typical activities can be the WSDL activity that
				knows how to communicate with WSDL-services, the Beanshell activity
				that knows how to locally execute a Beanshell script, or a Dataflow
				activity that knows how to execute a nested dataflow. (Typically
				included as another dataflow element within this Workflow
				description).
			</documentation>
		</annotation>
		<sequence>
			<element name="raven" type="tav:Raven" maxOccurs="1"
				minOccurs="0">
				<annotation>
					<documentation>Raven artifact from which the activity
						implementation class is to be loaded. The version of this artifact
						is mainly informational, as the currently loaded artifact is
						preferred.
					</documentation>
				</annotation>
			</element>
			<element name="class" type="string">
				<annotation>
					<documentation>Fully qualified Java class name defining this
						activity implementation. An instance of this class will be
						constructed and then configured with the deserialised configBean.
					</documentation>
				</annotation>
			</element>
			<element name="inputMap" type="tav:Map">
				<annotation>
					<documentation>Mapping from the processor's input ports to this
						activity's input ports (determined at run-time after
						configuration). Not all processor inputs need to be mapped, and
						neither does all the activity input ports need a mapping. Notice
						that this mapping is processorPort -> activityPort , while the
						order is opposite for outputMap. Each activity have their own
						mapping, which means that you can have alternative activities with
						different port names (but same depths). If one of the activities
						requires additional input ports this can be arrange by having
						additional processor ports, and only map them in that activity.
						(If the other activity is invoked those inputs are ignored - but
						note that they would still be iterated over according ot the
						iteration strategy).
					</documentation>
				</annotation>
			</element>
			<element name="outputMap" type="tav:Map">
				<annotation>
					<documentation>Mapping from the activity's output ports (determined
						at run-time after configuration) to the processor's output ports.
						Not all of the activity's output ports need to be mapped, but all
						of the processor output ports need to have a mapping. Notice that
						this mapping is activityPort -> processorPort, while the order is
						opposite for inputMap.
					</documentation>
				</annotation>
			</element>
			<element name="configBean" type="tav:ConfigBean">
				<annotation>
					<documentation>Serialised configuration bean. After constructing
						the activity instance of the defined class, this configuration
						bean is passed as configuration to the activity. The activity
						input and output ports will be defined at runtime after this
						configuration. (For some activities the configuration bean
						includes this port definition, while other calculate the ports by
						parsing service descriptions, etc).
					</documentation>
				</annotation>
			</element>
			<element name="annotations" type="tav:Annotations" maxOccurs="1"
				minOccurs="0">
				<annotation>
					<documentation>List of annotations describing this activity.
					</documentation>
				</annotation>
			</element>
		</sequence>
	</complexType>

	<complexType name="Raven">
		<annotation>
			<documentation>Raven artifact described using typical Maven groupId,
				artifactId and version. When loading a dataflow this artifact must
				have already been loaded from one of the plugins.
			</documentation>
		</annotation>
		<sequence>
			<element name="group" type="string" />
			<element name="artifact" type="string" />
			<element name="version" type="string" />
		</sequence>
	</complexType>

	<complexType name="Mapping">
		<annotation>
			<documentation>A mapping of port names. For instance in an inputMap,
				where a processor input port "database" is to be mapped to the
				activity input port "db", an inputMap would be made with
				from="database" to="db".
			</documentation>
		</annotation>
		<attribute use="required" name="from" type="tav:PortName" />
		<attribute use="required" name="to" type="tav:PortName" />
	</complexType>

	<element name="abstractConfigBean" abstract="true"
		type="tav:AbstractConfigBean" />

	<complexType name="AbstractConfigBean" />

	<complexType name="ConfigBean">
		<annotation>
			<documentation>A serialised configuration bean to configure a
				dispatch layer or activity. Typically the serialisation is done
				using a Java XML serialisation from libraries such as xstream, and
				the serialisation is therefore also dependent on the plugin defining
				the activity or dispatch layer. The alternative schema
				t2flow-extended.xsd adds descriptions of the most typical activities
				and dispatch layers.
			</documentation>
		</annotation>
		<sequence>
			<any namespace="##any" processContents="lax" />
		</sequence>
		<attribute name="encoding" type="string" use="required" />
	</complexType>

	<complexType name="DispatchStack">
		<annotation>
			<documentation>List of dispatch layers. This would typically contain
				at least the Invoke layer to perform the actual invocation of the
				activity.
			</documentation>
		</annotation>
		<sequence>
			<element name="dispatchLayer" type="tav:DispatchLayer"
				maxOccurs="unbounded" minOccurs="0" />
		</sequence>
	</complexType>

	<complexType name="DispatchLayer">
		<annotation>
			<documentation>A dispatch layer, identified by Java class name.
			</documentation>
		</annotation>
		<sequence>
			<element name="raven" type="tav:Raven" maxOccurs="1"
				minOccurs="0">
				<annotation>
					<documentation>Raven artifact from which the layer class is to be
						loaded. The version of this artifact is mainly informational, as
						the currently loaded artifact is preferred.
					</documentation>
				</annotation>
			</element>
			<element name="class" type="string">
				<annotation>
					<documentation>Fully qualified Java class name defining this
						dispatch layer. An instance of this class will be constructed and
						then configured with the deserialised configBean.
					</documentation>
				</annotation>
			</element>
			<element name="configBean" type="tav:ConfigBean">
				<annotation>
					<documentation>A serialised configuration for the dispatch layer.
						The deserialised version of this bean will be passed to the layer
						instance after initialisation.
					</documentation>
				</annotation>
			</element>
		</sequence>
	</complexType>

	<complexType name="IterationStrategyStack">
		<sequence>
			<element name="iteration" type="tav:Iteration"></element>
		</sequence>
	</complexType>

	<complexType name="Iteration">
		<sequence>
			<element name="strategy" type="tav:TopIterationNode"
				minOccurs="0" maxOccurs="unbounded" />
		</sequence>
	</complexType>

	<complexType name="TopIterationNode">
		<choice maxOccurs="1" minOccurs="0">
			<element name="cross" type="tav:CrossProduct" />
			<element name="dot" type="tav:DotProduct" />
		</choice>
	</complexType>

	<complexType name="IterationNode">
	</complexType>


	<complexType name="IterationNodeParent">
		<complexContent>
			<extension base="tav:IterationNode">
				<choice maxOccurs="unbounded" minOccurs="0">
					<element name="cross" type="tav:CrossProduct" />
					<element name="dot" type="tav:DotProduct" />
					<element name="port" type="tav:PortProduct" />
				</choice>
			</extension>
		</complexContent>
	</complexType>

	<complexType name="CrossProduct">
		<complexContent>
			<extension base="tav:IterationNodeParent" />
		</complexContent>
	</complexType>

	<complexType name="DotProduct">
		<complexContent>
			<extension base="tav:IterationNodeParent" />
		</complexContent>
	</complexType>


	<complexType name="DepthPort">
		<complexContent>
			<extension base="tav:Port">
				<sequence>
					<element name="depth" type="nonNegativeInteger"></element>
				</sequence>
			</extension>
		</complexContent>
	</complexType>

	<complexType name="GranularDepthPort">
		<complexContent>
			<extension base="tav:DepthPort">
				<sequence>
					<element name="granularDepth" type="nonNegativeInteger">
					</element>
				</sequence>
			</extension>
		</complexContent>
	</complexType>



	<complexType name="GranularDepthPorts">
		<annotation>
			<documentation>List of ports that have both depth and granular depth.
			</documentation>
		</annotation>
		<sequence>
			<element name="port" type="tav:GranularDepthPort" maxOccurs="unbounded"
				minOccurs="0"></element>
		</sequence>
	</complexType>


	<complexType name="AnnotatedGranularDepthPort">
		<complexContent>
			<extension base="tav:GranularDepthPort">
				<sequence>
					<element name="annotations" type="tav:Annotations"
						maxOccurs="1" minOccurs="0">
						<annotation>
							<documentation>
								List of annotations, describing this port. For
								instance a description could say what type of data the port
								expects, and an example annotation could say an example value
							</documentation>
						</annotation>
					</element>
				</sequence>
			</extension>
		</complexContent>
	</complexType>
	<complexType name="AnnotatedGranularDepthPorts">
		<annotation>
			<documentation>List of annotated ports that have both depth and
				granular depth.
			</documentation>
		</annotation>
		<sequence>
			<element name="port" type="tav:AnnotatedGranularDepthPort"
				maxOccurs="unbounded" minOccurs="0"></element>
		</sequence>
	</complexType>
	
	<complexType name="LastPredictedDepthPort">
			<complexContent>
			<extension base="tav:Port">
				<sequence>
					<element name="lastPredictedDepth" type="integer" minOccurs="0">
					</element>
				</sequence>
			</extension>
		</complexContent>
	</complexType>

	<complexType name="AnnotatedPort">
		<complexContent>
			<extension base="tav:LastPredictedDepthPort">
				<sequence>
					<element name="annotations" type="tav:Annotations"
						maxOccurs="1" minOccurs="0">
						<annotation>
							<documentation>
								List of annotations, describing this port. For
								instance a description could say what type of data the port
								expects, and an example annotation could say an example value
							</documentation>
						</annotation>
					</element>
				</sequence>
			</extension>
		</complexContent>
	</complexType>
	<complexType name="AnnotatedPorts">
		<annotation>
			<documentation>List of annotated ports.
			</documentation>
		</annotation>
		<sequence>
			<element name="port" type="tav:AnnotatedPort" maxOccurs="unbounded"
				minOccurs="0"></element>
		</sequence>
	</complexType>



	<complexType name="Map">
		<annotation>
			<documentation>0 or more mappings.</documentation>
		</annotation>
		<sequence>
			<element name="map" type="tav:Mapping" maxOccurs="unbounded"
				minOccurs="0"></element>
		</sequence>
	</complexType>

	<complexType name="DataLink">
		<annotation>
			<documentation>A link between two dataflow units, from source to
				link.
			</documentation>
		</annotation>
		<sequence>
			<element name="sink" type="tav:Link">
				<annotation>
					<documentation>The sink of the link - where the data will be
						flowing to. This must be either a processor input port or a
						dataflow output port.
					</documentation>
				</annotation>
			</element>

			<element name="source" type="tav:Link">
				<annotation>
					<documentation>The source of the link - where the data will be
						flowing from. This must be a dataflow input port or a processor
						output port.
					</documentation>
				</annotation>
			</element>
		</sequence>
	</complexType>

	<complexType name="Link">
		<annotation>
			<documentation>One end of the links in the Datalink. A link goes
				from/to a port, either a dataflow port or a processor port. If the
				type is "dataflow", then the "processor" element must not be
				present, and the port defines a dataflow input (if this link is a
				source) or output port (if this link is a sink). The must not be
				more than one DataLink with a sink to the same dataflow output port.
				If the type is "processor", then the "processor" element must be
				present, and name a processor in the same dataflow. The port must
				name a defined processor input port (if this link is a sink) or
				processor output port (if this link is a source). There must not be
				more than one DataLink with a sink to the same processor input port.
				If the type is "merge", this link must be used as a source (merge
				can't be used with a sink), and is similar to the type of
				"processor", except that more than one link to the processor is
				allowed. A "merge" element will be inserted in front of the defined
				processor input port, and the incoming links will be added to the
				merge in the order they have been defined in the dataflow.
			</documentation>
		</annotation>
		<sequence>
			<element name="processor" type="tav:ProcessorName" maxOccurs="1"
				minOccurs="0">
				<annotation>
					<documentation>If the type is "processor" or "merge" this element
						must be present and describe the processor name of this link. If
						the type is "dataflow" this element must not be present.
					</documentation>
				</annotation>
			</element>
			<element name="port" type="tav:PortName">
				<annotation>
					<documentation>If type is "processor" or "merge" this describes a
						processor input port (if this link is a sink) or output port (if
						this link is a source).
					</documentation>
				</annotation>
			</element>
		</sequence>

		<attribute use="required" name="type" type="tav:LinkType"></attribute>
	</complexType>

	<simpleType name="LinkType">
		<restriction base="string">
			<enumeration value="dataflow"></enumeration>
			<enumeration value="processor"></enumeration>
			<enumeration value="merge"></enumeration>
		</restriction>
	</simpleType>


	<complexType name="DepthPorts">
		<annotation>
			<documentation>List of ports that have depths.</documentation>
		</annotation>
		<sequence>
			<element name="port" type="tav:DepthPort" maxOccurs="unbounded"
				minOccurs="0">
			</element>
		</sequence>
	</complexType>

	<complexType name="PortProduct">

		<complexContent>
			<extension base="tav:IterationNode">
				<attribute use="required" name="name" type="tav:PortName"></attribute>
				<attribute use="required" name="depth" type="nonNegativeInteger"></attribute>
			</extension>
		</complexContent>
	</complexType>

	<complexType name="AnnotationChain">
		<annotation>
			<documentation>Chain of annotations. Annotations are serialised Java
				objects, similar to the ConfigBeans.
			</documentation>
		</annotation>
		<sequence>
			<element name="net.sf.taverna.t2.annotation.AnnotationChainImpl"
				form="unqualified">
				<complexType>
					<sequence>
						<element name="annotationAssertions" form="unqualified"
							type="tav:AnnotationAssertionImpl">

						</element>
					</sequence>
				</complexType>
			</element>
		</sequence>
		<attribute use="required" name="encoding" type="string"></attribute>
	</complexType>

	<complexType name="AnnotationAssertionImpl">
		<sequence>
			<element name="net.sf.taverna.t2.annotation.AnnotationAssertionImpl"
				form="unqualified">
				<complexType>
					<sequence>
						<element name="annotationBean" form="unqualified" type="tav:AnnotationBean" />										
						<element name="date" form="unqualified" type="tav:datetime" />
						<element name="creators" form="unqualified" />
						<element name="curationEventList" form="unqualified" />
					</sequence>
				</complexType>
			</element>

		</sequence>
	</complexType>
	
	<complexType name="AnnotationBean">
		<sequence>
			<any minOccurs="0" maxOccurs="unbounded" processContents="lax"  />
		</sequence>
		<attribute name="class" form="unqualified" />
	</complexType>

	<simpleType name="datetime">
		<annotation>
			<documentation>ISO 8601 datetime with spaces and letter time zones; YYYY-mm-dd hh:mm:ss.nnn TTT
			</documentation>
		</annotation>
		<restriction base="string">
			<pattern value="\d{4}-\d\d-\d\d \d\d:\d\d:\d\d\.?\d* .*"></pattern>
		</restriction>
	</simpleType>

	<simpleType name="Version1">
		<annotation>
			<documentation>Version of workflow element covered by this schema -
				restricted to "1" or "1.x" - for instance "1.2" would be allowed.
			</documentation>
		</annotation>
		<restriction base="string">
			<pattern value="1(|\..*)"></pattern>
		</restriction>
	</simpleType>

	<complexType name="Condition">
		<annotation>
			<documentation>A conditional link. The processor named in "target"
				will not be invoked before the processor named in "control" has
				finished all its iterations. (Note that the target processor will
				also wait for any required input data before invoking).
			</documentation>
		</annotation>
		<attribute use="required" name="control" type="tav:ProcessorName"></attribute>
		<attribute use="required" name="target" type="tav:ProcessorName"></attribute>
	</complexType>

	<simpleType name="ProcessorName">
		<annotation>
			<documentation>Name of a processor within a dataflow. Each processor
				in the same dataflow need a unique processor name. It is not
				required, but recommended, to avoid 'special' characters like space,
				", -, ', \, etc.
			</documentation>
		</annotation>
		<restriction base="string"></restriction>
	</simpleType>

	<simpleType name="PortName">
		<annotation>
			<documentation>Name of a port, either a dataflow input/output port,
				processor input/output port or a activity input/output port. Port
				names must be unique for a given grouping of ports. For instance you
				can't have two input ports on a dataflow with the same name, but you
				can have two separate dataflows, both having an input port with the
				same name, or an output port with the same name. In the same way a
				processor or an activity can have an input port and an output port
				with the same name (but they are separate ports), but not two input
				ports or output ports with the same name. It is not required, but
				recommended, to avoid 'special' characters like space, ", -, ', \,
				etc.
			</documentation>
		</annotation>
		<restriction base="string"></restriction>
	</simpleType>
</schema>