[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]