wsbpel message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsbpel] Error: Error handling process?
- From: Diane Jordan <drj@us.ibm.com>
- To: Yuzo Fujishima <fujishima@bc.jp.nec.com>, ws bpel tc <wsbpel@lists.oasis-open.org>
- Date: Wed, 30 Jun 2004 11:18:39 -0400
Hi Yuzo,
These should probably opened as issues.
If the error amounts to a simple editing change, it doesn't need
to go through the issues process - an email to the spec editing team is
sufficient. All other items should have issues opened so everyone
can review and we have a way to keep track. If you feel an item should
be reviewed by the full TC and the solution is fairly apparent, I'd
suggest that you open an issue and submit a proposal to vote with the suggested
resolution promptly thereafter. The issues list has a field called
"qualifier" where you could indicate that this is an error.
At present, this field indentified various types of issues (typo, clarification,
enhancement, requirement and so on ) although I'm not sure its been used
extensively.
I agree that the increase in the number
of issues for these is ok. I am not so concerned with how many we
open but rather that we continue to make progress resolving
them.
Regards, Diane
IBM Dynamic e-business Technologies
drj@us.ibm.com
(919)254-7221 or 8-444-7221, Mobile: 919-624-5123
Yuzo Fujishima <fujishima@bc.jp.nec.com>
06/30/2004 07:29 AM
|
To
| wsbpel@lists.oasis-open.org
|
cc
|
|
Subject
| [wsbpel] Error: Error handling
process? |
|
Dear WSBPEL TC members:
I think we might want to have some rule or at least convention to
report and track clear errors, not issues, in the specification.
For example, how about prepending the subject line with "Error:"?
Or should we have a dedicated subgroup to receive, publish, and track
error findings?
(We can submit an error as an issue, but I guess that can increase
the number of issues greatly. Personally, I think it is OK, though.)
Anyway, here is the error I found:
The last sentence in 14.8. Event Handlers
"... In addition, the outputVariable attribute is not optional
for invoke when the operation concerned is a request/response
operation."
should be removed because this is irrelevant to event handlers.
(Seems like a cut-and-paste remainder.)
Yuzo Fujishima
NEC Corporation
To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]