- 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