Simon Holdsworth: Chat room: - OASIS
Minutes of the OASIS SCA Bindings TC Virtual F2F starting 10th February 2009
Attendance:
|Bryan Aupperle |IBM |
|David Booz |IBM |
|Mike Edwards |IBM |
|Simon Holdsworth - chair |IBM |
|Piotr Przybylski – scribe 1 |IBM |
|Simon Nash |Individual |
|Anish Karmarkar |Oracle Corporation |
|Ashok Malhotra |Oracle Corporation |
|Plamen Pavlov |SAP AG* |
|Eric Johnson |TIBCO Software Inc. |
Resolutions:
• Minutes from the meeting of 5th February approved without objections.
• Issue BINDINGS-21 closed no action (m: Simon Nash, s: David Booz, no objections)
• Issue BINDINGS-29 closed no action (m: Piotr Przybylski, s: David Booz, no objections)
• Issue BINDINGS-55 resolved with the proposal in email () and the one change that Anish points out (“change @wsdli:wsdlEndpoint to @wsdli:wsdlLocation in last sentence of discussion of @wsdli:wsdlLocation”) (m: Bryan Aupperle, s: Anish Karmarkar, no objections)
• Issues BINDINGS-57, 58 and 59 resolved using the proposal in the referenced email (m: Eric Johnson, s: Simon Nash, no objections)
• Issues BINDINGS-61, 62 and 63 resolved using the proposal in the referenced email (m: Mike Edwards, s: Bryan Aupperle, no objections)
• Issues BINDINGS-64 resolved using the text in JIRA (m: Mike Edwards, s: Eric Johnson, no objections)
• Issues BINDINGS-66 resolved using the text in JIRA (m: Mike Edwards, s: Piotr Przybylski, no objections)
• Resolved direction: TC assert a direction for the resolution of BINDING-55, by adding normative statements to the @wsdlElement and other attributes as appropriate such that they can only point to WSDL 1.1 constructs (m: Eric Johnson, s: Simon Nash, no objections)
Completed Action Items:
• 20080904-1 [Editors] update SOAP intent as per email
• 20090122-1 [Simon Nash] Report back to bindings TC when JAVA-25 is resolved
• 20090129-1 [Simon Holdsworth] Include time to discuss the underlying concern behind 20080717-6 at the virtual F2F
• 20090210-1 [Anish Karmarkar] Post diffs of all latest specs from cd01
• 20090210-2 [Bryan Aupperle] Update proposed resolution for BINDINGS-55 based on TC direction
• 20090210-3 [Simon Holdsworth] Update proposed resolution for BINDINGS-65 with more detail
• 20090210-4 [Simon Nash] Update proposed resolution for BINDINGS-57, 58, 59
Open action items:
• 20080717-6 [Vladimir Savchenko] Send out a proposal for how WSDL bindings and portTypes relate to each other. Target: 14th August
• 20090108-1 [Editors] Produce cd02 with all resolved issues incorporated by January 29th
• 20090211-1 [Anish Karmarkar] Raise assembly issue for portType compatibility
• 20090211-2 [Anish Karmarkar] Produce updated proposal for BINDINGS-2
• 20090211-3 [Anish Karmarkar] Submit proposal for policy declaration of callback usage
• 20090211-4 [General] Write up HTTP binding use cases
Open issue ownership (no proposed resolution in red):
Simon Holdsworth: 39, 48, 60, 65, 67
Anish Karmarkar: 2, 25, 43
Piotr Przybylski: 22, 45
Eric Johnson: 54
Simon Nash: 23
Current Schedule for Bindings Specifications:
cd02 drafts to be completed by 29th January, with TC vote on 5th February
Public review drafts to be completed by 5th March, with TC vote on 12th March
Test assertions complete by end of March, test cases by end of April
Raw Chat room transcript (actions and resolutions marked in blue):
Piotr: Piotr scribes
Piotr: 83% voting members present
Piotr: 30 min limit on issue discussion
Piotr: Approval of the minutes from Feb5
Piotr: no comments, no objections to approval of minutes, minutes approved
Piotr: Actions
Piotr: 0904-1 done in the latest draft, complete
Piotr: 0108-1 on agenda today
Simon Holdsworth:
Piotr: 0122-1 - proposal at the above link
Piotr: Motion to close bindings 21 with no action, Simon N.
Piotr: Dave Booz seconds
Piotr: No new issues
Piotr: CD status
Piotr: 17 applied issues to CD drafts
Piotr: Current issues will cause a lot of changes to documents
Piotr: same here
anish: i think we should publish such delta as well
anish: i.e., a delta from previously published doc
Piotr: discussion about producing delta between CD versions
Piotr: Straightforward to create diff document
anish: i think eric's plan of producing the diff today and approving (or not) the CD on thrusday makes sense
Piotr: Action against editors - produce rev 6 with changes from CD 1
anish: i think we should publish 2 docs for each CD: a non-diff-ed one and a diff-ed one
Piotr: Anish can do all three by end of day
Piotr: We'll vote on CD on Thursday
Piotr: Action against Anish to post updated versions by end of day
Piotr: Open issue discussion, 11 issues with proposed resolutions
Piotr: Issues without proposals
Piotr: Simon
Piotr: 39 - callbacks in JMS, outline of proposal only
Piotr: 48 - mayProvide on bindings
Piotr: proposal by Thu
Piotr: 60 - should be discussed over next few days
Piotr: Eric
Piotr: 54
Piotr: 54 - will be available on Wed
Piotr: Anish
Piotr: 2 - callback for WS,
Piotr: two proposals, we need to pick one
Piotr: Action: Anish to provide proposal for issue #2
Piotr: 25
Piotr: Anish will retrieve discussion and present proposal on 25
Piotr: 43
Piotr: proposal/discussion on Thursday
Piotr: Simon, #23
Piotr: Simon and Anish will iterate over the issue off-line
Piotr: Discussion to continue on email thread
Piotr: Piotr
Piotr: 29 on Wed, 22 and 45 on Thu
Piotr: Open issues with proposed resolutions
Piotr: Bindings 55
Piotr: Discussed on Thursday
Piotr: Motion tabled on Thursday
Piotr: Issue disappeared, need to restate the motion
Simon Nash: motion text was: Eric Johnson: Motion text: I move that the TC assert a direction for the resolution of issue-55, by add normative statements to the @wsdlElement and other attributes as appropriate such that they can only point to WSDL 1.1 constructs.
Piotr: Anish - pushed back on the motion because of considerations for WSDL 2.0
Piotr: Simon N. - staying with WSDL 1.1 should be fine
Eric Johnson: Motion: TC assert a direction for the resolution of issue-55, by adding normative statements to the @wsdlElement and other attributes as appropriate such that they can only point to WSDL 1.1 constructs
Piotr: Simon Nash seconds
Piotr: do we allow extension points with WSDL 2.0
Dave Booz: Anish, you dont even need to use your extension element to get into the problem you're concerned about
anish: dave, can you elaborate?
Dave Booz: as i said in the last call....all you need is interface.wsdl20 with
Dave Booz: no attributes on the binding instance needed
anish: well, but i assume that a interface.wsdl20 -> interface.wsdl mapping exists
Dave Booz: y, but section 2.3 would still have the same issue
anish: k dave, i *think* we are saying the same thing (at least I was trying, i may not have articulated it correctly)
Piotr: Possible scenario: service with wsdl 2.0 interface and no element
Piotr: Eric: WSDL 2.0 is removed from Assembly and normative references, why do we want to introduce future extensions
anish: there is no requirement to vote 'yes' on your own motion [pic]
Piotr: Standard element should have MUST restriction to wsdl 1.1
Piotr: Proceed with motion, no objections to anonymous consent
Piotr: Motion is passed
anish would have objected, but don't think i convinced anyone and I don't feel very strongly
Piotr: Resolution to 55 - resolved by adding appropriate normative statements
Piotr: Action against Brian to create updated proposal
Dave Booz as I read the language it doesn't prohibit non-wsdl1.1 extension elements
anish right, it doesn't
anish: so ... is valid
Piotr: Issue 57,58,59 - naming conventions
Dave Booz: jndiURL
Piotr: How do we represent JNDI URL
Piotr: Simon N. objected to Eric's proposal
Simon Holdsworth: JNDIURLType
Simon Holdsworth: jndiURLAttribute
Piotr: Type - all upper, element, - all lower
Piotr: Type - all upper, element, - all lower
Piotr: Simon H. if starts with upper case and acronym, all upper, if lower, then all upper
Piotr: We'll try to resolve issue after the break, Eric will propose
Piotr: 15 min break
Piotr: This specification follows some naming conventions for artifacts defined by the specification. In addition to the conventions defined by section 1.3 of the Assembly [SCA-Assembly] specification, this specification adds two additional conventions:
Where the names of elements and attributes, or the values of elements and attributes consist partially or wholly of acronyms, the letters of the acronyms use in the same case. When the acronym appears at the start of the name of an element or an attribute, it is in lower case. In all other scenarios, it will be all upper case. For example, an attribute might be named "uri", or "jndiURL", whereas an XML Schema type might be named "JCABinding".
For the values of XML Schema elements and attributes defined in this specification, the values follow the same convention as the names of attributestypes. If the value is of type QName, the local part of the QName value follows the same convention as the names of attributes.
Piotr: Simon H concern - acronym after "."
Simon Holdsworth: Proposed resolution in email:
Eric Johnson: Amend proposal with: Replace "When the acronym appears at the start of the name of an element or an attribute, it is in lower case. " with "When the acronym appears at the start of the name of an element or an attribute, or after a period, it is in lower case. " Also wireFormat.JMSDefault --> "wireFormat.jmsDefault"
Piotr: Clarification, if acronym appears in the beginning of the value, it will be capitalized
Piotr: Augment proposal
Mike Edwards: we are spending an awfully long time on this issue, relative to its value
Piotr: remove ref to value from first bullet
Piotr: Simon N. will write proposal now
Piotr: Issues 61,62,63, conformance statement numbering
Piotr: Proposal posted by Simon H.
Piotr: Add conformance section to each bindings
Piotr: Add the following text to the Conformance section of each binding specification:
"Conformance to this specification requires conformance to the SCA Assembly and SCA Policy specifications."
Following the precendent of the Assembly specification:
Number every conformance statement in each binding spec. Use the following numbering scheme:
[pppsnnnn]
ppp = spec prefix, BWS for web service binding, BJM for JMS binding, BJC for JCA binding
s = section number
n = index number within section
Add such a number to every statement in each spec that includes RFC2119 keywords.
Construct a table in the conformance section with two columns.
First column contains the conformance statement number, linked to the position in the spec text where the statement appears.
Second column contains the conformance statement text, linked to the position in the spec text where the statement appears.
Update the conformance statements within the specification text so that the conformance statement text and number are references to the entries in the table.
Possible extra credit: apply some subtle highlighting to each conformance statement (very light grey background?) that gives a visual indication of the start and end of the conformance statement.
Piotr: Highlighting would be desirable
Piotr: Mike E. moves to accept proposal as resolution
Piotr: Bryan seconds
Piotr: Editorial aspect - statements in the table should stand on their own
Piotr: No comments, no objections, issues 61,62,63 are resolved with email
Piotr: oops, too fast, sorry
Piotr: Bryan Aupperle seconded the motion
Piotr: WS Binding spec mentions conversations in one section, 3.3 providing conversation intent
Piotr: resolution would remove the section
Piotr: Issue 64, Mike E moves to accept proposal in JIRA
Piotr: Eric seconds
Piotr: no objections
Piotr: motion is passed
Piotr: Issue 65
Piotr: JMS bindings spec mentions conversations in sections 6 and 7
Piotr: Simon will come back with more detailed proposal
Piotr: bindings 66
Piotr: Mike E moves to accept proposed resolution, Piotr seconds
Piotr: to bindings 66
Piotr: no objections, motion passed, issue is resolved
Simon Nash: Where the names of elements and attributes consist partially or wholly of
acronyms, the letters of the acronyms use the same case. When the acronym
appears at the start of the name of an element or an attribute, or after a
period, it is in lower case. If it appears elsewhere in the name of an
element or an attribute, it is in upper case. For example, an attribute
might be named "uri" or "jndiURL"
In all other scenarios, including types, values, and local parts of QName
values, acronyms will be all upper case. For example, an XML Schema type
might be named "JCABinding".
Piotr: Bindings 57,58,59
Piotr: Simon N. will revise
Piotr: Bindings 67
Piotr: No full resolution
Piotr: DESCRIPTION:
The JMS Binding spec currently has conformance statements for attributes and elements that may potentially appear in the uri.
In assembly cd02 Section 5.1.3, line 921 on:
If a binding element has a value specified for a target service using its @uri attribute, the binding element MUST NOT identify target services using binding specific attributes or elements. [ASM50015]
Additional clarity is needed because the JMS uri spec includes values that define the target, but also includes values that assist in connecting to the messaging infrastructure, and values that influence the headers in messages that are sent to the target.
PROPOSAL:
* Explicitly say that it is permissible to use the URI form on the JMS binding in combination with attributes and elements that define message header values and JNDI context values.
* Allow these values to be present in the URI and the binding, with the URI values taking precedence.
Based on the position that if values are specified in the URI, then that is because the service is saying that those values MUST be set that way for the service to work. So that means either the URI values take precedence, or we say the values cannot be present in the binding element. The former case is a bit more flexible in that we can change the URI without having to also update the binding element, so my preference would be to allow both but have the URI values take precedence.
* Include explicit statements that the destination, connectionFactory and activationSpec elements, MUST NOT be used in combination with the URI.
* Clarify that the use of the URI form is expected to be the case where the resources already exist, i.e. there is an implicit create="never" for the resources referred to in the @uri attribute.
Specific resolution text is required if this direction is acceptable to the TC.
anish: naive Q: aren't things like CF, ctx part of the "metadata" used to resolve the URI?
anish: how is this different than say DNS for http URLs that contain domain names?
anish: if you use cookies with HTTP, for the same URL you may get a dramatically different service
Simon Nash: Where the names of elements and attributes consist partially or wholly of
acronyms, the letters of the acronyms use the same case. When the acronym
appears at the start of the name of an element or an attribute, or after a
period, it is in lower case. If it appears elsewhere in the name of an
element or an attribute, it is in upper case. For example, an attribute
might be named "uri" or "jndiURL".
Values follow the rules for names of elements and attributes as stated
above, with the exception that acronyms will always be in all upper case.
In all other scenarios, including types and local parts of QName values,
the rules for values are followed. For example, an XML Schema type might
be named "JCABinding".
Piotr: Simon H. will incorporate feedback
Piotr: Simon N. will provide new proposal tomorrow
----- Day 2 -----
Eric Johnson: Simon H.: Request to discuss actions regarding portTypes and WSDL bindings
Eric Johnson: ... would like to touch on the http binding.
Eric Johnson: (Scribe - Eric)
Eric Johnson: Simon N: Agenda bashing?
Eric Johnson: Simon N.: Want to discuss BINDINGS-23
Eric Johnson: Anish: Can we discuss conflicts with SCA-BPEL.
Eric Johnson: Simon H: Yes, we can discuss that - but the question is how many people from this TC would be involved.
Eric Johnson: Anish: Potentially five or six people.
Eric Johnson: Simon H: We could recess for an hour or so to have that discussion.
Eric Johnson: Dave: Could we do that for 30 min.
Eric Johnson: Anish: 1/2 hr could be done
Eric Johnson: ... do really have more than 1/2 of work, but bindings TC probably has more work than BPEL....
Eric Johnson: ... which 1/2 hr would you like?
Eric Johnson: Simon H: Can Bindings TC have the 1st 1/2 hr - that way bindings TC gets two regular sized chunks.
Eric Johnson: Anish: Recess from 8:30 - 9:00 AM tomorrow, then?
Eric Johnson: Simon H: Yes.
Eric Johnson: Action items:
Eric Johnson: 20090210-1 - Done
Eric Johnson: 20090210-2 - done
Eric Johnson: 20090210-3 - Done
Eric Johnson: 20090210-4 - Done
Eric Johnson: Topics: New issues
Eric Johnson: (None)
Eric Johnson: Topic: Discuss concern around how WSDL bindings and portTypes relate to each other
Eric Johnson: Simon H: Simon N. requested that we put this on the agenda.
Eric Johnson: Simon N: About depending on what kind of binding you have, the actual portType can change. We have this notion that there is equivalence of various kinds of interfaces and portTypes...
Eric Johnson: ... if you could just derive the portType, you could derive equivalence.
Eric Johnson: ... However, depending on the type of binding, you won't get the same kind of portType. Vladimir's main point was these things are not as orthogonal as we want them to be. Does this cause problems?
Eric Johnson: Dave: How does the portType change because of the binding?
Eric Johnson: Simon N: RPC-Lit or Doc-lit changes the portType.
Eric Johnson: Anish: Is this about issue 23, or is this about something different?
Eric Johnson: ... If you want the same message on the wire, then you have to use different portTypes if you switch between RPC-LIT and Doc-Lit.
Eric Johnson: ... doc-lit fixes the messages on the wire. doc-lit uses "element", rpc-lit uses "type", so the element name ends up being defined by the rpc-lit binding.
Eric Johnson: Simon N: Suppose a ref & svc. Using interface WSDL. If one does rpc-lit, and one is doc-lit, do we consider these equivalent?
Eric Johnson: Dave: Interoperability question...
Eric Johnson: Anish: Bigger problem - we talk about interface compat. independently of bindings. If you use portTypes that use element, that can be done. If you use portTypes with "types", how can you tell that they're compatible?
Eric Johnson: Simon N: Compat. from what point of view?
Eric Johnson: ... if it uses the same portType from both ends, Assembly treats it as equivalent.
Eric Johnson: Anish: Asking the question - if you've got a reference & a svc that points to a portType that uses "type", assembly treats this as compatible. However, at the binding, they could end up different based on the binding.
Eric Johnson: ... What kind of incompatibility is this? Is this an invalid wire?
Eric Johnson: Simon H: We decided we couldn't mix binding.sca and binding.ws.
Eric Johnson: Mike E: If wired in SCA terms, there won't be a binding on the reference side.
Eric Johnson: Simon N: Could have a mixed mode of bindings if they're promoted.
Eric Johnson: Mike E: Don't think so - higher level binding obliterates.
Eric Johnson: Anish: How do you know that it is RPC lit by looking at the portType?
Eric Johnson: ... are you relying on Basic Profile?
Eric Johnson: Simon H: Can you just look at the interface? Do you have to factor in the binding?
Eric Johnson: Anish: scenario: Component reference that has an interface, and you promote the reference...
Eric Johnson: ... if you follow basic profile rules, if you use types for message parts, may only be used rpc-lit. If you use element, only doc-lit.
Eric Johnson: Simon N: Suppose comp. ref. pointing to portType with rpc-lit. In composite ref that promotes it and points at a different portType with doc-lit. Are these considered compat?
Eric Johnson: Mike E: Under discussion now. Take offline?
Eric Johnson: Simon N: Matters to bindings because of issue 23. Notion of equivalence arises in binding spec.
Eric Johnson: Simon H: Is this covered by issue 23?
Eric Johnson: Simon N: Probably come out there. Current proposal not adequate for this issue.
Eric Johnson: Anish: Is there an issue for this in Assembly?
Eric Johnson: Mike E: No. Question of matching is part of assembly spec - we should consider raising an issue. In fact there is a problem. Ways to specify interfaces in WSDL that should be equivalent but may not be treated that way.
Eric Johnson: Simon N: Operation name, input types, output types must be the same.
Eric Johnson: Anish: Definitely an assembly issue.
Eric Johnson: Simon N: Assembly - need to clarify the issue there?
Eric Johnson: Simon H: Any volunteers for taking this to assembly?
Eric Johnson: Anish: I can raise the issue.
Eric Johnson: Simon H: Can we strike the action item from our list?
Eric Johnson: Simon N: I think, with assembly issue, and issue-23, we can strike it.
Eric Johnson: Topic: HTTP binding
Eric Johnson: Simon H: No activity on this document. Obviously reflects our priorities.... Needs to be brought up to current issues.
Eric Johnson: ... when we accepted, we didn't commit to same time delivery.
Eric Johnson: ... are we going to move it forward after existing specs are in public review?
Eric Johnson: Dave: Don't see a reason why we couldn't jump into the binding spec.
anish: eric: the last time this came up there were variety of use cases for this
Eric Johnson: Simon H: OK, will continue on that basis.
anish: eric: may want to start gathering use cases from folks who are interested in moving this forward
Eric Johnson: Topic: Open issue discussion
Eric Johnson: Subtopic: Issue 55
Eric Johnson: Latest proposal:
Eric Johnson: (Bryan going through document)
anish: i like the requirement at top level
Eric Johnson: Simon N: comment - @wsdlElement - do we want the conformance MUSTs at the level of the individual bullets, instead of the top?
Eric Johnson: ... If this constraint is at a higher level, then someone could add alternate reference means.
Eric Johnson: Anish: Our direction was that @wsdlElement pointed at WSDL 1.1
Eric Johnson: Simon N: No, I don't think that was what the discussion meant.
Eric Johnson: Mike E: Confused by discussion. Is it the positioning of the MUST statement the issue?
Eric Johnson: Simon N: We would move the restriction to WSDL 1.1 to each of the sub-items service, port, binding.
Eric Johnson: Anish: Did I mis-remember. We decided that our defined elements point to WSDL 1.1. Our attributes mean WSDL 1.1. If you're going to use different things.
Eric Johnson: Simon N: Our motion was a direction, and not intended to be fine grained and precise. Not dictating the particular details of a particular case.
Eric Johnson: Anish: wording was element and subelement. We debated whether binding.ws as a whole was constrained. Decision was that defined contained attributes and elements would be restricted, not the binding.ws element as a whole.
Eric Johnson: ... If you want to point at WSDL 2.0, then you cannot use wsdlLocation, but must define your own.
Eric Johnson: Simon N: Eric did state in his discussion of the motion that I did not constrain this particular issue.
Eric Johnson: Bryan: Agreeing with Anish - understanding of discussion from last Thursday was about blanket statement for the binding as a whole vs. at an attribute level.
Mike Edwards: I have the full minutes in front of me
anish: motion text: the TC assert a direction for the resolution of issue-55, by add normative statements to the @wsdlElement and other attributes as appropriate such that they can only point to WSDL 1.1 constructs.
Eric Johnson: Eric: Intention of the motion was not meant to be very specific, and we did discuss leaving this issue open, but the point was to assert that we did not want a blanket statement for the binding.
Eric Johnson: Mike E: Motion as stated corresponds to the text that Bryan has done. You can go off and add your own extension elements. Standard elements should behave in a standard way. Otherwise people will get confused.
Eric Johnson: Simon N: We should talk about what we really want to do. Don't want to overturn the decision.
Eric Johnson: ... I don't think we decided.
Eric Johnson: Simon H: Bryan has a proposal that goes along with the motion. Do you (Simon N.) have an objection to the proposal?
Eric Johnson: Simon N: Does anyone else share my preference for a more fine-grained approach?
anish: one bug in the proposal for @wsdlLocation attr
anish: on line 120
Eric Johnson: Mike E: Need to change @wsdli:wsdlEndpoint to @wsdli:wsdlLocation in last sentence of discussion of @wsdli:wsdlLocation
Eric Johnson: Bryan moves: With the one change that Anish points out, that we accept the proposal as the resolution to Issue 55.
Eric Johnson: Anish 2nds
Simon Nash: in wsdlElement bullet: remove 1.1
Simon Nash: in first sub-bullet add MUST be a WSDL 1.1 service.
Simon Nash: in second sub-bullet add MUST be a WSDL 1.1 service and MUST be a WSDL 1.1 port
Simon Nash: in third sub-bullet add MUST be a WSDL 1.1 binding.
Eric Johnson: Simon N: Moves to make the above changes.
Eric Johnson: Motion not seconded.
Eric Johnson: Original motion passed, issue 55 resolved.
Eric Johnson: Bryan: I'll send out a revised draft with the one edit in a few minutes.
Eric Johnson: Sub-topic: Issue 57, 58, 59.
Eric Johnson: (Proposal at
Eric Johnson: (Simon N going through proposal)
Piotr: is the link above correct ?
Eric Johnson: Eric: Move to accept Simon N.'s proposal to resolve the issue.
Eric Johnson: Simon N: 2nd.
Eric Johnson: Motion passes with no objection. Issues 57, 58, 59 resolved.
Eric Johnson: Subtopic: BINDINGS-29
Eric Johnson: ...
Eric Johnson: Three choices - (1) leave properties in JCA, (2) introduce into other bindings, (3) remove from JCA, and define alternate mechanisms.
Eric Johnson: (Oops, that was Piotr)
Eric Johnson: Piotr: Want to poll the group for a direction.
Eric Johnson: Simon N: Looking at binding.jms - have a means to refer to request connection, and a response connection. Is this essentially the same concept but in a different form?
Eric Johnson: Piotr: JCA takes this one step further - provides an additional override. Stems from JCA's ability to adjust properties per interaction.
Eric Johnson: Simon N: Presumably this need for override hasn't come up. JCA apparently needs more flexibility than JMS does.
Eric Johnson: Simon H: Expected scenarios that we're supporting don't support this for JMS. Don't see a strong need to apply across bindings.
Eric Johnson: Dave: Leaning towards #1 - leave it alone. Possibly in the future going to #3
Eric Johnson: Bryan: Are there relationships between components and properties that we could align better with what JCA is doing - but that is future work.
Simon Nash: that was Dave
Eric Johnson: Simon H: Leaning towards direction #1.
Eric Johnson: (oops)
Eric Johnson: Piotr: Move to close issue 29 with no action.
Eric Johnson: Dave 2nds
Eric Johnson: Motion passes with no objection. Issue 29 closed with no action.
Eric Johnson: Subtopic: Bindings 2
Eric Johnson: (Anish's proposal at the above link, Mike Edwards follow up: )
Eric Johnson: (Anish walked through his proposal)
Eric Johnson: (Mike E walking through his changes)
Eric Johnson: Simon N; Are options ordered? Can I have an empty wsa:From?
Eric Johnson: Anish: No, you cannot have empty wsa:From
Eric Johnson: Bryan: Replace the "and" to "then" for 1.1
Eric Johnson: Dave : Why aren't we consistent using an information header wsa:From vs. [reply endpoint]? Why this inconsistency?
Eric Johnson: Anish: This is somewhat the fault of WS-Addr spec. Using the abstract property of [reply endpoint] relates to default behavior.
Eric Johnson: ... do we need more wording?
Eric Johnson: Eric: I'd like to see this inline
Eric Johnson: Mike E: Don't have to do that.
Eric Johnson: ... text is worth of inclusion.
Eric Johnson: Anish: Examples - I was hoping to treat them as editorial.
Eric Johnson: Mike E: subcode question - why isn't this a must? Is it difficult to put it in?
Eric Johnson: Anish: subsubcodes only applicable to SOAP 1.2. Might want to use an alternate subsubcode that provides more/alternate detail
Eric Johnson: Simon N: We discussed previously, and concluded this isn't a "MUST".
Eric Johnson: Mike E: #2 - Snuck in "callback operation"
Eric Johnson: Simon N: Wouldn't this be "callback message"?
Eric Johnson: Simon N: change to "callback request message correlated to an individual forward request message"....
Eric Johnson: Simon N: You don't invoke interfaces, you invoke operations
Eric Johnson: Simon N: "invoked the forward interface" that "interface" term again.
Eric Johnson: Mike E: Use forward request message?
Eric Johnson: Simon N: Yes.
Eric Johnson: Mike E: Didn't touch any of the examples.
Eric Johnson: (discussing points raised by Dave: )
Eric Johnson: Anish: If you're a client invoking a callback, you cannot set the replyto to anonymous. If you go to a polling approach, using make connection, that is a different "anonymous" make connection reply.
Eric Johnson: Simon N: What I just heard was that you have to use a different protocol....
Eric Johnson: Mike E: Is binding.ws capable of providing the intent that Dave asked about? Not clear that it can provide it under any circumstances?
Eric Johnson: Anish: Why can't it provide it?
Eric Johnson: Mike E: Will a default binding.ws element provide a polling implementation? Is there any way of applying this to binding.ws?
Eric Johnson: Simon N: Some out-of-bound mechanism saying that this would happen.
Eric Johnson: Mike E: You're claiming that a binding.ws client could validly provide a polling implementation?
Mike Edwards: The formal way to declare support for this would be to have a policy assertion
Mike Edwards: right
Eric Johnson: Anish: Without an out-of-bound agreement, no way to know to use a polling mechanism.
Mike Edwards: WS-Policy assertion
Eric Johnson: Anish: Back to defining a "WS-*" spec, whether we like it or not.
Eric Johnson: Simon N: This would be out of bound....
Eric Johnson: Anish: but there is a WS-Policy assertion - could be part of SCDL.
Eric Johnson: Anish: We're defining a protocol, and binding.ws makes the protocol optional. If you want to require that someone uses this protocol, how do we indicate how it gets used. Easiest way would be to define a WS-Policy assertion. Not sure TC members want to do that, but would be the smart thing to do.
Eric Johnson: Dave: Would at least like a note that says if you're using the "noListener" intent, should we indicate looking at the make connection spec?
Eric Johnson: ... Also agree that there is a higher level question of whether we need a policy assertion.
Eric Johnson: Mike E: Isn't this incompatible with noListener?
Eric Johnson: Anish: I don't think it is incompatible?
Eric Johnson: (Scribe wishing for a break.....)
Eric Johnson: Anish: "make connection anonymous" is legal according to this protocol.
Eric Johnson: Simon N: Ah, finally got it.
Eric Johnson: Simon H: We've got Mike's text, plus edits from discussion, plus note mentioned - who's going to do the work.
Eric Johnson: Anish: I can take a shot at v8.
Eric Johnson: Mike E: Over to you ...
Eric Johnson: Action: Anish to revise proposal for tomorrow.
Eric Johnson: Anish: Would like to ask the TC about the policy assertion.
Eric Johnson: Simon H: it is time for a break, do we discuss that point after the break, or with the revised proposal?
Eric Johnson: Anish: after break
Eric Johnson: (break for 15 minutes)
Eric Johnson: (resuming)
Eric Johnson: Simon H: Lets pickup callback and policy assertion notion?
Mike Edwards: that sounds like an Intent
Eric Johnson: Anish: designed a protocol, made it optional. Behooves us to define a way that policy assertion or something else that flags that this protocol must be used.
Eric Johnson: ... put it a policy assertion, or we define an attribute in binding.ws.
Eric Johnson: ashok: the attribute is more lightweight.
Eric Johnson: anish: it is - you still need the same normative statements. Do we want "supported but not required". You start getting into what is in policy.
Eric Johnson: ... do we want the protocol to be used at the boundaries of the SCA domain?
Eric Johnson: ... best to define a policy assertion.
Mike Edwards: +1 for a Policy assertion
Eric Johnson: Dave: This protocol is only for the edge, so it seems like we need an assertion, attributes on binding.ws don't help.
Mike Edwards: ...should be added to the proposal
Eric Johnson: Anish: Anyone who thinks that we should not define policy assertion? Happy to create a proposal, but don't want to waste time.
Eric Johnson: Simon N: Benefit is that if we do this policy assertion, then we can get compatibility between SCA impls...
Mike Edwards: SCA interop +1
Mike Edwards: +1 to an intent
Eric Johnson: Dave: Should we define an intent for this, so that a binding might always provide it?
Eric Johnson: Anish: What does the intent mean?
Eric Johnson: Mike E: It say that you must do this.
Eric Johnson: Anish: But that seems like a policy, not an intent.
Eric Johnson: Dave: There are various levels of abstraction...
Eric Johnson: Ashok: but they should always be abstract.
Eric Johnson: Dave: But if you do an intent, then you don't need to put it in a policy attachment.
Eric Johnson: ... you can add this to the "alwaysProvides" of your binding type.
Eric Johnson: ... not meaning to imply that it goes into the spec definition of the binding type.
Eric Johnson: Simon N: So then what happens? If I'm a vendor and I put it in my binding.type definition?
Eric Johnson: Anish: If this is all internal, then I must have some way of doing this....
Eric Johnson: Dave: Using the binding on the edge - the way you get policy sets attached is to just know, and you apply your intents. This just makes it easier.
Eric Johnson: Simon N: If I've got a particular bi-di service, then I would have to attach the policy set? How did it help me to define the intent?
Eric Johnson: Dave: Easier to deal with intents, rather than defining the policy set. "It just works" if the binding supports it. You'll have less configuration to do on the server side.
Eric Johnson: Anish: This is a "late" thing.
Eric Johnson: Dave: It will be late if you don't have an intent.
Eric Johnson: Simon N: Why do I need to specify the intent? Does it affect implementation semantics? Don't think it would.
Eric Johnson: Dave: Affects the way you write your binding code.
Eric Johnson: Simon N: If I had two ways to support it, then this would tell me which one to use.
Eric Johnson: Dave: Willing to back off if nobody wants it.
Eric Johnson: Anish: Hadn't thought of it as an intent. Need to think more.
Eric Johnson: Mike E: Back with you Anish to write this up.
Eric Johnson: Ashok: What are we doing about the intent? Dave?
Eric Johnson: Dave: Going to let Anish think about it.
Eric Johnson: Subtopic: BINDINGS-25
Eric Johnson: (Anish going through email: )
anish: 1) An implementation that claims conformance to this spec MUST support the bare element (i.e. support soap 1.1/http)
{corollary: Any implementation that claims conformance to this spec MUST include "soap.1_1" intent in its list of mayProvides}
2) An implementation that claims conformance to this spec SHOULD support the use of @wsdlElement within element.
3) An implementation that claims conformance to this specification and supports the use of @wsdlElement within element MUST support the WSDL 1.1 binding for SOAP 1.1 and SOAP 1.2.
Eric Johnson: Mike E: Stake in the ground - @wsdlElement support is mandatory.
Eric Johnson: Simon N: Echoing Mike's notion. People are expecting interoperability, and not quite getting it from the tools.... One side or the other of an interaction might need to get their hands dirty.
Eric Johnson: Anish: Happy to change proposal so that support for @wsdlElement is required.
Eric Johnson: Simon N: Need to be able to fall back to WSDL.
Eric Johnson: Simon N: Strange that we don't require SOAP 1.2. We do have an intent for SOAP 1.2, seems odd that we wouldn't require.
Eric Johnson: Simon H: Have we got a point of agreement, then?
Eric Johnson: Simon H: How do you want to move this forward?
Eric Johnson: Anish: Do we want me to tweak them now, or revise and resent?
Eric Johnson: Simon N: I think we can do it now.
anish: 1) An implementation that claims conformance to this spec MUST support the bare element and the "SOAP.1_1" and "SOAP.1_2" intents.
2) An implementation that claims conformance to this spec MUST support the use of @wsdlElement within element.
3) An implementation that claims conformance to this specification MUST support the WSDL 1.1 binding for SOAP 1.1 and SOAP 1.2.
Eric Johnson: Simon N: What about the plain vanilla SOAP intent?
Eric Johnson: Anish: supporting the qualified ones implies support for vanilla intent.
anish: s/An implementation that claims conformance to this spec/An SCA runtime/
Eric Johnson: Simon H: An issue worries me: this makes it clear that there are valid XML Schema conformant arrangements that are now implied as not required for support.
Eric Johnson: Simon N: Anish's #2 isn't required, is it?
Eric Johnson: Anish: We have optional items in the schema? Are we saying that everything in the schema MUST be supported.
Eric Johnson: Mike E: Let me ask the question the other way around? What do we want to be optional?
Eric Johnson: Anish: Support for extensions has to be optional. Extensions in the WSDL have to be optional.
Eric Johnson: Simon N: Let me ask about extensions - if an implementation doesn't like my extensions, does that mean that it has to fail.
Eric Johnson: Eric: Are we saying we're requiring failure if a conforming runtime encounters elements it doesn't understand.
Eric Johnson: Simon N: No, just that it is permissible to fail.
Eric Johnson: Anish: There is no way to flag that an extension is required or optional. If someone doesn't understand their spec, they don't know how to treat these attributes.
Eric Johnson: Eric: I think we have to be careful about requiring too much of binding.ws. We're imposing a heavy legacy burden.
Eric Johnson: Simon N: What if I'm talking about a mobile device that only does SOAP 1.1? Do we really want to rule SCA out of those environments.
Eric Johnson: Simon H: Sympathize, not wanting to require SOAP 1.2?
Eric Johnson: Mike E: What end user needs to know is what they can rely on? What can they do portably from one place to another? Can have a debate on whether SOAP 1.2 is required. If you don't know what it means, then that doesn't help end users.
Eric Johnson: Eric: If you're concerned about interoperability, then using Basic Profile makes sense.
Eric Johnson: Mike E: Also about portability. Developer and tool portability....
Eric Johnson: Simon N: SOAP 1.2 - don't think we should be forcing that SOAP 1.2 must be used, intent isn't just employ SOAP 1.2 if you can.
Eric Johnson: Mike E: Plea to make it clear what a user can expect from binding.ws.
Eric Johnson: Simon H: Two levels. What's the range of things that you can point at, but also which elements and attribute are you guaranteed to use. Assumption is that they're all mandatory.
Eric Johnson: ... Maybe it points to a WSDL document you don't support, but the use of the wsdlLocation attribute is required?
Eric Johnson: Simon N: Bad example - wsdlLocation doesn't have any conformance statements that it must be used if it is present.
Eric Johnson: Anish: Might not use it, because it has a cached copy. So there might be reasons why a runtime doesn't use it....
Eric Johnson: ... need to find the point of compromise between the two extremes.
Eric Johnson: ... soap 1.2, EPR are the questions. Simon made argument for not requiring SOAP 1.2, EPR also debatable.
Eric Johnson: Mike E: More questions in the back of my mind. What expectations do I have about what might be processed from my WSDL document. Are we going to demand that any binding.ws supports HTTP?
Eric Johnson: Anish: proposal I'm making is that pointing at WSDL - you support unextended SOAP 1.1 bindings for WSDL.
Eric Johnson: Mike E: Does that mandate HTTP?
Eric Johnson: Anish: Yes.
Eric Johnson: Anish: Did you mean the HTTP only binding?
Eric Johnson: Mike E: No.
anish: {}binding
Eric Johnson: Anish: Supporting that element would be a MUST, and support for SOAP 1.2 would be a SHOULD.
anish: proposal -- MUST for: SOAP.1_1, @wsdlElement, @wsdlLocation, {}binding with transport=""; SHOULD for: SOAP.1_2, {}binding with transport="", wsa:EndpointReference
Eric Johnson: Eric: We should be careful about over requiring. There's utility for supporting a subset in circumstances.
Eric Johnson: ... and if you're concerned about portability, you don't necessarily get that by enforcing runtime behavior.
Eric Johnson: Mike E: A minimal set of functionality dictates the minimal level at the design time.
Eric Johnson: Simon H: What is the assembly spec requiring?
Eric Johnson: Mike E: Not many cases in assembly where support for items is optional.
Eric Johnson: ... references to external documents are rare in assembly.
Eric Johnson: Anish: Are all intents required
Eric Johnson: ...?
Eric Johnson: Dave: No none of the intents MUST be supported.
Eric Johnson: (Anish going through what he posted in chat above.)
Eric Johnson: Mike E: Looking at this from a test perspective - I now have something to validate.
Eric Johnson: Eric: minor quibble - spec uses "endpointReference", not wsa:EndpointReference.
Dave Booz: we need ot get Ashok to fix this UPA junk in schema
Eric Johnson: Anish: this is horrible!
Eric Johnson: Mike E: Why not just reference the normative requirements of wsa:EndpointReference if there's an issue.\
Eric Johnson: Anish: if endpointReference is in our own namespace, support should be a "should".
Eric Johnson: ... stand by proposal in the chat.
anish: except for the namespace: s/wsa:/sca:/
Eric Johnson: Eric: WS-Addressing might drag in a whole bunch of security concerns.
Eric Johnson: Simon N: Are we really only using the URI from the EPR?
Eric Johnson: Anish: Why use the EPR, if all we need to use wsa:Address?
Eric Johnson: Simon N: this might depend on the resolution of issue 54.
Eric Johnson: Anish: Whatever the precedence rules, if all you have in the EPR is the URI, why bother?
Eric Johnson: Simon N: Relates to issue 54
Eric Johnson: Simon H: Need additional text in WS binding around the semantics of the EPR.
Eric Johnson: Anish: Since this is an element we've defined, we could say what Mike has suggested, that this has the semantics of the EPR as defined over there.
Eric Johnson: Anish: Two different things - are you required to support sca:endpointReference, and if you do support it, then what does that mean?
Eric Johnson: Simon N: It doesn't say endpoint address, it just says endpoint.
Eric Johnson: Simon H: Issue there that needs to be clarified.
Eric Johnson: Simon N: Uncomfortable making a final decision on this before settling issue 54.
anish: revised proposal -- MUST for: SOAP.1_1, @wsdlElement, @wsdlLocation, {}binding with transport=""; SHOULD for: SOAP.1_2, {}binding with transport="", sca:EndpointReference
Eric Johnson: Revising Anish's revised proposal -- MUST for: SOAP.1_1, @wsdlElement, @wsdlLocation, {}binding with transport=""; SHOULD for: SOAP.1_2, {}binding with transport="", sca:endpointReference
Eric Johnson: ... (naming conventions)
Eric Johnson: Mike E: Motion to call the question.
Eric Johnson: Simon N: Objection.
Eric Johnson: Dave B: There is no motion on the table.
Eric Johnson: Anish: Proposed an resolution, but it is not formulated as a motion.
Eric Johnson: Simon N: If we were to decide that a URI is relative, then I want the support of endpointReference to be required.
Eric Johnson: ... only asking to delay until we discuss the other issue.
Eric Johnson: Anish: Simon N's vote here depends on the other issue.
Eric Johnson: Simon N: yes.
anish: Topic: issue 54
anish: eric: tried to be consistent across SCA specs (assembly/binding)
anish: eric: there are three rules for URIs and I could not figure it out. SimonN had to point out the exclusivity
Eric Johnson:
anish:
anish: If the wsdl element is present on a service, use the address on the wsdl port
anish: eric: should you let the deployer to override
anish: ... multiple possibilities: fail, have something else override, or ignore
anish: ... nervous about putting in a "MUST"
anish: ... if it is the service element, then there could be multiple ports
anish: ... some of them may be non-soap
anish: ... not sure how to address that problem
anish: ... if sca:EPR is present and has an absolute address then use that. But has the same problem as ports
anish: ... assembly section 9 talks about using only relative URIs
anish: SimonN: depends on which part of section 9 you're looking at
anish: ... after structural URI issue was resolved, some new things are added
anish: Eric: the OSOA version had a notion of base URI, this isn't there anymore
anish: ... since there is no base URI, can't mandate the absolute URI
anish: Anish: ws-addressing says that wsa:EndpointReference/wsa:Address must be an absolute URI
Eric Johnson: anish: notion of specifying an absolute URI for a service is kind of strange.
Eric Johnson: .. what is the rationale?
Eric Johnson: Simon N: Could be useful in some kind of simple test scenario.
Eric Johnson: Anish: not captured by base URI.
Eric Johnson: Simon N: Not sure it ever was.
Eric Johnson: Eric: In creating proposal, I was trying to preserve the semantics of the existing proposal. The absolute URI problem is still there. Absolute URIs are convenient for reimplementing a service that already exists.
Eric Johnson: Simon N: relative vs. absolute. There is a notion of structural URI. URI on the binding element was to be considered the binding URI. Assembly should have no opinion.
Eric Johnson: ... believe that the statement in assembly spec about the service element, binding, that it must be relative is in error.
Eric Johnson: Dave: Believe this statement is correct.
Eric Johnson: (meeting recess)
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.