- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Wed, 5 Mar 2003 12:31:40 -0800
- To: <www-ws-desc@w3.org>
- Message-ID: <330564469BFEC046B84E591EB3D4D59C099D3FDB@red-msg-08.redmond.corp.microsoft.com>
------------------------------------------------------- Tuesday 4 March ------------------------------------------------------- 09:00 7 MEP review (cont) [scribe: Philippe] (slides not available yet) (Gudge does his presentation "An Interesting MEP") "A data item service" MEP 2 IN, OUT with HTTP binding, req-resp, single channel. sync n clients, one service. consider multicast binding n clients, one doing an input, the service doing n outputs. one input, one output (for n clients) from the client view, the http client sees a req-resp (I have 2 bindings, one for http, one for output only) Marc: the output is delivered through http? Gudge: no, no http involved. I have a binding that says you can send input and I'll broadcast it. Like IM or IRC. From the server propspective, it's an input/output. Gudge: both bindings refer to the same portType Martin: I assume that one binding is used for the input/output but in your case, they could be different? Gudge: they are completely different bindings. Umit: adding multicast is a different MEP Gudge: that's more a binding issue than portType. [sanjiva: I am temporarily on another call, but I note that dealing with multicast responses require different programming models - hence it must be represented at the portType level.] Marc: what problem are you pointing? Gudge: How abstract are portTypes? Is it reasonnable to describe such a portType and bind it the way I did? Glen: The implications here that we have application semantic on top of it. How do I express that I'm going to use one binding on the input and an other on the output? Jacek: Gudge's case seems an optimization, we don't have to care about it. Gudge: for me, it was interesting to have the abstract using one MEP and have it completely different from the consumer point of view. Jonathan: wanted to make sure that this potential issue wasn't a real one. Glen: still thinks that they are hidden issue in it, using two differents bindings from the same service, but that's ok for now. Jonathan: can we collect any issue against the MEP stuff? Jacek: I don't see the motivation for MEP 7 as it stands, but given the others don't have either, I'm fine. Jonathan: ... beauty contest in the desert ... :) jacek: our MEPs won't allow more than 2 roles? or we won't define some? if the latter, we should demonstrate that it is possible. Jeff: use extensiblility Amy: where does an additional role stand? for the moment, you have the service and everybody else. how do you describe alternative among eveybody else? Glen: if you stick on each input/output a uri, you can describe the message if you want. Gudge: you can do that, today but nothing in the syntax. The MEP has an uri and describes what those NCName means, so why does you need uris? Glen: it would be convenient. if there is ncname, it will be harder to define scheme. Gudge: it's a pair ... a qname :) Jonathan: anything else? Do we want to add the MEps in part 1, part 2, other? Amy: numeric are somewhat opaque. We need a motivation for each MEP. If somebody can't come up with a nickname and a use case, it might not be a every common idiom. [editorial discussion to have use cases] Amy: we need a sample for the MEPs. TomJ: what's the difference between MEP2 and MEP3? MEP3 is req and possible resp? [alewis: IN, OUT*, oFault?] Jeff: req and multiple resp. I can come up with names like "one-way", "multiple-output" ... Gudge: what's the point? Amy: let's collect the justifications. Jonathan: can we deal with it at CR time? Tom: collecting use cases is easy, but we are raising the bar high. Gudge: if I had to pick 2, I'll pick MEP1 and MEP4 :) [discussion about a beauty contest for MEPs] Tom: wants to reduce the list. Gudge: argues it is not worth going there for the moment. Amy: we have costumers for some of the MEPs. [GlenD: +1 to Gudge's MEP1 + MEP4. Let's do it.] Tom: this group may not be able to satisfy all your custumers. [sanjiva: Yeah and what about simple request/response stuff like getQuote()?] Jonathan: union rather than intersection for our MEPs? [Tom keeps arguing about satisfying his customers over others' :) ] Tom: I'd like to reduce the scope of the spec. I'd like to be done with it;. Gudge: having 7 MEPs make the spec more useful for more people. [Jonathan plays his straw poll/vote card] [sanjiva: are all 7 meps required to be supported? ] [sanjiva: That is, is a compliant proceessor required to handle all of them] sanjiva: compliance for the 7 meps? Jonathan: not all bindings need to support the meps. jeff: do we have a mep normatively but not a normative binding that supports them? Amy: the soap processor does not require you to do http which is the only binding provided there. [TomJ: To make my position on the 7 MEPs clear, I think that we have too many, inparticular MEP 3, 6 and 7. These MEPs don't have common use cases and we should really set the bar high on this and take them out of the normative spec.] [sanjiva: +1 for reducing the # of MEPs] [TomJ: I understand that others *have* use cases, but I haven't heard enough demand from multiple companies to make me believe there will be critical mass for them.] Amy: if you support the soap binding, the soap req-resp and the webmethod get. there are 2 meps required, if you support the binding, you have to support those 2 meps and not others. Glen: the soap resp MEP is not MEP 2. the binding is different. Amy: from WSDL point of view, I should be able to describe messages others than XML messages. Sanjiava: are we going to document 7 MEPs, with use cases, etc. What are our criteria? Jonathan: that's a political process. we'll have champion for each MEP. if no champion, they will be less likely to go in the spec. Jonathan: suggestion on how to move forward? [community feedback, champion, use cases, ...] MChapman: there is a document (usage scenarios) in the WSA with 36 MEPs... jonathan: we're trying to have balance with atomic ones and add a few really common ones. Gudge: I still like original formulation of fault from Amy: any message can be a fault. [MChapman: correction: the usage scenario doc i referenced is a wsd doc, wsa has its own! http://www.w3.org/TR/ws-desc-usecases/] [alewis: My formulation was actually that any message can *trigger* a fault. And that if there's no available return path, then it is discarded.] Amy: do we want a set of requirements for MEP? Philippe: we can throw some out at the CR phase Jonathan: we can ask people to show examples of usage of those MEPs. Amy: following QA recommendations, we might add performance requirements, two working and interoperable example the use a MEP in order to have it in the draft. Jonathan: reasonnable requirement to set for the CR phase. Martin: we can all parse the documents that use those MEPs. [sanjiva: are we going to define MEPs that we won't use at all??? I don't think we should do that.] Joanthan: some of these MEPs won't be usuable with our bindings. people we need to come up with some during the CR phase. Martin: this is the wsdl group, not the soap interoperable group. Amy: at some point, we need to find if each MEP is useful or not. JeffM: easier to mvoe to CR with less MEPs... Jonathan: if no one implements a MEP with a binding, we pull it out at the end of the CR phase. 2 interoperable implementations would be required. Sanjiva: is the tcp binding going to be documented? I thought we will provide one binding for each MEP... Jonathan: I thought the group agreed the reverse actually. To make it clear, if Amy wants to keep MEP 7, she'll need to convince someone else to implement it as well with the same binding. Amy: such effort are going on as we speak. Sanjiva: are you going to recommending the binding after the CR phase? Gudge: no, we'll just keep the MEP in the spec. Amy: "2 independent implementations". Philippe: how do we record that? Jonathan: as an issue in the MEP spec seems reasonnable. Sanjiva: we cannot prove that we have 2 implemetnations, unless we have the bindings. Jonathan: that's correct. JeffS: interoperability of WSDL is not the same as interoperable of SOAP. how did we get there? how do you think this criteria will be met? Amy: "we have supplied you with MEPs, go thou and bind them" Jonathan: the failure mode is to move the MEP into the darkness of your own namespace. :) ACTION: editors of the MEPs to record this CR requirement in the document Jonathan: name issue resolved? Gudge: I like numbers. [sanjiva: I like names .. :)] Gudge: lots of troubles we ran into were due to conotations with names. ------------------------------------------------------- 10:50 Break 11:20 7 MEP review (cont) [MEP names continued) [7 sins? 7 dwarves?] [related to their description] [arbitrary name or names of some sense?] [MEP name is pushed on the stack] DBooth: [catching up] I'm concerned with the way we are defining the MEPs. When is the appropriate time to raise this issue? Jonathan: ... CR ... evidence of utility of the MEPs ... DBooth: not concerned about the choice of MEPs but about the way we are defining them. I believe it conflicts with WSA understanding of MEP. Looking at the glossary definition from Gudge's presentation, was concerned with his definition of MEP. incomplete definition of MEPs, ignore the parties that are involve. Gudge: that's up to the binding. We agreed in Arizona that we would describe them from the server point of view. DBooth: that's orthogonal. Jonathan: our definition of MEP is in the MEP lists. Are you arguing against it? DBooth: yes, the parties are ommitted. Gudge: we established this morning to have a MEP and map to two different bindings. DBooth: I'm concerned about that. Doesn't seem the understanding of MEPs. Gudge: MEP in WSDL are not the same as SOAP MEPs and maybe different in WSA as well. The MEP describe messages in and out at the portType level. JeffM: for me, portType means the transport level DBooth: a WSDL is for use between parties, it's a shared thing. at least two. the point is to get interoperability. Both parties must agree. WSDL as is defined today is written, for convenience, is written from the point of the service. That does not change the fact that the document is intended to be used by both parties. We could have done the opposite way: Web Client Definition Language. The purpose would have been the same. JeffM: I disagree that we would be the same thing. DBooth: it would be the exact complement. Gudge: there is an assumption that flipping WSDL would be the mirror. This assumption is not true. Martin: you can setup expectations from the client point of view anyway. DBooth: the point of view is independent of the purpose of the description. Gudge: how does the service use it? Glen: you build skeletons on the service with it. that's a contract. DBooth: then, if the contract has all information between the two parties, it would be nice to have it shared by more. Amy: the client cannot see the agreegated service. DBooth: each interaction has a WSDL. different portTypes. [JacekK: this image might be helpful: http://lists.w3.org/Archives/Public/www-ws-desc/2003Feb/att-0069/01-meps.png] DBooth: different service address. WSD representts Agreement (or contract between 2 parties) Martin: not a contract in terms of negotiation. it's defined from the service. DBooth: take it or leave it contract. Definition of MEP 1 template for the exchange of messages between nodes. it's a message _exchange_ pattern. Levels of Abstraction / Reusability - No abstraction/reusability - Variable service address - Variable transport [GlenD: Node Emission and Reception Description (NERD)] [Gudge: Message Emmision and Reception Pattern - MERP ( rhymes with burp )] DBooth: you can reuse the abstract even with different protocols. Glen: if Gudge's example valid, we lost that already. DBooth: possible level of abstraction here. each level gives you more reusability. JeffS: we want to make standard here. I need you to be very specific of the piece of abstraction that we lost. DBooth: the symbolic identity of the parties must not be abstracted. JeffS: doesn't exist in WSDL 1.1 DBooth: my understanding of WSDL 1.1 is that the operations that are described are between two parties. JeffS: you're arguing that was implicit in WSDL 1.1 then. you want to make explicit? DBooth: we shouldn't push it in the binding. [http://lists.w3.org/Archives/Public/www-ws-desc/2003Feb/att-0069/01-meps.png] Jacek: in David's world, WSDL is a contract. SOAP MEP can cover any kind of complex MEP. What is a WSDL MEP? Is it the part that concerns one node and involved two parties? You can an MEP as me as a service and the world, or me, you, and the interactions, or me, you and a set of nodes. We should decide what way we go. Glen: there should no way to confuse at the abstract level me and you (or other nodes). Web Services is about the wire and what goes on the wire. need to think about the connections between things. JeffS: I'm trying to describe the messages from a network with a service [...] Umit: the problem with JeffS' level of abstraction, you loose the initial intention. multicast is not the same intention than simple req-resp. JeffS: a possible move is to accept both views. Gudge: given that binding can do the way like anyway, how do we go? Glen: it's going to be challenging for people to deal with that. DBooth: agree that 2 levels of abstraction is ok. People will want to reuse the same pattern of interactions. Gudge: from the service, it is always the same pattern. Glen: the semantic of the service is different. don't multicast my bank information. Gudge: how can you prevent that anyway? You stated that it is possible to build unsecure binding, which is fine. DBooth: if you define things at the binding level, you may not be able to reuse them Igor: can you 2 bindings concretizing one MEP? [input/output, one binding for input, one binding for output.] JeffS: you have to define constraint in the same binding. Our construction today implies that you'll need one binding construct to represent email input / soap output for example. Martin: so, in Gudge's example, who describe the multicast? Gudge: we have simple MEPs that can be bound to more sophisticated binding. DBooth: [trying to summarize] if you define an operation with MEP 2, it is ambiguous if the output is supposed to go back to the same party that sent it. Gudge: it always goes back to the party, it may go to others as well. [MChapman: i'll try and explain my issue: if at the abstart level one uses a mutlicast mep and in you binding over tcp (for example) how does that work - who defines all the extra mecanism, or should that mapping be invalid] Gudge: if it's going to take us too long, let's have MEP 1 (input only) and MEP 4 (output only). Glen: actually, no one explained how to do input/output over one way protocol Martin: then let's adopt CCPA. it only describes input, output messages. [sanjiva: CCPA?] [Gudge: CCPA - Canadian Chemical Producers' Association, Canadian Centre for Policy Alternatives, Cumberland County, PA, Canadian Concrete Pipe Association, Connecticut Community Providers Association, Centre for Creative and Performing Arts] [s/CCPA/CPPA/] [MChapman: ebxml Collaboration Profiles and Protocol Agreements] DBooth: I don't think we should the ambiguity between the input goes to the server and the output goes to somewhere we don't know. Amy: it doesn't seem that you're suggesting that we need multiple roles. you want to ensure that the output goes to the sender of the input message. JeffS: we can reuse properties and features to describe David's concern. Soap identifies the parties except the current one. tom: I believe that David want the input/output involved the same parties for the MEP 2. Amy: the agreement in Scottsdale was MEP 2, not request-response. there may be a use for a request-response, but that's not the agreement. Tom: I don't think that's true. DBooth: I'm okay with Amy's statement but let's distinguish it clearly then. [...] Jonathan: I propose to add this issue in the spec. DBooth: can we take a straw poll on this issue? Jonathan: do we want to be able to express a request-response at the portType level? JeffS: I note that in the current spec, you can make any arbitrary statement about an MEP. you rewrite MEP2 to include David's need. Glen: does our concept of MEPs can be linked to a more general concept of MEPs that includes roles? [dbooth: q1: Should we have an MEP at the PortType level that is request/response (i.e., the response is known to go back to the requester)?] [dbooth: q2: Should we have an MEP at the PortType level that is input/output without implying that the output goes to the same party as the input came from?] [jeffsch: jeffsch notes that q2 is the current MEP2] Tom: I always had the view that MEP2 was in fact q1 [dbooth: These two questions are not mutually exclusive. We can certainly say yes to both.] Martin: I don't really care as long as you can annotate the MEPs at the abstract level. Sanjiva: why is important to annotate the difference between those 2 cases? DBooth: it might not be important. I think it is important to know that interaction pattern and reuse it. Glen: WSIF have said it is important. Mark: with a request-response, you can assume the recipient of the output based on the sender of the input. [straw poll q1: 14 yes, 8 no q2: 15 yes, 5 no] Gudge: so we now have 14 MEPs... [sanjiva: I vote for not distinguishing] [sanjiva: (soon we'll be up to 140!)] ACTION: Editors MEP to add an issue to address request-response MEP. [JacekK: we have 8 MEPs, maybe 9 if MEP3 is also concerned] [going back to MEP name] [arbitrary name? meaningful name?] Jonathan: do we want to change the current names (MEP1, MEP2, ...) to something more meaningful? Having arbitrary names won't mislead people. do we want to change the current names (MEP1, MEP2, ...) to something more meaningful? [17 yes, 1 abstain] arbitrary names? [2 yes] ACTION: Editors MEP to suggest meaningful names for our MEPs [sanjiva: integrate to part1 draft] [do we want to include the MEP spec into part 1 or part 2? or separate?] [Allen: Part 1] Glen: soap describes the concept of MEP in part 1 and defined some in part 2 [sanjiva: specific MEPs are not binding specific .. they are not bindings either. They are abstract. So IMO either its in part 1 or in part 1.5.] [part 1? part 2? part 3?] part 3: 12 for part 1/part 2 in some fashion: 3 for Resolution: let's keep as separate spec for the moment. part 2 is for MEPs part 3 is for bindings ACTION: Editors to come up with a part for MEPs Jonathan: any objection to roll in the changes of part 1 into the main branch? [jjm-rns: no] [postponed] [Gudge: http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12.xml?rev=1.46.2.4&content-type=text/xml&only_with_tag=ComponentModelForMEPs] [Gudge: http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12.html?rev=1.21.2.1&content-type=text/html&only_with_tag=ComponentModelForMEPs] ------------------------------------------------------- 12:50 Lunch 14:00 issue clarify type and element - Arthur's proposal [11] [11] http://lists.w3.org/Archives/Public/www-ws-desc/2002Sep/0055.html Agenda item (clarify type and element) Arthur: problem is coupling between port type and binding. Caused by incompleteness in the binding rules [Arthur presents presentation: URL to follow......] [dbooth: Arthur's slides are now available as PowerPoint at http://www.w3.org/2003/ws/desc/3/05/arthur/RemovingElementAttribute.ppt or as HTML at http://www.w3.org/2003/ws/desc/3/05/arthur/RemovingElementAttribute_clean.htm] Tomj: concern that introducing more options on the binding that effect the wire Arthur: currently there's a diff port type per binding Tomj: did we already look at type and element (getting rid of one or both)? Gudge: in VA... Main motivation to create abstract messages ?? Arthur: yes Gudge: Agrees to get rid on one..... Arthur: if we keep both the bindings need to be a lot more rigorous Marsh: Is one of the reasons we've delayed this is that we can't decide which one to remove? Umit: Maybe we should really work on the bindings before we remove either one. [Now at Example SOAP Doc Binding slide] Gudge: It isn't possible to guarantee all messages in WSDL be bindable to SOAP/Doc, SOAP/RPC or ...... Still don't get the "wrap" use Glend: pitches for keeping element and removing type [sanjiva: Glen, if you keep only element, how do you define a string part?] [GlenD: Sanjiva, Just as you need to wrap an element in a type for the other direction, you can wrap a type in an element this way. name="foo" type="xsd:string" I could either put <part> around that, or <element> around it. Same fing. [sanjiva: spse you have a function foo that takes two strings s1 and s2. You would need to define two elements right? Beacuse the name is part of the definition] [GlenD: there are two elements, yep. name="s1" type="xsd:string"] [sanjiva: Right so its not the same thing- the other way you don't have that problem name="s2" type="xsd:string"] [GlenD: ?] [sanjiva: I mean wrapping an element in a type approach (i.e., the drop @element case)] [GlenD: what's the "problem" you refer to] [sanjiva: That you have to define a new element for each use of a simple type] [GlenD: oic well this gets into the next discussion... :) it's only redundant if you have both part and element. If "message" is just an element containing elements.... they're only defined once.....] [sanjiva: And what about a mime:image/jpeg "part"?] [GlenD: aye there's the rub, matey. annotations.] [sanjiva: yep] [GlenD: But that's the tricky part] [jeffm: Here is the url to the current "approval draft" for the WS-I 1.0 Basic profile: http://www.ws-i.org/Profiles/Basic/2003-01/BasicProfile-1.0-WGAD.html] [sanjiva: that's utter crap ;-)] [GlenD: we'll get there yeah yeah. :)] [Now on HTTP Post Binding slide] [Gudge and Arthur discuss HTTP Post/Get bindings ] Arthur: The net of the talk is to achieve abstractness at the port type.... Is there agreement that a worthy goal that port types are abstract?? [Group agrees (nobody decented)] Arthur: This implies that the binding specification need to be fixed (ie.not broken) Marsh: The question is do we want to remove either type or element..... Umit: should look at removing message before addressing the type/element decision... Marsh: Should we still keep the type vs element issue open?? group: yes ------------------------------------------------------- 15:15 Break 15:20 Renaming - Template [12] - Phillipe's proposal [13] portType -> interface; port -> endpoint; binding -> interfaceBinding - Jacek's proposal [14] binding/@type -> binding/@interface - DavidO's proposal [15] port -> Service portType -> Interface service -> ServiceCollection [12] http://lists.w3.org/Archives/Public/www-ws-desc/2003Feb/0120.html [13] http://lists.w3.org/Archives/Public/www-ws-desc/2003Feb/0103.html [14] http://lists.w3.org/Archives/Public/www-ws-desc/2003Feb/0108.html [15] http://lists.w3.org/Archives/Public/www-ws-desc/2003Feb/0112.html Agenda item: Renaming TomJ: Prefers smaller changes to the naming than DaveO's changes. SJ: Should save this for WSDLv2.0 GlenD: doesn't see name changing any more than changing a namespace as far as the language Amy: Name change is also desirable for naming conflicts between WSDL and other environements (ex defn. of service) Dbooth: Friendly ammendment (change port to webservice) to dave's proposal GlenD: s/web service/endpoint Marsh: Let's take one at a time Straw Poll: change portType to interface [results of straw poll (uc)] port: endpoint? endPoint? service? webservice? [Allen: I vote for endpoint] Issue: Re-open One interface per service issue [Gudge: I think we should choose some unicode code points outside the ASCII range and use those. Then we could get down to single character element names ;-)] TomJ: Call for straw poll: endpoint yes or no Yes = 16 No = 0 Marsh: Any objections to endpoint ? (none) Amy: should re-visit the service renaming until the (one interface per service issue) is solved.... [sanjiva: -1 for changing to interfaceBinding] Marsh: Changing "binding" to "interfaceBinding" Yes or No? Yes = O [TomJ: Proposal: binding/@type -> binding/@interface] [sanjiva: +1 to Jack's proposal to make binding use @interface] [Allen: yes] Marsh: All in favor of changing type attribute of binding to interface?? Yes or No Yes = all Marsh: change mep attribute on operation to "pattern" Y/N Yes = 13 No = 0 ------------------------------------------------------- 16:50 issue fault name uniqueness - Paco's proposal [10]. [10] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jan/0045.html New fault elements and names proposed to replace the generic fault [sanjiva: +1 TomJ's proposal] [Marsh: <inputFault name="..."> <message>ツ....</message>? </inputFault>] = what Jon thought Tom wanted] [Gudge: That works] [Marsh: <inputFault name="..." message="..."/>* = what Tom actually wanted.] [Gudge: I don't think that works. Because we can't enforce the uniqueness constraint] [sanjiva: I don't understand - do you mean from XSD?] [Gudge: that the groups need to have different names ( and those names need to be unique WRT input and output too )] [sanjiva: We can express that in English; are you saying it cannot be expressed in XSD?] [GlenD: good q] Amy: given the impending change in syntax for faults/fault groups, fault name uniqueness may be a non-issue Marsh: fault name uniqueness now a non-issue ------------------------------------------------------- Marsh: eliminating message agenda item deferred Marsh: Future F2F info updated on the web site, please check. Marsh: message (eliminate) issue will be moved back to telecon discussions ------------------------------------------------------- 17:00 Adjourn --------------------------------------------------------------------- Topics for future meetings: 1) issue eliminate message - [Relevant materials from Roberto, Gudge, etc.] 2) If we have no other outstanding Part 1 issues, we will try to tackle some properties/features dependent issues. - BindingType proposal from Kevin [.1]. Updated proposal at [.2]. - Issue 28: transport='uri' [.3] - Issue 2: SOAPAction has been deprecated, as of SOAP 1.2 [.4]. Jean-Jacques proposal at [.5]. Jacek's addendum at [.6]. [.1] http://lists.w3.org/Archives/Public/www-ws-desc/2002Aug/0009.html [.2] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jan/0068.html [.3] http://www.w3.org/2002/ws/desc/2/06/issues.html#x28 [.4] http://www.w3.org/2002/ws/desc/2/06/issues.html#x2 [.5] http://lists.w3.org/Archives/Public/www-ws-desc/2002Sep/0050.html [.6] http://lists.w3.org/Archives/Public/www-ws-desc/2002Sep/0056.html 3) HTTP Binding Issues (6a, 41, etc.) Big question: how much do we want to work on this [.1]. Jeffrey's summary and recommendations (no change) [.2]. [.1] http://lists.w3.org/Archives/Public/www-ws-desc/2003Feb/0025.html [.2] http://lists.w3.org/Archives/Public/www-ws-desc/2002Jun/0102.html
Received on Wednesday, 5 March 2003 15:31:52 UTC