OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

bpel4people-editors message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: AW: [bpel4people-editors] Forward Progress on BP-16


Please find below my comments.

Regards,

Ivana

Section 4
==========
Line 1075: 
"The name combined with the target namespace of a task element is used to uniquely identify the task definition. "
Change to 
"The name combined with the target namespace MUST uniquely identify a task element enclosed in the task definition."

Line 1396: 
"For all deadlines if a status is not reached within a certain time then an escalation action, specified using element <escalation>, can be triggered. "
Change to 
"For all deadlines if a status is not reached within a certain time then an escalation action, specified using element <escalation>, is triggered. "

Line 1411: keep "MAY"

Line 1432: 
"In the case where several reassignment escalations are triggered, the first reassignment (lexical order) will be considered for execution. "
change to 
"In the case where several reassignment escalations are triggered, the first reassignment (lexical order) MUST be considered for execution by the WS-HumanTask Processor. "

Line 1436: keep "MAY"

Line 1643: 
"People queries that cannot be executed successfully are treated as if they were returning an empty set. "
change to 
"People queries that cannot be executed successfully MUST be treated as if they were returning an empty set. "

Line 1646: keep "must" and change to "MUST"

Line 1718: keep "may" and change to "MAY"

Line 1763: 
"The name combined with the target namespace of a notification element is used to uniquely identify the notification definition. "
change to 
"The name combined with the target namespace MUST uniquely identify a notification in the notification definition. "

Section 7
==========
Line 1980: use "can" instead of "MAY"

Line 1991: keep the initial wording "The WS-HumanTask Processor receiving that message extracts... "#

Line 1994: "MUST registers " change to "MUST register"

Line 1997: "parent application MUST use" change to "parent application uses"

Line 2001: "The parent application MUST react " change to "The parent application reacts "

Line 2014: "Response message SHOULD NOT be passed back by parent application. " change to "Response message is not passed back by parent application. "

Line 2018: "it MUST send an exit " change to "it sends an exit "

Line 2023: "assignments MUST be overridden for a notification" change to "assignments MAY be overridden for a notification"

Line 2039: "available to the WS-HumanTask processor" change to "available to the WS-HumanTask Processor"

Line 2040: "registration service MUST be passed by Applicaton" change to "registration service is passed by applicaton"

Line 2043: "Application" to "application"

Line 2048: It is MAY

Line 2049: "the initiating message MUST NOT be returned" change to "the initiating message MAY NOT be returned"

Line 2053: It is MAY

Line 2063: Instaed add sentence "No attachments MUST be returned."

Line 2078: use "can" instead of "MAY"

Line 2114: It must be "MUST"

Line 2125: "For a WS-HumanTask Definition a task MUST " change to "A WS-HumanTask Processor MUST "

Line 2194: "This policy assertion may be associated" change to "This policy assertion can be associated "

Line 2197: "the provider of a human task MAY signal whether or not the corresponding task may communicate with an invoking component via the WS-HumanTask coordination protocol. " change to "the provider of a human task can signal whether or not the corresponding task can communicate with an invoking component via the WS-HumanTask coordination protocol. "

Line 2206: "This policy assertion specifies that the sender of an input message MUST include context information for a human task coordination type passed with the message." change to "This policy assertion specifies that the WS-HumanTask Processor MUST accept context information for a human task coordination type passed with the message."

Line 2223: "In that case it means that the sender of an input message MAY pass the human task context information with the message."
change to 
"In that case it means that the WS-HumanTask Processor MAY accept the human task context information with the message."


Section 8
==========
Line 2233: "override static deployment information that may have been set" change to "override static deployment information that can have been set"

Line 2265: "This MUST be done by the caller in one of the two ways" change to "This can be done in two ways"

Line 2281: Keep the initial wording

Line 2290: Keep the initial wording

Line 2296: Keep the initial wording

Line 2301: Keep the initial wording

Line 2387: "Note that the [fault endpoint] property is not used " change to "Note that the [fault endpoint] property MUST NOT be used "



-----Ursprüngliche Nachricht-----
Von: Dieter Koenig1 [mailto:dieterkoenig@de.ibm.com] 
Gesendet: Montag, 8. Dezember 2008 11:29
An: Luc Clement
Cc: bpel4people-editors@lists.oasis-open.org
Betreff: Re: [bpel4people-editors] Forward Progress on BP-16

Dear BPEL4People Editing team, I collected a couple of review comments
listed below - we may walk through in one of the next editor's calls.


Section 3.2.
line 516 - "they can be used" would be sufficient - no MAY needed

Section 4.+5.
(edited by DK) no comments

Section 6.
line 1811 (void  response) - this is normatively addressed in
ws-humantask-api.wsdl - no issue required
line 1826 - broken reference
line 1845 - dup of line 1808
line 1935 - add "A WS-HT processor MUST support the XPath functions listed
below"?

Section 7.
line 1993 - "WS-HumanTask Processor implementation" - drop "implementation"
line 2001 - "The parent application MUST react ..." - not sure if we need
this - it is alread mandated by WS-Coordination
line 2014 (same on line 2019 and line 2028) - "Response message SHOULD NOT
..." - revert to original sentence (this is a one-way operation - there is
never a response)
line 2017 (same on line 2033) - >>>NEW ISSUE<<< - scenario 3 - the parent
application must be a conformance target (!) as it has to send the "exit"
protocol message - in line 2033, they are called "Human task aware
requesting applications" - in line 2301, "the caller" is used
line 2048 and line 2053 (attachments) - MAY seems ok as the attachment
concept as a whole is optional
line 2057 and line 2060 - change "No attachments MUST be returned." to "
Attachments MUST NOT be returned."
line 2063 - drop "No attachments MUST be returned.."
line 2087 and line 2095 - again, the absence of a response is already
covered by the normative one-way interface of protocol operations, so these
two sentences can be reverted to their original wording
line 2114 - replace MAY by MUST,
line 2143 - revert "WS-HumanTask Definition" to "WS-HumanTask" - the
context is completely independent of a task definition
line 2197 - (policy assertion) replace MAY by SHOULD

Section 8.
line 2301 - "the caller" (conformance target) - see issue above
line 2335 - replace ")will be used" by "is used" (always use present tense)
line 2408 - add normative language to the SOAP binding section
line 2470 - replace "caller" by "WS-HumanTask Processor"


Kind Regards

Dieter König

Senior Technical Staff Member, WebSphere Process Server Architect
IBM Software Group, Application and Integration Middleware Software
WSS Business Process Solutions
                                                                                             
                                                                                             
                                                                                             
                                                                                             
                                                                                             
 Phone:            +49-7031-16-3426           IBM Deutschland                      (Embedded 
                                                                                 image moved 
                                                                                    to file: 
                                                                               pic09875.gif) 
                                                                                             
 E-Mail:           dieterkoenig@de.ibm.com    Schönaicher Str. 220                           
                                                                                             
                                              71032 Böblingen                                
                                                                                             
                                              Germany                                        
                                                                                             
                                                                                             
                                                                                             
                                                                                             
                                                                                             
 IBM Deutschland                                                                             
 Research &                                                                                  
 Development                                                                                 
 GmbH /                                                                                      
 Vorsitzender des                                                                            
 Aufsichtsrats:                                                                              
 Martin Jetter                                                                               
 Geschäftsführung:                                                                           
 Erich Baier                                                                                 
 Sitz der                                                                                    
 Gesellschaft:                                                                               
 Böblingen /                                                                                 
 Registergericht:                                                                            
 Amtsgericht                                                                                 
 Stuttgart, HRB                                                                              
 243294                                                                                      
                                                                                             




                                                                                                                                                  
  From:       "Luc Clement" <luc.clement@activevos.com>                                                                                           
                                                                                                                                                  
  To:         <bpel4people-editors@lists.oasis-open.org>                                                                                          
                                                                                                                                                  
  Date:       05.12.2008 02:15                                                                                                                    
                                                                                                                                                  
  Subject:    [bpel4people-editors] Forward Progress on BP-16                                                                                     
                                                                                                                                                  





Folks,

Unfortunately, we weren't able to make progress on the HT review this week.
Ivana, Dieter and I discussed when we met briefly on Wednesday that we need
to close our review of HT by Wed 10 and the review of the B4P updates by
Wed 17. This would permit the TC to approve our BP-16 proposal, and
subsequently release CD-02 early in the new year.

To this end we ask that all editors provide input on the HT updates
starting from 3.2 (to the end) no later than 10 Dec.

Ralf has not only completed his updates to B4P but mine also J. Sections 1
through 6 have been completed, and Ravi now has the pen. Given this
progress and on the assumption that Ravi will be completed shortly, I ask
that all input on BP-16 updates to B4P be submitted  by the 17th.

If there are any issues that need to be discussed, we can do so on the
meetings of the 10th and 17th.

Let's get this done before Xmas. I trust that everyone is on board with
this.

Luc'

Luc Clément
Active Endpoints, Inc
+1.978.793.2162  | luc.clement@activevos.com




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]