WS Description WG Issues List

Currently names of things like portTypes and bindings are uniquely only across that specific type. That is, one can have a binding called foo and a portType called foo. Should we make these names be unique across the entire document?

Resolved at November 2002 FTF. WSDL 1.2 will retain multiple symbol spaces, one for each top level construct.

If we decide to do so, what form should such documentation take? The removal of operation overloading and advice on how to restructure a WSDL 1.1 file that relies on this feature are an example.

Resolved to add a non-normative appendix detailing the changes from 1.1 to 1.2

It appears that most users who use <import> really treat it as an include mechanism. Should we bite the bullet and have both import and include mechanisms similar to XSLT?

No include will be added.

Issue re-opened. Discussed at November 2002 FTF. Resolved to add a wsdl:include mechanism that works like xs:include sans chameleon behaviour.

We have run into many, many people who appear to be confused about how import is supposed to work. The notion that it only establishes a relationship between a namespace and a location is quite hard to grasp it appears. Specifically, the fact that nothing is said about what one may find about the namespace at that location appears to be very confusing. We need to clarify the intended semantics at the minimum.

Update the document to completely clarify the intended semantics of <import>. The intended WSDL 1.1 semantics were the same as XSD's import, except with a mandatory location attribute. Sanjiva will ask Jean-Jacques to propose new wording.

WSDL 1.1 allows imports to documents in the same namespace. The constraint text:

The namespace attribute information item is of type anyURI in the namespace named "http://www.w3.org/2001/XMLSchema". Its actual value indicates that the containing WSDL document can contain qualified references to WSDL definitions in that namespace (via one or more prefixes declared with namespace declarations in the normal way). This value MUST NOT match the actual value of the enclosing WSDL document targetNamespace attribute information item. It MUST be identical to the actual value of the referred WSDL document's targetNamespace attribute information item.

in the spec disallows this

Resolved at November 2002 FTF that wsdl:import will work exactly like xs:import.

WSDL defines a service as a collection of ports, but there is no abstract analog.

Introduced serviceTypes at June 2002 F2F. removed again at September 2002 FTF.

WSDL 1.1 supports having multiple services in a single WSDL file. This has caused confusion amongst users.

Allow multiple services, where each MAY be of a different service type. (At the June F2F.)

Currently the {port types} property of the service component is populated via the bindings. Should the service have an implements attribute that lists the port types it implements?

resolved at November 2002 FTF NOT to add an implements attribute to the service element

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.

Do we want to allow WSDL 1.2 to use type systems which are NOT XML based

non-XML type systems are allowed via extensibility attributes of message/part elements.

We discussed this briefly at the April F2F (perhaps) but, I think it would be extremely helpful to permit alternate and multiple responses to a request; that is, permit multiple output messages in an operation like we have multiple faults in an operation. It would then be helpful to make them alternate or sequence. That is, do all of them come back or just one of them.

This issue is closed by leaving it to the realm of orchestration languages and applications. June 11, 2002 (at face-to-face).

See http://lists.w3.org/Archives/Public/www-ws-desc/2002May/0271.html

This issue is closed on the basis that the open-ended extensibility model we have adopted enables the description of arbitrary message exchange patterns. June 11, 2002 (at face-to-face meeting).

Further discussion on this issue occured during the November 2002 FTF.

Further discussion on this issue at Jan 2003 FTF. Decided to allow MEPs to be specified by URI. The WG will define a set of MEPs ( probably 6-7 )

For a parameter to be considered in/out it must also be the case that the parts be of exactly the same type.

Unknown. Issue is closed but no resolution is recorded. May be related to removal of parameterOrder

While parameter order is specified at a portType level, in the SOAP case, whether the binding is an RPC binding or not is not specified until later. Thus, the information is misplaced at best.

Resolved at September 2002 Face-to-face, Alex, VA to remove paramterOrder attribute

Notification operations are also not fully defined in WSDL 1.1. There are multiple interpretations of these in the community: event, callback etc. Also, there is little evidence that anyone is actually using them. We could consider replacing this with a first-class description of an event mechanism.

Per the 20-22 Jan 2003 face to face meeting, there will be a one-way, output-only MEP.

Solicit-response operations are not fully defined in WSDL 1.1. There are multiple interpretations of these in the community: event, callback etc. Also, there is little evidence that anyone is actually using them. We could consider replacing this with a first-class description of an event mechanism.

Per the 20-22 Jan 2003 face to face meeting, there will be a output-input MEP.

WSDL 1.1 allows overloaded operations- operations with the same name but different messages. If they are to be disallowed then we must require the operation name to be unique within a portType.

Do not allow operation overloading. See minutes for telecon on June 27, 2002 and follow-on email discussion.

Some users have asked that portTypes be extensible. We need to carefully consider whether that is a good thing or not.

Closed. port type extensibility added 20021010.

It is important that operations within port type be uniquely identifiable. Suggested approachs so far: a) make operations top-level and make their names QNames ( qualified by targetNamespace ) b) Use the port type name as the scope identifier and refer to this somehow from the binding

Proposal to make operations top-level constructs ( and hence named by QName ) presented at November 2002 FTF

resolved at the November 2002 FTF to reject proposal to make operations top-level. All operations of a combined port type MUST have unique local names.

The question is whether we can just have element and still retain full abstraction or if not whether we can just have type and live.

Per 18 Dec 03 telecon, noted this issue is obsolete since we now have a single way to indicate the schema construct that describes the 'message'.

In WSDL 1.1, a message can only be defined to be a sequence of parts. It is not possible to indicate that certain parts may be optional, may occur multiple times, etc.? Should we do that? Overlapping with XML Schema's mechanisms is an obvious concern.

We will consider this for WSDL 2.0 in conjunction with the resolution for issue "issue-eliminate-message." If <message> is retained in WSDL 2.0, then this issue becomes interesting; otherwise it's a non-issue.

Per 30 July 2003 meeting in Raleigh, NC, decided to eliminate message construct and use XML Schema (or some other type system) directly.

Using the <message> mechanism to define the structure of a message makes the <message> syntax an alternate infoset defining syntax to XSD in some sense. It would be nice to be able to write message definitions just using XSD and eliminate the <message> mechanism altogether.

Continued discussion at November 2002 Face-to-face at Macromedia. Multiple proposals, one to replace message with references to elements/types/named model groups in schema ( Roberto, Jeff, Gudge ) another to move the parts in message inside the input and output elements of port type operations ( Sanjiva, Paco, Joyce )

Original resolution: We will consider this for WSDL 2.0. For WSDL 1.2, we will not remove the <message> construct.

At 30 July 2003 meeting in Raleigh, NC, decided to remove message and message/part constructs, and replace with interface/operation/input/@body that points to a GED. (Restricts SOAP to a single GED in s:Body.) Replace with interface/operation/input/@headers that point to a list of GEDs. Same for interface/operation/output. interface/operation/fault TBD. Add attribute to operation to indicate whether a set of rules was used when writing the schema as a hint/guide to reconstructing method signatures in proxy code.

WSDL 1.1 requires all references to be QNames. For example, a reference to a portType from a binding element must always use a QName even if that portType is in the same namespace and even if it is defined in the same document. It would be convenient to support local part references for intra-namespace references.

Update the document to clearly indicate that all references must be with QNames, whether inter-document or intra-document. Sanjiva delegates to Roberto on April 29, 2002.

WSDL 1.1 has an optional attribute on definitions which is defined as being used to provide a lightweight form of documentation. I would like to remove that as it's not clear that that has been useful or used.

Decided to remove during the July 18th telecon.

WSDL 1.1 indicates that the targetNamespace attribute is optional. I would like to make it required as otherwise the NCNames used in other places don't make much sense.

Accepted during telcon on June 27, 2002.

[email] For http:urlReplacement it is not clear what should happen for "search patterns" where there is no correspondingly named part in the message.

Strings enclosed within single curly braces MUST be input message part names; any other strings enclosed within single curly braces are a fatal error. [email]

Accepted per 29 May 2003 telecon.

[email] For http:urlReplacement it not not clear what URL escaping should be done on the replacement text.

- Is an embedded "?" to be expanded into "?" or "%3f".

- Is an embedded "%3f" to be expanded into "%3f" or "%253f"

Per 13 Feb 2003 teleconference, editors to add text compatible with I18N.

[email] Is it legal for the part referenced to reference a schema element instead of a type?

Per 30 July 2003 meeting in Raleigh, NC, decided to eliminate message construct and have interface/operation/input etc refer directly to global element declarations in XML Schema (and not complexTypes).

[email] If [the value of abstract type] is xsd:string, then it is unclear how chars outside the ASCII range are to be handled. UTLencoded UTF8 perhaps?

Wait until Charmod goes to REC, if possible, since it contains a pretty strong requirement that W3C specifications "use Internationalized Resource Identifiers (IRI) (or an appropriate subset thereof)."

Per 13 Feb 2003 teleconference, editors to add text compatible with I18N.

[email] The spec does not say much about how values of abstract types are to be stringified when the type is something else xsd:string. Should it just be stringified as XML (and then URLencoded)?

Per 13 Feb 2003 teleconference, leave HTTP request URLs segmented, flat, and (somewhat) human readable.

[SOAPAction has been deprecated, as of SOAP 1.2] <quote section="3.4 soap:operation">

The soapAction attribute specifies the value of the SOAPAction header for this operation. This URI value should be used directly as the value for the SOAPAction header; no attempt should be made to make a relative URI value absolute when making the request. For the HTTP protocol binding of SOAP, this is value required (it has no default value). For other SOAP protocol bindings, it MUST NOT be specified, and the soap:operation element MAY be omitted.

<quote>

Does this mean the SOAPAction value should include the quotes needed ?, i.e. if you're expecting a SOAP request

POST .... 
SOAPAction: "/foo/bar"

do you include the quotes in the soap:operation ?, e.g.

<soap:operation soapAction="/foo/bar" />

or not?, if not and the soapAction is mandatory for HTTP bindings, how do you specify that you want an empty SOAPAction header ? e.g.

POST ....
SOAPAction: 

Closed 5/21/2004 FTF. No @soapAction will mean no soapaction header.

[SOAPAction has been deprecated, as of SOAP 1.2] <quote section="3.4 soap:operation">

The soapAction attribute specifies the value of the SOAPAction header for this operation. This URI value should be used directly as the value for the SOAPAction header; no attempt should be made to make a relative URI value absolute when making the request. For the HTTP protocol binding of SOAP, this is value required (it has no default value). For other SOAP protocol bindings, it MUST NOT be specified, and the soap:operation element MAY be omitted.

<quote>

It's my opinion that WSDL should not specify the absolute exclusion of the SOAPAction for non-HTTP bindings. What if an SMTP binding wants to use exactly the same URI, but encapsulate it in an "X-SOAPAction" header?

Per 4 Nov 2003 face-to-face, decided to simplify SOAP binding extension to just <wsoap:action uri="xs:anyURI" />.

[email] Possibly one of the most talked about parts of WSDL:

• What is the standard way to describe an array?
• How many other valid ways are there to describe an array?
• How do i define more complex types?
• Does the new WSDL 1.1 approach to arrays support all the different array types in SOAP?

[needs review]

[email] I ran across this example at http://www.w3.org/2001/03/14-annotated-WSDL-examples

The example is correct but does emphasize a concern.

1) when a part is typed "element" and referenced to schema

2) and the binding's soap:body "namespace" attribute is used

Spec reads Section 3.5

...although the namespace attribute only applies to content not explicitly

defined by the abstract types. ...

A case becomes present where the namespace attribute can be declared and the element's namespace *is* explicitly declared by the targetNamespace of the schema (assuming XSD) which is the namespace to be used and *NOT* the text of the soap:body namespace attribute. However, if the schema was non-XSD *and* no targetNamespace (or such) could be isolated, the value of the namespace would default to the "namespace" attribute.

This seems confusing and it would seem in the interests of best practices to either

1) declare the namespace attribute of the soap:body element equal to the intended namespace

or

2) omit the namespace attribute *if* the element is explictly declared in schema.

(I would think (1) would clear any garbled confusion in either case).

email

[email] SOAP defines EncodingStyle as being scoped at the element + child level [the same as namespaces], meaning that a single SOAP message may contain different parts with different encoding styles, but in WSDL this is scoped at the message level, i.e. the whole message uses a particular encoding style, so there are potential SOAP messages that can't be modelled in WSDL.

email Allow encodingStyle to be specified on each message block (and also fault detail) but not their descendants, i.e. each block has a single encodingStyle

[email] The sample in section 4.1 of the spec uses xsd:binary which doesn't exist, its not clear what the correct type to use in its place would be.

Removed example; rewrite in primer.

[email] In section 2.1, extensibility is expilictly stated for all the elements, but not for attributes.

In the WSDL Schema, PartType is extended from "openAtts". This means anyAttributes can be defined in addition to the three optional attributes specified for Part (name, type, element). Though it mentions in section 2.3 that "other message-typing attributes may be defined as long as they use a namespace different from that of WSDL", it would be better for those who use the grammar as a convenient reference if this is also reflected in section 2.1.

Per 18 Dec 03 telecon, same description for attribute and children extensibility; neither in pseudo syntax to minimize clutter.

[email] In example 1 of WSDL 1.1 (2001-03-15) the binding reference from the port does not resolve because of a typo. The binding name should be:

tns:StockQuoteSoapBinding

The example is missing "Soap" in there.

Simon Fell also notes that examples 2,4 and 5 have the same problem.

[email] [see also issue 43] In example 3 the <types> element comes after <service>. This is not allowed according to the WSDL schema (A 4.1) or the grammar in section 2.1.

Removed example; rewrite in primer.

[email] According to the schema in section A-4.1 the <import> element might take an subordinate documentation element. The grammar in section 2.1 ought to be changed to say:

<wsdl:import namespace="uri" location="uri"> *
<wsdl:documentation .... />?
</wsdl:import>

In WSDL 1.1 (2001-03-15) it simply says.

<import namespace="uri" location="uri"/>*

The namespace qualifier for <import> is also missing in the current text.

[email] [see also issue 20]

According to the schema in section A-4.1 the 'name' attribute of <part> is optional.

This is not indicated in the grammar in section 2.1 and section 2.3. Section 2.3 also states that "The part _name_ attribute provides a unique name among all the parts of the enclosing message".

I believe the schema is wrong and that the definition of "partType" should be changed to:

<complexType name="partType">
<complexContent>
<extension base="wsdl:openAtts">
<attribute name="name" type="NMTOKEN" use="required"/>
<attribute name="type" type="QName" use="optional"/>
<attribute name="element" type="QName" use="optional"/>
</extension>
</complexContent>
</complexType>

Per 30 July 2003 meeting in Raleigh, NC, decided to remove message and message/part construct.

[email] This is an editorial issue for WSDL 1.1 - the schema doesn't declare the parameterOrder attribute.

Removed @parameterOrder.

[email] At present, it is possible with WSDL 1.1 to specify particular headers which should be included with particular messages. This was, I believe, a reasonable first stab at integrating headers with a description language, but it falls far short of being able to support the kind of rich semantic additions that are going to be coming down the line as SOAP extensions over the next few months/years.

Without going into too much detail, I'd like to see us require the ability to specify that a particular SOAP "module" is offered by, or required by, particular services or operations. SOAP 1.2 (part 1, sec 3) discusses the concept of SOAP "features", which are semantic extensions named with a URI and implemented by either SOAP extensions (headers) or bindings. Bindings already have a requirement for URI naming, and I'm attempting to push for extensions to do the same. Once we have URIs for such things, it becomes possible to say something like "this operation supports the 'http://www.w3.org/2002/06/reliable-message' extension", which would imply some set of headers/exchanges mandated by that specification. It's unclear to me as to whether we would require a schema description of every possible header which such an extension might produce, but that's another facet of this which we should discuss.

This is also a potentially complex issue in that it gets into situations where messages that are not actually specified directly in the WSDL may become part of the exchange due to the extension specs, but I think we need to figure this stuff out if we hope to live in a world with true "orthogonal extensibility" and some hope of negotiation/interop.

Per 11 Dec 2003 telecon, noted that features and properties are currently included in the draft [email].

[email] I'd like to see changed with the WSDL specification is the ability to add <documentation> tags to a <part>. right now, you can't officially comment arguments to an operation, which seems like an error.

Per 18 Dec 03 telecon, noted that we now allow documentation everywhere.

[email] Does a binding have to specify all the operations in a portType ? I thought not, but i can't spot anything in the spec that says one way or the other.

Fixed.

[email] [s/actor/role/, as of SOAP 1.2] Is there anyway to specify the actor URI for a header in WSDL, i can't spot anything ?

email

As described in proposal above, with minor amendments from Gudge and Jonathan.

[email] [see also issue 46] The _transport_ attribute of <soap:binding> is optional, but it is not clear to me what the default is.

Is "http://schemas.xmlsoap.org/soap/http" the default?

If so, shouldn't the schema in section A-4.1 declare this value as the default?

soap:transport is mandatory

[email] Section 3.7 of the WSDL spec states that soap:headerfault elements are optional, but they aren't in the schema both in the spec and at http://schemas.xmlsoap.org/wsdl/soap/.

Closed 5/21/2004 FTF. Schema is obsolete and will be completely rewritten.

[email] [see also issue 12] Section 3.7 of the WSDL spec states that the soap:header and soap:headerfault elements take a required 'part' attribute of type NMTOKEN, but the schema in the spec and at http://schemas.xmlsoap.org/wsdl/soap/ state that the attribute is 'parts' and of type NMTOKENS.

Header now points directly to Schema.

[email] In most places, the <import> element seem to correspond to a #include directive, for example in section 2.1.2 stockquoteservice.wsdl example. This does not seem to be the case for the stockquote.wsdl example in the same section. If the <import> element in that section was equivalent to a #include directive, the schema stockquote.xsd would be included as is, and there would be a missing surrounding <types> element.

Remove example; rewrite in primer.

[email] Currently, the specification is not XML Infoset based.

Fixed.

[email] Does WSDL 1.1 support the new SOAP 1.2 (graph) data model, encoding and RPC convention? Does it support the new SOAP 1.2 transport binding framework, and revised extensibility model (features)? More generally, does it support all of SOAP 1.2?

Per 11 Dec 2003 telecon, decided to split this into separate issues. See new issues 99, 100, and 101.

[email] [see also issue 25] The second issue that has been confusing to me is the literal vs. encoded. I think that WSDL specification should take it upon itself to clarify the issue clearly. I am sure that some people out there truly understand the difference but I am sure ther is a great deal of confusion about this also.

Original resolution: Removed @use. @encodingStyle is a hint about how types/schema was generated. Reopened by Macromedia\Tom at telecon prior to 30 July 2003.

Per 18 Dec 03 telecon, noted that SOAP encoding can be used via some other, to-be-invented schema language in the current design. (See new issue 97.)

[email] [see also issue 24] WSDL 1.1 uses XML Schema to describe data in, for example, SOAP 1.1 encoding. XML Schema is not really good at describing graph data model strictly, therefore WSDL 1.1 has the "encoded" use of schemas but it does not specify concretely how schemas are dealt with.

If we want to keep "encoded" use, IMHO we'll have to specify how XML Schema schemas are understood in connection with SOAP data model. AFAIK, this has been a big interop issue.

Removed @use. @encodingStyle is a hint about how types/schema was generated.

[email] [See also issue 35-36] _Background_ Currently WSDL 1.1 defines 4 transmissions primitives (one-way, request-response, solicit-response, notification). SOAP 1.2 defines the concept of Message Exchange Pattern (MEP) [1]. A MEP is a template for the exchange of messages between SOAP Nodes.

_Issue_ In its current state, WSDL 1.1 is not able to define which MEP a Web Service will use over a SOAP binding (several different MEP can define a one-way transmission primitive).

_Proposed solution_ As MEP are almost independant of SOAP 1.2, I would suggest replacing transmission primitives by MEP.

Per 11 Dec 2003 telecon, decided to close given Part 2 of the spec [email].

[email] _Background_ In SOAP 1.2, RPC is an extension of SOAP, that is a particular use of SOAP.

_Issue_ Regarding SOAP 1.2, the style attribute can only be seen as a hint that SOAP 1.2 is used with *an* RPC extension. It does not specify which RPC extension is used nor any other important informations like which encoding is used for the parameters...

_Proposed solution_ Remove the style attribute and create a way for defining which SOAP extensions are used (see below).

At 22 Sep 2003 meeting in Palo Alto, CA decided to resolve per 31 July 2003 meeting. Per 31 July 2003 meeting in Raleigh, NC, removed @style from SOAP binding; defined an attribute on operation that may be used to indicate that a set of rules was used when constructing the XML Schema for the Body.

[email] _Background_ A SOAP 1.2 message can be transfered over many protocols. SOAP 1.2 defines bindings for specifying use of underlying protocols. For example [2] describes *an* HTTP binding for SOAP 1.2.

_Issue_ The transport attribute allows to define which binding is used for a Web Services accessed over SOAP 1.2. However this attribute may be ill named (there may exists several bindings for a particular transport) and it does not allow specifying which options of a binding are used.

_Proposed solution_ Use the soap:binding element to define which binding is used and

Closed 5/21/2004 FTF. Obsolete - already have provided the protocol attribute.

[email] Background_ Currently WSDL 1.1 says that the parts attribute indicates which message parts appear somewhere within the SOAP body. Other parts may appear in other locations (such as attachements).

_Issue_ WSDL 1.1 does not specify the precise structure of the body (are the parts allowed to appear in any order, may they be contained in element information items descendant of the body...). In addition, it does specify nothing for the parts not transmitted in the body.

_Proposed solution_ Have WSDL 1.1 define in a precise way the structure of the SOAP body. Give some directives for specifying in a Web Services description what happen to the parts not transmitted in the body (is it possible to not transmit them...).

Closed 5/21/2004 FTF. Obsolete - parts are gone.

[email] [Child aspect already covered by issue 5]

_Background_ In WSDL 1.1, the encodingStyle attribute is a list of uri. In SOAP 1.2, the encodingStyle attribute is an uri. Moreover, an element can use an encodingStyle while some of its children use another encodingStyle. (Note: the usage of the encodingStyle attribute is being discussed currently and may differ in the final version of SOAP 1.2).

_Issue_ WSDL 1.1 and SOAP 1.2 does not have the same use of the encodingStyle attribute.

_Proposed solution_ Change the WSDL 1.1 use of the encodingStyle attribute.

email Restrict the value of the encodingStyle attribute to be either empty (for literal) or a single URI (for encodings like SOAP encoding).

[email] _Background_ WSDL 1.1 uses the soap:address element to specify the destination of the message.

_Issue_ The way of targetting a WSDL message through SOAP 1.2 is dependant on the binding used and may also depend on the MEP used. The soap:address element may not be sufficient to describe this targetting.

_Proposed solution_ The target of a WSDL message should be defined in the soap:binding element.

Closed 5/21/2004 FTF.

[email] Should this new version of WSDL have backward compatibility support for SOAP 1.1, or just support SOAP 1.2? More generally, should it have support for individual version of SOAP and other protocols?

Yes, we will provide a SOAP 1.1 binding (Note).

[email and email] I do believe strongly that this distinction between RPC style and document style is quite misleading. The reason I think the issue becomes relevant to WSDL is that most users will not be exposed to SOAP or will not quite understand SOAP. Interface description language is what is viewed as the contract and the underlying protocol becomes part of the solution. From my own experience, I kept on happily ignoring the distinction between the two. The document style was meaningless to me. I became more aware of the issue when I used somebody else's WSDL that indicated document style and ran into some incompabilities.

So even if we cannot consolidate those two styles, should we atleast make an attempt to a) raise awareness of this issue and possibly put it in front of the relevant group and b) possibly provide some guidance and explanation in the primer or some other non-normative documents.

Per 31 July 2003 meeting in Raleigh, NC, decided to eliminate separate styles in SOAP binding and use attribute on operation to indicate whether a set of rules was used when writing the schema as a hint/guide to reconstructing method signatures in proxy code.

[email] Some users have asked that portTypes be extensibile. We need to carefully consider whether that is a good thing or not.

email

[email] [See also issue 26] Solicit-response operations are not fully defined in WSDL 1.1. There are multiple interpretations of these in the community: event, callback etc.. Also, there is little evidence that anyone is actually using them. We could consider replacing this with a first-class description of an event mechanism.

email

[email] [See also issue 26] Notification operations are also not fully defined in WSDL 1.1. There are multiple interpretations of these in the community: event, callback etc.. Also, there is little evidence that anyone is actually using them. We could consider replacing this with a first-class description of an event mechanism.

email

[email] [See also issue 13] While parameter order is specified at a portType level, in the SOAP case, whether the binding is an RPC binding or not is not specified until later. Thus, the information is misplaced at best.

email

[email] There is confusion in the user community about what should go in a binding vs. a port vs. a service in terms of extensibility. An approach could be to that data marshalling type extensions go in a binding and transport stuff goes in to a port and anything else goes into a service.

[email] The portType is supposed to represent the abstract interface of a service without reference to how the service is accessed. However, the current design couples the binding extensions with the structure of the portType making it necessary to define a separate portType for each binding extension. SOAP RPC Style, SOAP Document Style, and HTTP GET or PORT each require specific structure in the portType, yet all can be used to access the same logical service.

It is useful to provide HTTP GET and POST endpoints for a service in addition to a SOAP/HTTP endpoint. Each endpoint should provide access to the same underlying service. It is therefore reasonable to expect that each endpoint should be bound to the same portType. The portType should be an abstract definition of the interface of the service. The bindings should describe how to access the service using a given protocol. However, the binding extensions for HTTP GET and POST are not defined in a way that allows them to use the same portType as SOAP/HTTP. To work around this problem, an additional, but semantically equivalent portType, must be defined. [see email above for examples]

Potential Solutions

* Expand the definitions of the binding extensions so they can be applied to any portType. For example, in the HTTP GET or POST bindings, define how the response is generated from a message that has several parts.

* Eliminate message definitions and instead define portTypes directly in terms of XML Schema types. Use XPath to bind parts of the schema to the protocol.

At the 22 Sep 2003 meeting in Palo Alto, CA, decided to resolve per 30-31 July 2003 meeting. At the 30-31 July 2003 meeting in Raleigh, NC, decided to eliminate message and eliminate the different binding styles for SOAP.

[email] The binding extension for SOAP depends on the following features:

* The message part XSD style, either type or element.

* The SOAP style, either RPC or Document.

* The encoding style, either literal or encoded.

* The direction of the message, either input or output.

Since each of these four properties has two values, there are a total of sixteen possible combinations. The text of the WSDL 1.1 specification should be clearer about how these properties interact and which combinations are valid since not all seem to be. Each combination should be enumerated and described clearly, and illustrated with an example.

It is important to establish the validity and interpretation of each combination in order to improve interoperability between vendors. For example, the current version of WebSphere Studio creates services that use literal encoding in RPC style, but the current version of Microsoft Visual Studio .NET does not support the generation of Web references to that type of service. It is not clear whether this restriction is based on a belief that the combination is not valid, or is simply a prioritization of function delivery.

At 22 Sep 2003 meeting in Palo Alto, CA, decided to resolve as per 30-31 July 2003 meeting. At the 30-31 July 2003 meeting in Raleigh, NC, we decided to eliminate the message construct and use only elements directly; we also decided to eliminate the style mechanism in the SOAP binding; we have previously decided to eliminate the use of SOAP encoding.

[email] [see also issue 6] In WSDL 1.1 it is possible to defined an input message part that is a complex XML schema type. [see email above for example]

The WSDL 1.1 specification does not explicitly describe how to URL encode complex types, but a reasonable interpretation is to use the serialized content as a the query string value. For example, suppose an input message has a part named employee of type PersonType. This part would be passed in a query string as:

employee=<name>John Doe</name><birthdate>1960-01-01</birthdate>

Now suppose that PersonType had an attribute named sex. [see email above for example]

How would this be passed in a query string? Clearly the WSDL 1.1 is silent on this topic. The WSDL 1.1 specification should either explicitly disallow attributes, or should define some serialization that can be used with URL encoding, e.g. prefix the content with a comma-separated list of attribute values enclosed in square brackets:

employee=[sex(male)]<name>John Doe</name><birthdate>1960-01-01</birthdate>

Per 13 Feb 2003 teleconference, leave HTTP request URLs segmented, flat, and (somewhat) human readable.

[email] In section 2.3 Messages, it states: " WSDL defines several such message-typing attributes for use with XSD: *element. Refers to an XSD element using a Qname. *type. Refers to an XSD simpleType or complexType using a Qname."

While in the section 3.1 example 4 and example 5, element is used as follow:

<message name="GetTradePriceInput">
        <part name="tickerSymbol" element="xsd:string"/>
        <part name="time" element="xsd:timeInstant"/>
</message>

References: Section 2.3 Message Section 3.1 SOAP Examples

[email] [see also issue #10] Section 3.1 SOAP Examples, example 3 lists <types> as the last element under <definitions>. This is inconsistent with the schema where <type> is defined as the second of the sequenced elements of the "definitionsType"; similar issue with section 4.1 HTTP GET and POST Binding example 6 where <binding> is put after <service>

References: Section 3.1 SOAP Examples, example 3 Section 4.1 HTTP GET and POST Binding example 6 A 4.1 WSDL Schema

[email] Section 3.6 sopa:fault grammar indicates that fault has a required name attribute while in the schema no such attribute defined for faultType

References: Section 3.6 soap:fault A 4.2 SOAP Binding Schema

Closed 5/21/2004 FTF. Schema is obsolete and will be completely rewritten.

[email] Section 3.6 soap:fault grammar indicates that the use attribute of fault is required while in the schema use is defined as optional

References: Section 3.6 soap:fault A 4.2 SOAP Binding Schema

Resolved at the 22 Sep 2003 consistent with prior decision to eliminate the use of SOAP encoding.

[email] [see also issue 18] Section 3.3 sopa:binding grammar and the SOAP binding schema both indicate that the transport attribute of binding is optional while in the text, it is "required"

References: Section 3.3 soap:binding A 4.2 SOAP Binding Schema

Closed 5/21/2004 FTF. Schema is obsolete and will be completely rewritten.

[email] Section 3.4 soap:operation grammar indicates that the operation is optional. In the text of the same section, it also states that "For other SOAP protocol bindings, it MUST NOT be specified, and the soap:operation element MAY be omitted."

However, in the SOAP Binding schema, no value is specified for minOccur/maxOccur. It implies that this element is required.

References: Section 3.4 soap:operation A 4.2 SOAP Binding Schema

Closed 5/21/2004 FTF. Schema is obsolete and will be completely rewritten.

[email] Section 3.5 soap:body grammar and the SOAP binding schema both indicate that the use attribute of soap:body is optional while in the text, it is "required"

References: Section 3.3 soap:binding A 4.2 SOAP Binding Schema

Resolved at the 22 Sep 2003 consistent with prior decision to eliminate the use of SOAP encoding.

[email] Section 3.7 sopa:header and soap:headfault grammar indicates that there can be 0 or more <soap:header> element while in the schema no minOccur/maxOccur specified for <soap:header> which means there can be exactly one occurrence

References: Section 3.7 sopa:header and soap:headfault A 4.2 SOAP Binding Schema

Fixed.

[email] Inheritance rules have been changed since 2000/10 version XML schema. It requires that everything must be re-stated to be inherited. In section 3.1 SOAP Examples (example 5) and section 5.11 MIME Binding example (example 7), array declaration still follows old rules. See Appendix A for more details.

References: Section 3.1 SOAP Examples (example 5) Section 5.11 MIME Binding example (example 7)

Removed example; rewrite in primer.

[email] This issue can be viewed as an example our observation that the binding extension specification is not clearly documented and not sufficient.

Section 3.5 states that "The soap:body element specifies how the message parts appears inside the SOAP Body element. ... provides information on how to assemble the different message parts inside the Body element if the SOAP message ".

Section 3.7 states that "the soap:header and soap:headerfault elements allows header to be defined that are transmitted inside the Header element of the SOAP Envelope. It is patterned after the soap:body element ".

These statements imply that it should be similar to assemble different message parts inside SOAP message body and message header. However, the attributes of these two elements are quite different and the usage of the word "part(s)" and "message" is very confusing to many readers.

The grammar section lists these elements as below: <soap:body parts="nmtokens"? use="literal|encoded" encodingStyle="uri-list"? namespace="uri"?> <soap:header message="qname" part="nmtoken" use="literal|encoded" encodingStyle="uri-list"? namespace="uri"?>* <soap:headerfault message="qname" part="nmtoken" use="literal|encoded"encodingStyle="uri-list"? namespace="uri"?/>* <soap:header>

The text about parts attribute of soap:body reads as "The optional parts attribute of type nmtokens indicates which parts appear somewhere within the SOAP Body portion of the message (other parts of a message may appear in other portions of the message such as when SOAP is used in conjunction with the multipart/related MIME binding). If the parts attribute is omitted, then all parts defined by the message are assumed to be included in the SOAP Body portion". Here it's very hard to understand if "part" refer to the WSDL message part or the SOAP message part, also it's hard to understand if it's talking about WSDL message or SOAP message.

There is no explanation about:

* Why does soap:header need to have the "message" and "part" attributes while soap:body can be bound to a particular input/output message?

* Is it intended to allow part from other messages to be incorporated into the SOAP header? Then what is the meaning of grouping parts into a message?

* Why does not soap:header allow more than one part per message while in soap:body "parts" attribute can be a list of WSDL message parts?

[email] operation addresses should not be required to be relative

Closed 5/21/2004 FTF. Closed without action: Can be achieved by putting one operation per interface and bind the interface to a uri.

[email] each operation in a binding should choose its own method, not one for all

Define http:operation/@verb.

Incorporated per [Rennes Meeting].

[email] any HTTP method should be allowed [in the HTTP binding]

Closed 5/20/2004 FTF. Extensibility in the HTTP method will be provided per the proposal at http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0057.html, with the amendment that the default media type will be x-www-url-encoded.

[email] need a way to set HTTP headers [in the HTTP binding]

Closed 5/20/2004 FTF.