Process definitions are XML documents (though OpenWFE may be extended to understand other formats/sources of process definitions).

The root node is named 'process-definition' and has two mandatory attributes : 'name' and 'revision'.

An XML Schema for the workflow definitions can be found at http://www.openwfe.org/flowdef.xsd If you want to take leverage of it with a power-xml-editor, your workflow definition XML document like this :

<process-definition 

    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="http://www.openwfe.org/flowdef.xsd"

    name="myflow" 
    revision="1.x"
>

the first children nodes may be description nodes like :

    <description language="default">
     A filtered flow. The participant 'alice' may not have complete access to all
     fields of the workitems transiting to her through this flow.  
    </description>
    
    <description language="fr">
     Un flux filtré. La participante 'alice' n'a pas forcément accès à tous les
     champs des workitems qui transitent vers elle au travers du flux.
    </description>

Such descriptions are used by the UI to present the workflow to the potential launcher. As you can see, a description can be specified in multiple languages, following the two-letter international language code.

the node child immediately after a description (or the first node child if there are no descriptions) is considered as the body of the workflow definition (much like the body of a procedure.

There can be one and only one expression that stands as the body of the definition.

After the body, there may be zero or more 'filter-definition' children, like for example :

    <filter-definition 
       name="reviewer-filter" 
       type="closed" 
       add="false"
    >
        <field regex="review" permissions="rw" />
            <!-- read-write -->

        <field regex="docUrl" permissions="r" />
            <!-- read-only -->

        <field regex="initiatorReview" permissions="" />
            <!-- hidden -->

    </filter-definition>

Such a filter can be attributed to a participant (or a dynamic participant) expression in the body of the flow, like in :

    <participant 
       ref="reviewer-alpha" 
       filter="reviewer-filter" 
    />

This filter defined here is a closed filter so that every field it doesn't mention are considered as hidden. As its 'add' attribute is set to 'false', a user cannot add a field to the workitem. The filter should be followed by the UI or the process acting on the workitem, but anyway, when the workitem gets back the 'filtered' expression, the filter is enforced and any illegal changes are discarded.

A workflow definition can contain sub process definitions.

<process-definition 
    name="flow" 
    revision="1.13"
>

    <description>
A recursive flow subdefinition
    </description>

    <subprocess ref="review" />

    <process-definition name="review">
        <sequence>
            <participant ref="role-alpha" />
            <if>
                <not>
                    <equals field-value="reviewed" other-value="true" />
                </not>
                <subprocess ref="review" />
                    <!-- loop until 'reviewed' is set to 'true' -->
            </if>
        </sequence>
    </process-definition>

</process-definition>

This example contains a subprocess named 'review'. The main process only contains a reference to the subprocess. If you carefully examine the example, you'll notice that it is recursive : the subprocess 'review' may call itself. The participant 'role-alpha' will keep receiving the workitem until the field 'reviewed' is set to 'true'.

The language tags appeared here : 'process-definition' and 'subprocess'. The latter one calls a defined subprocess through its 'ref' attribute. Of course, you can specify 'field-ref' or 'variable-ref' instead of 'ref' so that subprocesses to be launched at determined at runtime.