[BP-145] htt:tTask in PRD-03 with htt:tTaskDetails

Status:

Applied

Project:

OASIS BPEL4People TC

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None

Type:

Improvement

Priority:

Minor

Reporter:

Luc Clement

Assigned To:

Luc Clement

Resolution:

Fixed

Votes:

0

Submitted by: Mark Ford

During the course of work, Mark Ford identified the following issue

... do you know what the following API elements
should be referring to instead of htt:tTask? I'm guessing that htt:tTask
was from an older version of the schema and was renamed to something else.
These elements are from ws-humantask-api.wsdl.

     <xsd:element name="getParentTaskResponse">
       <xsd:complexType>
         <xsd:sequence>
           <xsd:element name="parentTask" type="htt:tTask" minOccurs="0"/>
         </xsd:sequence>
       </xsd:complexType>
     </xsd:element>

     <xsd:element name="getSubtasksResponse">
       <xsd:complexType>
         <xsd:sequence>
           <xsd:element name="subtask" type="htt:tTask" minOccurs="0"
maxOccurs="unbounded"/>
         </xsd:sequence>
       </xsd:complexType>
     </xsd:element>

Dieter reviewed this and provided the following in return.

However, Mark Ford discovered an error in the API WSDL. The type of the
return value of the two operations is wrong because it is not defined in
the data types XML Schema (prefix htt). As a consistency issue between WSDL
and XSD, this was not recognized by the XML Schema validations. Just from
the WSDL point of view, it could be handled as an editorial fix and done
immediately (change "htt:tTask" to "htt:tTaskDetails" in these two places),
but there is also a remark in the API definition table in 7.1.1 that needs
to be changed (for the getSubtasks operation, change "Returns all sub tasks
of a task (created instances + not yet created sub task definitions)") to
"Returns all sub tasks of a task (created instances)".

I propose that we accept Dieters issue.

Proposal:

(1) For the getParentTask and getSubtasks API operations, change the type of the return value from "htt:tTask" to "htt:tTaskDetails"
(2) Change the remark in the API definition table in 7.1.1 that needs to be changed - for the getSubtasks operation, change "Returns all sub tasks of a task (created instances + not yet created sub task definitions)") to "Returns all sub tasks of a task (created instances)".

[BP-144] encoding QNames + Org Entity for HT Advanced query operations

Status:

Applied

Project:

OASIS BPEL4People TC

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None

Type:

Bug

Priority:

Major

Reporter:

Luc Clement

Assigned To:

Dieter Koenig

Resolution:

Fixed

Votes:

0

Submitted by: Mark Ford

Issues raised by: http://lists.oasis-open.org/archives/bpel4people-comment/201003/msg00000.html

Proposal by Dieter Koenig

<dk>
(values in where-clauses - we need to add a clarification here)
(1) For QName instances, we should expect values of the form

      name="{http://example.com}ApproveClaim"

(2) For tOrganizationalEntity instaces, we must split the complex value into separate simple-typed values and should expect them in the form

      potentialOwner.user="userid"
      potentialOwner.group="groupid"
      potentialOwner.user IN ( "userid1", "userid2" , ..., "useridN" )
      potentialOwner.group IN ( "groupid1", "groupid2", ..., "groupidN" )

which can be combined using AND / OR in the usual way.
</dk>

There was a further clarification raised during the 20100331 call. The proposal was amended as follows:

 Proposal: as described above with the modification that the {namespace} part for QName values is optional and treated as wildcards if not specified.

[BP-143] MessageChoice Name Attribute

Status:

Applied

Project:

OASIS BPEL4People TC

Component/s:

PR Comment

Affects Version/s:

None

Fix Version/s:

None

Type:

Improvement

Priority:

Minor

Reporter:

Luc Clement

Assigned To:

Dieter Koenig

Resolution:

Fixed

Votes:

0

Submitted by: Dieter König

Target:

WS-HumanTask 1.1 CD 06 and PRD 01, section 5.3 Message Schema and Appendix B. WS-HumanTask Language Schema and ws-humantask.xsd

Description:

The WS-HT Lean Task pseudosyntax in section 5.3 and all Lean Task examples use a "messageChoice" element with a "name" attribute which has no definition in the XML Schema.

This attribute contains one of the possible values of a "messageField"
element, therefore its semantics are more similar to an XML Schema simple type enumeration value.

Finally, the type of this attribute should not be "xsd:NCName" as it holds values of arbitrary XML Schema simple types.

Proposal:

In the WS-HT Lean Task pseudosyntax in section 5.3 and all Lean Task examples, rename the attribute "name" to "value", and add the definition

   <xsd:attribute name="value" type="xsd:anySimpleType" />

to the "messageChoice" element in Appendix B. WS-HumanTask Language Schema and ws-humantask.xsd.

[BP-142] Definition of element tComment is not complete

Status:

Applied

Project:

OASIS BPEL4People TC

Component/s:

PR Comment

Affects Version/s:

None

Fix Version/s:

None

Type:

Improvement

Priority:

Minor

Reporter:

Luc Clement

Assigned To:

Ivana Trickovic

Resolution:

Fixed

Votes:

0

Submitted by: Ivana Trickovic

Target: ws-humantask-types.xsd, WS-HumanTask specification, version 1.1, PR 1
 
Issue Description:
In the XML file: Definition of element tComment is not complete. Attributes id, lastModifiedTime and lastModifiedby are missing.
In the specification: Attribute ID is of type "xsd:string". Other IDs are of type xsd:anyURI.
These inconsistencies shall be removed.
 
Proposal:
In the XML file, include the following XML snippet
<xsd:complexType name="tComment">
     <xsd:sequence>
       <xsd:element name="id" type="xsd:anyURI" />
       <xsd:element name="addedTime" type="xsd:dateTime" />
       <xsd:element name="addedBy" type="htt:tUser" />
       <xsd:element name="lastModifiedTime" type="xsd:dateTime" />
       <xsd:element name="lastModifiedBy" type="htd:tUser" />
       <xsd:element name="text" type="xsd:string" />
       <xsd:any namespace="##other" processContents="lax"
             minOccurs="0" maxOccurs="unbounded" />
     </xsd:sequence>
</xsd:complexType>
 
instead of
<xsd:element name="comment" type="tComment" />
<xsd:complexType name="tComment">
  <xsd:sequence>
    <xsd:element name="addedTime" type="xsd:dateTime" />
    <xsd:element name="addedBy" type="htt:tUser" />
    <xsd:element name="text" type="xsd:string" />
    <xsd:any namespace="##other" processContents="lax"
             minOccurs="0" maxOccurs="unbounded" />
  </xsd:sequence>
</xsd:complexType>
 
 
In the specification (p. 30), include the following XML snippet:
<xsd:complexType name="tComment">
     <xsd:sequence>
       <xsd:element name="id" type="xsd:anyURI" />
       <xsd:element name="addedTime" type="xsd:dateTime" />
       <xsd:element name="addedBy" type="htt:tUser" />
       <xsd:element name="lastModifiedTime" type="xsd:dateTime" />
       <xsd:element name="lastModifiedBy" type="htd:tUser" />
       <xsd:element name="text" type="xsd:string" />
       <xsd:any namespace="##other" processContents="lax"
             minOccurs="0" maxOccurs="unbounded" />
     </xsd:sequence>
</xsd:complexType>
 
instead of
<xsd:complexType name="tComment">
     <xsd:sequence>
       <xsd:element name="id" type="xsd:string" />
       <xsd:element name="addedTime" type="xsd:dateTime" />
       <xsd:element name="addedBy" type="htt:tUser" />
       <xsd:element name="lastModifiedTime" type="xsd:dateTime" />
       <xsd:element name="lastModifiedBy" type="htd:tUser" />
       <xsd:element name="text" type="xsd:string" />
       <xsd:any namespace="##other" processContents="lax"
             minOccurs="0" maxOccurs="unbounded" />
     </xsd:sequence>
</xsd:complexType>

[BP-141] Type of IDs not consistently defined

Status:

Applied

Project:

OASIS BPEL4People TC

Component/s:

PR Comment

Affects Version/s:

None

Fix Version/s:

None

Type:

Improvement

Priority:

Minor

Reporter:

Luc Clement

Assigned To:

Ivana Trickovic

Resolution:

Fixed

Votes:

0

Submitted by: Ivana Trickovic

Target: WS-HumanTask specification, ws-humantask-api.wsdl, version 1.1, PR 1
 
Issue Description:
The following IDs are defined to be of type xsd:string:
tTaskAbstract
- id
- parentTaskId
 
tTaskDetails
- id
- parentTaskId
 
tTaskQueryResultRow
- id
- parentTaskId
 
Other IDs are of type xsd:anyURI. All IDs shall be of the same type.
 
Proposal:
Set all IDs in the specification and XML file to be of type anyURI.
 

[BP-140] Task API - batchComplete/batchFail input parameters

Status:

Applied

Project:

OASIS BPEL4People TC

Component/s:

PR Comment

Affects Version/s:

None

Fix Version/s:

None

Type:

Improvement

Priority:

Minor

Reporter:

Luc Clement

Assigned To:

Ivana Trickovic

Resolution:

Fixed

Votes:

0

Submitted by: Ivana Trickovic

Target: WS-HumanTask specification, version 1.1, PR 1
 
Issue Description:
batchComplete and batchFail operations are only batch operations that do not have input parameters, other than task identifier. However, the complete operation allows to pass output data of the task. Similarly, the fail operation allows to pass fault data and fault name. Extend the batch operations with optional input parameters.
 
Proposal:
The following changes need to be made in WSDL. The specification text does not need to be changed.
 
Include the following XML snippet:
<xsd:element name="batchComplete">
   <xsd:complexType>
      <xsd:sequence>
         <xsd:element name="identifier" type="xsd:anyURI" maxOccurs="unbounded"/>
         <xsd:element name="taskData" type="xsd:anyType" minOccurs="0"/>
      </xsd:sequence>
   </xsd:complexType>
</xsd:element>
 
instead of
<xsd:element name="batchComplete">
   <xsd:complexType>
      <xsd:sequence>
         <xsd:element name="identifier" type="xsd:anyURI" maxOccurs="unbounded"/>
       </xsd:sequence>
   </xsd:complexType>
</xsd:element>
 
 
Include the following XML snippet:
<xsd:element name="batchFail">
   <xsd:complexType>
      <xsd:sequence>
<xsd:element name="identifier" type="xsd:anyURI" maxOccurs="unbounded"/>
<xsd:element name="fault" type="htt:tFault" minOccurs="0"/>
      </xsd:sequence>
   </xsd:complexType>
</xsd:element>
 
 
instead of
<xsd:element name="batchFail">
   <xsd:complexType>
      <xsd:sequence>
<xsd:element name="identifier" type="xsd:anyURI" maxOccurs="unbounded"/>
      </xsd:sequence>
   </xsd:complexType>
</xsd:element>

[BP-139] Task API - Complete/fail optional parameters

Status:

Applied

Project:

OASIS BPEL4People TC

Component/s:

PR Comment

Affects Version/s:

None

Fix Version/s:

None

Type:

Improvement

Priority:

Minor

Reporter:

Luc Clement

Assigned To:

Ivana Trickovic

Resolution:

Fixed

Votes:

0

Submitted by: Ivana Trickovic

Target: WS-HumanTask specification, version 1.1, PR 1
 
Issue Description:
For the complete operation the specification says (on p. 73): "If no output data is set the operation MUST return hta:illegalArgumentFault."
As the data can also be set using operation setOutput, the output data can be defined as an optional parameter. So this constraint should be removed. The output data is already defined as optional in the WSDL file.
 
For the fail operation the specification says (on p. 74): "If fault name or fault data is not set the operation MUST return hta:illegalArgumentFault."
As the fault data and name can also be set using operation setFault, the fault data and name can be defined as optional parameters. So this constraint should be removed. The fault data and name are already defined as optional in the WSDL file.
 
Proposal: (revised below)
Remove the following statements:
On p. 73 (operation complete): "If no output data is set the operation MUST return hta:illegalArgumentFault."
On p. 74 (operation fail): "If fault name or fault data is not set the operation MUST return hta:illegalArgumentFault."

Proposal revision at http://www.oasis-open.org/apps/org/workgroup/bpel4people/email/archives/201002/msg00007.html. Here is the excerpt

Below please find an updated proposal incorporating also comments raised by Dieter and Phil.
 
On p. 73 (operation complete):
Include
"The fault hta:illegalStateFault MUST be returned if the task interface defines non-empty task output but no output data is provided as the input parameter and the task output data has not been set previously, e.g. using operation setOutput."
 
instead of
 
"If no output data is set the operation MUST return hta:illegalArgumentFault."
 
On p. 74 (operation fail):
 
Include
"The fault hta:illegalStateFault MUST be returned if the task interface defines at least one faults but either fault name or fault data is not provided and it has not been set previously, e.g. using operation setFault."
 
instead of
 
"If fault name or fault data is not set the operation MUST return hta:illegalArgumentFault."

[BP-138] Task API - Extend batch operations

Status:

Closed

Project:

OASIS BPEL4People TC

Component/s:

PR Comment

Affects Version/s:

None

Fix Version/s:

None

Type:

Improvement

Priority:

Minor

Reporter:

Luc Clement

Assigned To:

Ivana Trickovic

Resolution:

Fixed

Votes:

0

Submitted by: Ivana Trickovic

Target: WS-HumanTask specification, version 1.1, PR 1
 
Issue Description:
Batch operations allow to apply the same operation with the same data to multiple task, e.g. set the priority of multiple tasks to the same value. However it is currently not possible to apply the same operation to multiple tasks but with different data, e.g. set the priority of multiple tasks to new values, or complete multiple tasks with different output data, etc.
Extend all batch operations to allow applying the same operation to multiple tasks with different data.

Comment by Luc Clement [ 17/Feb/10 10:23 AM ]

closed with no action to take

[BP-137] Task API - Type of commentID not consistently defined

Status:

Applied

Project:

OASIS BPEL4People TC

Component/s:

PR Comment

Affects Version/s:

None

Fix Version/s:

None

Type:

Improvement

Priority:

Minor

Reporter:

Luc Clement

Assigned To:

Ivana Trickovic

Resolution:

Fixed

Votes:

0

Submitted by: Ivana Trickovic

Target: ws-humantask-api.wsdl, version 1.1, PR 1
 
Issue Description:
Type of commentID not consistently defined. The addComment operation has input data and output data. The input data defines task identifier to be of type xsd:anyURI. The output data defines comment identifier to be of type xsd:string. Other operations, e.g. updateComment, define comment identifier to be of type "xsd:anyURI".
 
Proposal:
Change comment identifier to be of type xsd:anyURI.
The xsd snippet should look as follows:
 
<xsd:element name="addCommentResponse">
      <xsd:complexType>
- < <xsd:sequence>
   <xsd:element name="commentID" type="xsd:anyURI" />
</xsd:sequence>
     </xsd:complexType>
</xsd:element>
 
In addition, make the following changes:
- use the same naming conventions (ws-humantask-api.wsdl): Change "commentID" to "commentIdentifier"

[BP-136] Task API - Type of task identifier not consistently defined

Status:

Applied

Project:

OASIS BPEL4People TC

Component/s:

PR Comment

Affects Version/s:

None

Fix Version/s:

None

Type:

Improvement

Priority:

Minor

Reporter:

Luc Clement

Assigned To:

Ivana Trickovic

Resolution:

Fixed

Votes:

0

Submitted by: Ivana Trickovic

Target: ws-humantask-api.wsdl, version 1.1, PR 1
 
Issue Description:
Type of task identifier not consistently defined. Operations getRendering and getRenderingTypes use task identifier to obtain rendering and rendering types, respectively. They define task identifier to be of type xsd:anyType. Other operations define the identifier to be of type "xsd:anyURI".
 
Proposal:
Change task identifier to be of type xsd:anyURI.
The xsd snippet should look as follows:
 
<xsd:element name="getRendering">
        <xsd:complexType>
          <xsd:sequence>
            <xsd:element name="identifier" type="xsd:anyURI"/>
            <xsd:element name="renderingType" type="xsd:QName"/>
          </xsd:sequence>
        </xsd:complexType>
</xsd:element>
 
<xsd:element name="getRenderingTypes">
        <xsd:complexType>
          <xsd:sequence>
            <xsd:element name="identifier" type="xsd:anyURI"/>
          </xsd:sequence>
        </xsd:complexType>
  </xsd:element>
 

[BP-135] Query operation inconsistencies

Status:

Applied

Project:

OASIS BPEL4People TC

Component/s:

PR Comment

Affects Version/s:

None

Fix Version/s:

None

Type:

Improvement

Priority:

Minor

Reporter:

Luc Clement

Assigned To:

Ivana Trickovic

Resolution:

Fixed

Votes:

0

Submitted by: Ivana Trickovic

Target: WS-HumanTask specification and ws-humantask-api.wsdl, version 1.1, PR 1
 
Issue Description:
A couple of inconsistencies have been found:
1. The specification says that getMyTaskAbstract has the following input parameters:

    * task type ("ALL" | "TASKS" | "NOTIFICATIONS")
    * generic human role
    * work queue
    * status list
    * where clause
    * order-by clause
    * created-on clause
    * maxTasks
    * taskIndexOffset

"order-by clause" and "taskIndexOffset" are not included in the wsdl file.
 
2. Operations getMyTaskAbstract and getMyTaskDetails differ in the list of input parameters. Operation getMyTaskDetails does not allow to specify "order-by clause" and "taskIndexOffset".
 
3. The type of "maxTasks" not consistently defined
 
Proposal:
1. Change element getMyTaskAbstract (in ws-humantask-api.wsdl) as follows:
<xsd:element name="getMyTaskAbstracts">
  <xsd:complexType>
    <xsd:sequence>
  <xsd:element name="taskType" type="xsd:string" />
  <xsd:element name="genericHumanRole" type="xsd:string" minOccurs="0" />
  <xsd:element name="workQueue" type="xsd:string" minOccurs="0" />
  <xsd:element name="status" type="htt:tStatus" minOccurs="0" maxOccurs="unbounded" />
  <xsd:element name="whereClause" type="xsd:string" minOccurs="0" />
  <xsd:element name="orderByClause" type="xsd:string" minOccurs="0" />
  <xsd:element name="createdOnClause" type="xsd:string" minOccurs="0" />
  <xsd:element name="maxTasks" type="xsd:int" minOccurs="0" />
  <xsd:element name="taskIndexOffset" type="xsd:int" minOccurs="0" />
    </xsd:sequence>
  </xsd:complexType>
</xsd:element>
 
2. Extend the list of input data of operation getMyTaskDetails to allow defining "order-by clause" and "taskIndexOffset", in the specification (section 7.1.2) and wsdl file .
The xsd snippet should look as follows:
 
<xsd:element name="getMyTaskDetails">
     <xsd:complexType>
        <yxsd:sequence>
         <xsd:element name="taskType" type="xsd:string" />
<xsd:element name="genericHumanRole" type="xsd:string" minOccurs="0" />
<xsd:element name="workQueue" type="xsd:string" minOccurs="0" />
<xsd:element name="status" type="htt:tStatus" minOccurs="0" maxOccurs="unbounded" />
<xsd:element name="whereClause" type="xsd:string" minOccurs="0" />
  <xsd:element name="orderByClause" type="xsd:string" minOccurs="0" />
<xsd:element name="createdOnClause" type="xsd:string" minOccurs="0" />
<xsd:element name="maxTasks" type="xsd:int" minOccurs="0" />
  <xsd:element name="taskIndexOffset" type="xsd:int" minOccurs="0" />
      </xsd:sequence>
   </xsd:complexType>
</xsd:element>
 
3. Change maxTasks to be of type xsd:int instead of xsd:integer for operation "GetTaskHistory".
 

[BP-134] Task API - missing operations in the wsdl file

Status:

Applied

Project:

OASIS BPEL4People TC

Component/s:

PR Comment

Affects Version/s:

None

Fix Version/s:

None

Type:

Improvement

Priority:

Minor

Reporter:

Luc Clement

Assigned To:

Ivana Trickovic

Resolution:

Fixed

Votes:

0

Submitted by: Ivana Trickovic

Target: ws-humantask-api.wsdl, version 1.1, PR 1
 
Issue Description:
The following operations are not included in the ws-humantask-api.wsdl file: updateComment, deleteComment, getSubtasks, getSubtaskIdentifiers, hasSubtasks, getParentTask, getParentTaskIdentifier, isSubtask, instantiateSubTask.

Proposal at: http://www.oasis-open.org/apps/org/workgroup/bpel4people/email/archives/201002/msg00005.html

The TC approved the proposal with the following changes:

Dieter Koenig: Three minor suggestions:
(1) Rename getParentTasksIdentifier to getParentTaskIdentifier (as in the spec -- this is probably just a typo)
(2) Prefix some of the WSDL part names like subTask or parentTask (four places) -- in the case of getParentTaskIdentifier, this avoids interpreting the taskIdentifier as an in/out parameter (the task ids are different in request and response)
(3) The result element of getParentTaskIdentifier and getParentTask should be optional (minOccurs="0") -- not every task has a parent

Dieter Koenig: (1) is just about the request/response elements, the wsdl message and operation seem to be ok

[BP-133] Result Aggregation Default Behavior

Status:

Applied

Project:

OASIS BPEL4People TC

Component/s:

PR Comment

Affects Version/s:

None

Fix Version/s:

None

Type:

Improvement

Priority:

Minor

Reporter:

Luc Clement

Assigned To:

Dieter Koenig

Resolution:

Fixed

Votes:

0

Reported By: Dieter König

Target: WS-HumanTask 1.1 CD 06 and PRD 01, section 4.8 Completion Behavior and section 7.2 XPath Extension Functions

Description:

WS-HT 1.1 section 4.8.2.1 describes the result construction from parallel subtasks using declarative result aggregation. In addition, section 7.2 defines XPath aggregation functions helping a WS-HT processor in performing this result aggregation. Section 7.2 also describes the returned value of an XPath function invoked with an empty node set.

This description is incomplete.

In addition to describing the XPath function results, it must be described what the parent task's output field will look like (in XML terms -- "NaN"
is just an XPath convention). This description has to consider a number of cases for the XML Schema definition of the aggregated XML value:
      Aggregation of XML elements vs. attributes
      Mandatory (minOccurs="1") vs. optional (minOccurs="0") elements
      Mandatory (use="required") vs. optional (use="optional") attributes
      Default value specified (default="...") vs. unspecified
      Null value allowed (nillable="true") vs. disallowed
      (nillable="false")

Finally, by default, the numeric XPath functions themselves should all return "NaN" for consistency reasons.

Proposal:

Between the end of the normative text in section 4.8.2.1 and the examples at the end of the section, add the following text.

<new_paragraph>

If a declarative result aggregation is applied, it is still possible that no values can be provided for the aggregation of a particular output field, for example, if no subtask has set a value to an optional field (by omission or by an explicit nil value).

In this case, the following rules determine how the aggregated output field of the parent task is set.
   (1) -- If the result value is optional (element defined with
   minOccurs="0" or attribute defined with use="optional") then the
   corresponding element or attribute in the parent task output MUST be
   omitted.
   (2) -- If (1) does not apply and a default value is provided (element or
   attribute with default="{value}") then the parent task output element or
   attribute MUST be explicitly set to this default value.
   (3) -- If (1)-(2) do not apply and the result value is a nillable
   element (element defined with nillable="true") then the parent task
   output element MUST be set to a nil value (<a xsi:nil="true"/>).
   (4) -- If (1)-(3) do not apply, that is, the result is mandatory
   (element defined with minOccurs="1" or attribute defined with
   use="required") but a value cannot be supplied, then a standard fault
   htd:aggregationFailure MUST be thrown to indicate a non-recoverable
   error.

</new_paragraph>

Finally, at the end of section 7.2, change the default behavior of the "sum" XPath function from:
   "Returns the sum value of all number nodes - returns 0 for an empty
   node-set"
to:
   "Returns the sum value of all number nodes - returns NaN for an empty
   node-set"

[BP-132] Mismatch between the specification text and XSD/XSD snippets in the document

Status:

Applied

Project:

OASIS BPEL4People TC

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None

Type:

Improvement

Priority:

Minor

Reporter:

Luc Clement

Assigned To:

Luc Clement

Resolution:

Unresolved

Votes:

0

Submitted by: Ivana Trickovic

Target: WS-HumanTask 1.1 CD 05 revision 10
 
Issue Description:
Elements "peopleAssignment" and "presentationElements" are defined as optional elements in section 4.1 (Overall Syntax) and ws-humantask.xsd.
Section 4.2 says that these elements are mandatory.
Remove the inconsistency between the specification text and the XSD.
 
Proposal:
Make the following changes in section 4.2, lines 1374 and 1392:
 
Include
 
"The element is optional."
 
Instead of
 
"The element is mandatory."
 

[BP-131] Need Conformance Sections for HT and B4P specs

Status:

Applied

Project:

OASIS BPEL4People TC

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None

Type:

Improvement

Priority:

Minor

Reporter:

Luc Clement

Assigned To:

Luc Clement

Resolution:

Unresolved

Votes:

0

Submitted by Dieter Koenig

Target:

WS-HumanTask 1.1 CD 05 revision 10, section 12 Conformance BPEL4People 1.1 CD 05 revision 3, section 8 Conformance

Description:

Both sections are empty.

Proposal:

Add the following content:

WS-HT, 12. Conformance

The XML schema pointed to by the RDDL document at the namespace URI, defined by this specification, are considered to be authoritative and take precedence over the XML schema defined in the appendix of this document.

There are four conformance targets defined as part of this specification: a WS-HumanTask Definition, a WS-HumanTask Processor, a WS-HumanTask Parent and a WS-HumanTask Client (see section 2.3). In order to claim conformance with WS-HumanTask 1.1, they MUST comply with all normative statements in this specification (for each conformance target, respectively), notably all MUST statements have to be implemented.

B4P, 8. Conformance

The XML schema pointed to by the RDDL document at the namespace URI, defined by this specification, are considered to be authoritative and take precedence over the XML schema defined in the appendix of this document.

There are four conformance targets defined as part of this specification: a BPEL4People Definition, a BPEL4People Processor, a WS-HumanTask Definition and a WS-HumanTask Processor (see section 2.3). In order to claim conformance with BPEL4People 1.1, they MUST comply with all normative statements in the BPEL4People and the WS-HumanTask specification (for each conformance target, respectively), notably all MUST statements have to be implemented.

Comment by Luc Clement [ 28/Oct/09 10:46 AM ]

Proposal accepted with the following amendments:

Phil: Proposal: they => the implementations of these conformance targets
Sean Gabriel: Discussion -> to address ambiguity of "they", need to clearly define which conformance targets are being referenced
Dave Ings: Proposal: amenda Dieter's draft by replaceing the word "they" with "the conformance targets" and deleting the text in parenthesis.
Sean Gabriel: Motion to accept BP-131 (changing "they" with Dave's proposal, applied to each spec)

[BP-130] Name of startDeadline/completionDeadline must be unique

Status:

Applied

Project:

OASIS BPEL4People TC

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None

Type:

Improvement

Priority:

Minor

Reporter:

Luc Clement

Assigned To:

Luc Clement

Resolution:

Unresolved

Votes:

0

Submitted by: Ivana Trickovic

Target:
 
WS-HumanTask 1.1 CD 05 revision 10
 
Issue Description:
Proposal for issue BP-127 introduced operations that use name of startDeadline/completionDeadline as input parameter. The specification must mandate that the name of startDeadline and completionDeadline are unique among the names of all deadlines specified within a task definition.
 
 
Proposal:
 
In section 4.9 make the following change: Add sentence
 
"The value of the name attribute MUST be unique for all deadline specifications within a task definition."
 
at the end of the following paragraph:
 
"The element <deadlines> is used to include the definition of all deadlines within the task definition. It is optional. If present then the WS-HumanTask Definition MUST specify at least one deadline. Deadlines defined in ad-hoc sub tasks created at runtime MUST NOT contradict the deadlines of their parent task."
 

[BP-129] XPath Context Undefined

Status:

Applied

Project:

OASIS BPEL4People TC

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None

Type:

Improvement

Priority:

Minor

Reporter:

Luc Clement

Assigned To:

Dieter Koenig

Resolution:

Unresolved

Votes:

0

Submitted by: Dieter Koenig

Target:

WS-HumanTask 1.1 CD 05 revision 9
BPEL4People 1.1 CD 05 revision 2

Description:

When XPath 1.0 is used as an Expression Language in BPEL4People or WS-HumanTask language elements then the XPath context is undefined.

The following proposal is inspired by WS-BPEL 2.0 section 8.2.4 (
http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html#_Ref130811481
).

Proposal:

In the WS-HumanTask specification, add a new section:
========================================
2.6 Default use of XPath 1.0 as an Expression Language The XPath 1.0 specification [XPATH 1.0] defines the context in which an XPath expression is evaluated. When XPath 1.0 is used as an Expression Language in WS-HumanTask language elements then the XPath context is initialized as follows:
-- Context node: none
-- Context position: none
-- Context size: none
-- Variable bindings: none
-- Function library: Core XPath 1.0 and WS-HumanTask functions MUST be available and processor-specific functions MAY be available
-- Namespace declaration: all in-scope namespace declarations from the enclosing element

Note that XPath 1.0 explicitly requires that any element or attribute used in an XPath expression that does not have a namespace prefix must be treated as being namespace unqualified. As a result, even if there is a default namespace defined on the enclosing element, the default namespace will not be applied.
========================================

In the BPEL4People 1.1 specification, add a new section:
========================================
2.6 Default use of XPath 1.0 as an Expression Language The XPath 1.0 specification [XPATH 1.0] defines the context in which an XPath expression is evaluated. When XPath 1.0 is used as an Expression Language in BPEL4People or inlined WS-HumanTask language elements then the XPath context is initialized as follows:
-- Context node: none
-- Context position: none
-- Context size: none
-- Variable bindings: all WS-BPEL variables visible to the enclosing element as defined by the WS-BPEL scope rules
-- Function library: Core XPath 1.0, WS-BPEL, BPEL4People and WS-HumanTask functions MUST be available and processor-specific functions MAY be available
-- Namespace declaration: all in-scope namespace declarations from the enclosing element

Note that XPath 1.0 explicitly requires that any element or attribute used in an XPath expression that does not have a namespace prefix must be treated as being namespace unqualified. As a result, even if there is a default namespace defined on the enclosing element, the default namespace will not be applied.
========================================

Comment by Dave Ings [ 21/Oct/09 10:32 AM ]

Opened as per 10/21 TC.

[BP-128] CreateLeanTask Interaction Styles

Status:

Applied

Project:

OASIS BPEL4People TC

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None

Type:

Improvement

Priority:

Minor

Reporter:

Luc Clement

Assigned To:

Dieter Koenig

Resolution:

Unresolved

Votes:

0

File Attachments:

Lean Task Interactions + DK.doc     ws-humantask-leantask-api.wsdl    

Submitted by: Dieter Koenig

Refer to: http://lists.oasis-open.org/archives/bpel4people/200910/msg00009.html

Target:

WS-HumanTask 1.1 CD 05 revision 8
 + Issue 111 resolution attached to
http://www.oasis-open.org/apps/org/workgroup/bpel4people/email/archives/200910/msg00003.html
 + Issue 111 resolution amendment within TC call minutes in
http://www.oasis-open.org/apps/org/workgroup/bpel4people/email/archives/200910/pdf00000.pdf

Description:

The amended issue 111 resolution describes "createLeanTask" as a one-way
operation. This operation definition must be revised such that the invoked
lean task's output can be returned.

Proposal:

In the same way as an operation implemented by a standard WS-HT task, the
"createLeanTask" operation should support two interaction styles:
(1) A request-response operation returning the lean task's output -- note
that this is a long-running operation that can only be invoked via
asynchronous protocols.
(2) A one-way operation that also accepts an EPR which is used for a
callback in order to deliver the lean task's output.

Revise the CreateLeanTask operation definition as shown in the attached
document "Lean Task Interactions + DK.doc" (see change tracking). Note that
this proposal document also contains additional formatting and a minor
simplification of lean task operation names.

Introduce a new WS-HT XML namespace on page 2 of the WS-HumanTask
specification:

      htlt -
      http://docs.oasis-open.org/ns/bpel4people/ws-humantask/leantask/api/200803


and a new WSDL artifact defining the lean task operations (see attached
file "ws-humantask-leantask-api.wsdl").

(See attached file: Lean Task Interactions + DK.doc)(See attached file:
ws-humantask-leantask-api.wsdl)

Comment by Dieter Koenig [ 11/Oct/09 03:49 AM ]

Revision of WS-HT 1.1 Chapter 9 (Lean Tasks)

Comment by Dieter Koenig [ 11/Oct/09 03:50 AM ]

New WS-HT 1.1 WSDL artifact (Lean Task API Operations)

Comment by Dave Ings [ 21/Oct/09 10:20 AM ]

Opened as per 10/21 TC.

[BP-127] WS-HT API's required to set task deadlines

Status:

Applied

Project:

OASIS BPEL4People TC

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None

Type:

Improvement

Priority:

Minor

Reporter:

Luc Clement

Assigned To:

Dieter Koenig

Resolution:

Unresolved

Votes:

0

Reported by: Ralf Mueller

Target:

Latest WS-HT spec

Description:

As part of the the discussion on BP-104, a new set of WS-HT API's needs to be added to
set a task deadlines duration or deadline expression of the startDeadline and completionDeadline

Proposal:

1. Modify type "tDeadline" in ws-humantask.xsd to include a name attribute
    for deadlines. This is to identify a deadline out of the potential many deadlines
   a task might specify
  <xsd:complexType name="tDeadline">
    <xsd:complexContent>
      <xsd:extension base="tExtensibleElements">
        <xsd:sequence>
          <xsd:choice>
            <xsd:element name="for" type="tDuration-expr" />
            <xsd:element name="until" type="tDeadline-expr" />
          </xsd:choice>
          <xsd:element name="escalation" type="tEscalation" minOccurs="0" maxOccurs="unbounded" />
        </xsd:sequence>
        <xsd:attribute name="name" type="xsd:NCName" use="required"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  
2. WS-HT Chapter 7.1.1., Participant Operations
Add the following API's:

setTaskStartDeadlineExpression
In:
  task identifier
  deadline name
  deadline expression
Out:
  void

setTaskStartDurationExpression
In:
  task identified
  deadline name
  duration expression
Out:
  void

setTaskCompletionDeadlineExpression
In:
  task identifier
  deadline name
  deadline expression
Out:
  void

setTaskCompletionDurationExpression
In:
  task identifier
  deadline name
  duration expression
Out:
  void
  
Operations above should support Batch Processing, the Pre-State is CreatedReady, Reserved, In Progress and
there is no state transition as part of above operations

Please note that above API's simply set the duration or deadline expressions of a task deadline. As an alternative
we could have the API overwrite the entire startDeadline, completionDeadline definition (including the deadline
escalation definitions). Personally, i wouldn't go that route though.

Comment by Dave Ings [ 21/Oct/09 10:14 AM ]

Opened as per 10/21 TC.

[BP-126] NEW ISSUE: RDDL document creation for declared namespaces

Status:

Applied

Project:

OASIS BPEL4People TC

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None

Type:

Task

Priority:

Minor

Reporter:

Luc Clement

Assigned To:

Dave Ings

Resolution:

Unresolved

Votes:

0

Submitted by: Martin Chapman

Target:
 
  New document(s)
 
Description:
 
When we publish to docs.oasis-open.org (required as part of public review) we need to provide a RDDL document. A RDDL document - if an http namespace is declared - contains meta-data about the specifications, and our namespace URLs need to point to such a documents. An example is WS-BPEL 2.0:http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v20-rddl.html
 
Proposal:
 
  Using the template at http://docs.oasis-open.org/templates/rddl.html ,edit specific versions for our specs. It is not clear to me whether we need to have one rddl per
  spec, so this is up for discussion/clarification.

Comment by Dave Ings [ 23/Sep/09 10:23 AM ]

Opened as per 9/23 TC.

Comment by Dave Ings [ 04/Nov/09 10:30 AM ]

Resolved as per 11/04 TC minutes.

[BP-125] OrganizationalEntity Cannot Contain Users AND Groups

Status:

Applied

Project:

OASIS BPEL4People TC

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None

Type:

Improvement

Priority:

Minor

Reporter:

Luc Clement

Assigned To:

Dieter Koenig

Resolution:

Unresolved

Votes:

0

Submitted by: Dieter Koenig

Target:

WS-HumanTask 1.1 CD 05 revision 03, Section 3.4.4 Data Type for
Organizational Entities and "ws-humantask-types.xsd". Also affected are
BPEL4People 1.1 CD 05 and example XML artifacts.

Description:

Section 3.4.4 defines the tOrganizationalEntity data type. It is used in
literal people assignments and API operations like forward or nominate.

Queries used to resolve logical people groups may return users or groups.
Moreover, they may also return mixed sets of users and groups. Likewise,
other occurrences of tOrganizationalEntity may also require support for
such mixed sets.

The choice allows an element of this type to contain EITHER a list of zero
or more users OR a list of zero or more groups, but not users AND groups.

<xsd:element name="organizationalEntity" type="tOrganizationalEntity"/>
<>xsd:complexType name="tOrganizationalEntity">
  <xsd:choice
    <xsd:element ref:="users"/>
    <xsd:element ref:="groups"/>
  </xsd:choice>
</xsd:complexType>

<xsd:element name="user" type="tUser"/>
<>xsd:simpleType name="tUser">
  <xsd:restriction base="xsd:string"/>
</xsd:simpleType>

<xsd:element name="users" type="tUserlist"/>
<>xsd:complexType name="tUserlist">
  <xsd:sequence>
    <xsd:element ref:="user" minOccurs="0" maxOccurs="unbounded"/>
  </xsd:sequence>
</xsd:complexType>

<xsd:element name="group" type="tGroup"/>
<>xsd:simpleType name="tGroup">
  <xsd:restriction base="xsd:string"/>
</xsd:simpleType>

<xsd:element name="groups" type="tGrouplist"/>
<>xsd:complexType name="tGrouplist">
  <xsd:sequence>
    <xsd:element ref:="group" minOccurs="0" maxOccurs="unbounded"/>
  </xsd:sequence>
</xsd:complexType>


Proposal:

Also allow the presence of users AND groups in an element of type
tOrganizationalEntity.

(A) Change the first paragraph in 3.4.4 from:
"The following XML schema definition describes the format of the data that
is returned at runtime when evaluating a logical people group. The result
can contain either a list of users or a list of groups. The latter is used
to defer the resolution of one or more groups of people to a later point,
such as when the user accesses a task list."

to:
"The following XML schema definition describes the format of the data that
is returned at runtime when evaluating a logical people group. The result
can contain a list of users or groups. A group is used to defer the
resolution of a group of people to a later point, such as when the user
accesses a task list."

(B) Change the XML Schema type definitions as follows (also in
"ws-humantask-types.xsd"):

<xsd:element name="organizationalEntity" type="tOrganizationalEntity"/>
<>xsd:complexType name="tOrganizationalEntity">
  <xsd:choice minOccurs="0" maxOccurs="unbounded">
    <xsd:element name="user" type="tUser"/>
    <xsd:element name="group" type="tGroup"/>
  </xsd:choice>
</xsd:complexType>

<xsd:element name="user" type="tUser"/>
<>xsd:simpleType name="tUser">
  <xsd:restriction base="xsd:string"/>
</xsd:simpleType>

<xsd:element name="group" type="tGroup"/>
<>xsd:simpleType name="tGroup">
  <xsd:restriction base="xsd:string"/>
</xsd:simpleType>

(C) Make all operation signatures referencing the existing list types
tUsers and tGroups consistent with the above definition.

(D) Make all examples using elements of type tOrganizationalEntity, tUsers
and tGroups in WS-HT, B4P and example XML artifacts consistent with the
above definition.

Comment by Dave Ings [ 22/Sep/09 08:15 AM ]

Opened as per 9/16 TC.

Comment by Dave Ings [ 22/Sep/09 08:17 AM ]

As per 9/16 TC

Comment by Dave Ings [ 22/Sep/09 08:18 AM ]

Resolved as per 9/16 TC minutes.

[BP-124] Location Attribute Mandatory in Result Aggregation

Status:

Applied

Project:

OASIS BPEL4People TC

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None

Type:

Improvement

Priority:

Major

Reporter:

Luc Clement

Assigned To:

Dieter Koenig

Resolution:

Unresolved

Votes:

0

Submitted by: Dieter Koenig

Target: WS-HumanTask CD 05 revision 02, Section 4.7.2 Declarative Result Aggregation

Description:

Section 4.7.2 defines the <aggregate> element used to combine output from multiple subtasks.
<htd:aggregate location="query" condition="bool-expr"? function= "function-call"/>

If a task interface (or an individual WSDL part, see also issue BP-123) only has one simple-typed element then the location query can be optional.
The aggregation function is then applied to this single simple-typed element. Example: an approval step which just returns a boolean value.

Proposal:

In section 4.7.2, make the @location attribute optional within the <aggregate> element:
<htd:aggregate location="query"? condition="bool-expr"? function= "function-call"/> (question mark added to @location)

In the explanation, change from:
"The mandatory location attribute MUST contain ..."
to:
"The optional location attribute MUST contain ..."

[BP-123] WSDL Part Name Missing in Result Aggregation

Status:

Applied

Project:

OASIS BPEL4People TC

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None

Type:

Improvement

Priority:

Minor

Reporter:

Luc Clement

Assigned To:

Dieter Koenig

Resolution:

Unresolved

Votes:

0

Submitted by: Dieter Koenig

Target:

WS-HumanTask CD 05 revision 02, Section 4.7.2 Declarative Result Aggregation

Description:

Section 4.7.2 defines the <aggregate> element used to combine output from multiple subtasks:
<htd:aggregate location="query" condition="bool-expr"? function= "function-call"/>

An interface of a task (and its subtasks) may be defined using a WSDL message with multiple WSDL parts. In this case, the @location attribute is not sufficient to uniquely identify the source and target of the aggregation function. It is unclear to which WSDL part the location query is applied.

Proposal:

In section 4.7.2, add an optional @part attribute to the <aggregate>
element:
<htd:aggregate part="NCName"? location="query" condition="bool-expr"?
function="function-call"/>

with the following explanation:
"The optional part attribute MUST contain the name of a WSDL part. The part attribute MUST be specified when the task interface is defined using a WSDL message with more than one WSDL part."

[BP-122] Task Definition Structure

Status:

Closed

Project:

OASIS BPEL4People TC

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None

Type:

Improvement

Priority:

Minor

Reporter:

Luc Clement

Assigned To:

Dieter Koenig

Resolution:

No Action

Votes:

0

Submitted by:

Target: WS-HumanTask CD 05 revision 02, Section 4 Human Tasks and Section 5 Lean
Tasks; ws-humantask.xsd

Description:

The definition of composite tasks requires three elements for each
composition nesting level.

<task name="...">
  <composition type="..." activationPattern="...">?
    <subtask name="...">+
      <task name="...">>
        <composition type="..." activationPattern="...">?
          <subtask name="...">+
            ...

This is an unnecessary syntax complexity -- one element nesting level can
be saved for each composition nesting level.

Moreover, both subtask and task have a @name attribute -- this is confusing
when referencing the name in completion conditions or result aggregations.

Finally, the overriding elements in the <localTask> element create an
unnecessary complexity within a set of task definitions.


Proposal:

   (See attached file: Task Definition Structure.doc)(See attached file:
   ws-humantask - work in progress.xsd)

Use one composition element with @compositionType and @activationPattern
attributes. Add a @name attribute to the <localTask> element such that each
child of <subtasks> has a name. Remove the overriding elements from
<localTask>.

<task name="...">
  <subtasks compositionType="..." activationPattern="...">?
    <task name="...">+
      <subtasks compositionType="..." activationPattern="...">?
        ...

Submission email: http://lists.oasis-open.org/archives/bpel4people/200908/msg00000.html.

See the attachments for more details. Note that the XML Schema file already
anticipates other issue resolutions such as BP-97, BP-102 (which are not
important for this issue discussion).

Comment by Luc Clement [ 07/Oct/09 10:37 AM ]

We decided to close with no action.

[BP-121] Optional PeopleAssignments and PresentationElements

Status:

Applied

Project:

OASIS BPEL4People TC

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None

Type:

Improvement

Priority:

Minor

Reporter:

Luc Clement

Assigned To:

Dieter Koenig

Resolution:

Unresolved

Votes:

0

Submitted by: Dieter Koenig

Target:

WS-HumanTask CD 05 revision 02, section 4.1 Overall Syntax

Description:

In the syntax definition for human tasks, the two elements
<peopleAssignments> and <presentationElements> are mandatory.

For composite tasks, routing patterns, and lean tasks, they should not be
required.

Proposal:

Make both elements optional, that is, add a '?' to <peopleAssignments> and
<presentationElements> within the <task> syntax in 4.1.

[BP-120] Missing (Forbidden) Composition Element in Lean Tasks

Status:

Applied

Project:

OASIS BPEL4People TC

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None

Type:

Improvement

Priority:

Minor

Reporter:

Luc Clement

Assigned To:

Dieter Koenig

Resolution:

Unresolved

Votes:

0

Submitted by: Dieter Koenig

Target:

WS-HumanTask CD 05 revision 02, section 5.1 Lean Tasks

Description:

The new element <htd:composition> can be used in a human task definition in
order to define a composite task. However, it should be explicitly
forbidden in a lean task definition.

Proposal:

Add the element

  <htd:composition>
    ...
  </htd:composition>

at the end of the syntax definition for the <leanTask> element in section
5.1, but show it using a *** strike through *** style in order to clarify
that it is forbidden in lean tasks.

[BP-119] Missing Composition Element

Status:

Applied

Project:

OASIS BPEL4People TC

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None

Type:

Improvement

Priority:

Major

Reporter:

Luc Clement

Assigned To:

Dieter Koenig

Resolution:

Unresolved

Votes:

0

Submitted by: Dieter Koenig

Target:

WS-HumanTask CD 05 revision 02, section 4.1 Overall Syntax

Description:

The new element <htd:composition> is missing in the syntax of the human
task definition.

Proposal:

Add the element

  <htd:composition>?
    ...
  </htd:composition>

at the end of the syntax definition for the <task> element in section 4.1.

[BP-118] Usage of Term "Task Type" in WS-HT

Status:

Applied

Project:

OASIS BPEL4People TC

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None

Type:

Improvement

Priority:

Minor

Reporter:

Luc Clement

Assigned To:

Ravi Rangaswamy

Resolution:

Unresolved

Votes:

0

Submitted by: Dieter König

Target: WS-HumanTask CD 05 revision 02

Description:

The term "task type" is used inconsistently -- sometimes in the sense of "task definition" (as opposed to "task instance") and sometimes in the sense of "task vs. notification" (e.g. in the API).

Proposal: http://lists.oasis-open.org/archives/bpel4people/200908/msg00004.html

[BP-117] Usage of Term "People Activity" in WS-HT

Status:

Applied

Project:

OASIS BPEL4People TC

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None

Type:

Improvement

Priority:

Minor

Reporter:

Luc Clement

Assigned To:

Luc Clement

Resolution:

Unresolved

Votes:

0

Submitted by: Dieter Koenig

Target:

WS-HumanTask CD 04 revision 04, section 3.2 Composite Tasks and Sub Tasks, second paragraph

Description:

This paragraph has a sentence "Therefore the existence of sub tasks usually won't be visible on people activity level".

There is no concept of people activities in WS-HT and there must not be a reference to BPEL4People.

Proposal:

Drop this sentence.

Comment by Dave Ings [ 08/Jul/09 03:52 PM ]

Opened at 7/8 TC.

Comment by Dave Ings [ 08/Jul/09 03:53 PM ]

Proposed resolution accepted at 7/8 TC.

[BP-116] Missing Pre-State / Post-State Specifications for Administrative Operations

Status:

Applied

Project:

OASIS BPEL4People TC

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None

Type:

Improvement

Priority:

Minor

Reporter:

Luc Clement

Assigned To:

Dieter Koenig

Resolution:

Unresolved

Votes:

0

File Attachments:

BP-116 - ws-humantask-1.1-spec.doc     BP-116 rev1 - ws-humantask-1.1-spec.doc    

Submitted by: Dieter Koenig

Target:

WS-HumanTask CD 04 revision 03, section 7.1.4 Operation Authorizations

Description:

Section 7.1.4 introduces client operations for administrative purposes.
Unlike section 7.1.1, which specifies the general-purpose client operations, the table in 7.1.4 has no columns defining the task pre-states in which an operation may be called and the task post-state after the operation is performed.

Proposal:.

Add the following paragraph (copied from 7.1.1) before the table in 7.1.4:

<newParagraph>
If the task is in a predefined state listed as valid pre-state before the
operation is invoked then, upon successful completion, the task MUST be in
the post state defined for the operation. If the task is in a predefined
state that is not listed as valid pre-state before the operation is invoked
then the operation MUST be rejected and MUST NOT cause a task state
transition.
</newParagraph>

In addition, add two columns "Pre-State" and "Post-State" to the table in
7.1.4, with the following content:

+---------------------+ ... +-------------+--------------+
| Operation Name | ... | Pre-State | Post-State |
+---------------------+ ... +-------------+--------------+
| activate | ... | Created | Ready |
+---------------------+ ... +-------------+--------------+
| nominate | ... | Created | Ready |
| | ... | | Reserved |
+---------------------+ ... +-------------+--------------+
| setGenericHumanRole | ... | Created | (no state |
| | ... | Ready | transition) |
| | ... | Reserved | |
| | ... | InProgress | |
+---------------------+ ... +-------------+--------------+

Comment by Dieter Koenig [ 04/Jul/09 09:20 AM ]

The file attachment shows the proposed two new columns for the table that defines administrative operations.

Comment by Dieter Koenig [ 22/Jul/09 11:12 AM ]

Revised proposal - setGenericHumanRole can now be called in all non-final states (I added the Suspended/* states)

[BP-115] Missing Authorization Specifications for Batch Operations

Status:

Applied

Project:

OASIS BPEL4People TC

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None

Type:

Bug

Priority:

Minor

Reporter:

Luc Clement

Assigned To:

Dieter Koenig

Resolution:

Unresolved

Votes:

0

Submitted by: Dieter Koenig

Target:

WS-HumanTask CD 04 revision 03, section 7.1.5 Operation Authorizations

Description:

The resolution of BP-69 introduced a number of batch operations (see section 7.1.1):
 - batchClaim
 - batchStart
 - batchStop
 - batchRelease
 - batchSuspend
 - batchSuspendUntil
 - batchResume
 - batchComplete
 - batchRemove
 - batchFail
 - batchSetPriority
 - batchSkip
 - batchForward
 - batchDelegate
 - batchActivate
 - batchNominate
 - batchSetGenericHumanRole

The specification of the corrresponding operation authorizations are missing.

Proposal:

Batch operations interact with multiple tasks simultaneously, and the authorization for each interaction has to be decided individually.
Consequently, add the following paragraph to section 7.1.5 Operation Authorizations, right before the table that defines the operation-specific
authorizations:

<newParagraph>
All batch operations (operations with a name prefix "batch") may be invoked by any caller; no specific authorization is required. Missing authorizations for operations on individual tasks result in a report entry in the batch operation's response message.
</newParagraph>

In addition, add a generic entry to the table (operation name = "batch*", all entries = "+").

[BP-114] Missing Spec Text in Section 4.6 Elements for Composite Tasks

Status:

Applied

Project:

OASIS BPEL4People TC

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None

Type:

Improvement

Priority:

Minor

Reporter:

Luc Clement

Assigned To:

Ivana Trickovic

Resolution:

Fixed

Votes:

0

Submitted by: Dieter Koenig

Target:

WS-HumanTask CD 04 revision 04, section 4.6 Elements for Composite Tasks

Description:

The section has one syntax definition element but no text -- introduction text must be added, explaining the introduced syntax.

Proposal: http://www.oasis-open.org/apps/org/workgroup/bpel4people/email/archives/200908/msg00025.html with the following amendment:

Change
- Original text: creationPattern: This optional attribute specifies the way how sub-tasks are created. If the value is set to manual the task client triggers creation of enclosed sub-tasks. Otherwise, they are automatically created at the time the composite task itself turns into status inProgress. The default value for this attribute is manual.

To:
- Changed text: instantiationPattern: This optional attribute specifies the way how sub-tasks are instantiated. If the value is set to manual the task client triggers instantiation of enclosed sub-tasks. Otherwise, they are automatically instantiated at the time the composite task itself turns into status inProgress. The default value for this attribute is manual.

Comment by Dave Ings [ 08/Jul/09 04:07 PM ]

Resolved due to fat fingers. Will be reopened.

[BP-113] Missing Authorization Specifications for new Operations

Status:

Applied

Project:

OASIS BPEL4People TC

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None

Type:

Improvement

Priority:

Minor

Reporter:

Luc Clement

Assigned To:

Dieter Koenig

Resolution:

Unresolved

Votes:

0

Submitted by Dieter Koenig

Target:

WS-HumanTask CD 04 revision 03

Description:

The resolution of BP-28 introduced a number of new operations (see section 7.1.1):
- getSubtasks
- getSubtaskIdentifiers
- hasSubtasks
- getParentTask
- getParentTaskIdentifier
- isSubtask

The corresponding operation authorizations (see section 7.1.5) are missing..

Proposal:

Posted with http://www.oasis-open.org/apps/org/workgroup/bpel4people/email/archives/200907/msg00017.html

[BP-112] Aggregation Functions Invoked with Empty Node-Set

Status:

Applied

Project:

OASIS BPEL4People TC

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None

Type:

Improvement

Priority:

Minor

Reporter:

Luc Clement

Assigned To:

Dieter Koenig

Resolution:

Unresolved

Votes:

0

Submitted by: Dieter Koenig

Target:
   WS-HumanTask 1.1 CD 04 rev 2, section 6.2, second table: XPath functions
   for Result Aggregation.

Description:
   The aggregation function specifications do not describe the return value
   for the case where an empty node-set is passed.

Proposal:
   See inlined text in the table of aggregation functions below. As the
   color code may be lost during mail transmission, I also attached a
   document showing the changes.

   (See file: XPath Extension Functions.doc attached to email http://lists.oasis-open.org/archives/bpel4people/200906/msg00071.html)
                                                                                       
                               | |
         concat | Returns the | In
                               | concatenation of all |
                               | string nodes - |
                               | returns an empty | • node-set of string
                               | string for an empty | nodes
                               | node-set |
       ------------------------+-----------------------+------------------------------
                               | |
         concatWithDelimiter | Returns the | In
                               | concatenation of all |
                               | string nodes, |
                               | separated by the | • node-set of string
                               | specified delimiter | nodes
                               | string - returns an |
                               | empty string for an |
                               | empty node-set | • delimiter string
       ------------------------+-----------------------+------------------------------
                               | |
         leastFrequentOccurenc | Returns the least | In
         e | frequently occurring |
                               | string value within |
                               | all string nodes, or | • node-set of string
                               | an empty string in | nodes
                               | case of a tie or for |
                               | an empty node-set |
       ------------------------+-----------------------+------------------------------
                               | |
         mostFrequentOccurence | Returns the most | In
                               | frequently occurring |
                               | string value within |
                               | all string nodes, or | • node-set of string
                               | an empty string in | nodes
                               | case of a tie or for |
                               | an empty node-set |
       ------------------------+-----------------------+------------------------------
                               | |
         voteOnString | Returns the most | In
                               | frequently occurring |
                               | string value if its |
                               | occurrence is above | • node-set of string
                               | the specified | nodes
                               | percentage and there |
                               | is no tie, or an |
                               | empty string | • percentage value in
                               | otherwise (including | the range from 0 to
                               | an empty node-set) | 100
       ------------------------+-----------------------+------------------------------
                               | |
         and | Returns the | In
                               | conjunction of all |
                               | boolean nodes - |
                               | returns false for an | • node-set of boolean
                               | empty node-set | nodes
       ------------------------+-----------------------+------------------------------
                               | |
         or | Returns the | In
                               | disjunction of all |
                               | boolean nodes - |
                               | returns false for an | • node-set of boolean
                               | empty node-set | nodes
       ------------------------+-----------------------+------------------------------
                               | |
         vote | Returns the most | In
                               | frequently occurring |
                               | boolean value if its |
                               | occurrence is above | • node-set of boolean
                               | the specified | nodes
                               | percentage, or false |
                               | otherwise (including |
                               | an empty node-set) | • percentage value in
                               | | the range from 0 to
                               | | 100
       ------------------------+-----------------------+------------------------------
                               | |
         avg | Returns the average | In
                               | value of all number |
                               | nodes - returns NaN |
                               | for an empty | • node-set of number
                               | node-set | nodes
       ------------------------+-----------------------+------------------------------
                               | |
         max | Returns the maximum | In
                               | value of all number |
                               | nodes - returns NaN |
                               | for an empty | • node-set of number
                               | node-set | nodes
       ------------------------+-----------------------+------------------------------
                               | |
         min | Returns the minimum | In
                               | value of all number |
                               | nodes - returns NaN |
                               | for an empty | • node-set of number
                               | node-set | nodes
       ------------------------+-----------------------+------------------------------
                               | |
         sum | Returns the sum | In
                               | value of all number |
                               | nodes - returns 0 |
                               | for for an empty | • node-set of number
                               | node-set | nodes
                                                                                       

Comment by Dave Ings [ 08/Jul/09 04:08 PM ]

Resolved at 7/8 TC.

[BP-111] Addition Register, Unregister and List to support interop of Task Parent and Task Processor

Status:

Applied

Project:

OASIS BPEL4People TC

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None

Type:

Improvement