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.

[email] need a way to specify an authentication requirement [in the HTTP binding]

Closed 5/20/2004 FTF. See resolution of issue 165.

[email] We discussed this briefly at the 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 is perhaps a suggestion for new functionality.

[email] The <mime:content> is defined with a "part" and a "type" attribute spec. E.g.

<output> 
     .. 
    <mime:part> 
       <mime:content part="docs" type="text/html"/> 
    </mime:part>
</output> 

I think it would be very useful to permit the part to come from a different message just as it is done with the <soap:header > binding. Like <mime:content message = "tns:rnheaders" part="serviceHdr" type="text/xml"/>

MIME Binding outside the scope of our charter, closing issue with no action.

[email] A 4.4 MIME Binding Schema permits "zero" parts in multipart/related.

<element name="multipartRelated" type="mime:multipartRelatedType"/>
<complexType name="multipartRelatedType" content="elementOnly">
      <element ref="mime:part" minOccurs="0" maxOccurs="unbounded"/>
</complexType>

This is not legal.

MIME Binding outside the scope of our charter, closing issue with no action.

The examples in Section 5.11 clearly see the need for parts being optional. However since decided that parts in messages will not be permitted to be optional, we need to fix the examples. Example 7 carries in its description:

The response contains multiple parts encoded in the MIME format multipart/related: a SOAP Envelope containing the current stock price as a float, zero or more marketing literature documents in HTML format, and an optional company logo in either GIF or JPEG format.

However, neither the abstract level definitions nor the concrete bindings shown make the parts (attachments) optional. Specifically the "optional" company-logo nor the marking literature (zero or more => optional w/ cardinality) are really not optional. We need to fix the examples accordingly.

[email] I, and I think the TAG, agree with having a WSDL definition for a HTTP GET-in/SOAP out binding that is orthogonal to the SOAP POST binding. Could this be added to the WSDL issues list, as it sounds like you are in agreement as well.

Closed at 5/21/2004 FTF.

At a recent SOAPBuilders interop forum, we discussed the current WSDL SOAP bindings lack of being able to specify the specific fault codes that may be thrown by the various operations. For example, given the following WSDL 1.1 snippet, we can tell that a fault can be thrown, but we have no idea what specific faultcodes we should expect.

<operation name="doWapSheDangDang">
  <soap:operation ... />
  <input>...</input>
  <output>...</output>
  <fault name="fault-name">
    <soap:fault name="fault-name" use="encoded" encodingStyle="..." 
namespace="..." />
  </fault>
</operation>

The soap:fault element "specifies the contents of the contents of the SOAP Fault Details element", it says absolutely nothing about the fault code.

There needs to be a mechanism that allows one to specify the fault codes that may be thrown. The service would be allowed to throw fault codes other than those listed, however.

Just one possible way of addressing this... (I'm sure ya'll could come up with a better one)

<operation name="beBoppaLooLa">
  <soap:operation ... />
  <input>...</input>
  <output>...</output>
  <fault name="fault-name">
    <soap:fault code="server.unauthorized" name="fault-name" use="encoded" 
encodingStyle="..." namespace="..." />
    <soap:fault code="custom.invalidWhatchamagig" ... />
  </fault>
</operation>

Closed 5/21/2004 FTF. Obsolete, ability to specify code/subcodes has already been added.

[email] Section 2.3 (Messages) of WSDL spec permits defining parts of a message using either "type" or "element" attribute:

<definitions .... > <message name="nmtoken"> * <part
    name="nmtoken" element="qname"? type="qname"?/> *
    </message> </definitions>

Section '2.3.2 Abstract vs. Concrete Messages' also states:

Message definitions are always considered to be an abstract definition of the message content. A message binding describes how the abstract content is mapped into a concrete format.

However, section '3.5 soap:body' in the SOAP bindings section requires that the parts be defined using the "type" if the "use" is "encoded":

The required use attribute indicates whether the message parts are encoded using some encoding rules, or whether the parts define the concrete schema of the message.

If use is encoded, then each message part references an abstract type using the type attribute. These abstract types are used to produce a concrete message by applying an encoding specified by the encodingStyle attribute.

If use is literal, then each part references a concrete schema definition using either the element or type attribute.

No explanation is given why the parts need to be defined using "type" if "use" is "encoded". The SOAP binding scheme is therefore requiring that things be defined in a particular way at the abstract level, violating the separation of abstract definitions and applying multiple concrete bindings to the same abstract level definitions.

We should either remove the restriction or clearly state why this restriction needs to be there. No justification is provided in the spec for this, other than simply having one statement that calls for it.

Resolved per 30-31 July 2003 meeting at the 22 Sep 2003 meeting in Palo Alto, CA. 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.

I believe that the distinction that WSDL 1.1 makes about operations and HTTP verbs, is misleading. In particular, it adds to the confusion regarding the use of the new Web Method Specification Feature in SOAP 1.2, as many people seem to believe that you still need to specify a WSDL operation when you've specified which HTTP method you're using.

HTTP "verbs", such as GET, PUT, POST, etc.. are "operations" in the same way that "GetStockQuote" is. I would like to see the HTTP binding for WSDL 1.2 reflect this.

Adopt Hugo's proposal; open syntax issues 169, 170.

[email] WSDL 1.1 includes a binding for SOAP 1.1 endpoints. It specifies the binding, if SOAP is used along with HTTP. If i wish to use SOAP over FTP, then i need to make certain changes in SOAP bindings of WSDL. I have listed these changes below:

1) "tranport" attribute of <definitions>\<bindings>\<soap:bindings> element need to be changes. It is an URI. Can i use any unique string for this, or i need to get a standard URI from a body like IANA?

2)"soapAction" <definitions>\<bindings>\<operation>\<soap:operation> will no more be used.

3) "location" attribute <definitions>\<service>\<port>\<soap:address> would be a FTP URL

Am i missing something? Do i need to make any other changes in the WSDL bindings?

Per 11 Dec 2003 telecon, decided we won't be doing a SOAP/FTP binding [email].

[email] [email] The question I would like to see explored is how to describe such a service in WSDL. The essense of the issue is how to represent the equivalent of hypertext links. Starting from a document, the flow is as follows:

1) One of the elements contains an attribute of type {http://www.w3.org/1999/xlink}:href. The type of that attribute is of type {http://www.w3.org/2001/XMLSchema}:anyURI.

2) The value of the attribute is to be treated as the {http://schemas.xmlsoap.org/wsdl/http/}:address location of web service. This service is expected to be accessed via a {http://www.w3.org/2002/06/soap/features/web-method/}:Method of GET using the {http://www.w3.org/2002/06/soap/bindingFramework/ExchangeContext/}:ExchangePatternName of http://www.w3.org/2002/06/soap/mep/soap-response/.

3) The resulting document contains an element of exactly the same shape and form as in step (1), and the cycle continues.

Previously agreed to structure our schema so that serviceType derivations can be reused as service references. Support for specific service reference formats such as xlink is not provided.

[email] In addition to R085 there is a small syntactic issue. WSDL must make it possible to invoke an HTTP method like GET with no arguments, for the case where the endpoint URI *is* the URI you want to GET. In other words, http:operation/@location should be optional. I notice that soap:operation has an issue to be made optional so there is some good symmetry there.

Make http:operation/@location optional.

Incorporated per [Rennes Meeting].

[email] Section 2.5 talks about soap:binding, the first sentence is:

The soap:body element specifies how the message parts appear inside the SOAP Fault element.

I don't think this statement is true and it is at least certainly misleading because the soap:body appear inside input, output and soap:fault is patterned after soap:body. All of section 2.5 seems to suffer from the confusion with soap:fault.

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

[email] The issue has to do with how can a WSDL mark some of the headers at the soap binding level to be optional. WSDL 1.1 specification is silent on this and it is not clear if it is an error if some of the headers defined in a WSDL document are missing from the SOAP message that is generated. WSDL 1.1 spec does not provide a way to mark soap:headers "optional".

Current spec for the soap:bind extensions stands as follows:

<soap:header message="qname" part="nmtoken" use="literal|encoded" encodingStyle="uri-list"? namespace="uri"?>*

The WS-I BP team feels it would be desirable to provide a way (an AII?) to mark the soap:header elements optional or required. Alternatively all headers can be made mandatory unless marked optional via the newly defined attribute.

Per 11 Dec 2003 telecon, noted that we have removed the direct soap:headers attribute way of specifying SOAP headers. Features can handle optionality of headers as appropriate. [email]

[email] In 3.1, HTTP GET/POST Examples, in the first blue box, the request format for port2 and port3 should probably have part1 instead of p1, and correspondingly for p2 and p3. Otherwise the names p1, p2 and p3 appear to have been plucked out of the ether.

Remove example; rewrite in primer.

The description language MUST support optional message parts in the address. I don't see a way of using http:urlReplacement and having some parts being optional. But maybe I just missed this and some examples would clear it up.

The current HTTP binding now defines how only some parts may map into the request URI and meets revised R128 wording. [email]

Accepted per 29 May 2003 teleconference.

We have a statement from XMLP WG that we should describe attachments. We should wait to see what they come up with before we start that item.

Closed 5/19/2004 FTF. We'll describe MTOM availability using our feature mechanism and oordinate with the XMLP working group to get that feature described in the MTOM/XOP specifications. No normative change to our specs.

[email] It seems to me that in that particular section, it is not the "Fault" element layout that is under discussion, but the SOAP-Body element layout.

Closed 5/21/2004 FTF. Obsolete - text has been completely rewritten.

[email] It is also somewhat unclear what the element name for parts, referenced via their type attribute, shall be. Maybe some clarification would be useful for true interoperability?

At 30 July 2003 meeting in Raleigh, NC, we decided to remove the message/part construct and use XML Schema element declarations directly in interface/operation/input etc.

In part 2, we use a terminology which is different from that used by the WS-Arch WG. For example, patterns names are different. This is confusing the audience.

Issue is obsolete - Patterns and MEPs have converged

Is it ok for an endpoint to point to an interface derived from what is expected? 2 cases in which this happen is when endpoint in a service element and endpoint reference also gives you expected interface.

The semantics of other AIIs with [local name] = 'name' does not match the semantics of interface/input/@name and interface/output/@name. The latter is used to correlate messages with the interface/@pattern and does not allow the author of the wsdl:interface to coin a name (as other AIIs with the same [local name] do).

Per 11 Sep 2003 telecon, decided to use 'messageReference'.

If a pattern specifies only one input (or output) message, the @name AII is not needed to resolve which interface/input (or interface/output) matches the messages named in the pattern.

Per 4 Sep 2003 teleconference, Make the @ formerly known as "name" optional. We will also > state in the specification that this attribute is required to disambiguate > two or more messages that flow in the same direction in a pattern.

Does a WSDL processor have to validate portions of a WSDL document that it doesn't care about? What if it doesn't care about the hint for mapping to a method signature? What if it doesn't care about a specific binding? How much validation does a WSDL processor have to do?

Add conformance section with: 1) document conformance: conform to schema, etc. 2) infoset conformance 3) processor conformance (accepts any conformant WSDL, types, exts, Jacek's proposal)

If a binding construct does not specify an interface, and therefore provides transport (and wire rep) details indepenent of an interface, it is not a 'binding' because it is not an association between two things.

Recently adopted proposal states that the QName of binding/@interface, when present, MUST match QName of service/@interface. This match process must account for interface inheritance.

When all is said and done, the semantics for a combination of binding info pieces must be consistent and reasonable. We should consider not using so many syntactic constraints to make that happen.

What is the interaction between binding extensions? Is it out of scope of Part 1, which appears to be the status quo? We should be explicit, especially if we define any sort of composition mechanism across bindings.

Do we need to define SOAP header faults? Are they currently in use? If so, are we defining them correctly?

Closed 5/21/2004 FTF. Obsolete: SOAP header faults are already gone.

The HTTP (non-SOAP) binding currently uses message/part to map constructs for URL replacement. Can it use XPath instead? Would it be restricted only to the case where the Schema was written using the encoding rules? Do input/@headers map to HTTP headers? Can you have standard HTTP headers as elements?

URL replacement syntax incorported. New issue 158 openned to track HTTP headers portion of this issue.

Should we define a new binding element for @soapActionURI?

Closed 5/21/2004 FTF. Obsolete - we already have added soapAction attribute.

Redundant direction information between children of operation/{input, output} and direction information in MEP URI.

Per 30 Oct 2003 teleconference, decided not to change the name of this element.

Accepted, editors to use WSA terms when possible.

It would be cool to split the mep description in two layers: - one layer that defines the nodes and messages - one layer that tells who is the service

Obsoleted by MEP work now completed.

Concern re: loading a wsdl:definitions and being confident that the correct interface component (for example) has been loaded. Recognition that this is an environmental problem, associated with the cataloging, namespace-resolution approach and is out of scope of this WG.

Per 2 Oct 2003 telecon, decided to include recommended practice re: use of namespace across documents in primer.

2005-3-31: Recent additions have satisifed this issue.

What happens if the same location is included twice or if there are include cycles? The XMLSchema spec explicitly permits them.

Per 18 Dec 2003 telecon, decided to make multiple includes same as one. [email].

Should wsdl:service/@name be optional? We don't want to force users to have to invent a name when service appears on the wire, but currently we require @name within the context of a wsdl:description.

Consider for example a service jointly provided by a (well-known, fixed) intermediary I1 and a server S. A (SOAP) message travels through I1 and S. It contains blocks B1 and B2. B1 is processed by I1. I1 appends B3 to the outbound message. B2 and B3 are both processed by S. What does the corresponding WSDL look like?

[See also a followup message from Ugo Corda, pointing to additional potential issues email]

Closed 5/19/2004 FTF.

Currently provide support for alternative schema languages and believe this is the way to support SOAP encoding. What would this purpose-built schema language look like?

Closed 5/21/2004 FTF. We will not do this new schema language for soap data model.

Is it sufficient to be able to mark an interface with a single style versus multiple? Or do we want to allow the development of overlapping, perhaps orthogonal indicators of the style(s) used to construct the interface and its messages?

Issue 23 is generally about full support for SOAP 1.2, and specifically it mentions many aspects of the SOAP 1.2 Recommendation. I suggest that we split this issue into separate issues on support for the Data Model and Encoding (one), RPC (two), transport binding framework (three). Features are already covered by issue 14. After such split, we can close issue 23 [email]. (See related issue 97.)

Closed 5/21/2004 FTF. Resolved as duplicate of 97.

Issue 23 is generally about full support for SOAP 1.2, and specifically it mentions many aspects of the SOAP 1.2 Recommendation. I suggest that we split this issue into separate issues on support for the Data Model and Encoding (one), RPC (two), transport binding framework (three). Features are already covered by issue 14. After such split, we can close issue 23 [email].

Closed 5/21/2004 FTF. Can't support without a SOAP data model schema language (see issue 97).

Issue 23 is generally about full support for SOAP 1.2, and specifically it mentions many aspects of the SOAP 1.2 Recommendation. I suggest that we split this issue into separate issues on support for the Data Model and Encoding (one), RPC (two), transport binding framework (three). Features are already covered by issue 14. After such split, we can close issue 23 [email].

Closed 5/21/2004 FTF. Already handled by @protocol and F&P.

The question came up at the face-to-face whether a wsdl:import imported any embedded schemas. As I remember Glen, Tom and Sanjiva all thought that it should while Roberto thought that it did not. Was there any resolution to this issue? [email].

Hi all, I agreed to try and come up with a proposal for combining the two attribute operation styles into one, so here it is. I'm proposing here a change to the accepted proposal [1] referenced from the last WD because our spec doesn't actually contain the text. [email].

[email].

Hi all, as per my action item I've reviewed appendix E [1] (mainly from the POV of other type systems) and here's what I found.

In the current spec, we always use the attributes named 'body' or 'headers' (in no namespace) for referencing element declarations, whether XML Schema, DTD or Relax NG.

It means that our model of a message is one that has a single optional body XML element information item and zero or more header XML element information items. This isn't specified anywhere and it isn't clear if there may be more kinds of things in a message.

So my first suggestion is to specify an explicit language what the model of message is, perhaps as a paragraph in the section on The Message Reference Component. We also need to decide explicitly on the extensibility of the message model, i.e. whether there are other things in the model of a message.

If we only accept XML element declarations (body and headers), it will require that we devise a (possibly simple and limited) mapping to non-XML stuff for use with HTTP and MIME (for exampe for URL parameters and HTML form encoding). If we're happy with this, we will also require that all type systems that might be used in WSDL declare XML elements and we need to say so in the spec. I don't see that as much of a problem, it is certainly possible for this to work with SOAP Encoding and SOAP Data Model. It may be awkward if we have a nice non-XML data model and a binding that uses it and we need to go through an XML conversion step in order to describe this in WSDL.

If we accept XML element declarations and other stuff as well (i.e. there are other kinds of stuff in a message than just header and body XML element information items), we'll need an example for that in Appendix E.

Issue factored into issues 143, 144, 145.

[email].

Proposal to hoist faults into the interface alongside operations.

Accept Paul's proposal to hoist faults in the interface. Rename faultDefault to fault. Allow <value>,<subcode> as children of <wsoap:fault[Default]>. Remove per-operation (in|out)fault.

[email].

How can RDF statements (including OWL statements) be represented in WSDL?

Closed with no action, see Jacek's withdrawal - confirmed 2006-01-05.

[email].

WSDL 1.1 document included a set of rules for naming and representing ArrayOfBlah in an /encoded/ binding which greatly aided interoperability of for rpc/encoded exchanges.

I therefore propose we provide suggested schema extracts for representing a vector, a matrix and an associative array. These would not be normative, but would provide a well supported pattern to follow when generating code from WSDL and WSDL from code.

Close with no action, per decision.

[email].

It appears that the definition of the property component in WSDL 2.0 ([1]) does not allow the use of schema languages other than XML Schema.

Accept proposal

[email]. [email].

In the Interface Description section of the charter there is the following:

Developers are likely to want to extend the functionality of an existing Web service. The Working Group will look into extending interface descriptions in a decentralized fashion, i.e. without priori agreement with the original interface designers.

We read this as WSDL 2.0 providing a mechanism for versioning a Web Service, at least an outline how to add contents of a message without breaking existing interactions.

There appears to be nothing in the requirements relating to how to version a Web Service beyond being able to identify versions of services and descriptions.

Has this issue been lost, or is our reading of the charter incorrect ?

Joint TF with Schema and WSDL to investigate whether best practices can be developed, which will be included in the Primer.

[email]. [email].

Should we allow complete URL replacement (changes to portions of the URL other than query parameters) or only query parameter mechanism?

Question raised as to whether all possible schemas can be encoded in a URL, or only a restricted subset.

Should only RPC style be encoded?

Call it something other than RPC?

Will we support the body in text/xml encoding only, or also alternate x-www-url-encoded (forms encoding) syntax?

There are also three more Part 3 issues raised against Philippe's HTTP binding, which seem to be siblings of Issue 110. I summarize these in the enclosed mail.

1) Is it good practice to extract part of your content to parameterize your URI? If not, what is the best way?

2) Do we want to name the "restricted-to-simpleTypes RPC" style with a URI ala the RPC styls?

3) What if you start using fragids?

Addressed by Philippe's comprehensive proposal, adopted on March 25 2004.

[email].

This letter proposes three new features for WSDL 2.0 intended to make it much easier for users to directly interact with WSDL definitions. The first feature allows for the use of inclusion by value as an addition to WSDL 2.0's current standard mechanism of inclusion by reference. The second feature provides simplified elements that can be used to describe common WSDL scenarios. The third feature provides a simplified serialization for the WSDL 2.0 infoset that makes WSDLs easier to read and write.

No Action.

[email].

Arguably the most common protocol design style for application protocols is what this letter will refer to as the headerBody style. Protocols such as HTTP, SOAP, FTP, IMAP, ACAP, SMTP, etc. all use application messages that contain a single body and multiple headers.

Given the universal popularity of this design style this letter proposes that WSDL 2.0 add direct support for this style to WSDL 2.0.

Revised proposal, friendly amendment.

Proposal adopted as a feature (not required, built-in, or mandated by conformance.) Will go in Part 2.

[email].

I'm here proposing an alternate approach to indicating operation styles (not using the 'style' attribute).

Issue withdrawn after successfully resolving Issue 98.

Open issue on the name of wsoap:fault/@name and outfault/@name (should indicate that it is a reference, not defining a name)

Closed 5/21/2004 FTF. Obsolete, already fixed.

Is there something we can do to improve conformance on the wire between WSDL-based agents? This would prevent us from getting immediately profiled.

Added conformance section delineating processor and document conformance.

Change MEP labels from A and B to IN and OUT

Proposed resolution accepted.

Marking operations as 'safe'

Add optional Boolean "safe" attribute to interface operation, corresponding property in the component model.

[FTF minutes]

Rename @message to @element.

Accepted.

[FTF minutes]

Rename @messageReference to @label.

Accepted, along with editorial license to adjust names in the component model accordingly.

Operation name feature proposal.

Closed with no action.

[email]

Editors to add clarification text with regards to issue 121.

[email]

Intention expressed by Yaron is correct. Editors will add clarification.

[email] Might be reopening Issue 16.

Further clarify the spec to make clear that all operations must be bound.

[email]

Editors to clarify the spec to say that wsdl:required attribute means that a feature must be understood and it must be engaged.

[email]

No action. This topic has been discussed in depth by the WG before, and had to be resolved by going with the majority. There is no new information that would lead us to reconsider this issue, or to expect a different outcome this time.

[email]

No consensus to change. Closed with no action.

What is the required behavior if it is impossible to successfully import/include an identified document? If this an unrecoverable error that requires that the WSDL be rejected for processing? If so, then shouldn't the spec explicitly state this? [email]

It's ok to have bad imports but if during QName resolution you can't find something then it fails like any other qname resolution issue. Include will fail early (immediately).

In the case of import the specification doesn't actually define what happens if someone writes two imports for an identical namespace. Although some limited definition redundancy is supported by the spec the support would not appear to be robust enough to support importing the same WSDL definition twice. Therefore putting in two imports as a way to provide redundant locations would appear illegal.

But this begs the question - Is it illegal to specify two imports for the same namespace? If so, shouldn't this be explicitly stated in the spec? [email]

Add to spec to explicitly allow >2 imports from same ns.

Both WSDL import and include only allow for a single location to be specified. Given the unreliable nature of the Internet would it not be appropriate to allow for more than one location to be specified?

Given the permissive semantics of include it would be tempting to specify multiple includes, all pointing to the same file but at different locations as a way to make the WSDL definition more robust in the face of network failures. However this would needlessly waste system resources making unnecessary file requests. If the WSDL processor knows that a set of URIs are equivalent then it need only make requests until it finds a URI that works. [email]

Closed with no action.

[email]

Closed with no action.

[email]

Clarify that if an optional extension (i.e., an extension not marked as required) is not understood it MUST be ignored. Any not understood extension attributes MUST be ignored.

[email]

Message attribute must be optional so it can be omitted when a corresponding attribute for a different type system is in use instead. Factored out description of empty bodies into a new issue (150).

email]

This is by design. We note that issue 133 is a by-product of the removing <message> discussion. If you want to have alternate actual elements for a message reference (label) of a MEP then you have to define a wrapper element with a schema and use that. Alternatively DavidB suggested one could define two operations and achieve the same result (different input same output).

[email]

Closed with no action.

[email]

[email]

Proposal rejected, will pursue a stylistic solution insteead. Issue reclassified as Editorial. Editorial work rejected.

[email]

Accept the addition of the in-optional-out MEP to Part 2.

[email]

Changing the xs:anySimpleType in section 2.7.2.3 to xs:anyType, and appropriately reword the text in table 2-7.

Proposed resolution accepted.

[email]

[email]

Editors to add clarifications (sample text included in proposal) to the Core spec, clarifying that references from WSDL components to XML Schema components, and from WSDL components to WSDL components, operate consistently with XML Schema to XML Schema references - that is, an import statement is needed for each namespace used in such a reference.

The content model of wsdl:definitions is non-deterministic. I notice it has been this way since the substitution group based extensibility was removed on 2003-08-04. I note in passing that one of the reasons we went with substitution groups was that it gave us a deterministic content-model. [email]

The only fix I can see given the current grammer is to change the content model of wsdl:definitions to be <xs:any namespace='##any' minOccurs='0' maxOccurs='unbounded' />, which doesn't capture any of the contraints regarding wsdl:include, wsdl:import, wsdl:types, but there you go!

Adopted proposed resolution

[email]

See email for complete proposal.

No action.

[email]

TBD

Closed 5/21/2004 FTF. We don't say how an infoset must be serialized, only that it should match (validate against) the schema. SOAP canonicalization should handle this case.

[email]

TBD

Rename {message} property to {element}.

[email]

email

Adopted proposed resolution, as well as "properties and" in section 3.2. Reaffirmed our desire to provide guidance on how to support non-XML type systems.

[email]

TBD

No action, mooted by resolution of issue 143.

[email]

TBD

No action, mooted by resolution of issue 143.

[email]

element="" (no GED) means anything goes.

Proposal accepted (#empty changed to #none)

[email, email]

Closed 5/20/2004 FTF. http:inputSerialization and http:outputSerialization attributes will be added, per the proposal at http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0057.html.

[email]

Double-check that we have a URI-comparison algorithm in place for any URIs we need to compare. Double-check our use of relative URIs is reasonable and consistent.

Change all URIs EXCEPT import/@location and include/@location to absolute URIs at the XML document level.

[email]

[email Conflicts should be allowed with the required="true" taking precedence.

clarify that the strongest value wins.

[email], factored at 26 Feb 2004 telcon. There doesn't appear to be an explicit way (post-message removal) to describe a message with an empty body.

Proposal accepted (#empty changed to #none)

From minutes of 5 Mar 2004 FTF, there may be inconsistencies between attributes refering to other components. We should use a single strategy, e.g. @ref, or @{componentType}Ref.

[email]

Proposal accepted.

From 5 Mar 2004 FTF minutes: Are imports for the same namespace as the targetNamespace of the importing document allowed? If so, what does that mean?

No action: keep consistent with Schema, disallow imports of the targetNamepace.

[proposal] Should it be relative to the address of the service or to the [base URI] property of the location element information item?

@location will be relative to the address of the service.

[proposal] Do we want the "multipart/related" format?

Use XOP. Plan to revisit this after competing SOAP 1.2 HTTP binding XOP support.

XOP is SOAP-specific. Use case appears marginal. Close with no action.

[proposal] Doesn't list the Out patterns for the moment. Waiting to see how the dicussion on addressing is going to stabilize.

Plan to revisit this after competing SOAP 1.2 HTTP binding Output operations .

Closed at 5/21/2004 FTF. Add wording to say that our bindings only support the identified MEPs but others can be handled if appropriate rules are defined elsewhere.

[email]

Clarify that even though we identify operations and endpoints and other stuff by QName, they are not referencible by QName because those QNames are only unique within that component (within the interface or within the service).

[email]

Allow f&p markup within <wsdl:service>

Yes, allow f&p within service and endpoint, and in message references, fault references, and binding message references as well. Also see issue 228 roe remaining locations f&p could be allowed.

From issue 85, there remains an open question about facilities for setting HTTP headers within the HTTP binding.

Subsumed by adopting proposal for Issue 112.

@element="#any" means any single element, preventing the desctiption of messages with text, mixed content, or a sequence of elements. Are there compelling use cases for adding these capabilities? [email]

No new facilities. Add a note pointing out that our SOAP binding only allows a single element in the body.

Should we describe reasonable paths through document for the purpose of concretely defining processor conformance? Alternatively should we just rely on document conformance?

[email]

Accepted proposal.

HTTP/MIME allow wildcards for declaring accepted media-types. Should this specification also allow wildcards for acceptedMediaTypes and/or mediaType attribute values, such as "image/*"?. There is already an issue recorded for this problem by XMLP as stated in XMLP Issue 443.

wildcards (/*) are allowed. */* is not at this point (see issue 245).

Should other choices be allowed to represent media-type values? Even if allowed, should this specification utilize them?

Obsolete. IANA media types are sufficient.

We need a WSDL 2.0 published schema to refer to to fix the table"

http://www.w3.org/2004/03/wsdl

[email]. Should we describe the availability of chunking and other HTTP 1.1 options in the description so that clients don't have to undergo the performance hit (and apparent real-world interop problems) of runtime negotiation of HTTP features like chunking, and transfer-encoding?

Prasad suggests a space-separated list of supported HTTP options.

Closed 5/20/2004 FTF. Will support an http:transfer-coding attribute on bindings.

[email] "adding support to basic https options like basic/mutual authentication." Issue is whether to add description support for any authentication requirements a service may impose on a client. See also issue 56.

Closed 5/20/2004 FTF. Will add http:authenticationType and http:authenticationRealm to endpoint.

[email]

The serialization should be done the same way as out messages. Adding a column "Fault serialization" in Table 3-1 in section 3.1.1.1 of Part 3 whose value is application/xml in all cases should do the trick.

For the HTTP status code, I think that we have 3 options:

• not say anything: the requester agent should expect a fault from the provider agent, which could be received with any HTTP status code (200, 4xx, ...);
• have faults be returned with specific HTTP error codes: e.g., faults are returned with a 4xx or 5xx status code.
• offer it to be specified as a property of the HTTP binding with an attribute on the http:operation element.

I don't think that the latter is necessary. It would be good IMO to go with the second option with a SHOULD, i.e. recommend using a 4xx or 5xx status code when a fault is returned.

Provide an http:code attribute to specify the code on binding/fault. Ensure that for http:faultSerialization="application/xml" that the body of the fault response contains the XML specified in binding/fault/@ref.

[email] Pseudo-schema doesn't quite match the draft.

Part 1, Part 3, schema, and pseudo-schema all need to be synchronized about where f&p are allowed. See issue 157.

[email] Is the Operation being invoked indicated by the name of the wsdl:operation, or by the operation of the binding? Spec is unclear.

Unique GED requirement addresses this, commenter agrees he's unlikely to get more.

[email] David Orchard proposed an attribute-based syntax for Web Method, rather than the generic property syntax proposed by Hugo.

wsdl:interface/wsdl:operation/@webMethod (?)

Closed with no action

[email] David Orchard proposes a syntax. WG on 22 April 2004 discusses this as a shortcut syntax issue. [Precursor email from Mark Baker]

[email] I'd like to think of a way of using that web method/rest name in the binding. Strawman: the http:binding could have an attribute for re-using the webMethod, ie UseWebMethodAsHTTPOperations="true"...

Closed at 5/21/2004 FTF. Obsolete: webMethod has been removed.

Discussed the implications of XML 1.1 a the 29 April 2004 telcon, thought there might be a need to indicate which version of XML is used in XML messages.

[Marsh] For SOAP/HTTP binding, this is a non-issue (XMLP WG says it must be XML 1.0.) For XML bodies in HTTP messages, there might be other ways that parsing can fail (e.g. invalid, dependent on external resources, etc.) - why we should single out XML version?

Closed with no action: XML serialization is not constrained by WSDL.

[email]

Change:

      <wsoap:code>
        <wsoap:value>xs:QName</wsoap:value>
        <wsoap:subcode>
          <wsoap:value>xs:QName</wsoap:value>
          <wsoap:subcode>...</wsoap:subcode>
        </wsoap:subcode>?
      </wsoap:code>

to

      <wsoap:code value="xs:QName">
        <wsoap:subcode value="xs:QName">
          <wsoap:subcode>...</wsoap:subcode>
        </wsoap:subcode>?
      </wsoap:code>

This makes the syntax more consistent with the rest of the SOAP binding which is rather attribute-heavy.

Proposal accepted.

[email]

Closed 5/21/2004 FTF.

[email]

proposal accepted.

[email]

proposal accepted.

[email]

proposal accepted.

[email]

proposal, plus a note warning people that changes in Schema support for XML 1.1 might cause this to change prior to Recommendation.

Proposal adopted, with a note that "processing of documents encoded in XML 1.1 is not a conformance requirement".

[email]

Moved to CR comments list. 3/29/06

Spec review at FTF: PUT & DELETE decision not reflected in draft.

Added to EDTODO.

Spec review at FTF.

Resolved to use inside-out lexical scoping:nearest enclosing scope wins (as opposed to highest level of "required" as previously.

Spec review at FTF: text implies only SOAP HTTP protocol can be used.

Resolved to fix wording to make it clear other transports were possible (when they have been defined and given a URI.)

Spec review at FTF: defaultMEP and defaultWebMethod appear in the component model: is there semantics associated with using defaults instead of local attributes?

No difference - default* will be removed from the spec, XML mapping updated to propogate the defaults into the corresponding property.

[email]

will use wsoap: convention instead of wsoap12:.

[email]

Closed at 5/21/2004 FTF: Wording will be updated to ensure MTOM is not precluded.

Spec review at FTF.

Remove soap:header - use soap:module for this.

Spec review at FTF

Removed soap:header (Issue 185), placement of soap:module will not change.

Spec review at FTF:

Closed at 5/21/2004 FTF. Obsolete since webMethodDefault is removed in issue resolution of Issue 190.

Spec reveiw at FTF:

Closed at 5/21/2004 FTF.

Spec review at FTF:

email. Counterproposal at email.

Part 1 and 2b and counterproposal adopted. Part 2a and 3 rejected.

Spec review at FTF:

Closed at 5/21/2004 FTF.

Spec review at FTF:

Closed 5/20/2004 FTF. Will add a statement to the introduction of Part 2 along the lines of "if you are familiar with soap meps, wsdl meps are the same but a little bit more abstract". Will add a statement to Part 3 relating WSDL MEPs and the SOAP MEPs bound.

Spec review at FTF:

Accepted.

Spec review at FTF:

Resolved to allow soap:module at i/o, ops, and binding - module determines what the layers mean.

Spec review at FTF:

Closed 5/21/2004 FTF. Adopted Sanjiva's proposal for turning subelements into attributes, and Roberto's amendment to add @type to the binding to determine at the top level what the binding binds to.

[email]

Closed with no action.

Spec review at FTF

No change. We will keep modules at i/o level.

May 2004 FTF: Don't like the ability to override a required feature in the interface with a non-required one in the binding.

Add to primer a note saying essentially "Note that overriding in the binding features required at the interface can cause unexpected results."

[19 May FTF] Mismatch between value of media type attribute and pattern -- says nothing about the data.

Out of scope what to do when messages don't match the description. Close with no action.

[19 May FTF] Possible error conditions: mismatch between the media type attribute and the actual data.

Out of scope what to do when messages don't match the description. Close with no action.

[19 May FTF] Where should the annotation appear, on the type and/or the element?

Say in the spec that this annotation can appear on element declarations and complex type definitions, where these types are derived from base64binary.

[19 May FTF] Consider changing name from mediaType to contentType

Obsolete.

[19 May FTF] Would like more examples: e.g using a static type -- i'm always going to use an image/jpeg. What would that look like?

Accepted, editors to add more examples (valid and runnable) illustrating each significant feature.

[19 May FTF] Explain why this proposal is limited to base64encoded?

Added hexBinary as well. Rationale for contentType on hexBinary (and base64binary): content types can be applied to sequences of octets, therefore the XML Schema types whose value sets are sequences of octets can be annotated with content type.

[19 May FTF] Explain why */* AND absence means this is opaque application data (i.e. application/octet-stream.

Removed that sentence from the spec.

[19 May FTF] Pattern includes use of priority -- either explain relationship or get rid of it.

Obsolete. Closed with no action.

[19 May FTF] How do annotations show up in component model? (currently limited to a "binary information element")

Obsolete and duplicate.

[email] A service may want to indicate that it wants the HTTP Transmission Optimization Feature to be used, and that the content of a particular element (e.g. a large Base64-encoded image) must be optimized.

[email] One way we could approach this would be to have a xop:optimize element under binding, which references to the elements to be optimized:

<binding>
    ...
    <xop:optimize>
      <element ref="id_of_element1_to_be_optimized" hint="required" />
      <element ref="id_of_element2_to_be_optimized" hint="recommended" />
    </xop:optimize>
    ...
  </binding>

Solicit input on this from XMLP WG, perhaps any hints should be defined by them.

proposal accepted.

[email]

- 2.1.2: Is the pseudo-schema normative? Where are its vocabulary and rules explained?

- 2.2.1: "The interfaces a given interface extends MUST NOT themselves extend that interface either directly or indirectly." What does "that" refer to? (would be good to mention recursion).

- 2.2.2.3: There needs to be a description of, or references to, the properties here (e.g., {message references})

- 2.3.1: "execution of an operation of the interface." -> "execution of *any* operation of the interface." ?

- 2.3.1: "The reason... is because that" Poor English.

- 2.3.1: "If a non-XML type system is in use... then additional properties would need to be added..." Poor English.

- 2.3.1: "...to allow associating such.." Poor English.

- 2.3.1: "to allow associating such message types with the message reference" Shouldn't that be *fault* reference?

- 2.5.1: "A Message Reference component associates to a message exchanged in an operation an XML element declaration that specifies its message content." Tortured English.

- 2.5.1: "Message Reference components are identified by the role the message plays in the {message exchange pattern} that the operation is using. That is, a message exchange pattern defines a set /meof placeholder messages that participate in the pattern and assigns them unique names within the pattern." What does this mean? This passage is *very* confusing.

- 2.5.1: "element" is used often, but not defined; is this Element Information Item?

- 2.6.1: "A Fault Reference component associates a Fault component that defines the fault message type for a fault that occurs related to a message participating in an operation. Fault Reference components are identified by the role the related message plays in the {message exchange pattern} that the operation is using." What? Please have pity on your readers.

- 2.6.1: "The purpose of a Fault Reference component is to associate..." Bad English. Try: "A Fault Reference component's purpose is the association of..."

- 2.6.2.1: "The ref attribute information item refers to a fault component." Shouldn't this be "*interface* fault component."?

- 2.11.1: "Interface Operation components are local to Interface components; they cannot be referred to by QName, despite having both {name} and {target namespace} properties. That is, two Interface components sharing the same {target namespace} property but with different {name} properties MAY contain Interface Operation components which share the same {name} property. Thus, the {name} and {target namespace} properties of the Interface Operation components are not sufficient to form the unique identity of an Interface Operation component. To uniquely identify an Interface Operation component one must first identify the Interface component (by QName) and then identify the Interface Operation within that Interface component (by a further QName)." What is the effect of this statement upon bindings? It doesn't place any direct requirements on them.

- 2.13: Shouldn't 2.14 Endpoints come before this section?

- 2.13.1: "A Service component describes a set of endpoints (see 2.14 Endpoint) at which the single interface of the service is provided." Circular definition; confusing.

[Jonathan] Editors adopt as much as possible, come back to WG with any that require discussion.

Accepted.

[email] - A.1: The "fragment identifiers" section of the media type registration needs to list the mechanism described in C.2.

[Jonathan] accept.

Fix the link to point to App C, and associated clarifications to the text.

[email] - 2.15: "Two components of the same type are considered equivalent if, for each property, the value in the first component is the same as the value in the second component." Are simple values compared character-by-character? Is any schema information (e.g., defaulting, for canonicalisation) necessary? How are sets compared? Will this work for Properties (which have an associated value)?

email, plus amendment.

Proposals accepted, plus a reference to charmod for string eq.

[email] - 2.12.1: It seems wasteful to duplicate the interface message into the binding if there is no additional information therein. Can it be omitted with no effect in this case? I.e., the specified properties only serve to identify the message, not to affect the concrete representation of it; it should be explicitly stated that the absence of those properties has no effect on the interpretation of the description.

Accepted.

[email] - 2.11.2: "A REQUIRED ref attribute information item" - this requires all binding operations to refer to corresponding interface operations, despite earlier indications in 2.9.1 that bindings could be specified generically "across all operations of an interface." If that is true, how should one do so?

[Mark] I suggest that this requirement was dropped, and guidance given on specifying generic operations.

No action

[email] - 2.9.1: In many places in the spec, the semantics and constraints on component properties (e.g., optionality) are described in the Infoset mappings, rather than in the properties themselves. For clarity and applicability to other mappings, it would be better to place them at the component model level.

[Mark] I suggest expanding the content model of each component property in the property lists, and removing redundant syntactic constraints from the infoset mappings.

Also see email.

Accepted.

[email] - 2.8: The term "properties" is used throughout to denote a part of the component model; this section redefines it as something similar but different.

[Mark] Suggest using a distinguished term (perhaps "attributes"?).

No action

[email] - 2.4.4: "hence the rules which refer to the output element do not apply." Read literally, this has the (unintended?) effect of obviating the first rule.

Accepted.

[email] - 2.4.4: This section implies that you MUST define your messages in XML Schema to use RPC style; such a restriction is not necessary, as long as it is functionally equivalent.

[Mark] I suggest rewriting to the effect that other message definitions are allowed, as long as they are functionally equivalent.

Proposed resolution accepted, with a friendly amendment not to lose the MUST.

[email] - 2.4.2.3: The style attribute has a very loose semantic; it seems purpose-built for RPC, and therefore is effectively yet another extensibility mechanism. Also, it is readily imaginable for an operation to have more than one style; e.g., RPC as well as web:method="POST" semantics. Therefore, it needs to be able to carry multiple values; while this could be accommodated by making the value a list of URIs, I suggest it would be better to define this as an rpc-specific attribute with a boolean value (e.g., ext:rpc="1").

[Jonathan] See Issue 98 resolution. Close without action unless new information is presented (we've already considered and rejected using extension attributes instead of providing a common style attribute extensibility hook.

Not reopened, editors will check that multiple styles is on the edtodo list, along with anything else that might have been resolved at the same time.

[email] - 2.3.1: Why is it advantageous to define a fault at the Interface level, if it's just repeating information in the operations?

[Mark] I suggest either removing this functionality or better motivating it.

Concrete proposal.

Proposal accepted, including Mark's amendment, plus note that errors are an open set.

[email] - Table 2-2 (and elsewhere): What is an "actual value"? Does this imply that it is not the [normalized value]?

[Jonathan] Consistify our info-speak.

Determined that actual value is the correct term; we will include or import defn of "actual value" from XML Schema.

[email] - 2.2.1: What are the semantics of interface extension? E.g., how are duplicate operations in the set handled? This is mentioned in a few places, but not comprehensively documented.

Accepted.

[email] - 2.1.1: Why are QNames, rather than URIs, used to identify components? If there are good reasons for not using the primary identification mechanism in the Web, they should be documented here, along with caveats as to their use (e.g., if signing content, etc). If not, URIs should be used.

[Jonathan] Close with no action. QNames make WSDL internal references simpler. We provide a mapping to URIs for external use. We don't need to document the rationale of every design decision we've made in the spec.

Proposal withdrawn.

[email] - 2.1.1: "an unambiguous name for the intended semantics of the components." -> "an unambiguous name *space* for the intended semantics of the components." (the namespace isn't used as a name on its own, is it?)

[Jonathan] Accept above edit.

Change it from "an unambiguous name for the intended semantics of the components." to "an unambiguous name for the intended semantics of the *collection of * components."

[email] - 2.1.1: "imported/included" - There needs to be a reference to these processes. Also, the definition of how to arrive at a component model and how to interpret it are intertwined; while it makes sense to specify the semantics and mapping of individual components together, the separation of the import and exclude functionalities is awkward.

[Mark] I suggest that the import/include mechanism be documented along with the (expanded) definition of the component model, rather than after the use of that model. An explicit processing model could also be documented there, whereby one can deterministically convert an Infoset into a component model.

proposal accepted.

[email] - 2.1.1: The component model is not well-defined; no where is it said that components have properties, nor is are their aspects explained, and the {} notation's significance is not documented.

[Mark] I suggest adding a section detailing the principles and notation of the component model.

proposal accepted.

[email] - 2.1.1: "Type system components are element declarations drawn from some type system. They define the [local name], [namespace name], [children] and [attributes] properties of an element information item."

This effectively limits web services to an Infoset data model. However, in other places it the document indicated that other data models are allowed by WSDL; which is it? E.g., in 2.5.1: "If a non-XML type system is in use (as considered in 3.2 Using Other Schema Languages) then additional properties would need to be added to the Message Reference Component (along with extensibility attributes to its XML representation) to allow associating such message types with the message reference." What is the benefit of this approach, instead of just using a more neutral reference mechanism (i.e., "content" or "ref" instead of "element") to determine the type of a message?

To me, this is a base requirement for WSDL; a good proportion of the content on the Web is NOT most naturally expressed or modeled as an XML Infoset, and even WSDL itself has chosen to specify its data model in a layer above the Infoset (the "Component Model"). Why should the messages WSDL describes be confined to the Infoset, or prejudiced by XMLisms like "element"?

I suggest removing any language (such as that above) that requires messages to be modelled as Infosets, and changing attributes named "element" (and similar) to "content" or another, more neutral term. I do not believe that this is a large change, nor is it one that will impact existing implementations greatly, but it will provide great benefit to the Web.

[Jonathan] WG had previously agreed (informally?) that WSDL only describes XML Web services. Other type systems are limited to those that support XML elements. Status quo proposal: reconfirm that decision, and explain the limitations on extensible type systems in the spec.

Adopted Proposal 1 and 3, rejected proposal 2. Spec was deemed adequately clear already that <types> holds any type declarations, though {element declarations} holds only those declarations in an Infoset-based type system.

[email]

WG believes this can be resolved editorially.

Accepted.

[email] Part 1, 2.11: "A Binding Operation component describes a concrete binding of a particular operation of an interface to a particular concrete message format."

This doesn't hold; the binding operation isn't constrained to a single concrete message format, and also describes protocol details.

"The Binding Operation component describes the concrete message format(s) and protocol interaction(s) associated with a particular interface operation for a given endpoint."

Accepted.

[wg discussion relative to issues 157, 167.]

Definitions, Interface Fault, Binding Fault seem to be the only remaining candidates.

Add f&p to Interface Faults, Binding Faults, and Fault References.

[wg discussion relative to issue 169.]

[rationale, proposal.]

Closed with no action

[email] Part 2 refers to {label} properties, whereas part one uses {message label}; should these be the same?

Editorial: Use {message label} in Part 2.

[email] * The draft uses "patterns" and "WSDL patterns" often; suggest either normalising to "WSDL Message Exchange Patterns" or beginning the introduction with "Web Services Description Language (WSDL) message exchange patterns (hereafter, 'patterns')..."

Begin the introduction with "Web Services Description Language (WSDL) message exchange patterns (hereafter, 'patterns')..."

Accepted.

[email] * It might be advisable to differentiate the MEPs described here from the messages in underlying protocols (to use SOAP terminology); perhaps "Interface Message Exchange Patterns"? (I don't feel strongly about this, just a suggestion

Accepted.

[email] * Can the destination or occurrence of a Fault be overridden dynamically? E.g., can I specify a SOAP header that says "send any faults over there" or "keep that fault to yourself"?) If so, the mechanisms in section 2 should be couched as "Default Fault Generation Rules," or "Default Fault Transmission Rules", with appropriate explanatory text, if the previous suggestion is accepted.