The summary of his suggestions is in bold blue, towards the end.
Hi Dave,
The attached is a supplementary sequence diagram.
As I understand it, the current WS-C HT proposal stops at Step 4 below, when the WS-C EPR exchanges have happened. There is nothing to indicate any information about how to invoke the Task Application implementation later from the Task List Client. Such an action should bring the Task Client to the end user (on the User Agent).
Since the Task was supposed to have been created at some point, I thin that it is appropriate that the Task Service is contacted at the time when the Task Life Cycle starts (i.e. when the taskCreate event occurs).
Then, when the Task is claimed the taskClaim event occurs and this is handled just between the user and the Task manager. This does not have to be propagated to the Task Service or Task App implementation.
When the user "starts" the task, the taskStart event occurs and this should trigger to bring the Task Application to the end user.
Since the current standard proposal does not contain any indication that this information has been obtained at this point, the startTask event must first obtain that information by using the WS-C HT Protocol. Programming interface is that the WS-C HT Protocol Service of Task Service should implement this mechanism.
The Task Application Implementation information should indicate: (1) what the Task Application is and (2) how to invoke it from the user agent.
The example of this would be perhaps:
• taskType=text/html (descriptor=mimeType), tasLink=http://services.mybank.com/loanApprovalService/loanApplicationForm.html (descriptor=URL)
• taskType=text/xforms, taskLink=http://services.mytravel.com/myTravelPlan.xml
• taskType=application/x-xul, taskLink=http://services.myVoting.com/vote.xul
• taskType=application/html, taskLink=http://services.myVoting.com/vote.html
• taskType=application/msecel, taskLink=http://services.myExcel.com/summerize.xls
• taskType=application/msproject, taskLink=http://services.myProject.com/updateProject.xls
• taskType=application/rpc, taskLink=rpc:services.myRPC.com/updateProject?operation=update?project=12345
Since my examples above are very clumsy, what elements and formats would be most appropriate need to be discussed.
(An alternative to this is that the startTask by default knows how to invoke the Task application impl, but that would not be suitable given that the Task Application may vary, unless we can presume that the Task is always a single XML page or a singe HTML form, for example. That also requires such an assumption to be stated in the standard).
HTTP header typically contains MIME-Types as Content-Types, but if other protocol is used this is not guaranteed and if multi-part, each MIME-Type does not represent the entire application. Hence, the examples specify the MIME-Types of the Task applications as well as the URLs with protocols and URIs.
If there is something better than MIME-Type or URL, suggestions are welcome.
There are other matters related with this. As I suggested, when some applications are suspended during the execution (during the InProgress State), it should be propagated to the Task Client and the Task Application implementation since they both has to be temporary shut down and preserve any temporary data or session if such is necessary.
Also, when the Task application "Completes", the Task Client must terminate the Task Application UI and return to Task List. This transition requires a communication from the Task Application to Task Client or Task Manager. The standard does not indicate, then, how the Task Client can pass it to either Task List Client or Task Manager so that the termination and loading of the Task List Client may occur.
Say, the user agent is Web Browser, then the action must be triggered from the User Agent to close down the Task Client and re-load the Task List Client.
The standard indicates that the WS-C sends the Completion event from the Task Application to the Task Manager, but this does not "push" a new UI (Task List Client) to the Web Browser without having some mechanism.
In our own Human Interface enabled services, we only use Web applications. In them, we have embedded a JavaScript of the Task Client UIs to tell the Web Browser to propagate the Completion to upper level, i.e. to send a URL of the Task List Client to the server. Of course, this is not the only way to do it.
If you have better suggestions for the mechanism to use here, that would be very welcome.
Summary of suggestions:
1. Add WS-C HT Protocol "startTask"
2. Obtain the Task application information to invoke it in the response of "startTask"
3. By using the information, the Task application impl is invoked and loaded to the User Agent.
4. Necessity for InProgress:Suspend to be added to the WS-C HT Protocol messages (may need a return message defined?)
5. Necessity for Completed to be propagated from the Task Client to the upper level on the user agent (not on the server side).
Since these are not added to Open Issues yet, I wonder whether we should discuss whether the committee would like to approve them as Open Issues and start discussions on these perhaps on email list as the next step?
Regards,
Yoichi
--------------------------------------------------------------------------
Yoichi Takayama, PhD
Senior Research Fellow
RAMP Project
MELCOE (Macquarie E-Learning Centre of Excellence)
MACQUARIE UNIVERSITY
Phone: +61 (0)2 9850 9073
Fax: +61 (0)2 9850 6527
www.mq.edu.au
www.melcoe.mq.edu.au/projects/RAMP/