Web Service Description Group Minutes, FTF meeting 28 Jan 2004 Bedford, hosted by Sonic. irc: http://www.w3.org/2004/01/28-ws-desc-irc Present: Roberto Chinnici Sun Microsystems Glen Daniels Sonic Software Paul Downey British Telecommunications Tom Jordahl Macromedia Philippe Le Hégaret W3C Jonathan Marsh Chair (Microsoft) Jeff Mischkinsky Oracle David Orchard BEA Systems Bijan Parsia University of Maryland MIND Lab Arthur Ryman IBM Adi Sakala IONA Technologies Jerry Thrasher Lexmark William Vambenepe Hewlett-Packard Umit Yalcinalp Oracle Phone: Allen Brookes Rogue Wave Software Amelia Lewis TIBCO Kevin Canyang Liu SAP Jean-Jacques Moreau Canon Sanjiva Weerawarana IBM Prasad Yendluri webMethods, Inc. Regrets: David Booth W3C Youenn Fablet Canon Jacek Kopecky Systinet Ingo Melzer DaimlerChrysler Jeffrey Schlimmer Microsoft Igor Sedukhin Computer Associates scribe: Adi Sakala -------------------------------------------------------- Wednesday 28 January -------------------------------------------------------- 13:00 Introductions and logistics - Assignment of scribes (Igor Sedukhin), Adi Sakala, Arthur Ryman, (Prasad Yendluri), (Dietmar Gaertner), Tom Jordahl, (Jeffrey Schlimmer), Philippe Le Hegaret, William Vambenepe, Umit Yalcinalp - Agenda bashing Scribes: Adi, Arthur, Tom, William, Philippe ------------------------------------------------------- 13:10 Publication plan Survey of remaining work Part 1: Open issues: misc (16) editorial (2) Part 2: Open issues: misc (1) editorial (1) Primer: ? Resolve the current 17 issues and 3 editorial issues. Should be able to go to last call on all parts by May and internally freeze within the working group by March. Primer by may should be mostly in the hands of editors. RDF mapping of wsdl 2.0, this proposal will be done parallel to other specs. Charter says we have a testsuite deliverable. Test Assertion Document: Paul: Says it is very important for people looking at these specs and trying to evaluate. Philippe: Testsuite could be owned by other groups not necessary by wsdl working group. Arthur: The eclipse project hosts the java implementation of wsdl and has test assertion document for wsdl 1.1. It would be a good idea to have blessing from group for 2.0 assertion document. Is there an easy way to reference to spec from the test assertion document? Paul: It would be a good idea to have the document done here so that other groups can refer to it like ws-i. JMarsh: Resource constraints. Philippe: How did xmlp group did this? Glen: Took all the assertions in the spec and converted them into test cases and the actual testing was done by soap builders. Jeff: Can't really have a framework due to licensing issues. JMarsh: Have a bucket of wsdl's valid and invalid and make them as test cases. Glen: It would be a good idea to go one step forward and actually define how the wire messages look when something is defined in wsdl. Arthur: Explains how eclipse does the validation of wsdl. Glen: Wsdl 1.1 has lot of problems due to not having wire traces as test collection. JMarsh: Need to have a scope so that we can achieve it appropriately as this is a big area. Arthur: If we host it at eclipse, companies who doesn't like opensource won't like referencing it. Dave: Working group produces the interoperable spec. I think it should be hosted by wsdl working group. Robert: Should we have bug tracking system, nightly builds etc. Arthur: The current goal would be to have a test assertion document which eclipse can take and build test cases and run through their validator. Paul: There is a commercial value in this document and we should not sacrifice that value. JMarsh: It looks like there is an agreement to host test assertion document here. Whether it should be in the same document or as a separate document. Jeffm: Having markup is a starting point but not a test assertion document itself. Glen: There are assertions in spec and there are n number of things that each assertion can fanout for testing. RESOLUTION: we should have a separate document for test assertions and this document has to be explicitly linked to the spec. ACTION: Phillpe and JMarsh will look at the ipr for test suite. RESOLUTION: Arthur is the Editor for this document. ------------------------------------------------------- 13:30 Faults - Issue 105: Abstract Faults [3] Work through some WSDL examples to verify that Paul's fault proposal [4] doesn't negatively impact bindings. [3] http://tinyurl.com/ysgl#x105 Pauls Proposal: http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0064.html TomJ: writing some fault samples on white board for discussion. <interface name=Ifoo> <fault name=BadTicker message=ns:faultelem/> <operation name=myop> <input message=ns:myinelem/> <output message=ns:myoutelem/> <outfault name=tns:BadTicker/> </operation> </interface> <binding name=IfooBinding> <wsoap:fault name=tns:BadTicker> <faultcode> </wsoap:fault> </binding> Roberto: The intent of soap spec is people should be able to resolve faults by looking at faultcodes instead of digging into detail element. Glen: In wsdl we should be able to specify the hierarchical fault codes that soap allows. Umit: How to distinguish faults on per operation basis. Glen: Message should really be element as it really pointing to element. Umit: Should we be able to allow two soap faults to be associated to a single fault definition. Glen: You can bind one of the fault at the top level and define more specifics at the operation level. Paul: The binding spec is behind. I don't think someone looked into it. Roberto: It should be something like <outfault ref="tns:BadTicker"/> I think it should be "ref", because we usually use "name" when defining a new component, not in references. Bijan: I just want to note that the issue of renaming message (especially to *element*) touchs on an action item of mine (that I'm finally understanding). First, I understand message to mean message*type*. If so, I don't want to restrict messageTypes to elementTypes. Tom: Take fault to fault in binding and just don't give any flexibility to override for different operations. RESOLUTION: Accept Paul's proposal to hoist faults in the interface. RESOLUTION: Rename faultDefault to fault. RESOLUTION: Allow <value>,<subcode> as children of <wsoap:fault[Default]>. RESOLUTION: Remove per-operation (in|out)fault NEW ISSUE: Open issue on the name of wsoap:fault/@name and outfault/@name (should indicate that it is a reference, not defining a name) ACTION: Sanjiva to consistify the @name attributes. ------------------------------------------------------- 14:00 Issue fault-name-uniqueness [5]: Should faults be named with QNames? In WSDL 1.1 fault names are NCNames which are not unique within portType even. This leads to a cumbersome mechanism to uniquely identify a fault. [4] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0064.html [5] http://tinyurl.com/ysgl#xissue%20fault%20name%20uniqueness Glen: Why cant we make interface names as URI's so that binding makes easy. Dave: How does symbol namespaces effect this?? Glen: What if we make targetNamespaces of wsdl as part of the namespace and combine it with interface name to make a URI? Eg: wsdl namespace http://foo.com, interface A, operation getFoo. Then referring to operation will be Qname of, http://foo.com/A, getFoo Roberto: Explaining the uniqueness of operation in case of inheritance scenario. Qname of operation name should be unique in the context of an Interface. [2nd Issue in Faults closed.] RESOLUTION: Close issue-fault-name-uniqueness - works just like operations. ------------------------------------------------------- 14:15 Issue 89: Binding message references in component model [6] [6] http://tinyurl.com/ysgl#x89 Roberto: Create two message reference components at binding level to be in consistent with abstract level. With the fault resolution at the binding this might not be an issue anymore. Sanjiva: We need to keep things in consistency. RESOLUTION: Close issue 89 by changing the namespace of wsoap:fault to wsdl:fault, and add a corresponding component in the abstract model. 15:00 Break ------------------------------------------------------- 15:20 Issue 87: Redundant direction information [38] Options: a) Drop direction property. b) Retain direction property. [38] http://tinyurl.com/ysgl#x87 JMarsh: Redundant direction information in our abstract model. TomJ: What would be ramifications for removing this model. This information is useful to validate the part 1 information that it is pointing to appropriate MEP. Glen: MEP has appropriate names and by looking at it you know what you are doing. Sanjiva: Removing the direction property. Since now we made messageReference optional, by using input and output name you can determine the direction. JMarsh: How does this work when you use defaulting model. And if we don't understand the message pattern then this property should be useful. RESOLUTION: Close issue #87 with no action. ------------------------------------------------------- 15:30 Optional Extensions (Latest Issue from Email thread [.1]): [.1] http://www.pacificspirit.com/blog/2004/01/28/extensibility_and_ignore_rule_in_web_architecture Glen: The issue here is our spec doesn't say anything about the processing of extensibility elements. Dave: What if somebody ships a processor that has a default behaviour and throws error on every optional element. The wording in spec should ensure us. Paul: There is a must understand tag. Dave: The default is if we don't specify must understand the processor should continue processing and not fail. Jeff: Want to have a policy for faulting on unknown things. Agrees with backward compatability argument of dave but would like the wording in such a way that if process wants to fail they can fail based on a policy. Dave: This is a problem with the using should and must. Glen: Optional extensibility elements should be ignored. Robert: If we agree on marking it as should understand, can we produce a test assertion for this. Glen: SOAP has these constraints in the spec so that tests can be shown to work. Dave and Roberto: Optional extensibility elements must be ignored. Arthur: What happens in generating code, rendering html, editor editing WSDL etc. Umit: If I process an extensor and mark it in the abstract model how do I know which state I am in? Dave: We can live with should ignore as long as we have test cases in the test assertion document. Prasad: +1 to DaveO's latest proposal; SHOULD ignore with some of the execeptions enumerated Philippe: "Optional extensions MAY be ignored. Unknown optional extensions SHOULD be ignored" "Known optional extensions SHOULD be processed. Unknown optional extensions SHOULD be ignored"? Prasad: How about optional extensions a WSDL processor can not process successfully SHOULD be ingored :) DaveO: Roberto brought up the issue of conformance. JeffM: Prasad, the conformance issue is how to have a conformance test with a SHOULD as opposed to a MUST. Prasad: Thanks Jeff. Yup thats always an issue. However conformance testing should not be a sole criteria why something is a SHOULD. MUST is a *bad* choice here. HTML and WSDL are very different though. What applies to HTML is not at all applicable to WSDL IMHO. Straw Poll Question: 1. Statement in spec, that a wsdl processor MUST ignore the optional extensibility element. 2. Statement in spec, that a wsdl processor Should ignore the optional extensibility element. No Resolution and still an OPEN ISSUE. ------------------------------------------------------- 16:30 Joint Session with Arch WG - Summary of Arch deliverables and areas WSDesc should be aware of - Use Cases document disposition - Issue 90: Synchronize terminology [7] - Issue 75: Incoherence between WSA and WSD MEPs [8] [7] http://tinyurl.com/ysgl#x90 [8] http://tinyurl.com/ysgl#x75 - WSA now have a much more useful usage scenario document now. - WSD group is lack of resources to work on this document moving forward. - Need to review the work done by the WSA working group on usage scenario. - talking about glossary and inconsistency of terminology in the WSA specification documents. - The hope is to adopt the WSA terminology in the WSDL working group. - WSA group will be flagging gap about soap intermediaries. 17:30 AdjournReceived on Wednesday, 4 February 2004 12:49:18 GMT
This archive was generated by hypermail 2.2.0 + w3c-0.30 : Thursday, 9 June 2005 12:14:42 GMT