Text Minutes from Bindings Virtual F2F, Day 2

[Mike Edwards <mike_edwards@uk.ibm.com>]

Introductions 
Roll call 
Scribe assignment 
Agenda bashing 

2. Actions 

Check status of any actions opened on previous call


20081201-2 [Anish Karmarkar] Propose wording along
the lines of "how about saying (1) wsdl allows extension, go look
at what the rules are in the wsdl spec, (2) we define the following extension
and what the MUST-ness for that is" to resolve Dave's second concern
from his email. 

20081201-3 [Simon Holdsworth] Produce updated revision
of binding.jms using the phrase "raised" for error situations
and revert line 219 to can 

20081201-4 [Piotr Przybylski] Amend binding.jca spec
to include all the listed updates except text for issue 45 

3. New Issues 

Please note, as per resolution on 9th October 2008,
new issues received on the mailing list after Noon GMT 1st November can
only be opened using the same voting rules as re-opening a closed issue
(2/3 majority of a full TC vote) 

Process any new issues opened on previous call 

No additional new issues 

4. Open Issue Discussion 

Continue discussing issue resolutions. 

Note that from a scheduling point of view, each issue
is limited to 1 hour of discussion on today's agenda. Any unresolved issues
will be carried over to the next day. 

Open issues with proposed resolutions: 

http://www.osoa.org/jira/browse/BINDINGS-51

WS Binding spec needs RFC 2119 language 
Raiser: Dave Booz, owner: Editors 
Status: Current proposed text in http://www.oasis-open.org/committees/download.php/30115/sca-binding-ws-1.1-spec-cd01-rev3.doc

Latest email: http://lists.oasis-open.org/archives/sca-bindings/200812/msg00020.html


http://www.osoa.org/jira/browse/BINDINGS-52

JMS Binding needs RFC 2119 language 
Raiser: Dave Booz, owner: Editors 
Status: Current proposed text in http://www.oasis-open.org/committees/download.php/30243/sca-binding-jms-1.1-spec-cd01-rev3.doc


http://www.osoa.org/jira/browse/BINDINGS-53

JCA Binding needs RFC 2119 language 
Raiser: Dave Booz, owner: Editors 
Status: Current proposed text in http://www.oasis-open.org/committees/download.php/29718/sca-binding-jca-1.1-spec-cd01-rev2.doc


http://www.osoa.org/jira/browse/BINDINGS-2

How should SCA callback semantics be carried over
Web Services? 
Raiser: Simon Nash, owner: Anish Karmarkar 
Status: Proposed resolution: http://lists.oasis-open.org/archives/sca-bindings/200810/msg00088.html
Latest email: http://lists.oasis-open.org/archives/sca-bindings/200810/msg00091.html


http://www.osoa.org/jira/browse/BINDINGS-7

JMS bindingType and ordered intent - clarification
needed 
Raiser: Peter Peshev, owner Simon Holdsworth 
Status: Proposed resolution in email: http://lists.oasis-open.org/archives/sca-bindings/200812/msg00005.html


http://www.osoa.org/jira/browse/BINDINGS-11

"Formal" WSDL generation is unclear, ambiguous,
and incomplete 
Raiser: Eric Johnson, owner: Eric Johnson, Anish Karmarkar

Status: Latest email: http://lists.oasis-open.org/archives/sca-bindings/200811/msg00071.html


http://www.osoa.org/jira/browse/BINDINGS-31

What is a "plain name" for a connection
factories or activation specs, and how is one distinguished from a JNDI
name? 
Raiser: Eric Johnson, owner: Simon Holdsworth 
Status: Updated proposal in http://lists.oasis-open.org/archives/sca-bindings/200812/msg00027.html


http://www.osoa.org/jira/browse/BINDINGS-40

Clarify rules around combination of destination, CF
and AS elements 
Raiser: Simon Holdsworth, owner: Simon Holdsworth

Status: Latest email: http://lists.oasis-open.org/archives/sca-bindings/200812/msg00028.html


http://www.osoa.org/jira/browse/BINDINGS-42

Clarify default data binding for JMS 
Raiser: Simon Holdsworth, owner: Simon Holdsworth

Status: Proposed resolution in email: http://lists.oasis-open.org/archives/sca-bindings/200812/msg00007.html


http://www.osoa.org/jira/browse/BINDINGS-44

Update binding.jms spec for wireFormat/operationSelection
elements 
Raiser: Simon Holdsworth, owner: Simon Holdsworth

Status: Latest email: http://lists.oasis-open.org/archives/sca-bindings/200810/msg00073.html


http://www.osoa.org/jira/browse/BINDINGS-55

WSDL 2.0 support 
Raiser: Bryan Aupperle, owner: Editors 
Status: Proposal in issue 

http://www.osoa.org/jira/browse/BINDINGS-57

Add a section documenting naming convention + be consistent
on naming intents (binding.ws) 
Raiser: Anish Karmarkar, owner: Editors 
Status: Proposal in issue 

http://www.osoa.org/jira/browse/BINDINGS-58

Add a section documenting naming convention + be consistent
on naming intents (binding.jca) 
Raiser: Anish Karmarkar, owner: Editors 
Status: Proposal in issue 

http://www.osoa.org/jira/browse/BINDINGS-59

Add a section documenting naming convention + be consistent
on naming intents (binding.jms) 
Raiser: Anish Karmarkar, owner: Editors 
Status: Proposal in issue 

Open issues with identified resolution owner: 

http://www.osoa.org/jira/browse/BINDINGS-21

Support for callback and conversation ID-s in bindings

Raiser: Peter Peshev, owner Peter Peshev 
Status: Proposed resolution in issue 
Notes: As for BINDINGS-2, this is waiting for clarification
around conversations at the assembly level 

http://www.osoa.org/jira/browse/BINDINGS-39

JMS callback specification does not cater for callbacks
using other bindings 
Raiser: Simon Holdsworth, owner Simon Holdsworth 
Status: Complete resolution proposal required 

http://www.osoa.org/jira/browse/BINDINGS-43

Update binding.ws spec for wireFormat/operationSelection
elements 
Raiser: Simon Holdsworth, owner: Anish Karmarkar 
Status: Specific resolution text required. 

http://www.osoa.org/jira/browse/BINDINGS-45

Update binding.jca spec for wireFormat/operationSelection
elements 
Raiser: Simon Holdsworth, owner: Piotr Przybylski

Status: Specific resolution text required. 

http://www.osoa.org/jira/browse/BINDINGS-54

Endpoint URI algorithm is unclear 
Raiser: Eric Johnson, owner: Eric Johnson 
Status: Initial proposal in JIRA. 

Open issues with no identified resolution owner: 

http://www.osoa.org/jira/browse/BINDINGS-22

Bindings specifications should provide exemplary Implementations
for Callbacks and Conversations 
Raiser: Mike Edwards 
Status: No proposed resolution 
Notes: As for BINDINGS-2, this is waiting for clarification
around conversations at the assembly level 

http://www.osoa.org/jira/browse/BINDINGS-23

@wsdlElement definition needs clarification on "equivalent"
and use of WSDL 2.0 constructs 
Raiser: Eric Johnson 
Status: Specific resolution text required 

http://www.osoa.org/jira/browse/BINDINGS-24

Which wire did a message arrive on? 
Raiser: Sanjay Patil 
Status: Waiting for examples from Sanjay as per 20080717-4


http://www.osoa.org/jira/browse/BINDINGS-25

Is it required that every implementation of binding.ws
support the soap intent? 
Raiser: Anish Karmarkar 
Status: No current proposal. Latest email: http://lists.oasis-open.org/archives/sca-bindings/200807/msg00006.html

http://www.osoa.org/jira/browse/BINDINGS-29

Properties on Bindings 
Raiser: Piotr Przybylski 
Status: No current proposal; defer until Policy 15
(External Attachment) is resolved 

http://www.osoa.org/jira/browse/BINDINGS-48

How are mayProvide intents on bindings satisfied 
Raiser: Ashok Malhotra 
Status: No current proposal; latest email: http://lists.oasis-open.org/archives/sca-bindings/200810/msg00041.html


6. AOB 

Topic: Actions 
20081201-2: Complete 
20081201-3: Complete 
20081201-4: Pending 

Topic: Bindings-51 
http://www.osoa.org/jira/browse/BINDINGS-51

Current proposed text in http://www.oasis-open.org/committees/download.php/30115/sca-binding-ws-1.1-spec-cd01-rev3.doc

Latest email: http://lists.oasis-open.org/archives/sca-bindings/200812/msg00020.html

anish: When a Web Service binding is specified
using the @wsdlElement attribute, the details of the binding are specified
by the WSDL element referenced by the value of the attribute. Per the WSDL
specification, WSDL elements allow for extensibility via elements as well
as attributes, and it specifies rules for processing such elements. The
Web Service binding does not constrain the use of such extensibility in
WSDL and relies on the rules specified in the WSDL specification for processing
such extended elements.

This binding requires that the SCA runtime MUST support
the WSDL extensions [include-a-list-of-extensions] defined at [include-a-list-of-refs].

Note that as a consequence of this, when using this
form of Web Service binding, it is not possible to determine whether the
binding is supported by the SCA runtime without parsing the referenced
WSDL element and its dependent elements. 
Simon Nash: s/WSDL elements allow/WSDL allows/
Anish reviews his propsal
Mike E. reviews his proposed revision

Discussion about what, if anything, needs to be said
about WSDL extensions not defined by SCA 
anish: simonN, perhaps there is a better phrase
than 'support', if so pl. suggest an alternative

Eric: list of specs should be limited to Assembly
and Policy 
Anish: Mild preference for listing all the WSDL extensions
for readability. 
Mike E. an SCA runtime should not be allowed to throw
an error if a WSDL document is used with an SCA-BPEL extension in it.

anish: btw, sca-bpel does not define any wsdl
extension, it defines BPEL extensions (on partnerlinks)

Mike Edwards: +1 to Martin's point

Bryan: we can and should use namespaces to separate
wsdl extensions that not all SCA runtimes would be required to support.

Martin: This is a question of packaging of conformance
points. 
General discussion about conformance relationships
between the specs. 
Mike E. we need to not use required WSDL extensions
but rather each spec needs to state what a conforming implementation must
support
anish: btw, eventhough partnerLinkTypes are
defined in WSDL, SCA-BPEL does not define extensions for partnerLinkType.
It defines extensions for partnerLink and Variables -- both of these occur
in a BPEL process 
Eric Johnson: Proposal: This binding requires
that the SCA runtime MUST support the WSDL extensions defined in the SCA
namespace. 

Mike Edwards: http://docs.oasis-open.org/ns/opencsa/sca/200712

anish: This binding requires that the SCA runtime
MUST support the WSDL extensions defined in the SCA namespace used by this
binding. 
This binding requires that an SCA runtime MUST support
the WSDL extensions defined in http://docs.oasis-open.org/ns/opencsa/sca/200712
namespace. 
Mike Edwards: so:  "sca:"  namespace


Simon Nash: where is "sca:" defined?

Martin C : all our specs should have a namespace
prefix table 
This binding requires that an SCA runtime MUST support
the WSDL extensions defined in the sca: namespace.

anish: using the prefix in this context, without
calling it out that it is a prefix, is strange
anish: how about:

Simon Nash: yes, we should explain that

Ashok: In the namespace identified by the sca:
prefix 
anish: This binding requires that an SCA runtime
MUST support the WSDL extensions defined in the namespace associated with
the prefix "sca" (as defined in section 1.1).

anish: or what ashok said


anish: s/This binding/This specification/

Eric Johnson: Revised text proposal:

Eric Johnson: When a binding.ws element uses
the @wsdlElement attribute, the details of the binding are specified by
the WSDL element referenced by the value of the attribute. Per the WSDL
specification, WSDL elements allow for extensibility via elements as well
as attributes, and it specifies rules for processing such elements. This
specification does not constrain the use of such extensibility in WSDL
and relies on the rules specified in the WSDL specification for processing
such extended elements.

This specification requires that an SCA runtime MUST
support the WSDL extensions defined in the namespace associated with the
prefix "sca" (as defined in section 1.1).

Note that as a consequence of this, when using the
@wsdlElement form of binding.ws, it is not possible to determine whether
the binding is supported by the SCA runtime without parsing the referenced
WSDL element and its dependent elements.
Mike Edwards: (ie the WSDL might contain extension
elements 
which cannot be supported by the SCA runtime).

anish: When a binding.ws element uses the @wsdlElement
attribute, the details of the binding are specified by the WSDL element
referenced by the value of the attribute. Per the WSDL specification, WSDL
allow for extensibility via elements as well as attributes, and it specifies
rules for processing such elements. This specification does not constrain
the use of such extensibility in WSDL and relies on the rules specified
in the WSDL specification for processing such extended elements.

This specification requires that an SCA runtime MUST
support the WSDL extensions defined in the namespace associated with the
prefix "sca" (as defined in section 1.1).

Note that as a consequence of this, when using the
@wsdlElement form of binding.ws, it is not possible to determine whether
the binding is supported by the SCA runtime without parsing the referenced
WSDL element and its dependent elements. 
Simon Nash: s/WSDL allow/WSDL allows/
Simon Holdsworth1: a (ie the WSDL might contain
extension elements which cannot be supported by the SCA runtime).

When a binding.ws element uses the @wsdlElement attribute,
the details of the binding are specified by the WSDL element referenced
by the value of the attribute. Per the WSDL specification, WSDL allows
for extensibility via elements as well as attributes, and it specifies
rules for processing such elements. This specification does not constrain
the use of such extensibility in WSDL and relies on the rules specified
in the WSDL specification for processing such extended elements.

This specification requires that an SCA runtime MUST
support the WSDL extensions defined in the namespace associated with the
prefix "sca" (as defined in section 1.1).

Note that as a consequence of this, when using the
@wsdlElement form of binding.ws, it is not possible to determine whether
the binding is supported by the SCA runtime without parsing the referenced
WSDL element and its dependent elements (i.e. the WSDL might contain extension
elements 
which cannot be supported by the SCA runtime).

Simon Nash: Because the WSDL might contain
extension elements 
which cannot be supported by the SCA runtime, when
using the @wsdlElement form of binding.ws, it is not possible to determine
whether the binding is supported by the SCA runtime without parsing the
referenced WSDL element and its dependent elements.

Simon Nash: Because a WSDL document might contain
extension elements 
that cannot be supported by the SCA runtime, when
using the @wsdlElement form of binding.ws it is not possible to determine
whether the binding is supported by the SCA runtime without parsing the
referenced WSDL element and its dependent elements.

s/the WSDL/a WSDL document/

anish: When a binding.ws element uses the @wsdlElement
attribute, the details of the binding are specified by the WSDL element
referenced by the value of the attribute. Per the WSDL specification, WSDL
allows for extensibility via elements as well as attributes, and it specifies
rules for processing such elements. This specification does not constrain
the use of such extensibility in WSDL and relies on the rules specified
in the WSDL specification for processing such extended elements.

This specification requires that an SCA runtime MUST
support the WSDL extensions defined in the namespace associated with the
prefix "sca" (as defined in section 1.1).

anish: When a binding.ws element uses the @wsdlElement
attribute, the details of the binding are specified by the WSDL element
referenced by the value of the attribute. Per the WSDL specification, WSDL
allows for extensibility via elements as well as attributes, and it specifies
rules for processing such elements. This specification does not constrain
the use of such extensibility in WSDL and relies on the rules specified
in the WSDL specification for processing such extended elements.

This specification requires that an SCA runtime MUST
support the WSDL extensions defined in the namespace associated with the
prefix "sca" (as defined in section 1.1). 
Because a WSDL document might contain extension elements

that cannot be supported by the SCA runtime, when
using the @wsdlElement form of binding.ws it is not possible to determine
whether the binding is supported by the SCA runtime without parsing the
referenced WSDL element and its dependent elements.

anish: simon, do you want it to say something
like 'MUST generate an error' if an unsupported extension is encountered?

AI: (Anish) Post updated draft of binding.ws spec
with above and correction per Dave B.'s note about non-required.


Topic: Bindings-52

http://www.osoa.org/jira/browse/BINDINGS-52

Current proposed text in http://www.oasis-open.org/committees/download.php/30243/sca-binding-jms-1.1-spec-cd01-rev3.doc
anish i found more occurrences of the word 'required',
so going to fix that as well 
anish never mind, they are all in section 4, which
we are going to change anyway 
Motion: Resolve bindings 52 using http://www.oasis-open.org/committees/download.php/30243/sca-binding-jms-1.1-spec-cd01-rev3.doc(Mike
E. second Eric) 
Resolution: Motion passes w/o



anish: ws-binding rev4 has been uploaded

anish: http://www.oasis-open.org/apps/org/workgroup/sca-bindings/download.php/30249/sca-binding-ws-1.1-spec-cd01-rev4.doc

anish: http://www.oasis-open.org/apps/org/workgroup/sca-bindings/download.php/30250/sca-binding-ws-1.1-spec-cd01-rev4.pdf

Simon Holdsworth1: External URLs: http://www.oasis-open.org/committees/download.php/30250/sca-binding-ws-1.1-spec-cd01-rev4.pdf

Simon Holdsworth1: http://www.oasis-open.org/committees/download.php/30249/sca-binding-ws-1.1-spec-cd01-rev4.doc

resuming 

Topic Bindings-51 (again)

Latest update at link above


anish should have been cd01-rev2-51proposal


Anish reviews latest changes (and clarifies totality
of changes) 
Discussion about document revision naming.
Motion: Resolve Bindings-51 using http://www.oasis-open.org/committees/download.php/30250/sca-binding-ws-1.1-spec-cd01-rev4.pdf
(Dave, second Mike E.) 
Resolution: Motion passes w/o

Mike takes up scribe duties

http://www.osoa.org/jira/browse/BINDINGS-2
How should SCA callback semantics be carried over
Web Services?
Raiser: Simon Nash, owner: Anish Karmarkar
Status: Proposed resolution: http://lists.oasis-open.org/archives/sca-bindings/200810/msg00088.html
Latest email: http://lists.oasis-open.org/archives/sca-bindings/200810/msg00091.html

Simon Holdsworth1: Latest discussion around
separation of the callback protocol description: http://lists.oasis-open.org/archives/sca-bindings/200812/msg00030.html

Anish suggests discussing the technical contents first,
before worrying about the packaging question 
http://lists.oasis-open.org/archives/sca-bindings/200810/msg00088.html

contains the document  SCA-bindings-issue2-proposal-v3.doc

Simon N: Does section 1) apply only for Bidirectional
interfaces? 
Anish: Yes, this is for implementing bidirectional
interfaces using SOAP 
Simon - is that error required even if the service
does not attempt to make a callback 
Anish: Yes, it is still an error if there is no callback
address 
Simon: Sounds as if there is inconsistency in the
handling of error conditions here, since for example, a bogus address could
only be detected when an actual callback is attempted.

anish that is the robustness principle

anish be liberal in what you accept and conservative
in what you send 

Anish describes 2) and 3) in the proposal

Simon - direction in SCA-J is not to provide correlation
at the application level 
Simon - so could we make the message ID an optional
requirement? 
Anish - There is nothing in WS-Addr that demands the
message ID header 
The WSDL Request/Response pattern does require a message
ID header on the request plus a relatesTo header on the response - but
here we have a new interaction pattern so we can set the rules for ourselves
Eric - what about the namespace being used here?

Anish - either we use the common namespace or we have
a namespace for the bindings (possibly with a suffix)

Simon H: But this is a URI and not a QName
- so we can make up what we want here

Anish - Q. on the Java TC direction

- not clear to Anish as to whether any decision was
actually made 
Simon N argues that there if there is no client API
in any SCA language, then it is best to avoid the overhead of a message
ID
anish: http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/#msgaddrpropsinfoset
Simon H: We need to propose that at least some C&I
support exists for the use of messageIDs - otherwise it is a useless thing


Mike E: I can make a proposal which would make the
MessageID optional on the originating client request but that IF it is
present, the service side is bound to return it in the callback relatesTo
header 
Dave Booz: +1 TO Mike E

anish: we do not want to go into the issue
of EPR comparison 
Martin C : not at all

anish: lots of dragons in there
Mike Edwards: I agree Anish

anish: simonN, don't all you need is a handle
to the request message 
Mike Edwards: +1 Anish

anish: ... and depending on which handle you
use (app decision) the right EPR/message id gets used by the container

Dave Booz: I'm not seeing how a 2nd callback
can be present...i'm not seeing how an app ever has a choice of more than
one callback the only time this would be the case is if an implementation
instance could be concurrently dispatched on multiple threads

Dave Booz: i think we already (in java) require
composite scope to use an API to get the callback, so the container can
provide the right callback info from the request msg which is currently
running 
Simon Holdsworth1: But the request might not
currently be running... 
anish: cookie by definition is opaque

Dave Booz: Simon - doesn't matter, when it
was it has a context - if it gets suspended, the container has to suspend
the context 

<discussion of the option of using EPR reference
parameters> 

Simon Holdsworth1: My concern is on "In
addition, when the service invokes the callback interface, it MUST include
a wsa:RelatesTo SOAP header block." - what do we mean by "the
service" exactly? 
Mike Edwards: " the service" here would
mean "the service component" 
Mike Edwards: the wording needs a tweak

Simon Holdsworth1: but tge service component
does not include SOAP header blocks in anything...

Dave Booz: that's a good point, in this case
I think service means the app initiates the invoke and the binding impl
forms up the message in collaboration 
Mike Edwards: the point is that the callback
is a cookie - and its contents would vary from binding to binidng

Simon Holdsworth1: OK, so its the collaboration,
so the binding.ws cannot mandate that the message ID can be sent in all
cases unless all component implementations guarantee to play ball

Mike Edwards: but that cookie must be used
by the service component
Dave Booz: Simon - no, it's a matter of the
component container and binding impl collaborating, the app only initiates
the callback 
Mike Edwards: the requirement is that ANY service
component MUST use a callback cookie that it was given by the binding on
the outbound requyest 
Simon Holdsworth1: Sorry - "component
implementations " -> component container...

Simon Holdsworth1: OK, is that stated anywhere?

Mike Edwards: as I said earlier - no, but it
needs to be 
Dave Booz: no it isn't because we don't
Mike Edwards: it is the assumption

Dave Booz: we don't specify what an SCA runtime
looks like. the collaboration we're takling about is something that a runtime
vendor has to figure out 
Simon Holdsworth1: SO otherwise the best we
can say is that the callback message SHOULD contain the relatesTo with
the original message ID 
Dave Booz: in order to allow 3rd party binding
impls, such a spec would be needed, but we aren't there today

Mike Edwards: no - we can say MUST
Mike Edwards: it is then up to the SCA runtime
to work out how to honour that 
Dave Booz: +1 to Mike

Tom Rutt speaks against reference parameters...
Simon Holdsworth1: I'm just concerned that
if we only put a MUST here, it places a requirement on all component implementations
from binding.ws which is not well called out - that requirement should
be made from assembly. 
Simon is not convinced of the need for the use of
the message IDs at this point 
anish interesting discussion in the chat

Dave Booz: Simon - I actually think there are
other cases of this....it was true for conversations, might even be true
for databindings and operation selection.  Runtime vendors are smart,
they'll figure it out. 
Dave Booz: i really dont want to get into specifying
the runtime, not in this release anyway 

COB

Yours,  Mike.

Strategist - Emerging Technologies,
SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester,
SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014  
 Mobile: +44-7802-467431  
Email:  mike_edwards@uk.ibm.com

---

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU