John-
As I said in an earlier message I am away after today. i will check my email but infrequently.
I do think another Use Case conf call is needed as well as the action items we developed in the first call. Given the concensus that is building within the full TC toward requirements definition, the development of a glossary would also be a contributor to moving our efforts forward. I believe we need to establish common reference points; common semantics & terms would also be of help.
For example in the Voting on Use Cases doc I authored, I labeled the individual (most probably from the UC subgroup) who would move a newly contributed use case through the agreed upon process as a Sponsor. Jeff in the Issues subgroup referred to the individual as a Champion. If we expect essentially the same role to be preformed use of the same label would be a small step to making all of our lives easier.
When I drafted the Voting doc my view was that the Sponsor would not necessarily be a Subject Matter Expert(SME) but someone who would do the leg work to get the contribution in the agreed upon format and get clarification and then "shepherd" the use case through the ageed upon process. A bulldog is probably a better analogy.
A reason for other than a UC subgroup member is that a use case initially (or on a retry) may require a level of expertise or explaination that none of us (in the Use Case subgroup) has.
Developing a glossary when abstract issues are involved AND the large, diverse group that makes up the BPEL TC will save us time in the long run. The different perspectives that are brought to the TC can be more efficiently used if we use terms in a way that has common meaning. It is not surprising to have different perspectives with a group made up of architects, developers, analysts,etc
Anyway I am off on a family field trip. For those in the US enjoy the holiday. Talk with you next week.
Sally