- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Mon, 24 May 2004 21:49:46 -0700
- To: <www-ws-desc@w3.org>
Web Service Description Group
Minutes, FTF meeting 21 May 2004
New York City, hosted by IBM.
-------------------------------------------------------
Friday 21 May
-------------------------------------------------------
Present:
David Booth W3C
Allen Brookes Rogue Wave Software
Roberto Chinnici Sun Microsystems
Glen Daniels Sonic Software
Paul Downey British Telecommunications
Youenn Fablet Canon
Hugo Haas W3C
Amelia Lewis TIBCO
Jonathan Marsh Chair (Microsoft)
David Orchard BEA Systems
Bijan Parsia University of Maryland MIND Lab
Arthur Ryman IBM
Jerry Thrasher Lexmark
Asir Vedamuthu webMethods
Sanjiva Weerawarana IBM
Umit Yalcinalp Oracle
Prasad Yendluri webMethods, Inc.
Regrets:
Tom Jordahl Macromedia
Hao He Thomson
Kevin Canyang Liu SAP
scribe: Youenn
-------------------------------------------------------
08:00 Issues list review
08:15 Fault Issues
- Issue 84: SOAP header faults needed? [8]
- Issue 62: Specify a specific SOAP fault code to be
returned [9]
- Issue 114: Name of wsoap:fault/@name [10]
- Issue 68: Confusing description between soap:body and
soap:fault [11]
- Issue 73: Clarify Fault versus Body in SOAP binding [12]
- Issue 29: How to specify the structure and ordering of
'soap:body' parts [13] (Obsolete?)
[8] http://www.w3.org/2002/ws/desc/2/06/issues.html#x84
[9] http://www.w3.org/2002/ws/desc/2/06/issues.html#x62
[10] http://www.w3.org/2002/ws/desc/2/06/issues.html#x114
[11] http://www.w3.org/2002/ws/desc/2/06/issues.html#x68
[12] http://www.w3.org/2002/ws/desc/2/06/issues.html#x73
[13] http://www.w3.org/2002/ws/desc/2/06/issues.html#x729
Issue 84: soap:headerFault needed ?
they are not in draft, already gone
RESOLUTION: issue 84 is closed
issue 62: specify specific fault code to be returned
glen: already dealt with that with code and subcode
RESOLUTION: issue 62 is closed
114: renamed @name to @ref
already done that
RESOLUTION: issue 114 closed
68: confusing between soap:body and soap:fault with the new text and
parts disappeared.
RESOLUTION issue 68 obsolete
73: editorial pb but obsolete
RESOLUTION: issue 73 closed
29: no more parts
RESOLUTION: issue 29 closed
-------------------------------------------------------
08:45 Soap:address Issues
- Issue 31: 'soap:address' insufficient to describe SOAP 1.2
Endpoint [13]
- Issue 52: Allow operation addresses to be absolute [14]
[13] http://www.w3.org/2002/ws/desc/2/06/issues.html#x31
[14] http://www.w3.org/2002/ws/desc/2/06/issues.html#x52
31 & 52: soap:address issues
Sanjiva: Now soap binding indicates the protocol and the mep in use.
soap:adress is now only a URL, so no pb. Issue should be
closed.
DaveO: What about supporting the soap/response mep?
Sanjiva: The soap binding spec has an issue because it always say
serialize the soap:Envelope with soap-response has not a
soap request
resolution for 31: we have the information we need one in the binding.
RESOLUTION: Issue 31 closed, already have protocol and mep in binding.
52: allow operation addresses to be absolute
Sanjiva: We do not need to change that.
Arthur: It is about splitting operations to different domains.
Sanjiva: Point of interface is about collecting a set of operations
and bind them together.
DaveO: The question is about why collecting operations together.
The pb it is trying to solve is a web pb.
Jmarsh: Maybe it is about changing the uri scheme on a per
operation basis? http and https?
Sanjiva: If the operations have different scheme/uri, interfaces
have no real meaning and collecting operations together
has also no real meaning. We should close it and not
support it. We have relative uri via @location for the
http-binding and interface inheritance. This is sufficient.
Paul: The issue is about binding each operation to a different
domain.
Sanjiva: You need to change the interface and put one operation
per interface.
Pauld: We change the abstract level.
Sanjiva: There is no value in putting operations in the same
interface that has a different end point
RESOLUTION: Issue 52 closed: can be achieved by putting one
operation per interface and bind the interface to a uri.
-------------------------------------------------------
09:30 Soap over HTTP Issues
- Issue 28: 'transport' cannot fully describe underlying
SOAP 1.2 protocol binding [15]
- Issue 61: Additional SOAP binding for HTTP
GET-in/SOAP-out [16]
[15] http://www.w3.org/2002/ws/desc/2/06/issues.html#x28
[16] http://www.w3.org/2002/ws/desc/2/06/issues.html#x61
RESOLUTION: Issue 28 closed: done that with protocol attribute.
[Issue 61 still open, with proposal, will appear on upcoming agenda.]
-------------------------------------------------------
09:45 SoapAction Issues
- Issue 1: How to specify an empty SOAP action [41]
- Issues 86: New @soapActionURI? [42]
[41] http://www.w3.org/2002/ws/desc/2/06/issues.html#x1
[42] http://www.w3.org/2002/ws/desc/2/06/issues.html#x86
Issue 1: empty soap action
one possible solution: if @soapaction is there, put it even if value
is empty otherwise, do not put it in.
RESOLUTION: Issue 1 closed, no @soapaction means no header.
ACTION: Sanjiva to implement the resolution that @soapaction not there
means no soapaction
Issue 86: new binding element for soapactionUri?
Glen: We already have that with @soapaction
RESOLUTION: Issue closed: we have addressed this with @soapAction
-------------------------------------------------------
10:00 Soap support Issues
- Issue 97: Schema language for SOAP encoding [43]
- Issue 99: Support SOAP 1.2 data model and encoding [44]
- Issue 100: Support SOAP 1.2 RPC [45]
- Issue 101: Support SOAP 1.2 transport binding framework [46]
[43] http://www.w3.org/2002/ws/desc/2/06/issues.html#x97
[44] http://www.w3.org/2002/ws/desc/2/06/issues.html#x99
[45] http://www.w3.org/2002/ws/desc/2/06/issues.html#x100
[46] http://www.w3.org/2002/ws/desc/2/06/issues.html#x101
Issue 97: soap data model and schema language?
Jmarsh: Should we add this as a deliverable?
Glen: We have a deliverable to support SOAP1.2 and soap data model
is part of soap 1.2.
Sanjiva: This is an adjunct.
Paul: Jacek wanting a new schema language. SOAP Encoding allows
getting this to interoperate.
Asir came with some pbs that will need large amount of work.
Paul: Benefit from soap encoding is restricting the schema
language. The graph part is not very used.
Sanjiva: Basically this is rpc-literal style.
Glen: Can we extend rpc style to restrict schema to map better
with soap encoding.
Roberto: Carrying signature is main purpose of rpc style. If we
want a restricted schema style, let define another one,
compatible with rpc style.
Paul: It's possibie work is being done elswhere to provide
restricted schema language to ease interoperability.
We should not redo this work.
Asir: We are talking about schema for xml fragments. The issue
is schema for soap data model.
Glen: Paul says that the benefit of soap data model is the
restriction of xml schema not the graphing.
Asir: Such a resttriction of schema would be useful.
Roberto: Feedback that does not reach XMLP wg, soap data model
still has graphing and other things. The best thing is to
do notinhg because if we restrict soap data model, we
will define our own data model, a work that is going on
elsewhere.
Hugo: How will you do if you want to use soap data model?
Glen: Need to indicate you use soap data model and define a
schema language.
Amy: Providing an identifier without defining precisely how
this works may cause interoperability problems, even
with conformant processors.
RESOLUTION: Issue closed: we will not do this new schema language
for soap data model.
Discussion about adding style that will ease interoperability and
map with 3G languages, where to put the bar in simplification.
Issue 99: Support SOAP 1.2 data model and encoding
RESOLUTION: Issue 99 closed: resolved as a duplicate of 97.
Issue 100 : Support SOAP 1.2 RPC
we cannot support it as it is soap data model related
RESOLUTION: Issue 100 closed,
Issue 101: Support SOAP 1.2 transport binding framework
Amy: We support this through F&P and the @protocol attribute.
We support use of new soap transport protocols.
RESOLUTION: Issue 101 closed as handled by @protocol and F&P.
-------------------------------------------------------
11:00 Issue 141: Should WSDL say anything about whitespace in
SOAP:Body? [47]
[47] http://www.w3.org/2002/ws/desc/2/06/issues.html#x141
Issue 141: Should WSDL say anything about whitespace in SOAP:Body?
It comes from an interop problem, especially for XML signatures.
Amy: XML-Sig has solved this through canonicalization transforms.
Jmarsh: Some processors might remove them or add them. Is it in
WSDL scope?
Hugo: This issue should be solved by SOAP1.2 normalization spec.
This is a WG note, that defines a canonicalization. Not
convinced it should appear in the WSDL.
Amy: This issue might cause pbs for implementers. There is a
means of specifying that signature, canonicalization...
is turned on, F&P. We should point people to F&P if they
need that.
Jmarsh: Maybe just adding the option at the description level the
ability to say: add whitespace or do not add whitespace.
RESOLUTION: Issue 141 closed as we don't say how the infoset is made
up from the schem-valid data and do not plan to do so
F&P can provide means of specifying that signature,
canonicalization can be turned on.
-------------------------------------------------------
xx:xx Schema inconsistencies
- Issue 19: Inconsistency on optionality of 'soap:headerfault'
- Issue 44: "name" attribute of "soap:fault" is not defined in
schema
- Issue 46: "transport" attribute of "soap:binding" should be
optional
- Issue 47: "soap:operation" should be optional
[48] http://www.w3.org/2002/ws/desc/2/06/issues.html#x19
[49] http://www.w3.org/2002/ws/desc/2/06/issues.html#x44
[50] http://www.w3.org/2002/ws/desc/2/06/issues.html#x46
[51] http://www.w3.org/2002/ws/desc/2/06/issues.html#x47
Amy: We could forward this kind of material to soapbuilders or
WS-I to fix WSDL1.1 schema.
RESOLUTION: Closed as a group since the soap binding schema is now
obsolete. It should be very clear from the spec since
we rewrite it completely.
-------------------------------------------------------
xx:xx New issues from Wed.
Issue 158
resembles 55
Hugo: Issue is here because of ADD.
-------------------------------------------------------
Issue 191: MEP
Hugo: Relationship between wsdl mep and soap mep.
Sanjiva: Proposal was use SOAP meps. But soap meps are at a
different abstraction level. When binding to soap which
has two meps, you should indicate which of the two meps to
use. We must say that only specific WSDL meps can be
bound to soap meps. You need to express which wsdl mep
mapa to soap mep.
Jmarsh: We should say something like: "we have the in/out wsdl mep,
which can be mapped to two soap specific meps through the
soap binding"
Amy: There was an issue about putting use case or scenarios for
each wsdl mep. We can put this information in this section.
It has never been made.
Jmarsh: We think about just adding a statement in the introduction:
"if you are familiar with soap meps, wsdl meps are the same
but a little bit more abstract"
RESOLUTION: issue 191 closed
ACTION: Part 2 Editors to add such a statement.
ACTION: Part 3 Editors to add a statement to relate each of the two
soap meps to wsdl meps.
-------------------------------------------------------
Issue 194: syntax
Paul explains his proposal: put all binding info in its own namespace
Sanjiva explains his response of this proposal: attributize as much as
possible binding specific info.
Glen: The question is: is it worthwhile to have the wsdl namespace
binding structure at all?
DaveO: Do we need structure of these extensions we are doing ?
Sanjiva: With the ones we are doing yes we need that.
DavidB: Benefit of having a specific syntax: tool can have a partial
understanding of the binding.
Amy: We have the hability to specify how that links to the
interface structure/operation structure. The connection
between wsdl:binding/wsdl:operation with
wsdl:interface/wsdl:operation is already there. Linkage is
important.
Umit: Binding looks like as a template. Linkage is implicit.
Sanjiva: wsdl editing tool will implement the abstract binding
editing and a plug-in will add specific feature. This is
human factor, it is only syntax that helps.
Glen: It is a little weird to go from one namespace to another one.
DavidB: Example: tool = find all bindings that have an operation with
that name.
Paul: Is it really useful to have the http binding resembles the
soap binding ?
Roberto: The human factor is important. The readability of binding
gains of being standardized. Having syntax closer to
component model is better.
Glen: I am not adverse to keeping the structure but I want to
know the benefit of that.
DaveO: There are ways to handle extensions: bottom typing,
attribute top typing, other ways. One advantage of Paul's
proposal is to allow better schema validation.
Amy: We have some awkwardness in the WSDL1.1 binding. On the
two proposals, Sanjiva's proposal removes awkwardness and
preserves the structure which is appealing. Another question
is: can we mix other namespace bindings elements?
DaveO: We could define the wsdl:binding type as abstract. The soap
binding will extend the wsdl:binding type and soap:operation
will extend wsdl:operation.
Sanjiva: But you loose human factor if you do not understand the
soap-binding namespace.
Umit: We can only extend types for schema not elements. This allow
fix name language.
Roberto: The resulting schema will be useless (with few constraints)
or ugly (with all constraints). We should stick with human
readability.
Jmarsh: Opinions whether binding schema would be ugly or not,
writable or not. The schema will not give the abstract
informations that daveB and roberto wants to (structure of
wsdl:binding/wsdl:operation). Maybe we should investigate
a little bit more on hoisting elements to attributes
(Sanjiva's proposal).
Sanjiva: Anything that makes sense to hoist we can. Soap:module
cannot be hoisted.
Presentation of sanjiva's proposal.
Roberto: I like this approach, a small glitch: many attributes from
different namespaces. Why not adding a type attribute at
the binding level. The value would be a uri, pointing to
the binding. If you do not understand this uri, then you
will not understand the rest of the binding.
Glen: The one thing you loose, is elements extensibility, as
attribute extensibility is more difficult.
Sanjiva: We already have this issue.
Discussions about roberto's binding typing proposal. The type added
by roberto's proposal adds component model constraints.
Consensus of the WG to adopt sanjiva's proposal with roberto's
ammendment.
RESOLUTION: Issue 194 closed by adopting Sanjiva's proposal as amended
by Roberto (add @type).
-------------------------------------------------------
Issue 173: do we loose expressiveness by going from element trees to
attributes for soap fault codes?
Two subcodes below a code/subcode is invalid.
PaulD: Fault code trees allow documentation that we loose with
attributes, but we can put it in other places, inside the
wsdl:fault for instance.
RESOLUTION: Issue 173 closed and accept Paul's roll-up.
[Editors have already implemented this change.]
-------------------------------------------------------
Issue 187:
Discussions about relationships between webmethod and soap mep and
the defaults.
Sanjiva: We should retain the default values and explain the
relationship between webmethod defaults and default meps.
Amy: We can have an intelligent defaulting mechanism. If you
set the defaultWebMethod to get, then the defaultMep if
not set will have a default value.
AI for youenn to write up a proposal for intelligent
webmethodDefault/mepDefault mechanism for the soap binding.
/**** NOTE FROM SCRIBE: ****/
AI deprecated since webMethod explicit support in WSDL is removed.
RESOLUTION: Issue 187 is then closed as obsolete.
-------------------------------------------------------
Issue 188: soap:addr http:addr
Sanjiva: Instead of having an http:address/soap:address element, we
could have an attribute (soap:address or http:address).
Asir: This issue is related with issue 190.
Issue 190: layering
Asir: We have mep and protocol binding, also applicable to http.
We can separate the two parts to allow reuse Discussions
about how to relate wsdl:HTTP binding options in the
wsdl:SOAP protocol in case the SOAP/HTTP binding is in use.
Jmarsh: Some of the http options (serializations for instance) are
not applicable to soap over http.
Asir: Let's create a list of http options that can be used for
soap over http.
Glen: Some http options in fact should directly go to soap layer
slots and not in an intermediate layer like the WSDL
component model. The web method attribute is syntactic sugar
to specify the value of the webmethod property in the
property bag. In HTTP this is not the same, it is in the
component model and it should be the same, have one
property for both http and soap binding. Then we could
maybe have the same syntax for both bindings.
Sanjiva: Pb is that if I write an HTTP wsdl application, I will
need to go to the soap spec to specify the web method.
Glen: We will provide this info in the http binding spec.
Sanjiva: We could create a new uri for the web method and the
binding will tell that this uri will map to the soap
webmethod value.
Glen: The point of F&P was to have a direct mapping between
wsdl F&P and soap engine F&P. Two questions: should we
merge the syntax and should we merge the properties.
Sanjiva: We should also make a list of the properties that can be
merged.
RESOLUTION: Any component model property or F&P property which appear
both in the SOAP and HTTP bindings we define, will be
unified to one property.
[RESOLUTION: Close issue 188, unify @soap:address and @http:address
into @address.]
[ACTION: Editors to unify @soap:address and @http:address
into @address.]
List of the different binding options and applicability to SOAP &
HTTP binding.
HTTP SOAP
protocol
mep
webmethod webmethod
action
code/subcode
module
address address
inputSerialization inputSerialization
outputSerialization outputSerialization
location location
separator separator
version version
AuthType AuthType
AuthRealm AuthRealm
cookie cookie
transfer-coding transfer-coding
DaveO: Two serialization for soap/http. Url-encoded is valid
for soap-response.
SOAP does not specify standard ways to map rpc parameters to uris.
We provide one way of doing that in HTTP. We can do that also in
the SOAP.
Issues for serialization of HTTP are also valid when using SOAP
over HTTP.
DaveO: One thing: we could allow url-encoded style for other
methods than GET. input/outputSerialization applies
when using SOAP over HTTP discussions about
outputSerialization use and relationship with MTOM.
-------------------------------------------------------
12:00 Lunch
scribe: Sanjiva
raw irc log: http://www.w3.org/2004/05/21-ws-desc-irc.html
-------------------------------------------------------
Continuing layering discussion ..
Discussion about soap response and its relationship to HTTP GET.
Asir finds wording in SOAP 1.2 spec which says HTTP GET is what SOAP
Response MEP is for.
Conclusion that SOAP Response is restricted to GET
It appears that the SOAP spec fixes the MEP -> WebMethod relationship
So, @binding/operation/soap:mep is really not a controllable bit for
operation.
DaveO: Two things: SOAP Web method feature and actual MEP
Glen: SOAP HTTP binding gives 1-1 relationship between SOAP MEP
and Web method. However if you invent your own MEP then
the relationship can be different/dynamic.
(DaveO is confused; Glen explains further)
Sanjiva: Proposes to remove the {web method} property of a binding
operation component (defined by the SOAP binding).
RESOLUTION: Agreed to remove {web method} property and associated
attribute. ;-)
ACTION: Editors to remove the {web method} property from the
component model (and related syntax, including defaulting
syntax)
Umit: notes some concern that this action implies someone who
defines a new MEP which may want to control the web
method doesn't have a way to tweak it.
Sanjiva: Proposes that with that decision inputserialization and
outputserialization are no longer controllable properties
in the SOAP binding.
Discussion about the truth value of that proposal.
[Asir: it is not a registered type ..
http://www.iana.org/assignments/media-types/application/]
[Hugo: http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.1]
Lots of discussion whether we need to provide control over how a URL
is constructed.
Our http binding defines an XML -> URI mapping. Discussion of how we
should make that be controllable.
Discussion of the value of making the XML -> URI mapping controllable.
Pro: easier to define mapping
Con: too flexible .. not within the 80/20 cut
Jonathan: Points out that making this controllable doens't help more
interop: if a person doesn't understand a different
serialization then they don't understand the binding ..
so its really like a brand new binding indicated deep
inside.
Glen: points out that this is true about other stuff too .. that
any extensibility in the binding may make the binding
unusable.
Straw poll: 3 for adding this know, 6 against it
There are folks who object to recording consensus; taking formal vote.
More discussion to try to come to consensus .. not much movement.
Formal vote: add inputSerialization control for SOAP response MEP (or
some other MEP defined elsewhere)
BT: yes
IBM: no
RogueWave: No
BEA: Yes
Lexmark: no
w3c: no
oracle: no
UMD: abstain
webmethods: no
tibco: yes
sun: yes
sonic: no
canon: no
yes: 4, no: 8, abstain: 1
Decision: no action to add this.
Jonathan asks anyone who wishes to file a minority opinion to record
such intent by emailing the list.
RESOLUTION: http:inputSerialization will not be added to SOAP binding.
Discussion of whether we should provide some pointers in the spec to
identify areas which had contention.
Proposal to add ednotes to the spec to indicate such spots.
Consensus to do that.
ACTION: Editors to add ednotes to the spec to indicate areas that had
contention.
Proposal to remove the separator property from the http binding.
Accepted as that's not variable per html defined form url encoding
style which we are using.
RESOLUTION: Remove @separator from HTTP binding.
ACTION: Editors to remove @separator from HTTP binding.
Discussing the location property: do we need that in the SOAP binding
Sanjiva's proposal: Do not allow tweaking the path as soap response
mep will say how to generate query string.
DaveO proposal: Allow @location attribute on a per-operation basis as
with http binding (with regexp control).
Straw poll: how many people would like to do DaveO's proposal
for: 4, against: 3
no consensus
Asir: This is related to input serialization as if the input ser
is fixed then why do u want to edit the url.
Glen: Suggests calling a duck a duck and say that this is
basically another input serialization proposal.
[Marsh: Sanjiva writes:
<binding type="soap" interface="I1">
<operation wsoap:mep="s-r" wsoap:location="/temp/{town}"
action="x"/>
</binding>
<foo>
<town/>
<zip/>
</foo>
Results in URI: http://something/temp/NYC?zip=10000
Status quo: http://something?city=NYC&zip=10000]
Suggestion to move this discussion to the mailing list ..
ACTION: DaveO to write up a scenario to motivate path creation on a
per-operation basis.
Now considering version, authType, authRealm, cookies, transfer-coding
properties and they would work for the soap binding.
Proposal is to allow the use of http:version etc. properties on the
soap binding.
Consensus to allow that
RESOLUTION: Allow http:version, http:authenticationType,
http:authenticationRealm, http:cookies,
http:transfer-coding on the SOAP binding.
ACTION: Editors to write up that we allow http:version etc.
in the soap binding when the protocol is http.
-------------------------------------------------------
Discussing soap:address and http:address
Current syntax for endpoints:
<endpoint name="foo" soap:address="..."/>
Amy's proposal: Introduce optional "address" attribute to
/service/endpoint to be the address of the endpoint.
Accepted
RESOLUTION: coalesce http:address and soap:address.
ACTION: Editors to update part 1 to add optional
/service/endpoint/@address
ACTION: Editors to update part 3 to remove soap:address and
http:address and update binding details accordingly.
RESOLUTION: issue 188 closed per above.
NOTE: issue 189 is the @location issue
Resolved issue 190 closed per agreed to marriage of http and soap
bindings.
RESOLUTION: Close 190 per above resolutions.
-------------------------------------------------------
Now talking about issue 61: soap response MEP
RESOLUTION: Close issue 61, add support for HTTP URI binding rules.
ACTION: editors to update part 3 to say that for SOAP Response MEPs
the URI will be generated following the HTTP binding rules
for generating a URI (for GET).
-------------------------------------------------------
RESOLUTION: Issue 184 to be closed with editorial AI to make sure the
wording does not preclude MTOM use.
ACTION: Editors to update soap binding default rules to allow use of
MTOM.
-------------------------------------------------------
Issue 178: op safety
RESOLUTION: Move action 178 to a test suite issue as we've done the
technical stuff needed.
-------------------------------------------------------
Issue 187: closed because now obselete (we removed @webMethod)
RESOLUTION: Close issue 187 as obsolete.
-------------------------------------------------------
Issue 154: need philippe for more info
-------------------------------------------------------
Issue 155: support for outbound ops in http
ACTION: Amy to provide wording to go into spec to say that our
bindings only support the identified MEPs but others can
be handled if appropriate rules are defined elsewhere.
RESOLUTION: Close issue 155 with the above editorial changes.
-------------------------------------------------------
Issue 158: related to ADD; defer
-------------------------------------------------------
Issue 170: closed due to obseleteness
RESOLUTION: Closed issue 170 as obsolete.
-------------------------------------------------------
Issue 171: xml version
lots of discussion about merits/demerits
Amy proposes closing without action;
Jonathan provides rationale: there are other serialization options
that we don't allow control either (charset).
RESOLUTION: Close issue 171 with no action.
16:00 Adjourn
Received on Tuesday, 25 May 2004 01:03:41 UTC