- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Tue, 16 Nov 2004 12:51:25 -0800
- To: <www-ws-desc@w3.org>
Web Service Description Group Summary, FTF meeting 9-11 November 2004 Sunnyvale, hosted by webMethods ------------------------------------------------------- Summary ------------------------------------------------------- Tuesday: Scheduling deliverables: Complete Last Call comments by January? Primer pub 15-20th Dec. SOAP 1.1 binding pub shortly. Assigning Media Types Note - issues will be tracked on WG issues list Editorial issues: Issues 74g, 78 referred to editors Issue 5f: No final resolution, AIs to write up competing proposals ACTION: DBooth and roberto to describe option 2 (remove definition of processor conformance, write up clear guidelines to developers) ACTION: DaveO to work on text for option 3 (redefining conformance in terms of building the component model) Potential new issues: 1) Is it clear that a server must implement everything it's description says it does? 2) Un-recognized required features result in components, un-recognized required element-based extensions don't. Why the difference? Issue 49: Issue closed by: 1) Rewording 8.1 as follows: "An element information item whose namespaces name is "...wsdl" and whose local part id definitions conforms to this specification if it is a valid according to the XML schema for that element as defined by this specification (uri to schema) and additionally adheres to all the constraints contained in this specification family and conforms to the specifications of any extensions contained in it." 2) add conformance sections to each of the bindings. 3) + 8.3, clarify that "this specification" means Part 1. 4) + adding a note advising extension specification authors to have a clear statement of conformance. Issue 54: ACTION: DaveO will recast the @compatibleWith proposal using an extension namespace. Issue 48d: RESOLUTION: Use Glen's text to clarify AD example, explain in intro to AD feature what the intended use is, and add that it SHOULD be used at interface level while discouraging use at binding level. Wednesday: SOAP 1.1 Binding Asir's changes to Part 3 and proposal for SOAP 1.1 WD adopted as modified by the following resolutions: RESOLUTION: Move the default attribute value in section 2.4.4 to the mapping rule table. RESOLUTION: Add text indicating which MEPs are supported by the SOAP 1.2 and SOAP 1.1 bindings. RESOLUTION: Add to the text the "ignore fault codes and subcodes for soap 1.1 RESOLUTION: Drop the soap11 mep ref in section 3.3 RESOLUTION: remove the http method selection and soap mep selection rules RESOLUTION: add a non-normative reference to BP within the soap 1.1 binding spec as explanation of how in-only WSDL MEP maps to soap 1.1 over HTTP. RESOLUTION: Add text in section 3.2 that soap modules in 11 are adopted from SOAP12 and then soap11 modules need to have a uri. RESOLUTION: drop SOAP feature in 11 binding and define one URI for SOAP11 HTTP binding RESOLUTION: add mention info from charter to soap11 intro NEW ISSUE: Make sure in-only mep is supported in wsdl soap12 binding ACTION: Asir to implement resolutions adopted at this FTF. ACTION: Part 3 Editors to roll in Asir's changes. After these actions are complete, we can publish the new spec. Issue LC19 RESOLUTION: Issue LC19 closed without action. Issue LC75a RESOLUTION: Issue LC75a closed without action. ACTION: Sanjiva to write the rationale for rejecting LC75a Issue LC55, LC56, LC61d ACTION: Roberto to write up the addition of infault and outfault at the binding level plus modifications at the component model. Formal Objections: F&P/Compositor compromise from Glen: Put F&P into Part 2 as a predefined extension. In exchange, add compositors to F&P. Simplify proposal for compositors based on Cannes suggestions. ACTION: Glen will post an e-mail describing the proposal. Unique GED requirement: ACTION: DBooth will produce text for the spec re: slide 12 of his presentation. ACTION: Editor remove ambiguity if it exists ACTION: Jonathan to create 3 new issues from slide 25 on points 1, 2, and 4 ACTION: Sanjiva will write up this proposal and email it to the list as a response to the objection. Thursday: Z update ACTION: Hugo to update the makefile to generate the spec with Z ACTION: Arthur to write up a sample of what a rewritten spec using an infoset-based component model would look like Test Suite: ACTION: Arthur to issue a call for test documents ACTION: Anish to propose additions to the test suite for the purpose of interoperability testing. Issue LC50 ACTION: Hugo to ask the XMLP wg to clarify the issue around the response in the SOAP/HTTP binding ACTION: DBooth and Anish to clarify what a node is Issue LC76a Postpone till definition of a node is available Issue LC48b RESOLUTION: Add text to part 2 and 3 about WSDLMEP and SOAP mep mapping that ponts to section 2.3 of part 3 ACTION: Editors of part 2 and 3 to add text about WSDLMEP and SOAP mep mapping that ponts to section 2.3 of part 3 Issue LC59a ACTION: Hugo send email about what HTTP request is when in-only is used ACTION: Hugo to check the HTTP bindings really support the MEPs it claims to support RESOLUTION: In-Optional-Out and Out-Optional-In will be marked at risk when entering CR and will be removed unless we see 2 interoperable implementations Issue LC59c RESOLUTION: we don't think it's necessary for the working group to work on it. Expect third party to chime in. Issue LC76b RESOLUTION: Editorial. Editors bring it back if they see issues. Issue LC76C ACTION: Hugo to contact Amy with our interpretation and ask for clarification Issue LC61e RESOLUTION: Close with no change to the spec. reply to issue submitter Issue LC59b RESOLUTION: close with no change to spec. we will suport MTOM. SOAP1.1 binding is not part of our recommendation and support for SwA is not part of our plan. Issue LC61a ACTION: Umit to check on operation@style RESOLUTION: Move all the styles and RPC signatures section to part 2. This address the perception concern, no change to the use of the styles. Issue LC74d RESOLUTION: Drop "The LocalPart of the output element's QName is obtained by concatenating the name of the operation and the string value "Response"" from RPC style" Issue LC74f RESOLUTION: close with no change to spec. reply to issue submitter that we don't have a glossary.if not happen with the definition, let us know. Issue LC74e ACTION: Roberto check on comments in 74e and come up with proposal.
Received on Tuesday, 16 November 2004 20:51:35 UTC