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


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel-reqts message

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

Subject: [wsbpel-reqts] Issue Categorization

Diane Jordan wrote:

> We have an issue coordination subgroup call tomorrow, Wed. Aug 13, at 
> 11 am eastern/9 pacific/5 Germany.  Dial in is:  1-877-988-8393, int'l 
> 203 566-8013, pc 484868.   Agenda items are:  develop a plan for 
> issues to cover in the Aug. 20 call, start plans for those to put on 
> the f2f agenda.  
> Some input for discussion:
> I've gotten input from some of the initial authors on issue priorities 
> and possible categories which may be of interest to the TC:  
> They've also agreed to act as champions for a number of these, where 
> others haven't volunteered - I'll be getting Peter an email with the 
> names/numbers sometime tomorrow.    If these seem reasonable to the 
> group, we may want to start organizing the discussion of issues on 
> calls or at the f2f around categories.  
> In terms of potential issues for the next call, based on the email 
> traffic, I'm thinking we can ask the following folks if they would be 
> ready with a proposal for discussion/possible resolution on the next 
> call:  issue 2 - Kevin Liu, issue 45 - Danny van der Rijn, issue 11 - 
> Yaron Goland/Danny v., issue 33 - Bernd Eckenfels, issue 44 - Mike 
> Marin.    If so, I will put them on the agenda and try to get a 
> proposal circulated by end of day monday.   Let me know if you have 
> others to suggest.
> I've forwarded a note below from Alastair Green suggesting we devote a 
> large part of the agenda at the f2f to a proposal from Choreography 
> dealing with compensations issues.  Its not clear whether this would 
> cover outstanding compensation related issues or new ones (or what 
> combination).   I'd like your opinions on this.
mm1: Thanks for forwarding this Diane and sorry for a delay in 
responding (as noted, limited access). Comments and suggestions below:

General: Several of these issues touch on the dependent functions: state 
management, compensation and activity structure.  Therefore, we may, 
even if substantial, address them in a compiled fashion to understand 
the breadth of the issues and to get a balanced resolution. RE: 
1,2,3,5,6 etc. for example.

    * Defer this type of prioritization not based on function but
      complexity. Whether or not the issue will be addressed within the
      scope of the effort will be decided by the TC.  Agree with Goland
      that this is subjective at best and should not be used as a
      criteria.  Other than if the TC feels the impact of the issue is
      in/out of scope (and important to the specification and adoption).
    * *I would suggest we consider what broad function areas are
      important such as: (1) state management and correlation, (2)
      asynchronous type operations, compensation and fault handling,
      supporting WSDL and XML, and (3) other such as editorial.  *Here
      are a few examples of why I propose this:
          o On an XML 'group', although some of these items do touch on
            XML, the central items of concern surround correlation.  We
            should concentrate on the functional issue and address that
            and ensure that the XML is supportive or robust enough to
            handle the functional area. RE: 11, 29, 39, 46, etc. for
          o Functions that may support asynchronous operations or
            long-running transactions may support capabilities outside
            of the scope of BPEL.  We need to resolve how to prioritize
            and if the references to WS-Transaction are considered
            normative.  Please advise.
          o Suggest we address WSDL and XML together - technology
            related constraints or parameters in order to ensure we use
            their capabilities and either technology where most
            appropriate.  These may not be independent. RE: 7, 12, 13, etc.
          o Suggest we address event handling per the functional areas
            supports such as the alarm handlers raised by Jeyaraman. 
            For example, 32 is tied to correlation and assessing it
            independently may not address the issues.
          o Error handling is key to several functional areas not just
            compensation. This should be addressed in general as it
            relates to lower level SOAP faults (if applicable), in
            support of events, activities, etc.

Issue 1: Although implications could be significant, this is an 
important issue for compensation (and to some extent other functions in 
the specification).
Issue 2, 6: Although these are deemed significant issues they are 
important to the specification's robustness and suggest these be 
considered.  Significant
issues should be addressed carefully because any deferral may impact 
specification viability.
Issue 26: The actual meaning / use of <sequence> and <flow> impacts this 
issue. And further discussion was initiated on related issues on the 
list.  This
should be addressed in a group. RE: 22, 23, 26, etc.

I've provided a broad matrix with color codes (in StarOffice/OpenOffice 
version) to show the larger potential buckets where these issues fall. 
Note, there are several categories that may apply to an issue but I have 
only provided a suggested primary one. These do not differ significantly 
from the submitters, but takes a more functional approach on key areas 
of interest.




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