WfMC Issues

XPDL Issues

• Missing Defaults
• Undefined Semantics
• Schema Errors and Ambiguities
• Schema Omissions and Inconsistencies

Missing Defaults

• //WorkflowProcess/@AccessLevel: Specify an explicit value of PUBLIC or PRIVATE.
• //SubFlow/@Execution: Specify an explicit value of SYNCHR or ASYNCHR.
• //ConformanceClass/@GraphConformance: Specify an explicit value of NON_BLOCKED, LOOP_BLOCKED or FULL_BLOCKED.
• //Condition/@Type: Specify an explicit value of CONDITION, OTHERWISE, EXCEPTION or DEFAULTEXCEPTION.
• /Package/Script: If your workflow uses expressions, you must include this element. OBE's default is set by the property obe.script, defaulting to text/x-xpath.

Undefined Semantics

• Date Format: XPDL does not specify a date format, unlike its predecessor language WPDL, which used ISO-8601.  If you are specifying dates, check the documentation for your workflow engine to determine what format it expects.  Some engines attempt a sequence of date conversions and use the first format that yields a valid conversion, and some even allow you to configure the formats to attempt, but in all cases beware the inherent ambiguity if semantic portability is important to you.  For configurable engines such as OBE, the standard XML Schema date and xsd:dateTime formats (also based on ISO-8601) would be sensible defaults to use. OBE provides configurable support for date format; the default is set by the property obe.xpdl.date.format, defaulting to the XML Schema xsd:dateTime format YYYY-MM-DD'T'hh:mm:ssZ, for example:  2005-10-30T17:38:12+00:00.
• Expression Usage: The Specification erroneously suggests that any string value can be an arbitrary expression.  This is not the case, because there is no general way for a workflow engine to distinguish an unquoted string literal from an arbitrary scripted expression.  Places where expressions can be used safely and unambiguously are:
• //Transition/Condition[@Type="CONDITION"]: A boolean expression on conditional transition.
• //ActualParameter with a corresponding //FormalParameter[@Mode="IN"], in which case a workflow engine always evaluates the parameter value as an expression (INOUT and OUT parameter values are always the Ids of workflow relevant data - //DataField or //WorkflowProcess/FormalParameter);
• Any other element or attribute for which the Specification explicitly requires the value to be an expression.
• //Xpression: The Schema permits multiple <Xpression> elements within a //Transition/Condition element, but the Specification does not define the behaviour when more than one <Xpression> occurs.  For semantic portability, avoid using multiple <Xpression> elements.
• //TransitionRestriction: The Schema permits multiple occurrences of a <TransitionRestriction> element within a single <Activity>. Each <TransitionRestriction> can contain a <Split>, a <Join>, or both, but the Specification does not define the semantics if more than one split or join is present overall.  To avoid confusion, do not specify more than one split and one join per activity.
• //PriorityUnit: The Schema defines a <PriorityUnit> element but the Specification does not define its semantics.  For semantic portability, avoid using it.
• //Performer: The Specification and Sample suggest that an activity can have multiple performers, but does not specify the syntax (nor, indeed, the semantics).  Some engines (such as OBE) support comma- or space-separated performer lists.  The syntax used in the Sample ( <Performer>DBConnection and Shipper</Performer>) is unlikely to work on any real workflow engine.
• //DeadlineCondition: The <DeadlineCondition> element in a <Deadline> is an expression that either yields a time interval to be added to the activity start time, or an absolute date-time value (it is not really a boolean condition).  Deadline semantics are implementation dependent and therefore non-portable, although some engines (such as OBE) quite reasonably interpret them as duration-type values.
• //ConformanceClass/@GraphConformance : The Specification provides incorrect definitions of the LOOP_BLOCKED and FULL_BLOCKED graph conformance levels.  Unlike its predecessor language WPDL (which defined WHILE and UNTIL constructs), XPDL lacks formal iteration semantics and cannot unambiguously support anything other than NON_BLOCKED graph conformance. OBE does support explicit WHILE, UNTIL and FOR_EACH iteration semantics via the extended attribute obe.Loop. and can therefore support LOOP_BLOCKED and FULL_BLOCKED semantics properly.
• //ExternalReference: The <ExternalReference> element is a reference to an external definition of an entity, but the Specification does not provide a precise definition of all possible formats and semantics.  Certain formats will therefore be less portable than others – a simple http: or file: URL reference to an external XML Schema is probably safe enough, but more complex URIs or protocols may not be portable.
• /Package/Script: The Specification defines the <Script> element's semantics informally: the Type attribute follows the pattern expected for a MIME media type, but none of the suggested values (text/javascript, text/vbscript, etc.) is actually a valid IANA-registered type.  Strictly speaking, therefore, the only way to specify the script grammar unambiguously would be via the Grammar attribute.  However, since the latter attribute is optional, a workflow engine is forced to use the Type attribute.  Some engines (such as OBE) use the official IANA registered types where available (e.g., application/javascript) or define their own MIME extension types instead (e.g.,  text/x-python, text/x-vbscript and so on) but these extended script types are as non-portable as the unregistered MIME media types suggested by the Specification.
• //ActualParameter matching //FormalParameter[@Mode="IN"]. The Specification requires an <ActualParameter> for an IN-type <FormalParameter> to be passed by value.  However, since such values are the result of evaluating an arbitrary expression in an arbitrary scripting language, they are as likely to be complex objects as primitive types, and in general it is not possible to pass an object by value.  Many engines will only apply strict pass-by-value semantics to primitive types.
• The specification does not state when an <ActivitySet> terminates, nor does it describe permissible activity net patterns.  For example, an activity set may have multiple start activities (those with no incoming transitions), unless the graph conformance is FULL_BLOCKED, in which case it may have only a single start activity.  However, in NON_BLOCKED or LOOP_BLOCKED mode, multiple finish activities (those with no outgoing transitions) would create an ambiguous flow with an implied OR-join.  The specification should be precise on these matters.
• RESTRICT_TO: The Specification suggests that access to workflow relevant data can be restricted within activities, but does not specify how this is achieved. WPDL defined a RESTRICT_TO keyword for this purpose but there is no equivalent in the XPDL Schema.
• DataField/@Length: The Schema provides this attribute but the Specification does not clearly state what it means ("The length of the data"). Does this mean the maximum length of a string type, the length of an array, or what?  Is it required for other types such as DATE, INTEGER, FLOAT - the specification should make this clear.
• //Performer: The Specification states that the default value for <Performer> is "Any Participant", but does not define what this really means.  For example, does the engine create a work item and if so, to whom is the work item assigned? OBE does not create work items for activities which have no performer or for which //Participant[ParticipantType="SYSTEM"].

Schema Errors and Ambiguities

• /Package/ValidFrom, /Package/ValidTo: The Specification states that the <ValidFrom> and <ValidTo> elements at the <WorkflowProcess> level override values inherited from the <Package> level, but the Schema does not define <ValidFrom> or <ValidTo> elements at the package level (so don't include them in your XPDL documents), nor does it define the format of <ValidFrom> and <ValidTo>.  Although some engines (such as OBE) quite reasonably interpret these as date or date/time strings, such usage is not guaranteed to be portable, especially given the additional ambiguity of the XPDL date/time types themselves.
• //FormalParameter/@Index: The <FormalParameter> element has an optional Index attribute that the specification merely describes as "The parameter index". It is unclear what purpose the attribute is intended to serve, especially given that the facts that:
• Index is an optional attribute,
• the Specification does not state whether the index is 0- or 1-based,
• there's nothing in the Specification or Schema to enforce contiguous index values, and
• the parameter order is implicit in the physical document order of the <FormalParameter> elements themselves.
• To minimize ambiguity either omit the Index attribute altogether (recommended) or provide a full complement of contiguous, unity-based indexes that are consistent with natural document order (i.e., 1, 2, 3, ... in that order).
• //Limit: The Schema incorrectly defines the <Limit> element as type xsd:string, whereas in fact it is required by the Specification to follow the pattern defined for <Duration> (i.e., an integer followed by an optional duration unit Y, M, D, h, m, or s).
• //SchemaType: The <SchemaType> element currently permits multiple child elements; however, since a child element is taken to be the document element of an XML Schema, there should only be one single child element, which should be a valid XML Schema. The Specification does not define a means to identify which element or data type defined within that schema is being referenced.  To avoid ambiguity such schema fragments should specify a single top-level type, with any other types being nested within it.
• //SubFlow/@Id: The Schema incorrectly defines the <SubFlow> element's Id attribute to be of type xsd:string, which does not agree with the type of the referenced <WorkflowProcess Id="..."> attribute (xsd:NMTOKEN).  Make sure all subflow Ids are valid NMTOKEN strings.
• //Created: The Schema defines the <Created> element to be xsd:string; it is actually a date type but lacking a format definition is therefore ambiguous.  To ensure portability, do not rely upon the <Created> element.  To use it, be aware of your engine's supported date formats.
• DeadlineCondition and ExceptionName: The Schema references but does not define these <Deadline> sub-elements.

Schema Omissions and Inconsistencies

• Identifier length: Unlike WPDL, XPDL does not enforce maximum lengths for any of the identifying strings, but the corresponding identifiers in WfMC Interfaces 2/3 (Workflow/ToolAgent APIs) do.  To avoid buffer overrun problems in systems which support WfMC Interfaces 1, 2 and 3, ensure that XPDL identifiers do not exceed 64 characters in length.
• References: Many elements cross-reference each other, but the Schema does not model these relationships using XML Schema's xsd:keyref feature, nor does it enforce key value uniqueness with the key feature.
• //DataField/@IsArray: This attribute is defined as the enumeration {TRUE, FALSE}, rather than using XML Schema's built-in xsd:boolean type. N.B. OBE does not currently support the  DataField/@IsArray attribute.
• //ExternalReference/@xref,@location,@namespace: These attributes break the pattern of proper-noun casing for element and attribute names used elsewhere within the Schema.
• <Automatic> and <Manual> are defined as sub-elements rather than as enumerated attributes of the <StartMode> and <FinishMode> elements?  The latter pattern is used consistently elsewhere throughout the schema; the use of elements here is inconsistent.
• Elements vs. Attributes: There does not appear to be a consistent rationale for the use of attributes as opposed to elements for holding user-defined strings (as opposed to strings that are actually enumerations).

Acknowledgement