[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes from 2009-02-11
Simon Holdsworth: SCA Bindings TC virtual face to face meeting Chat room: http://webconf.soaphub.org/conf/room/sca-bindings-TC Audio conference: Meeting Number: * 913929 * (press * before and after the digits) Phone numbers: Austria = Vienna 026822056419 Belgium = Brussels 022901709 China Toll Free = China North 108007121722, China South 108001201722 Denmark = Copenhagen 32714982 France = Paris 0170994364, Lyon 0426840196, Marseilles 0488915310 Germany = Berlin 030726167296, Frankfurt 069710445413, Hamburg 040809020620, Munich 089244432767, Stuttgart 0711490813212, Dusseldorf 021154073845 India Toll Free = 0008001006703 Ireland = Dublin 014367612 Italy = Milan 0230413007, Rome 06452108288, Turin 01121792100 Japan = Tokyo 0357675037 Netherlands = Amsterdam 0207965349 Portugal = Lisbon 211200415 Russia Toll Free = 81080022074011 Spain = Barcelona: 934923140, Madrid: 917889793 Sweden = Stockholm 0850520404 Switzerland = Geneva 0225927186 UK Toll Free = 08003581667 UK Toll = London 02071542988, Manchester 01612500379, Birmingham 01212604587 USA Toll Free = 18665289390 USA Toll = 19543344789 Simon Holdsworth: Agenda Simon Holdsworth: 1. Opening Introductions Roll call (LOA: Martin Chapman) Scribe assignment Top 10 on the scribe list: Nimish Hathalia TIBCO Software Inc. Plamen Pavlov SAP AG Khanderao Kand Oracle Corporation Martin Chapman Oracle Corporation Simon Nash Individual Laurent Domenech TIBCO Software Inc. Anish Karmarkar Oracle Corporation Eric Johnson TIBCO Software Inc. Ashok Malhotra Oracle Corporation David Booz IBM Agenda bashing Meeting timing: 15 minute break at 09:00. Discussion of specific issue resolutions limited to 30 mins on each day 2. Actions 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 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 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) No new issues 4. Discuss concern around how WSDL bindings and portTypes relate to each other As per AI 20080717-6 5. HTTP binding specification status. Needs to be brought up to date with respect to conformance, conventions etc. Members need to review and open issues if we are to make progress on this binding. 6. Open Issue Discussion http://www.osoa.org/jira/browse/BINDINGS-55 WSDL 2.0 support Raiser: Bryan Aupperle, owner: Bryan Aupperle Status: Latest proposal: http://lists.oasis-open.org/archives/sca-bindings/200902/msg00038.html 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: Eric Johnson Status: Latest proposal at http://lists.oasis-open.org/archives/sca-bindings/200902/msg00044.html 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: Eric Johnson Status: Latest proposal at http://lists.oasis-open.org/archives/sca-bindings/200902/msg00044.html 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: Eric Johnson Status: Latest proposal at http://lists.oasis-open.org/archives/sca-bindings/200902/msg00044.html http://www.osoa.org/jira/browse/BINDINGS-29 Properties on Bindings Raiser: Piotr Przybylski, owner: Piotr Przybylski Status: No current proposal; discussion required 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/200902/msg00050.html Latest email: http://lists.oasis-open.org/archives/sca-bindings/200902/msg00051.html http://www.osoa.org/jira/browse/BINDINGS-25 Is it required that every implementation of binding.ws support the soap intent? Raiser: Anish Karmarkar, owner: Anish Karmarkar Status: Proposal: http://lists.oasis-open.org/archives/sca-bindings/200902/msg00049.html http://www.osoa.org/jira/browse/BINDINGS-54 Endpoint URI algorithm is unclear Raiser: Eric Johnson, owner: Eric Johnson Status: Latest email: http://lists.oasis-open.org/archives/sca-bindings/200902/msg00046.html http://www.osoa.org/jira/browse/BINDINGS-65 Remove references to SCA conversations from binding.jms Raiser: Simon Holdsworth, owner: Simon Holdsworth Status: Proposal in email: http://lists.oasis-open.org/archives/sca-bindings/200902/msg00055.html http://www.osoa.org/jira/browse/BINDINGS-67 JMS URI vs. binding attributes/elements Raiser: Simon Holdsworth, owner: Simon Holdsworth Status: Proposed direction for resolution in issue needs updating Open issues with identified resolution owner: http://www.osoa.org/jira/browse/BINDINGS-22 Bindings JCA specification should provide exemplary Implementation for Callbacks Raiser: Mike Edwards, owner: Piotr Przybylski Status: No proposed resolution http://www.osoa.org/jira/browse/BINDINGS-23 @wsdlElement definition needs clarification on "equivalent" and use of WSDL 2.0 constructs Raiser: Eric Johnson, owner: Simon Nash Status: Specific resolution text required 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-48 How are mayProvide intents on bindings satisfied Raiser: Ashok Malhotra, owner: Simon Holdsworth Status: No current proposal; latest email: http://lists.oasis-open.org/archives/sca-bindings/200810/msg00041.html http://www.osoa.org/jira/browse/BINDINGS-54 Endpoint URI algorithm is unclear Raiser: Eric Johnson, owner: Eric Johnson Status: Initial proposal in JIRA. http://www.osoa.org/jira/browse/BINDINGS-60 JMS Default wire format insufficient to cover real world usage Raiser: Simon Holdsworth, owner: Simon Holdsworth Status: No proposal 7. AOB Eric Johnson: Simon H.: Request to discuss actions regarding portTypes and WSDL bindings anonymous morphed into anish 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 becuase of the binding? Eric Johnson: s/becuase/because/ 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: http://lists.oasis-open.org/archives/sca-bindings/200902/msg00038.html 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 52. Eric Johnson: Anish 2nds Simon Nash: in wsdlElement bullet: remove 1.1 Simon Nash: in first sub-bullet add <service-name> MUST be a WSDL 1.1 service. Simon Nash: in second sub-bullet add <service-name> MUST be a WSDL 1.1 service and <port-name> MUST be a WSDL 1.1 port Simon Nash: in third sub-bullet add <binding-name> 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 http://lists.oasis-open.org/archives/sca-bindings/200902/msg00044.html) 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: ... http://www.osoa.org/jira/browse/BINDINGS-29 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? Bryan Aupperle: s/Issue 52/Issue 55/ 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 2http://lists.oasis-open.org/archives/sca-bindings/200902/msg00050.html Eric Johnson: (Anish's proposal at the above link, Mike Edwards follow up: http://lists.oasis-open.org/archives/sca-bindings/200902/msg00051.html ) 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: http://lists.oasis-open.org/archives/sca-bindings/200902/msg00063.html ) 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 a 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? Eric Johnson: s/\?/./ 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 +` Mike Edwards: +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: http://lists.oasis-open.org/archives/sca-bindings/200902/msg00049.html ) anish: 1) An implementation that claims conformance to this spec MUST support the bare <binding.ws/> 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 <binding.ws> element.
3) An implementation that claims conformance to this specification and supports the use of @wsdlElement within <binding.ws> 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 <binding.ws/> 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 <binding.ws> 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. 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, {http://schemas.xmlsoap.org/wsdl/soap/}binding with transport="http://schemas.xmlsoap.org/soap/http"; SHOULD for: SOAP.1_2, {http://schemas.xmlsoap.org/wsdl/soap12/}binding with transport="http://schemas.xmlsoap.org/soap/http", 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, {http://schemas.xmlsoap.org/wsdl/soap/}binding with transport="http://schemas.xmlsoap.org/soap/http"; SHOULD for: SOAP.1_2, {http://schemas.xmlsoap.org/wsdl/soap12/}binding with transport="http://schemas.xmlsoap.org/soap/http", sca:EndpointReference
Eric Johnson: Revising Anish's revised proposal -- MUST for: SOAP.1_1, @wsdlElement, @wsdlLocation, {http://schemas.xmlsoap.org/wsdl/soap/}binding with transport="http://schemas.xmlsoap.org/soap/http"; SHOULD for: SOAP.1_2, {http://schemas.xmlsoap.org/wsdl/soap12/}binding with transport="http://schemas.xmlsoap.org/soap/http", sca:endpointReference
Eric Johnson: ... (naming conventions) Eric Johnson: Mike E: Motion to call the question. Eric Johnson: Simon H: 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: (oops Simon H. Objection. - actually Simon N) 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 anish: <eric walks thru his email> 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) |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]