sca-bpel message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: raw minutes for 11.08
- From: "Mark Ford" <mark.ford@active-endpoints.com>
- To: <sca-bpel@lists.oasis-open.org>
- Date: Thu, 8 Nov 2007 13:03:37 -0500
Mark Ford: Agenda approved
Mark Ford: No response on approval for previous
minutes
Mark Ford: Chairs will take responsibility of
formatting raw minutes
Mark Ford: No objection to approving
minutes
Mark Ford: a) AI #0010 Mike Edwards - Notify all
the OpenCSA TCs about update to the Issues Process for allowing status change
from 'Applied' to 'Resolved'
Mark Ford: Action Item was done by Mike
Edwards
Mark Ford: b) AI #0013 Danny van der Rijn - come
back with a rewording proposal for issue-5
Mark Ford: Action Item was done by Danny van der
Rijn
Mark Ford: c) AI #0014 Michael Pelligrini
propose a sentence for resolving the 2nd part of issue 11
Mark Ford: Action item was done by Michael
Pelligrini
Mark Ford: d) AI #0015 Michael Rowley follow
up on the 1st part of issue 11 on email
Mark Ford: Michael is not on the call, leaving
action item open
Mark Ford: Summary of issue - namespace
convention
Mark Ford: No discussion of issue
Mark Ford: Mike Edwards moves to accept
proposal
Mark Ford: Mike Edwards moves to accept
proposal
Mark Ford: Anish seconds
Mark Ford: no objections, motion
passed
Mark Ford: 7. New Issues
Mark Ford: Summary of issue by Martin Chapman. Use
of RFC 2119 language within spec.
Mark Ford: No questions or comments
Mark Ford: No objections, issue
accepted
Mark Ford: 8. Issue Discussion
Alex Yiu: Latest email for Issue 5 :
Mark Ford: Danny summarizes issue
Mark Ford: Definition of static analysis
required
Mark Ford: Martin: how does this differ than
ws-bpel SA ?
Mark Ford: Danny: For the purposes of determining
whether something is a service or reference you cannot evaluate the
expressions.
Sanjay: There is no one in the Q, so I am fine with
the free form discussion at the moment
Mark Ford: sorry
Mark Ford: The WS-BPEL 2.0 doesn't include any
language for static analysis of expressions
Mark Ford: Sanjay: We should identify the purpose
of SA
Mark Ford: Martin: we're only doing SA for which
end of plink a process implements.
Mark Ford: Martin: All we have to say is that we
need to ignore expression
Mark Ford: Danny: In agreement, but looking for a
way to put into a coherent normative sentence
Martin C: we could say that sca static alanysis
MUST ignore and and MUST NOT evaluate expressions
Sanjay: An SCA static analysis is the class of the
valid static BPEL static analysis that does not evaluate expressions. The
purpose of the SCA static analysis is to derive SCA Service and Reference for a
BPEL process definition.
Mark Ford: Danny: we could vote on intent and let
the editors fix it up
Sanjay: An SCA static analysis is the class of the
valid static BPEL static analysis that does not evaluate expressions. The
purpose of the SCA static analysis is to derive SCA Services and References for
a BPEL process definition.
Mark Ford: change made to make Service and
Reference plural
Mark Ford: Danny made motion to accept, Martin
seconded
Alex Yiu: typo in "the valid static BPEL static
analysis" ...
Mark Ford: Martin amends motion to have editors do
"editorial fixup"
Mark Ford: Danny accepts as a friendly amendment,
no objections
Alex Yiu: "An SCA static analysis is the class of
the BPEL static analysis that does not evaluate expressions. The purpose of the
SCA static analysis is to derive SCA Services and References for a BPEL process
definition."
Mark Ford: Martin: editorial fixup does not change
the intent of the text
Alex Yiu: s/the valid static BPEL static
analysis/the BPEL static analysis
Mark Ford: Martin: in other cases, some motions
will be crafted text and NOT to be changed by editors
Mark Ford: Danny: agrees with Martin that editors
should have leeway in some cases but in other cases they should not
Mark Ford: no other discussion for ammendment, no
objections
Mark Ford: +1
Mark Ford: Martin: clarifying the current motion:
Have the editors insert the above text, making it read better
Mark Ford: Danny: email includes a from and to to
help the editors identify where the change is needed in the spec
Sanjay: s/the partnerLink MUST be wired to
corresponding SCA service/the partnerLink MUST be associated with the
corresponding SCA service
s/the service MUST be wired using a binding/the
service MUST be configured using a binding
Mark Ford: Sanjay: making a motion to
ammend
Mark Ford: Martin: the motion is only about the
wording for static analysis
anish does it matter, sanjay can make any amendment
he wants. No?
Mark Ford: Sanjay withdraws amendment
Mark Ford: no objections, motion
passed
Alex Yiu: +1 to Sanjay's suggestion
Sanjay: s/the partnerLink MUST be wired to
corresponding SCA service/the partnerLink MUST be associated with the
corresponding SCA service
s/the service MUST be wired using a binding/the
service MUST be configured using a binding
Mark Ford: Summary: Issue 5 - part 1 on static
analysis was passed
Mark Ford: Current discussion is Issue 5 - part 2
on usage of term "wire" within the text
Mark Ford: Alex: suggests that all of the changes
are grouped together to make the editing easier
Mark Ford: MArtin: people making proposals are
responsible for providing the exact text
Sanjay: An SCA static analysis is the class of the
BPEL static analysis that does not evaluate expressions. The purpose of the SCA
static analysis is to derive SCA Services and References for a BPEL process
definition.
Mark Ford: Martin: The first removal of wire is
fine, but the second is consistent with the SCA text
Mark Ford: Sanjay: We need to produce a concrete
proposal
Sanjay: s/the partnerLink MUST be wired to
corresponding SCA service/the partnerLink MUST be associated with the
corresponding SCA service
s/the service MUST be wired using a binding/the
service MUST be configured using a binding
Mark Ford: Sanjay: Move that we do the changes that
were cut/pasted earlier
Mark Ford: Martin: We need the whole text to
provide the context for the changes
Sanjay: An SCA static analysis is the class of the
BPEL static analysis that does not evaluate expressions. The purpose of the SCA
static analysis is to derive SCA Services and References for a BPEL process
definition.
Mark Ford: Sanjay pastes proposal for part 1
(above)
Sanjay: If a an SCA static analysis of the process
determines that it is possible that the first message for a partner link will be
received in a <receive> activity, the <onMessage> element of a
<pick> activity or the <onEvent> element of an event handler then
the partner link MUST be associated with a corresponding SCA service in the
component type. If the partner link declaration has initializePartnerRole="yes",
then the service MUST must be configured using a binding that knows the identity
of the partner as soon as the partner link becomes active (e.g. the binding
cannot depend on using a reply-to field as the mechanism to initialize partner
role.).
Mark Ford: Sanjar pastes proposal for part 2
(above)
Mark Ford: Sanjay motions to change the text to
read as above
Mark Ford: no further discussion on the motion, no
objection, motion is passed
Martin C: martin 2nd the motion
Mark Ford: Sanjay: Still discussing issue 5, we
have enough for a formal proposal now
Mark Ford: Danny: This change goes in Section
2.1
Mark Ford: Issue 5 resolved
Mark Ford: Alex: was issue 14 opened?
Mark Ford: Sanjay: yes
Mark Ford: no other business, call
ended
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]