- From: Jonathan Marsh <jonathanMarsh@dev.w3.org>
- Date: Tue, 03 Aug 2004 07:33:11 +0000
- To: public-ws-desc-eds@w3.org
Update of /sources/public/2002/ws/desc/issues
In directory hutz:/tmp/cvs-serv14543/issues
Modified Files:
wsd-issues.html wsd-issues.xml
Log Message:
8/2 FTF update
Index: wsd-issues.xml
===================================================================
RCS file: /sources/public/2002/ws/desc/issues/wsd-issues.xml,v
retrieving revision 1.107
retrieving revision 1.108
diff -C2 -d -r1.107 -r1.108
*** wsd-issues.xml 1 Aug 2004 16:47:11 -0000 1.107
--- wsd-issues.xml 3 Aug 2004 07:33:09 -0000 1.108
***************
*** 1 ****
! <?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='wsd-issues-html.xsl'?>
<!DOCTYPE issues SYSTEM "wsd-issues.dtd">
<issues update="$Date$">
<!--
<issue>
<issue-num>2@@</issue-num>
<title>@@@</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Active</status>
<originator>@@@</originator>
<responsible/>
<description>
<p>[<a href="@@@">email</a>]</p>
</description>
<proposal/>
<resolution/>
</issue>
-->
<issue>
<issue-num>251</issue-num>
<title>Schemas for SOAP and HTTP Binding</title>
<locus>Part 3</locus>
<requirement></requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>Asir</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0304.html">email</a>] The schema for SOAP Binding [1] is old and out of sync with Part 3. What is
the schemaLocation for the schema for HTTP Binding?</p>
</description>
<proposal/>
<resolution><p>Editors to update these schemas.</p></resolution>
</issue>
<issue>
<issue-num>250</issue-num>
<title>Properties within wsoap:module</title>
<locus>Part 3</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Asir</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0302.html">email</a>]</p>
</description>
<proposal/>
<resolution><p>Accepted.</p></resolution>
</issue>
<issue>
<issue-num>249</issue-num>
<title>HTTP binding mismatch and identification missing</title>
<locus>Part 3</locus>
<requirement></requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>Hugo</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0285.html">email</a>]</p>
</description>
<proposal/>
<resolution><p>Accepted.</p></resolution>
</issue>
<issue>
<issue-num>248</issue-num>
<title>Property component's dependency on XML Schema</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Roberto</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0283.html">email</a>]</p>
</description>
<proposal/>
<resolution><p>Proposed resolution adopted.</p></resolution>
</issue>
<issue>
<issue-num>246</issue-num>
<title>HTTP binding and interface operation MEP</title>
<locus>Part 3</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Hugo</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0279.html">email</a>]</p>
</description>
<proposal/>
<resolution><p>Proposed resolution adopted.</p></resolution>
</issue>
<issue>
<issue-num>245</issue-num>
<title>Define expectedMediaTypeItem to be RFC 2616 Accepts header</title>
<locus>Media Type Description</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Active</status>
<originator>Hugo</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0263.html">email</a>]</p>
</description>
<proposal/>
<resolution/>
</issue>
<issue>
<issue-num>244</issue-num>
<title>Decouple SOAP Version from SOAP Binding?</title>
<locus>SOAP 1.1</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Active</status>
<originator>Asir</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0250.html">email</a>]</p>
</description>
<proposal/>
<resolution/>
</issue>
<issue>
<issue-num>243</issue-num>
<title>Component reference vs. QName</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Asir</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0249.html">email</a>]</p>
</description>
<proposal/>
<resolution><p>Proposed resolution adopted.</p></resolution>
</issue>
<issue>
<issue-num>242</issue-num>
<title>Binding accepts header and output serialization </title>
<locus>Media type description</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Active</status>
<originator>Hugo</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0005.html">email</a>]</p>
</description>
<proposal/>
<resolution/>
</issue>
<issue>
<issue-num>241</issue-num>
<title>AD Feature: HTTP header conflicts</title>
<locus>Part 2</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Hugo</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0131.html">email</a>]</p>
</description>
<proposal/>
<resolution><p>Indicate error for AD HTTP binding in case of conflict.</p></resolution>
</issue>
<issue>
<issue-num>240</issue-num>
<title>input serialization flexibility</title>
<locus>Part 3</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>DaveO</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0073.html">email</a>]</p>
</description>
<proposal/>
<resolution><p>Accepted.</p></resolution>
</issue>
<issue>
<issue-num>239</issue-num>
<title>Part 1 Editorial Issues</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>Asir</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0110.html">email</a>]</p>
</description>
<proposal/>
<resolution><p>Accepted.</p></resolution>
</issue>
<issue>
<issue-num>238</issue-num>
<title>Consistent placement of <feature> and <property></title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>Sanjiva</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0267.html">email</a>]</p>
</description>
<proposal/>
<resolution><p>Accepted.</p></resolution>
</issue>
<issue>
<issue-num>237</issue-num>
<title>Editorial issues with Part 3</title>
<locus>Part 3</locus>
<requirement></requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>Hugo</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0011.html">email</a>]</p>
</description>
<proposal/>
<resolution><p>Move pseudo-schema up front.</p></resolution>
</issue>
<issue>
<issue-num>236</issue-num>
<title>MTOM/XOP support</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>Umit</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0038.html">email</a>]</p>
</description>
<proposal/>
<resolution><p>Accepted.</p></resolution>
</issue>
<issue>
<issue-num>235</issue-num>
<title>Definition of Fault</title>
<locus>Part 1/Part 2</locus>
<requirement></requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>MarkN</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0138.html">email</a>]
* A short, formal definition of what a Fault is, in WSDL terms, may be
useful (not necessarily in this document, but somewhere).</p>
</description>
<proposal>
<p>Add to part one text that relates fault syntax to the semantic of
application fault.</p>
</proposal>
<resolution><p>Proposal accepted.</p></resolution>
</issue>
<issue>
<issue-num>234</issue-num>
<title>Ruleset terminology</title>
<locus>Part 2</locus>
<requirement></requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>MarkN</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0138.html">email</a>]
* Section 2 uses "generation" in reference to Faults, which seems to have
a different meaning than in SOAP. When A SOAP Fault is generated, it is
not necessarily transmitted on the wire; here, the implication seems
to be that it is. Suggest using "Fault transmission," "Fault delivery,"
or "Fault destination" throughout instead. This would make the first
sentences in the section something like: "WSDL patterns specify the
destination and transmission of any Faults generated in a message
exchange using standard rules. The most common such rules are
defined here and referenced by patterns later in this document.
A Fault, regardless of the rule in effect, terminates the message
exchange it occurs in."</p>
</description>
<proposal>
<p>fault propagation rulset</p>
</proposal>
<resolution><p>Accepted.</p></resolution>
</issue>
<issue>
<issue-num>233</issue-num>
<title>Dynamically override Fault destination?</title>
<locus>Part 2</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>MarkN</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0138.html">email</a>]
* 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.</p>
</description>
<proposal/>
<resolution>
<p>Add informative note in part
2 could describing how various extensions may effect message
delivery including delivery of faults</p>
</resolution>
</issue>
<issue>
<issue-num>232</issue-num>
<title>Differentiate our MEPs from underlying protocol MEPs</title>
<locus>Part 2</locus>
<requirement></requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>MarkN</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0138.html">email</a>]
* 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</p>
</description>
<proposal/>
<resolution><p>Accepted.</p></resolution>
</issue>
<issue>
<issue-num>231</issue-num>
<title>Clarify "patterns"</title>
<locus>Part 2</locus>
<requirement></requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>MarkN</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0138.html">email</a>]
* 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')..."</p>
</description>
<proposal>
<p>Begin the introduction with "Web Services Description Language (WSDL) message
exchange patterns (hereafter, 'patterns')..."</p>
</proposal>
<resolution><p>Accepted.</p></resolution>
</issue>
<issue>
<issue-num>230</issue-num>
<title>{label} vs. {message label}</title>
<locus>Part 1/Part 2</locus>
<requirement></requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>MarkN</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0189.html">email</a>]
Part 2 refers to {label} properties, whereas part one uses {message label}; should these be the same?
</p>
</description>
<proposal/>
<resolution>
<p>Editorial: Use {message label} in Part 2.</p>
</resolution>
</issue>
<issue>
<issue-num>229</issue-num>
<title>useOperationWebMethod</title>
<locus>Part 3</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>WG</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0257.html">wg discussion</a> relative to issue 169.]</p>
</description>
<proposal>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0241.html">rationale</a>,
<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0053.html">proposal</a>.]</p>
</proposal>
<resolution><p>Closed with no action</p></resolution>
</issue>
<issue>
<issue-num>228</issue-num>
<title>Should f&p be allowed in more places?</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>WG</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0257.html">wg discussion</a> relative to issues 157, 167.]</p>
</description>
<proposal>
<p>Definitions, Interface Fault, Binding Fault seem to be the only remaining candidates.</p>
</proposal>
<resolution>
<p>Add f&p to Interface Faults, Binding Faults, and Fault References.</p>
</resolution>
</issue>
<issue>
<issue-num>227</issue-num>
<title>Description of Binding Operation component</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>MarkN</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0200.html
">email</a>] 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."</p>
<p>This doesn't hold; the binding operation isn't constrained to a single
concrete message format, and also describes protocol details.</p>
</description>
<proposal>
<p>"The Binding Operation component describes the concrete message
format(s) and protocol interaction(s) associated with a particular
interface operation for a given endpoint."</p>
</proposal>
<resolution><p>Accepted.</p></resolution>
</issue>
<issue>
<issue-num>226</issue-num>
<title>Cross-binding HTTP features</title>
<locus>Part 3</locus>
<requirement></requirement>
<priority>Editorial</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>Asir</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0080.html">email</a>]</p>
</description>
<proposal>
<p>WG believes this can be resolved editorially.</p>
</proposal>
<resolution><p>Accepted.</p></resolution>
</issue>
<issue>
<issue-num>225</issue-num>
<title>Non-XML type system extensibility.</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Mark Nottingham</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0060.html">email</a>]
- 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."</p>
<p>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?</p>
<p>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"?</p>
<p>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.</p>
</description>
<proposal>
<p>[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.</p>
</proposal>
<resolution>
<p>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.</p>
</resolution>
</issue>
<issue>
<issue-num>224</issue-num>
<title>Formalize component model</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Mark Nottingham</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0060.html">email</a>]
- 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. </p>
</description>
<proposal>
<p>[Mark] I suggest adding a section detailing the principles and notation
of the component model.</p>
</proposal>
<resolution>
<p><a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0085.html">proposal</a> accepted.</p>
</resolution>
</issue>
<issue>
<issue-num>223</issue-num>
<title>Import/include processing model</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Mark Nottingham</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0060.html">email</a>]
- 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. </p>
</description>
<proposal>
<p>[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.</p>
</proposal>
<resolution>
<p><a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0085.html">proposal</a> accepted.</p>
</resolution>
</issue>
<issue>
<issue-num>222</issue-num>
<title>Name[space] for the intended semantics</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>Mark Nottingham</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0060.html">email</a>]
- 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?)</p>
</description>
<proposal>
<p>[Jonathan] Accept above edit.</p>
</proposal>
<resolution>
<p>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."</p>
</resolution>
</issue>
<issue>
<issue-num>221</issue-num>
<title>Identify components by URI</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Mark Nottingham</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0060.html">email</a>]
- 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.</p>
</description>
<proposal>
<p>[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.</p>
</proposal>
<resolution>
<p>Proposal withdrawn.</p>
</resolution>
</issue>
<issue>
<issue-num>220</issue-num>
<title>Document interface extension semantics</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>Mark Nottingham</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0060.html">email</a>]
- 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.</p>
</description>
<proposal/>
<resolution><p>Accepted.</p></resolution>
</issue>
<issue>
<issue-num>219</issue-num>
<title>Actual value vs. normalized value</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Mark Nottingham</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0060.html">email</a>]
- Table 2-2 (and elsewhere): What is an "actual value"? Does this
imply that it is not the [normalized value]?</p>
</description>
<proposal>
<p>[Jonathan] Consistify our info-speak.</p>
</proposal>
<resolution>
<p>Determined that actual value is the correct term; we will
include or import defn of "actual value" from XML Schema.</p>
</resolution>
</issue>
<issue>
<issue-num>218</issue-num>
<title>Justify interface faults.</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Mark Nottingham</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0060.html">email</a>]
- 2.3.1: Why is it advantageous to define a fault at the Interface
level, if it's just repeating information in the operations? </p>
</description>
<proposal>
<p>[Mark] I suggest either removing this functionality or better motivating it.</p>
<p>Concrete <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0276.html">proposal</a>.</p>
</proposal>
<resolution>
<p>Proposal accepted, including Mark's amendment, plus note that
errors are an open set.</p>
</resolution>
</issue>
<issue>
<issue-num>217</issue-num>
<title>Syntax for multiple styles</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Mark Nottingham</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0060.html">email</a>]
- 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").</p>
</description>
<proposal>
<p>[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.</p>
</proposal>
<resolution>
<p>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.</p>
</resolution>
</issue>
<issue>
<issue-num>216</issue-num>
<title>RPC and XML Schema not orthogonal</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Mark Nottingham</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0060.html">email</a>]
- 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.</p>
</description>
<proposal>
<p>[Mark] I suggest rewriting to the effect that other message
definitions are allowed, as long as they are functionally equivalent.</p>
</proposal>
<resolution>
<p>Proposed resolution accepted, with a friendly amendment not to lose the MUST.</p>
</resolution>
</issue>
<issue>
<issue-num>215</issue-num>
<title>Clarify rule obviation</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>Mark Nottingham</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0060.html">email</a>]
- 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.</p>
</description>
<proposal/>
<resolution><p>Accepted.</p></resolution>
</issue>
<issue>
<issue-num>214</issue-num>
<title>Refine "properties" terminology</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Mark Nottingham</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0060.html">email</a>]
- 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. </p>
</description>
<proposal>
<p>[Mark] Suggest using a distinguished term (perhaps
"attributes"?).</p>
</proposal>
<resolution><p>No action</p></resolution>
</issue>
<issue>
<issue-num>213</issue-num>
<title>Refine component model property constraints</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>Mark Nottingham</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0060.html">email</a>]
- 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.</p>
</description>
<proposal>
<p>[Mark] I suggest expanding the content model of each component
property in the property lists, and removing redundant syntactic
constraints from the infoset mappings.</p>
<p>Also see <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0095.html">email</a>.</p>
</proposal>
<resolution><p>Accepted.</p></resolution>
</issue>
<issue>
<issue-num>212</issue-num>
<title>Explain using bindings across all operations</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Mark Nottingham</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0060.html">email</a>]
- 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? </p>
</description>
<proposal>
<p>[Mark] I suggest that this requirement was dropped, and
guidance given on specifying generic operations.</p>
</proposal>
<resolution><p>No action</p></resolution>
</issue>
<issue>
<issue-num>211</issue-num>
<title>Omit interface message in binding?</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>Mark Nottingham</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0060.html">email</a>]
- 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.</p>
</description>
<proposal/>
<resolution><p>Accepted.</p></resolution>
</issue>
<issue>
<issue-num>210</issue-num>
<title>Refine equivalence algorithm</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Mark Nottingham</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0060.html">email</a>]
- 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)?</p>
</description>
<proposal>
<p><a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0195.html">email</a>,
plus <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0199.html">amendment</a>.</p>
</proposal>
<resolution>
<p>Proposals accepted, plus a reference to charmod for string eq.</p>
</resolution>
</issue>
<issue>
<issue-num>209</issue-num>
<title>Reference frag ids from media type registration</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>Mark Nottingham</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0060.html">email</a>]
- A.1: The "fragment identifiers" section of the media type registration
needs to list the mechanism described in C.2.</p>
</description>
<proposal>
<p>[Jonathan] accept.</p>
</proposal>
<resolution>
<p>Fix the link to point to App C, and associated clarifications to the text.</p>
</resolution>
</issue>
<issue>
<issue-num>208</issue-num>
<title>Misc. editorial comments</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>Mark Nottingham</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0060.html">email</a>]</p>
<p>- 2.1.2: Is the pseudo-schema normative? Where are its vocabulary and
rules explained?</p>
<p>- 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).</p>
<p>- 2.2.2.3: There needs to be a description of, or references to, the
properties here (e.g., {message references})</p>
<p>- 2.3.1: "execution of an operation of the interface." -> "execution of
*any* operation of the interface." ?</p>
<p>- 2.3.1: "The reason... is because that" Poor English.</p>
<p>- 2.3.1: "If a non-XML type system is in use... then additional
properties would need to be added..." Poor English.</p>
<p>- 2.3.1: "...to allow associating such.." Poor English.</p>
<p>- 2.3.1: "to allow associating such message types with the message
reference" Shouldn't that be *fault* reference?</p>
<p>- 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.</p>
<p>- 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.</p>
<p>- 2.5.1: "element" is used often, but not defined; is this Element
Information Item?</p>
<p>- 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.</p>
<p>- 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..."</p>
<p>- 2.6.2.1: "The ref attribute information item refers to a fault
component." Shouldn't this be "*interface* fault component."?</p>
<p>- 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.</p>
<p>- 2.13: Shouldn't 2.14 Endpoints come before this section?</p>
<p>- 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.</p>
</description>
<proposal>
<p>[Jonathan] Editors adopt as much as possible, come back to WG with any that
require discussion.</p>
</proposal>
<resolution><p>Accepted.</p></resolution>
</issue>
<issue>
<issue-num>207</issue-num>
<title>How to mark which elements to optimize</title>
<locus>Part 3</locus>
<requirement></requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Hugo</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0089.html">email</a>]
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.</p>
</description>
<proposal><p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0007.html">email</a>]
One way we could approach this would be to have a xop:optimize element
under binding, which references to the elements to be optimized:</p>
<pre><![CDATA[<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>]]></pre>
<p>Solicit input on this from XMLP WG, perhaps any hints should be defined by them.</p></proposal>
<resolution>
<p><a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0139.html">proposal</a> accepted.</p>
</resolution>
</issue>
<issue>
<issue-num>206</issue-num>
<title>Annotations and schema component model.</title>
<locus>Media type description</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Active</status>
<originator>WG</originator>
<responsible/>
<description>
<p>[19 May FTF] How do annotations show up in component model? (currently
limited to a "binary information element")</p>
</description>
<proposal/>
<resolution/>
</issue>
<issue>
<issue-num>205</issue-num>
<title>Explain priority</title>
<locus>Media type description</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Active</status>
<originator>WG</originator>
<responsible/>
<description>
<p>[19 May FTF] Pattern includes use of priority -- either explain
relationship or get rid of it.</p>
</description>
<proposal/>
<resolution/>
</issue>
<issue>
<issue-num>204</issue-num>
<title>Why default to */* instead of to "no effect"?</title>
<locus>Media type description</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Active</status>
<originator>WG</originator>
<responsible/>
<description>
<p>[19 May FTF] Explain why */* AND absence means this is opaque
application data (i.e. application/octet-stream.</p>
</description>
<proposal/>
<resolution/>
</issue>
<issue>
<issue-num>203</issue-num>
<title>Limited to base64encoded?</title>
<locus>Media type description</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Active</status>
<originator>WG</originator>
<responsible/>
<description>
<p>[19 May FTF] Explain why this proposal is limited to base64encoded?</p>
</description>
<proposal/>
<resolution/>
</issue>
<issue>
<issue-num>202</issue-num>
<title>More examples</title>
<locus>Media type description</locus>
<requirement></requirement>
<priority>Editorial</priority>
<topic/>
<status>Active</status>
<originator>WG</originator>
<responsible/>
<description>
<p>[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?</p>
</description>
<proposal/>
<resolution/>
</issue>
<issue>
<issue-num>201</issue-num>
<title>Name of mediaType</title>
<locus>Media type description</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Active</status>
<originator>WG</originator>
<responsible/>
<description>
<p>[19 May FTF] Consider changing name from mediaType to contentType</p>
</description>
<proposal/>
<resolution/>
</issue>
<issue>
<issue-num>200</issue-num>
<title>Where should appInfo go?</title>
<locus>Media type description</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Active</status>
<originator>WG</originator>
<responsible/>
<description>
<p>[19 May FTF] Where should the annotation appear, on the type and/or the element?</p>
</description>
<proposal/>
<resolution/>
</issue>
<issue>
<issue-num>199</issue-num>
<title>mismatch between the media type attribute and the actual data</title>
<locus>Media type description</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Active</status>
<originator>WG</originator>
<responsible/>
<description>
<p>[19 May FTF] Possible error conditions: mismatch between the media type
attribute and the actual data.</p>
</description>
<proposal/>
<resolution/>
</issue>
<issue>
<issue-num>198</issue-num>
<title>mismatch between value of media type attribute and pattern</title>
<locus>Media type description</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Active</status>
<originator>WG</originator>
<responsible/>
<description>
<p>[19 May FTF] Mismatch between value of media type attribute and pattern -- says nothing about the data.</p>
</description>
<proposal/>
<resolution/>
</issue>
<issue>
<issue-num>197</issue-num>
<title>Don't override interface feature requiredness in binding</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Umit</originator>
<responsible/>
<description>
<p>May 2004 FTF: Don't like the ability to override a required feature in the interface with a non-required one in the binding.</p>
</description>
<proposal/>
<resolution>
<p>Add to primer a note saying essentially "Note
that overriding in the binding features required at the interface
can cause unexpected results."</p>
</resolution>
</issue>
<issue>
<issue-num>196</issue-num>
<title>Module operation at operation level versus input/output level</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Asir</originator>
<responsible/>
<description>
<p>Spec review at FTF</p>
</description>
<proposal/>
<resolution>
<p>No change. We will keep modules at i/o level.</p>
</resolution>
</issue>
<issue>
<issue-num>195</issue-num>
<title>Property value merging</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>DaveO</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0040.html">email</a>]</p>
</description>
<proposal/>
<resolution>
<p>Closed with no action.</p>
</resolution>
</issue>
<issue>
<issue-num>194</issue-num>
<title>Why interleave wsdl: and wsoap: namespaced elements?</title>
<locus>Part 1, Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Glen</originator>
<responsible/>
<description>
<p>Spec review at FTF:</p>
</description>
<proposal/>
<resolution>
<p>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.</p>
</resolution>
</issue>
<issue>
<issue-num>193</issue-num>
<title>Module declaration at different levels</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Youenn</originator>
<responsible/>
<description>
<p>Spec review at FTF: </p>
</description>
<proposal/>
<resolution>
<p>Resolved to allow soap:module at i/o, ops, and binding - module determines what the layers mean.</p>
</resolution>
</issue>
<issue>
<issue-num>192</issue-num>
<title>2.4.1, 2.5.1 "increasing specificity" -> "decreasing ..."</title>
<locus>Part 3</locus>
<requirement/>
<priority>Editorial</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Amy</originator>
<responsible/>
<description>
<p>Spec review at FTF:</p>
</description>
<proposal/>
<resolution>
<p>Accepted.</p>
</resolution>
</issue>
<issue>
<issue-num>191</issue-num>
<title>Relationship of SOAP MEPs and WSDL MEPs</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Hugo</originator>
<responsible/>
<description>
<p>Spec review at FTF: </p>
</description>
<proposal/>
<resolution>
<p>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.</p>
</resolution>
</issue>
<issue>
<issue-num>190</issue-num>
<title>Layering of SOAP webMethod on top of HTTP binding</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>DaveO</originator>
<responsible/>
<description>
<p>Spec review at FTF: </p>
</description>
<proposal/>
<resolution><p>Closed at 5/21/2004 FTF.</p></resolution>
</issue>
<issue>
<issue-num>189</issue-num>
<title>Binding message content to URI</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>DaveO</originator>
<responsible/>
<description>
<p>Spec review at FTF: </p>
</description>
<proposal>
<p><a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0276.html">email</a>.
Counterproposal at <a href=" http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0210.html">email</a>.</p>
</proposal>
<resolution>
<p>Part 1 and 2b and counterproposal adopted. Part 2a and 3 rejected.</p>
</resolution>
</issue>
<issue>
<issue-num>188</issue-num>
<title>wsoap:address vs. http:address?</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>DaveO</originator>
<responsible/>
<description>
<p>Spec reveiw at FTF: </p>
</description>
<proposal/>
<resolution><p>Closed at 5/21/2004 FTF.</p></resolution>
</issue>
<issue>
<issue-num>187</issue-num>
<title>Interaction between MEPdefault and webMethodDefault</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Youenn</originator>
<responsible/>
<description>
<p>Spec review at FTF: </p>
</description>
<proposal/>
<resolution><p>Closed at 5/21/2004 FTF. Obsolete since webMethodDefault is removed in issue resolution of Issue 190.</p></resolution>
</issue>
<issue>
<issue-num>186</issue-num>
<title>Interaction and placement of soap:header and soap:module</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Umit</originator>
<responsible/>
<description>
<p>Spec review at FTF</p>
</description>
<proposal/>
<resolution>
<p>Removed soap:header (Issue 185), placement of soap:module will not change.</p>
</resolution>
</issue>
<issue>
<issue-num>185</issue-num>
<title>Eliminate soap:header</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Sanjiva</originator>
<responsible/>
<description>
<p>Spec review at FTF.</p>
</description>
<proposal/>
<resolution>
<p>Remove soap:header - use soap:module for this.</p>
</resolution>
</issue>
<issue>
<issue-num>184</issue-num>
<title>MTOM serialization into SOAP body</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Ugo</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0055.html">email</a>]</p>
</description>
<proposal/>
<resolution><p>Closed at 5/21/2004 FTF: Wording will be updated to ensure MTOM is not precluded.</p></resolution>
</issue>
<issue>
<issue-num>183</issue-num>
<title>wsoap:prefix</title>
<locus>Part 3</locus>
<requirement/>
<priority>Editorial</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Sanjiva</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0042.html">email</a>]</p>
</description>
<proposal/>
<resolution>
<p>will use wsoap: convention instead of wsoap12:.</p>
</resolution>
</issue>
<issue>
<issue-num>182</issue-num>
<title>defaultMEP inheritance-syntax or model?</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Jonathan</originator>
<responsible/>
<description>
<p>Spec review at FTF: defaultMEP and defaultWebMethod appear in the component model: is there semantics associated with using defaults instead of local attributes?</p>
</description>
<proposal/>
<resolution>
<p>No difference - default* will be removed from the spec, XML mapping updated to propogate the defaults into the corresponding property.</p>
</resolution>
</issue>
<issue>
<issue-num>181</issue-num>
<title>Bind to other protocols</title>
<locus>Part 3</locus>
<requirement/>
<priority>Editorial</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>JJM</originator>
<responsible/>
<description>
<p>Spec review at FTF: text implies only SOAP HTTP protocol can be used.</p>
</description>
<proposal/>
<resolution>
<p>Resolved to fix wording to make it clear other transports were possible
(when they have been defined and given a URI.)</p>
</resolution>
</issue>
<issue>
<issue-num>180</issue-num>
<title>Inconsistent propogation of soap:module and features & properties</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Roberto</originator>
<responsible/>
<description>
<p>Spec review at FTF.</p>
</description>
<proposal/>
<resolution>
<p>Resolved to use inside-out lexical scoping:nearest enclosing scope wins (as opposed to highest level of "required" as previously.</p>
</resolution>
</issue>
<issue>
<issue-num>179</issue-num>
<title>PUT & DELETE need to be added</title>
<locus>Part 3</locus>
<requirement/>
<priority>Editorial</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Hugo</originator>
<responsible/>
<description>
<p>Spec review at FTF: PUT & DELETE decision not reflected in draft.</p>
</description>
<proposal/>
<resolution>
<p>Added to EDTODO.</p>
</resolution>
</issue>
<issue>
<issue-num>178</issue-num>
<title>Track operation safety</title>
<locus>Test suite</locus>
<requirement/>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Active</status>
<originator>TAG</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0028.html">email</a>]</p>
</description>
<proposal/>
<resolution/>
</issue>
<issue>
<issue-num>177</issue-num>
<title>Normative dependence on XML Schema 1.0 precludes XML 1.1</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>JJM</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0011.html
">email</a>]</p>
</description>
<proposal>
<p><a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0049.html">proposal</a>, plus
a note warning people that changes in Schema support for XML 1.1 might cause this to change prior
to Recommendation.</p>
</proposal>
<resolution>
<p>Proposal adopted, with a note that "processing of documents encoded
in XML 1.1 is not a conformance requirement".</p>
</resolution>
</issue>
<issue>
<issue-num>176</issue-num>
<title>Can a WSDL 2.0 XML 1.1 document contain (or reference), a XML Schema 1.0 type description? </title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>JJM</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0011.html">email</a>]</p>
</description>
<proposal/>
<resolution>
<p><a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0049.html">proposal</a> accepted.</p>
</resolution>
</issue>
<issue>
<issue-num>175</issue-num>
<title>Is it valid for a XML 1.1 document to import or include a XML 1.0 document (and vice versa)?</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Paul</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0012.html">email</a>]</p>
</description>
<proposal/>
<resolution>
<p><a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0049.html">proposal</a> accepted.</p>
</resolution>
</issue>
<issue>
<issue-num>174</issue-num>
<title>Tie WSDL conformance to XML conformance?</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Arthur</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0032.html">email</a>]</p>
</description>
<proposal/>
<resolution>
<p><a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0049.html">proposal</a> accepted.</p>
</resolution>
</issue>
<issue>
<issue-num>173</issue-num>
<title>Convert nested subcodes into a flat list (attribute)</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Paul</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0022.html">email</a>]</p>
</description>
<proposal/>
<resolution>
<p>Closed 5/21/2004 FTF.</p>
</resolution>
</issue>
<issue>
<issue-num>172</issue-num>
<title>Change wsoap:code/wsoap:value to an attribute</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Sanjiva</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0081.html">email</a>] </p>
</description>
<proposal>
<p>Change:</p>
<pre><![CDATA[ <wsoap:code>
<wsoap:value>xs:QName</wsoap:value>
<wsoap:subcode>
<wsoap:value>xs:QName</wsoap:value>
<wsoap:subcode>...</wsoap:subcode>
</wsoap:subcode>?
</wsoap:code>]]></pre>
<p>to</p>
<pre><![CDATA[
<wsoap:code value="xs:QName">
<wsoap:subcode value="xs:QName">
<wsoap:subcode>...</wsoap:subcode>
</wsoap:subcode>?
</wsoap:code>]]></pre>
<p>This makes the syntax more consistent with the rest of the
SOAP binding which is rather attribute-heavy.</p>
</proposal>
<resolution>
<p>Proposal accepted.</p>
</resolution>
</issue>
<issue>
<issue-num>171</issue-num>
<title>Indicate XML version for XML in SOAP and HTTP bindings?</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>WG</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal>
<p>[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?</p>
</proposal>
<resolution><p>Closed with no action: XML serialization is not constrained by WSDL.</p></resolution>
</issue>
<issue>
<issue-num>170</issue-num>
<title>Shortcut syntax for synchronizing webMethod and HTTP verb</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>David Orchard/Mark Baker</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0035.html">email</a>] David Orchard proposes a syntax. WG on 22 April 2004 discusses this as a shortcut syntax issue. [Precursor <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0007.html">email</a> from Mark Baker]</p>
</description>
<proposal>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0035.html">email</a>] 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"...</p>
</proposal>
<resolution><p>Closed at 5/21/2004 FTF. Obsolete: webMethod has been removed.</p></resolution>
</issue>
<issue>
<issue-num>169</issue-num>
<title>Syntax for webMethod - property or attribute?</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>David Orchard/Mark Baker/WSDL WG</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0053.html">email</a>] David Orchard proposed an attribute-based syntax for Web Method, rather than the generic <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0031.html">property syntax</a> proposed by Hugo.</p>
</description>
<proposal>
<p>wsdl:interface/wsdl:operation/@webMethod (?)</p>
</proposal>
<resolution><p>Closed with no action</p></resolution>
</issue>
<issue>
<issue-num>168</issue-num>
<title>Which operation</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Mark Baker</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0044.html">email</a>] Is the Operation being invoked indicated by the name of the wsdl:operation, or by the operation of the binding? Spec is unclear.</p>
</description>
<proposal/>
<resolution><p>Unique GED requirement addresses this, commenter agrees he's unlikely to get more.</p></resolution>
</issue>
<issue>
<issue-num>167</issue-num>
<title>Synchronize pseudo-schema</title>
<locus>Part 1</locus>
<requirement/>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>Hugo</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0047.html">email</a>] Pseudo-schema doesn't quite match the draft.</p>
</description>
<proposal/>
<resolution>
<p>Part 1, Part 3, schema, and pseudo-schema all need to be synchronized about where f&p are allowed. See issue 157.</p>
</resolution>
</issue>
<issue>
<issue-num>166</issue-num>
<title>Binding of Faults in HTTP Binding</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>Hugo</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0032.html">email</a>]</p>
</description>
<proposal>
<p>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.</p>
<p>For the HTTP status code, I think that we have 3 options:</p>
<ul>
<li>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, ...);</li>
<li>have faults be returned with specific HTTP error codes: e.g., faults
are returned with a 4xx or 5xx status code.</li>
<li>offer it to be specified as a property of the HTTP binding with an
attribute on the http:operation element.</li>
</ul>
<p>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.</p>
</proposal>
<resolution><p>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.</p></resolution>
</issue>
<issue>
<issue-num>165</issue-num>
<title>HTTPS support</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>Youenn</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0304.html">email</a>] "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 <a href="#x56">issue 56</a>.</p>
</description>
<proposal/>
<resolution>
<p>Closed 5/20/2004 FTF. Will add http:authenticationType and http:authenticationRealm to endpoint.</p>
</resolution>
</issue>
<issue>
<issue-num>164</issue-num>
<title>Support for HTTP chunking and other HTTP options</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>Youenn</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0303.html">email</a>]. 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?</p>
</description>
<proposal>
<p>Prasad suggests a space-separated list of supported HTTP options.</p>
</proposal>
<resolution>
<p>Closed 5/20/2004 FTF. Will support an http:transfer-coding attribute on bindings.</p>
</resolution>
</issue>
<issue>
<issue-num>163</issue-num>
<title>Publishing WSDL 2.0 schema</title>
<locus>Media type description</locus>
<requirement/>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>Media Type TF</originator>
<responsible/>
<description>
<p>We need a WSDL 2.0 published schema to refer to to fix the table"</p>
</description>
<proposal/>
<resolution>
<p>http://www.w3.org/2004/03/wsdl</p>
</resolution>
</issue>
<issue>
<issue-num>162</issue-num>
<title>Allowing other choices for mediaType values</title>
<locus>Media type description</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Active</status>
<originator>Media Type TF</originator>
<responsible/>
<description>
<p>Should other choices be allowed to represent media-type values? Even if allowed, should this specification utilize them?</p>
</description>
<proposal/>
<resolution/>
</issue>
<issue>
<issue-num>161</issue-num>
<title>Should media-type values allow wild cards</title>
<locus>Media type description</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Active</status>
<originator>Media Type TF</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal/>
<resolution/>
</issue>
<issue>
<issue-num>160</issue-num>
<title>Formalize processing model</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Jacek</originator>
<responsible/>
<description>
<p>Should we describe reasonable paths through document for the purpose of concretely defining processor conformance? Alternatively should we just rely on document conformance?</p>
</description>
<proposal>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0265.html">email</a>]</p>
</proposal>
<resolution>
<p>Accepted <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0206.html">proposal</a>.</p>
</resolution>
</issue>
<issue>
<issue-num>159</issue-num>
<title>Messages with mixed Body content or multiple element content</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>WG</originator>
<responsible/>
<description>
<p>@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? [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0247.html">email</a>]</p>
</description>
<proposal/>
<resolution>
<p>No new facilities. Add a note pointing out that our SOAP
binding only allows a single element in the body.</p>
</resolution>
</issue>
<issue>
<issue-num>158</issue-num>
<title>Setting HTTP headers in the HTTP binding</title>
<locus>Part 3</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>Philipe Le Hegaret
</originator>
<responsible/>
<description>
<p>From issue 85, there remains an open question about facilities for setting HTTP headers within the HTTP binding.</p>
</description>
<proposal/>
<resolution>
<p>Subsumed by adopting proposal for Issue 112.</p>
</resolution>
</issue>
<issue>
<issue-num>157</issue-num>
<title>f&p at the service level</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Glen</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0186.html">email</a>]</p>
</description>
<proposal>
<p>Allow f&p markup within <wsdl:service></p>
</proposal>
<resolution>
<p>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.</p>
</resolution>
</issue>
<issue>
<issue-num>156</issue-num>
<title>Endpoints and QNames</title>
<locus>Part 1</locus>
<requirement/>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>Ugo Corda</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0242.html">email</a>]</p>
</description>
<proposal>
</proposal>
<resolution>
<p>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).</p>
</resolution>
</issue>
<issue>
<issue-num>155</issue-num>
<title>Out patterns in HTTP binding</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>Philippe</originator>
<responsible/>
<description>
<p>[<a href="http://www.w3.org/2004/01/21-httpbinding.html">proposal</a>] Doesn't list the Out patterns for the moment. Waiting to see how the dicussion on addressing is going to stabilize.
</p>
</description>
<proposal>
<p>Plan to revisit this after competing SOAP 1.2 HTTP binding Output operations .</p>
</proposal>
<resolution><p>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.</p></resolution>
</issue>
<issue>
<issue-num>154</issue-num>
<title>Multi-part post in HTTP binding</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>Philippe</originator>
<responsible/>
<description>
<p>[<a href="http://www.w3.org/2004/01/21-httpbinding.html">proposal</a>] Do we want the "multipart/related" format? </p>
</description>
<proposal>
<p>Use XOP. Plan to revisit this after competing SOAP 1.2 HTTP binding XOP support.</p>
</proposal>
<resolution>
<p>XOP is SOAP-specific. Use case appears marginal. Close with no action.</p>
</resolution>
</issue>
<issue>
<issue-num>153</issue-num>
<title>Base URI for operation/@location in HTTP binding</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>Philippe</originator>
<responsible/>
<description>
<p>[<a href="http://www.w3.org/2004/01/21-httpbinding.html">proposal</a>] Should it be relative to the address of the service or to the [base URI] property of the location element information item? </p>
</description>
<proposal>
</proposal>
<resolution>
<p>@location will be relative to the address of the service.</p>
</resolution>
</issue>
<issue>
<issue-num>152</issue-num>
<title>Importing the targetNamespace</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Jacek</originator>
<responsible/>
<description>
<p>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?</p>
</description>
<proposal>
<p/>
</proposal>
<resolution>
<p>No action: keep consistent with Schema, disallow imports of the targetNamepace.</p>
</resolution>
</issue>
<issue>
<issue-num>151</issue-num>
<title>Reference attribute name consistency</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>WSD WG</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0067.html">email</a>]</p>
</proposal>
<resolution>
<p>Proposal accepted.</p>
</resolution>
</issue>
<issue>
<issue-num>150</issue-num>
<title>Indicating empty bodies</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>DaveO, WG</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0138.html">email</a>], 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.</p>
</description>
<proposal>
<p/>
</proposal>
<resolution>
<p>
<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0091.html">Proposal</a> accepted (#empty changed to #none)</p>
</resolution>
</issue>
<issue>
<issue-num>149</issue-num>
<title>Duplicate features with conflicting @required</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Jonathan Marsh</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0208.html">email</a>]</p>
</description>
<proposal>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0209.html">email</a> Conflicts should be allowed with the required="true" taking precedence.</p>
</proposal>
<resolution>
<p>clarify that the strongest value wins.</p>
</resolution>
</issue>
<issue>
<issue-num>148</issue-num>
<title>Double check URI comparison algorithm and relative URI use</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Jonathan Marsh</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0180.html">email</a>]</p>
</description>
<proposal>
<p>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.</p>
</proposal>
<resolution>
<p>Change all URIs EXCEPT import/@location and
include/@location to absolute URIs at the XML document
level.</p>
</resolution>
</issue>
<issue>
<issue-num>147</issue-num>
<title>HTTP binding uses static content-type header</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>Youenn</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0131.html">email</a>, <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0137.html">email</a>]</p>
</description>
<proposal/>
<resolution>
<p>Closed 5/20/2004 FTF. http:inputSerialization and http:outputSerialization attributes will be added, per the proposal at <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0057.html">http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0057.html</a>.</p>
</resolution>
</issue>
<issue>
<issue-num>146</issue-num>
<title>should WSDL be able to describe an operation with *anything* in the message?</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Jacek</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0110.html">email</a>]</p>
</description>
<proposal>
<p>element="" (no GED) means anything goes.</p>
</proposal>
<resolution>
<p>
<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0091.html">Proposal</a> accepted (#empty changed to #none)</p>
</resolution>
</issue>
<issue>
<issue-num>145</issue-num>
<title>How can you tell which type system is in use?</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Bijan Parsia</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0046.html">email</a>]</p>
</description>
<proposal>
<p>TBD</p>
</proposal>
<resolution>
<p>No action, mooted by resolution of issue 143.</p>
</resolution>
</issue>
<issue>
<issue-num>144</issue-num>
<title>Why can't message reference simpleTypes?</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Bijan Parsia</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0046.html">email</a>]</p>
</description>
<proposal>
<p>TBD</p>
</proposal>
<resolution>
<p>No action, mooted by resolution of issue 143.</p>
</resolution>
</issue>
<issue>
<issue-num>143</issue-num>
<title>Referencing other type systems</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Bijan Parsia</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0046.html">email</a>]</p>
</description>
<proposal>
<p>
<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0229.html">email</a>
</p>
</proposal>
<resolution>
<p>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.</p>
</resolution>
</issue>
<issue>
<issue-num>142</issue-num>
<title>Name of "message" property on Message|Fault Reference component</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Bijan Parsia</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0046.html">email</a>]</p>
</description>
<proposal>
<p>TBD</p>
</proposal>
<resolution>
<p>Rename {message} property to {element}.</p>
</resolution>
</issue>
<issue>
<issue-num>141</issue-num>
<title>Should WSDL say anything about whitespace in SOAP:Body?</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Jacek</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0083.html">email</a>]</p>
</description>
<proposal>
<p>TBD</p>
</proposal>
<resolution>
<p>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.</p>
</resolution>
</issue>
<issue>
<issue-num>140</issue-num>
<title>Version attribute proposal</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Tom Jordahl</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0049.html">email</a>]</p>
</description>
<proposal>
<p>See email for complete proposal.</p>
</proposal>
<resolution>
<p>No action.</p>
</resolution>
</issue>
<issue>
<issue-num>139</issue-num>
<title>Non-deterministic schema</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Martin Gudgin</originator>
<responsible/>
<description>
<p>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. [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0045.html">email</a>]</p>
</description>
<proposal>
<p>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! </p>
</proposal>
<resolution>
<p>Adopted proposed resolution</p>
</resolution>
</issue>
<issue>
<issue-num>138</issue-num>
<title>Second level xs:import</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>DaveO</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0137.html">email</a>]</p>
</description>
<proposal>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0022.html">email</a>]</p>
</proposal>
<resolution>
<p>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.</p>
</resolution>
</issue>
<issue>
<issue-num>137</issue-num>
<title>Properties should not be limited to simple types</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Glen</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0034.html">email</a>]</p>
</description>
<proposal>
<p>Changing the xs:anySimpleType in section 2.7.2.3 to xs:anyType, and
appropriately reword the text in table 2-7.</p>
</proposal>
<resolution>
<p>Proposed resolution accepted.</p>
</resolution>
</issue>
<issue>
<issue-num>136</issue-num>
<title>Add in-optional-out MEP</title>
<locus>Part 2</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Yaron</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0166.html">email</a>]</p>
</description>
<proposal>
<p/>
</proposal>
<resolution>
<p>Accept the addition of the in-optional-out MEP to Part 2.</p>
</resolution>
</issue>
<issue>
<issue-num>135</issue-num>
<title>WSDL Specification readability</title>
<locus>Part 1</locus>
<requirement/>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>DaveO</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0160.html">email</a>]</p>
</description>
<proposal>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0059.html">email</a>]</p>
</proposal>
<resolution>
<p>Proposal rejected, will pursue a stylistic solution insteead. Issue reclassified as Editorial.
Editorial work rejected.</p>
</resolution>
</issue>
<issue>
<issue-num>134</issue-num>
<title>Proposal for adding Compositors</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Umit, et al</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0153.html">email</a>]</p>
</description>
<proposal/>
<resolution>
<p>Closed with no action.</p>
</resolution>
</issue>
<issue>
<issue-num>133</issue-num>
<title>Why aren't two input/output elements allowed to share the same @element value?</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>DaveO</originator>
<responsible/>
<description>
<p>
<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0139.html">email</a>]</p>
</description>
<proposal>
<p/>
</proposal>
<resolution>
<p>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).</p>
</resolution>
</issue>
<issue>
<issue-num>132</issue-num>
<title>Message attribute optional</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>DaveO</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0138.html">email</a>]</p>
</description>
<proposal>
<p/>
</proposal>
<resolution>
<p>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).</p>
</resolution>
</issue>
<issue>
<issue-num>131</issue-num>
<title>Treatment of optional extensions</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>DaveO</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0136.html">email</a>]</p>
</description>
<proposal/>
<resolution>
<p>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.</p>
</resolution>
</issue>
<issue>
<issue-num>130</issue-num>
<title>Need async request/response HTTP binding</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>DaveO</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0135.html">email</a>]</p>
</description>
<proposal>
<p/>
</proposal>
<resolution><p>Closed with no action.</p></resolution>
</issue>
<issue>
<issue-num>129</issue-num>
<title>Allow multiple values for import/include locations</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Yaron</originator>
<responsible/>
<description>
<p>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?</p>
<p>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. [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0119.html">email</a>]</p>
</description>
<proposal/>
<resolution>
<p>Closed with no action.</p>
</resolution>
</issue>
<issue>
<issue-num>128</issue-num>
<title>Two imports for the same namespace illegal?</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Yaron</originator>
<responsible/>
<description>
<p>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.</p>
<p>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? [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0119.html">email</a>]</p>
</description>
<proposal>
<p/>
</proposal>
<resolution>
<p>Add to spec to explicitly allow >2 imports
from same ns.</p>
</resolution>
</issue>
<issue>
<issue-num>127</issue-num>
<title>Behavior if import/include fails</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Yaron</originator>
<responsible/>
<description>
<p>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? [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0119.html">email</a>]</p>
</description>
<proposal>
<p/>
</proposal>
<resolution>
<p>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).</p>
</resolution>
</issue>
<issue>
<issue-num>126</issue-num>
<title>Confusion between binding and element names</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Yaron</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0118.html">email</a>]</p>
</description>
<proposal/>
<resolution>
<p>No consensus to change. Closed with no action.</p>
</resolution>
</issue>
<issue>
<issue-num>125</issue-num>
<title>Make messageReference mandatory</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Yaron</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0117.html">email</a>]</p>
</description>
<proposal>
<p/>
</proposal>
<resolution>
<p>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.</p>
</resolution>
</issue>
<issue>
<issue-num>124</issue-num>
<title>Semantics of mandatory properties and features</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Yaron</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0116.html">email</a>]</p>
</description>
<proposal/>
<resolution>
<p>Editors to clarify the spec to say that wsdl:required
attribute means that a feature must be understood and
it must be engaged.</p>
</resolution>
</issue>
<issue>
<issue-num>123</issue-num>
<title>Requiring all operations to be bound</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Yaron</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0115.html">email</a>] Might be reopening Issue 16.</p>
</description>
<proposal/>
<resolution>
<p>Further clarify the spec to make clear that all operations must be bound.</p>
</resolution>
</issue>
<issue>
<issue-num>122</issue-num>
<title>messageReference semantics on binding</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Yaron</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0114.html">email</a>]</p>
</description>
<proposal>
<p/>
</proposal>
<resolution>
<p>Intention expressed by Yaron is correct. Editors will add clarification.</p>
</resolution>
</issue>
<issue>
<issue-num>121</issue-num>
<title>Broken resolution of NCNAME or QNAME</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Yaron</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0113.html">email</a>]</p>
</description>
<proposal>
<p/>
</proposal>
<resolution>
<p>Editors to add clarification text with regards to issue 121.</p>
</resolution>
</issue>
<issue>
<issue-num>120</issue-num>
<title>Operation name feature</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Umit</originator>
<responsible/>
<description>
<p>Operation name feature <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0082.html">proposal</a>.</p>
</description>
<proposal>
<p/>
</proposal>
<resolution>
<p>Closed with no action.</p>
</resolution>
</issue>
<issue>
<issue-num>119</issue-num>
<title>Renaming @messageReference</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Bijan at Jan 04 FTF</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0013.html">FTF minutes</a>]</p>
</description>
<proposal>
<p>Rename @messageReference to @label.</p>
</proposal>
<resolution>
<p>Accepted, along with editorial license to adjust names in the component model accordingly.</p>
</resolution>
</issue>
<issue>
<issue-num>118</issue-num>
<title>Renaming @message</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Bijan at Jan 04 FTF</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0013.html">FTF minutes</a>]</p>
</description>
<proposal>
<p>Rename @message to @element.</p>
</proposal>
<resolution>
<p>Accepted.</p>
</resolution>
</issue>
<issue>
<issue-num>117</issue-num>
<title>Marking operations as 'safe'
</title>
<locus>Part 1</locus>
<requirement>
</requirement>
<priority>Design
</priority>
<topic/>
<status>Closed</status>
<originator>TAG</originator>
<responsible/>
<description>
</description>
<proposal>
<p>Marking operations as 'safe' </p>
</proposal>
<resolution>
<p>Add optional Boolean "safe" attribute to
interface operation, corresponding property in the
component model.</p>
</resolution>
</issue>
<issue>
<issue-num>116</issue-num>
<title>Renaming the label of MEPs</title>
<locus>Part 2</locus>
<requirement>
</requirement>
<priority>Design
</priority>
<topic/>
<status>Closed</status>
<originator>Jonathan Marsh
</originator>
<responsible/>
<description>
</description>
<proposal>
<p>Change MEP labels from A and B to IN and OUT</p>
</proposal>
<resolution>
<p>Proposed resolution accepted.</p>
</resolution>
</issue>
<issue>
<issue-num>115</issue-num>
<title>Improving on-the-wire conformance</title>
<locus>Part 1</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Jonathan Marsh
</originator>
<responsible/>
<description>
<p>Is there something we can do to improve conformance on
the wire between WSDL-based agents? This would prevent
us from getting immediately profiled.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Added conformance section delineating processor and document conformance.</p>
</resolution>
</issue>
<issue>
<issue-num>114</issue-num>
<title>Name of wsoap:fault/@name
</title>
<locus>Part 3</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Jonathan Marsh
</originator>
<responsible/>
<description>
<p>Open issue on the name of wsoap:fault/@name and
outfault/@name (should indicate that it is a reference,
not defining a name)</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Closed 5/21/2004 FTF. Obsolete, already fixed.</p>
</resolution>
</issue>
<issue>
<issue-num>113</issue-num>
<title>Operation style
</title>
<locus>Part 1</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Jacek Kopecki
</originator>
<responsible/>
<description>
<p>
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0054.html">email</a>].
</p>
</description>
<proposal>
<p>I'm here proposing an alternate approach to
indicating operation styles (not using the 'style' attribute).</p>
</proposal>
<resolution>
<p>Issue withdrawn after successfully resolving Issue 98.</p>
</resolution>
</issue>
<issue>
<issue-num>112</issue-num>
<title>New headers/body style?
</title>
<locus>Part 1</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Yaron Goland
</originator>
<responsible/>
<description>
<p>
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0069.html">email</a>].
</p>
</description>
<proposal>
<p>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.</p>
<p>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.</p>
<p>
<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0167.html">Revised proposal</a>, <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0170.html">friendly amendment</a>.
</p>
</proposal>
<resolution>
<p><a href="">Proposal</a> adopted as a feature (not required, built-in, or mandated by conformance.) Will go in Part 2.</p>
</resolution>
</issue>
<issue>
<issue-num>111</issue-num>
<title>Simplified syntax?
</title>
<locus>Part 1</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Yaron Goland
</originator>
<responsible/>
<description>
</description>
<proposal>
<p>
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0071.html">email</a>].
</p>
<p>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.</p>
</proposal>
<resolution>
<p>No Action.</p>
</resolution>
</issue>
<issue>
<issue-num>110</issue-num>
<title>Full URLReplacement?</title>
<locus>Part 3</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>Philippe Le Hegaret
</originator>
<responsible/>
<description>
<p>
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0051.html">email</a>].
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0059.html">email</a>].
</p>
</description>
<proposal>
<p>Should we allow complete URL replacement (changes to
portions of the URL other than query parameters) or only query parameter
mechanism?</p>
<p>Question raised as to whether all possible schemas can be encoded in a
URL, or only a restricted subset.</p>
<p>Should only RPC style be encoded?</p>
<p>Call it something other than RPC?</p>
<p>Will we support the body in text/xml encoding only, or also alternate
x-www-url-encoded (forms encoding) syntax?</p>
<p>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.</p>
<p>1) Is it good practice to extract part of your content to parameterize
your URI? If not, what is the best way?</p>
<p>2) Do we want to name the "restricted-to-simpleTypes RPC" style with a
URI ala the RPC styls?</p>
<p>3) What if you start using fragids?</p>
</proposal>
<resolution>
<p>Addressed by Philippe's comprehensive proposal, adopted on March 25 2004.</p>
</resolution>
</issue>
<issue>
<issue-num>109</issue-num>
<title>WSDL versioning
</title>
<locus>Part 1</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Paul Downey
</originator>
<responsible/>
<description>
<p>
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0016.html">email</a>].
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0076.html">email</a>].
</p>
</description>
<proposal>
<p>In the Interface Description section of the charter there is the following:</p>
<p>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. </p>
<p>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.</p>
<p>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.</p>
<p>Has this issue been lost, or is our reading of the charter incorrect ?</p>
</proposal>
<resolution>
<p>Joint TF with Schema and WSDL to investigate whether best practices can be developed, which will be included in the Primer.</p>
</resolution>
</issue>
<issue>
<issue-num>108</issue-num>
<title>Properties and schema other than XSD
</title>
<locus>Part 1</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Roberto Chinnici
</originator>
<responsible/>
<description>
<p>
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0006.html">email</a>].
</p>
</description>
<proposal>
<p>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.</p>
</proposal>
<resolution>
<p>Accept proposal</p>
</resolution>
</issue>
<issue>
<issue-num>107</issue-num>
<title>Schema for vector, matrix, array
</title>
<locus>Primer</locus>
<requirement>
</requirement>
<priority>Editorial</priority>
<topic/>
<status>Active</status>
<originator>Paul Downey
</originator>
<responsible/>
<description>
<p>
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0048.html">email</a>].
</p>
</description>
<proposal>
<p>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.
</p>
<p>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. </p>
</proposal>
<resolution/>
</issue>
<issue>
<issue-num>106</issue-num>
<title>Using RDF in WSDL
</title>
<locus>RDF Mapping</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Active</status>
<originator>Jacek Kopecky
</originator>
<responsible/>
<description>
<p>
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003May/0076.html">email</a>].
</p>
<p>How can RDF statements (including OWL statements) be represented in WSDL?</p>
</description>
<proposal>
</proposal>
<resolution/>
</issue>
<issue>
<issue-num>105</issue-num>
<title>Abstract Faults
</title>
<locus>Part 1</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Paul Downey
</originator>
<responsible/>
<description>
<p>
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0046.html">email</a>].
</p>
</description>
<proposal>
<p>Proposal to hoist faults into the interface alongside operations.</p>
</proposal>
<resolution>
<p>Accept <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0064.html">Paul's proposal</a> 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.</p>
</resolution>
</issue>
<issue>
<issue-num>104</issue-num>
<title>Appendix E cleanup
</title>
<locus>Part 1</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Jacek Kopecky
</originator>
<responsible/>
<description>
<p>
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0136.html">email</a>].
</p>
</description>
<proposal>
<p>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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
</proposal>
<resolution>
<p>Issue factored into issues 143, 144, 145.</p>
</resolution>
</issue>
<issue>
<issue-num>103</issue-num>
<title>Proposal for combining the two attribute operation styles to one
</title>
<locus>Part 1</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Jacek Kopecky
</originator>
<responsible/>
<description>
<p>
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. [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0164.html">email</a>].
</p>
</description>
<proposal>
</proposal>
<resolution>Close issue 103 as irrelevant since styles are removed.</resolution>
</issue>
<issue>
<issue-num>102</issue-num>
<title>Schemas in imported WSDL
</title>
<locus>Part 1</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Allen Brookes
</originator>
<responsible/>
<description>
<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? [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0109.html">email</a>].
</p>
</description>
<proposal>
</proposal>
<resolution>Issue 102 closed with Glen's wording and with "root"
changed to "importing".</resolution>
</issue>
<issue>
<issue-num>101</issue-num>
<title>Support SOAP 1.2 transport binding framework
</title>
<locus>Part 3</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Jacek Kopecky
</originator>
<responsible/>
<description>
<p>
Issue <a href="#x23">23</a> 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 [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0014.html">email</a>].
</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Closed 5/21/2004 FTF. Already handled by @protocol and F&P.</p>
</resolution>
</issue>
<issue>
<issue-num>100</issue-num>
<title>Support SOAP 1.2 RPC</title>
<locus>Part 3</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Jacek Kopecky
</originator>
<responsible/>
<description>
<p>
Issue <a href="#x23">23</a> 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 [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0014.html">email</a>].
</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Closed 5/21/2004 FTF. Can't support without a SOAP data model
schema language (see issue 97).</p>
</resolution>
</issue>
<issue>
<issue-num>99</issue-num>
<title>Support SOAP 1.2 data model and encoding</title>
<locus>Part 3</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Jacek Kopecky
</originator>
<responsible/>
<description>
<p>
Issue <a href="#x23">23</a> 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 [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0014.html">email</a>].
(See related issue <a href="#x97">97</a>.)
</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Closed 5/21/2004 FTF. Resolved as duplicate of 97.</p>
</resolution>
</issue>
<issue>
<issue-num>98</issue-num>
<title> > 1 style per interface
</title>
<locus>Part 1, 3</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Jacek Kopecky
</originator>
<responsible/>
<description>
<p>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? </p>
</description>
<proposal>
</proposal>
<resolution>Make @style an unordered list of URIs</resolution>
</issue>
<issue>
<issue-num>97</issue-num>
<title>Schema language for SOAP encoding</title>
<locus>Part 3</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Jacek Kopecky
</originator>
<responsible/>
<description>
<p>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?</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Closed 5/21/2004 FTF. We will not do this new schema language
for soap data model.</p>
</resolution>
</issue>
<issue>
<issue-num>96</issue-num>
<title>Support for SOAP intermediaries
</title>
<locus>Part 3</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Jean-Jacques Moreau [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0331.html">email</a>]
</originator>
<responsible/>
<description>
<p>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?</p>
<p>[See also a followup message from Ugo Corda, pointing to additional
potential issues <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0004.html">email</a>]</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Closed 5/19/2004 FTF.</p>
</resolution>
</issue>
<issue>
<issue-num>95</issue-num>
<title>service/@name required?
</title>
<locus>Part 1</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>5 Nov 2003 f2f
</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal>
</proposal>
<resolution>@name optional for the standalone service type use. it
will be required inside the context of a wsdl document.
we may be able to describe in the schema as well as in
the spec but we should check for side effect. Close
issue 95.</resolution>
</issue>
<issue>
<issue-num>94</issue-num>
<title>Include cycles
</title>
<locus>Part 1</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Amy Lewis [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0056.html">email</a>]
</originator>
<responsible/>
<description>
<p>What happens if the same location is included twice or if
there are include cycles? The XMLSchema spec explicitly
permits them.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Per 18 Dec 2003 telecon, decided to make multiple
includes same as one. [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0019.html">email</a>].</p>
</resolution>
</issue>
<issue>
<issue-num>93</issue-num>
<title>Uniqueness across wsdl:definitions
</title>
<locus>Primer</locus>
<requirement>
</requirement>
<priority>Editorial</priority>
<topic/>
<status>Active</status>
<originator>Sanjiva Weerawarana
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0146.html">email</a>]
</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal>
<p>Per 2 Oct 2003 telecon, decided to include
recommended practice re: use of namespace across documents in
primer.</p>
</proposal>
<resolution/>
</issue>
<issue>
<issue-num>92</issue-num>
<title>Layering message patterns
</title>
<locus>Part 2</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>FABLET Youenn
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0176.html">email</a>]
</originator>
<responsible/>
<description>
<p>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</p>
</description>
<proposal/>
<resolution>
<p>Obsoleted by MEP work now completed.</p>
</resolution>
</issue>
<issue>
<issue-num>91</issue-num>
<title>MEP terminology
</title>
<locus>Part 1, 2, 3</locus>
<requirement>
</requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>David Booth
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0061.html">email</a>]
</originator>
<responsible/>
<description/>
<proposal/>
<resolution>Issue 91 is closed, editors will use the term "Message
Exchange Pattern" rather than "Message Pattern".</resolution>
</issue>
<issue>
<issue-num>90</issue-num>
<title>Use WSA terms?
</title>
<locus>Part 1, 2, 3</locus>
<requirement>
</requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>David Booth
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0068.html">email</a>]
</originator>
<responsible/>
<description/>
<proposal/>
<resolution>
<p>Accepted, editors to use WSA terms when possible.</p>
</resolution>
</issue>
<issue>
<issue-num>89</issue-num>
<title>Binding message references in component model
</title>
<locus>Part 1, 2, 3</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Roberto Chinnici
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0077.html">email</a>]
</originator>
<responsible/>
<description/>
<proposal/>
<resolution>Close issue 89 by changing the namespace of wsoap:fault
to wsdl:fault, and add a corresponding component in the
abstract model.</resolution>
</issue>
<issue>
<issue-num>88</issue-num>
<title>Rename wsdl:operation to wsdl:messageExchange?
</title>
<locus>Part 1, 3</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Savas Parastatidis
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0024.html">email</a>]
</originator>
<responsible/>
<description/>
<proposal/>
<resolution>
<p>Per 30 Oct 2003 teleconference, decided not to change the name
of this element.</p>
</resolution>
</issue>
<issue>
<issue-num>87</issue-num>
<title>Redundant direction information
</title>
<locus>Part 1, 2</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Raised at 10 Sep 2003 <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0045.html">e-mail</a>.
</originator>
<responsible/>
<description>
<p>Redundant direction information between children of
operation/{input, output} and direction information in MEP URI.</p>
</description>
<proposal/>
<resolution>Close issue #87 with no action.</resolution>
</issue>
<issue>
<issue-num>86</issue-num>
<title>New @soapActionURI?</title>
<locus>Part 3</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Raised at 4 Sep 2003 <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0018.html">teleconference</a>.
</originator>
<responsible/>
<description>
<p>Should we define a new binding element for @soapActionURI?</p>
</description>
<proposal/>
<resolution>
<p>Closed 5/21/2004 FTF. Obsolete - we already have added soapAction attribute.</p>
</resolution>
</issue>
<issue>
<issue-num>85</issue-num>
<title>HTTP binding depends on message/part</title>
<locus>Part 3</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>Philipe Le Hegaret
</originator>
<responsible/>
<description>
<p>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?</p>
</description>
<proposal/>
<resolution>
<p>URL replacement syntax incorported. New issue 158 openned to track HTTP headers portion of this issue.</p>
</resolution>
</issue>
<issue>
<issue-num>84</issue-num>
<title>SOAP header faults needed?</title>
<locus>Part 3</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Sanjiva Weerawana</originator>
<responsible/>
<description>
<p>Do we need to define SOAP header faults? Are they
currently in use? If so, are we defining them correctly?</p>
</description>
<proposal/>
<resolution>
<p>Closed 5/21/2004 FTF. Obsolete: SOAP header faults are already gone.</p>
</resolution>
</issue>
<issue>
<issue-num>83</issue-num>
<title>Interaction between binding extensions
</title>
<locus>Part 1, 3</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Glen Daniels
</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal/>
<resolution>Issue 83 is closed with no action.</resolution>
</issue>
<issue>
<issue-num>82</issue-num>
<title>Relax binding syntax
</title>
<locus>Part 1</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Glen Daniels
</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal/>
<resolution>given the changes to the syntax, we close issue 82 with no
action.</resolution>
</issue>
<issue>
<issue-num>81</issue-num>
<title>Account for interface inheritance
</title>
<locus>Part 1</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Philipe Le Hegaret
</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal>Duplicate of 76?</proposal>
<resolution>Issue 81 closed without action, no compelling
scenario and workaround exists.</resolution>
</issue>
<issue>
<issue-num>80</issue-num>
<title>Inappropriate binding component name
</title>
<locus>Part 1</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>David Booth
</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal/>
<resolution>Keep "binding", close issue 80 with no action.</resolution>
</issue>
<issue>
<issue-num>79</issue-num>
<title>How much validation?
</title>
<locus>Part 1, 2</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Umit Ulcinap
</originator>
<responsible/>
<description>
<p>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?</p>
</description>
<proposal/>
<resolution>
<p>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)</p>
</resolution>
</issue>
<issue>
<issue-num>78</issue-num>
<title>Implied value for interface/.*put
</title>
<locus>Part 1, 2</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Sanjiva Weerawana
</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal/>
<resolution>
<p>Per 4 Sep 2003 <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0018.html">teleconference</a>,
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.</p>
</resolution>
</issue>
<issue>
<issue-num>77</issue-num>
<title>[local name] for interface/.*put
</title>
<locus>Part 1, 2</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Sanjiva Weerawana
</originator>
<responsible/>
<description>
<p>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).</p>
</description>
<proposal/>
<resolution>
<p>Per 11 Sep 2003 telecon, decided to use 'messageReference'.</p>
</resolution>
</issue>
<issue>
<issue-num>76</issue-num>
<title>Pointing to derived interfaces</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>WG</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal/>
<resolution>Duplicate of issue 81</resolution>
</issue>
<issue>
<issue-num>75</issue-num>
<title>Incoherence between WSA and WSD MEPs</title>
<locus>Part 2</locus>
<requirement/>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>Someone @ XMLEurope2003</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal/>
<resolution>
<p>Issue is obsolete - Patterns and MEPs have converged</p>
</resolution>
</issue>
<issue>
<issue-num>74</issue-num>
<title>Clarify name for parts in SOAP binding</title>
<locus>Part 3</locus>
<requirement/>
<priority>Editorial</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Carl Binding</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/public-ws-desc-comments/2003Mar/0001.html">email</a>]
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?</p>
</description>
<proposal/>
<resolution>
<p>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.</p>
</resolution>
</issue>
<issue>
<issue-num>73</issue-num>
<title>Clarify Fault versus Body in SOAP binding</title>
<locus>Part 3</locus>
<requirement/>
<priority>Editorial</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Carl Binding</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/public-ws-desc-comments/2003Mar/0001.html">email</a>]
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.</p>
</description>
<proposal/>
<resolution>
<p>Closed 5/21/2004 FTF. Obsolete - text has been completely rewritten.</p>
</resolution>
</issue>
<issue>
<issue-num>72</issue-num>
<title>Describe XMLP attachments</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Jonathan Marsh</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal/>
<resolution>
<p>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.</p>
</resolution>
</issue>
<issue>
<issue-num>71</issue-num>
<title>Optional message content in http:urlReplacement</title>
<locus>Part 3</locus>
<requirement>R128</requirement>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>David Orchard</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal>
<p>The current HTTP binding now defines how only some
parts may map into the request URI and meets revised R128
wording. [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003May/0068.html">email</a>]</p>
</proposal>
<resolution>
<p>Accepted per 29 May 2003 teleconference.</p>
</resolution>
</issue>
<issue>
<issue-num>issue toplevel element name uniqueness</issue-num>
<title>Should all top-level elements' names be unique across the
target namespace?</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic>
</topic>
<status>Closed</status>
<originator>Eric Prud'hommeaux</originator>
<responsible/>
<description>
<p>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?</p>
</description>
<proposal>
</proposal>
<resolution>
<p> Resolved at November 2002 FTF. WSDL 1.2 will retain multiple
symbol spaces, one for each top level construct.</p>
</resolution>
</issue>
<issue>
<issue-num>issue transition documentation</issue-num>
<title>Do we need to provide user documentation describing the
transition between WSDL 1.1 and WSDL 1.2?</title>
<locus>Both</locus>
<requirement/>
<priority>Editorial</priority>
<topic>
</topic>
<status>Closed</status>
<originator>Jonathan Marsh</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p> Resolved to add a non-normative appendix detailing the changes
from 1.1 to 1.2</p>
</resolution>
</issue>
<issue>
<issue-num>issue add include</issue-num>
<title>Should we add an "include" mechanism?</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic>
</topic>
<status>Closed</status>
<originator>Sanjiva Weerawarana</originator>
<responsible/>
<description>
<p>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?</p>
</description>
<proposal/>
<resolution>
<p>No include will be added.</p>
<p>Issue re-opened. Discussed at November 2002 FTF. Resolved to
add a wsdl:include mechanism that works like xs:include sans
chameleon behaviour.</p>
</resolution>
</issue>
<issue>
<issue-num>issue clarify import</issue-num>
<title>Clarify semantics of import.</title>
<locus/>
<requirement/>
<priority>Editorial</priority>
<topic>
</topic>
<status>Closed</status>
<originator>Sanjiva Weerawarana</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>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.</p>
</resolution>
</issue>
<issue>
<issue-num>issue importing documents in same namespace</issue-num>
<title>Should imports of documents in the same namespace be
possible?</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic>
</topic>
<status>Closed</status>
<originator>Sanjiva Weerawarana</originator>
<responsible/>
<description>
<p>WSDL 1.1 allows imports to documents in the same
namespace. The constraint text:
</p>
<p>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. </p>
<p> in the spec disallows this</p>
</description>
<proposal>
</proposal>
<resolution>
<p> Resolved at November 2002 FTF that wsdl:import will work exactly
like xs:import.</p>
</resolution>
</issue>
<issue>
<issue-num>issue service type</issue-num>
<title>Should we have an abstract view of a service?</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic>
</topic>
<status>Closed</status>
<originator>Sanjiva Weerawarana</originator>
<responsible/>
<description>
<p>WSDL defines a service as a collection of ports, but there is no
abstract analog.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Introduced serviceTypes at June 2002 F2F. removed again at September
2002 FTF.</p>
</resolution>
</issue>
<issue>
<issue-num>issue multiple services</issue-num>
<title>Should a single WSDL file only define one service?</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic>
</topic>
<status>Closed</status>
<originator>Sanjiva Weerawarana</originator>
<responsible/>
<description>
<p>WSDL 1.1 supports having multiple services in a single WSDL
file. This has caused confusion amongst users.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Allow multiple services, where each MAY be of
a different service type. (At the June F2F.)</p>
</resolution>
</issue>
<issue>
<issue-num>issue implements attribute</issue-num>
<title>Should there be an implements attribute on 'service'</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic>
</topic>
<status>Closed</status>
<originator>Sanjiva Weerawarana</originator>
<responsible/>
<description>
<p>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?</p>
</description>
<proposal>
</proposal>
<resolution>
<p> resolved at November 2002 FTF NOT to add an implements attribute
to the service element</p>
</resolution>
</issue>
<issue>
<issue-num>issue fault name uniqueness</issue-num>
<title>Should faults be named with QNames?</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic>
</topic>
<status>Closed</status>
<originator>Sanjiva Weerawarana</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal>
</proposal>
<resolution>
Close issue-fault-name-uniqueness - works just like
operations (no change to spec).
</resolution>
</issue>
<issue>
<issue-num>issue allow nonxml typesystems</issue-num>
<title>Allow non-XML type systems?</title>
<locus>part 1</locus>
<requirement/>
<priority>Design</priority>
<topic>
</topic>
<status>Closed</status>
<originator>September 2002 Face-to-face</originator>
<responsible/>
<description>
<p>Do we want to allow WSDL 1.2 to use type systems which are NOT
XML based</p>
</description>
<proposal>
<p> non-XML type systems are allowed via extensibility attributes of
message/part elements.</p>
</proposal>
<resolution>Fixed.
</resolution>
</issue>
<issue>
<issue-num>issue operation patterns</issue-num>
<title>Should more operation patterns be supported?</title>
<locus>Part 1</locus>
<requirement/>
<priority/>
<topic>
</topic>
<status>Closed</status>
<originator>Prasad Yendluri</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>This issue is closed by leaving it to the realm of
orchestration languages and applications. June 11, 2002 (at
face-to-face).</p>
</resolution>
</issue>
<issue>
<issue-num>issue extensible message exchange patterns</issue-num>
<title>Should we have a mechanism to define extensible message
exchange patterns?</title>
<locus>part 1</locus>
<requirement/>
<priority/>
<topic>
</topic>
<status>Closed</status>
<originator>Glen Daniels</originator>
<responsible/>
<description>
<p>See http://lists.w3.org/Archives/Public/www-ws-desc/2002May/0271.html</p>
</description>
<proposal>
</proposal>
<resolution>
<p>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).</p>
<p>
Further discussion on this issue occured during the November 2002 FTF.
</p>
<p>
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 )
</p>
</resolution>
</issue>
<issue>
<issue-num>issue require type match for in out parameters</issue-num>
<title>For a part to be an in/out parameter, the type must
match.</title>
<locus>Part 1</locus>
<requirement/>
<priority/>
<topic>
</topic>
<status>Closed</status>
<originator>Jacek Kopecky</originator>
<responsible/>
<description>
<p>For a parameter to be considered in/out it must also be the case
that the parts be of exactly the same type.</p>
</description>
<proposal>
</proposal>
<resolution>
<p> Unknown. Issue is closed but no resolution is recorded. May be
related to removal of parameterOrder</p>
</resolution>
</issue>
<issue>
<issue-num>issue remove parameter order</issue-num>
<title>Should we remove parameter order?</title>
<locus>part 1</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>
</topic>
<status>Closed</status>
<originator>Sanjiva Weerawarana</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p> Resolved at September 2002 Face-to-face, Alex, VA to remove
paramterOrder attribute</p>
</resolution>
</issue>
<issue>
<issue-num>issue remove notification operations</issue-num>
<title>Should we remove notification operations?</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>
</topic>
<status>Closed</status>
<originator>Sanjiva Weerawarana</originator>
<responsible/>
<description>
<p>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.
</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Per the 20-22 Jan 2003 face to face meeting, there will be a one-way, output-only MEP.</p>
</resolution>
</issue>
<issue>
<issue-num>issue remove solicit response operations</issue-num>
<title>Should we remove solicit-response operations?</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic>
</topic>
<status>Closed</status>
<originator>Sanjiva Weerawarana</originator>
<responsible/>
<description>
<p>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.
</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Per the 20-22 Jan 2003 face to face meeting, there will be a output-input MEP.</p>
</resolution>
</issue>
<issue>
<issue-num>issue operation overloading</issue-num>
<title>Should operation overloading be disallowed?</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic>
</topic>
<status>Closed</status>
<originator>Joyce Yang</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Do not allow operation overloading. See minutes
for telecon on June 27, 2002 and follow-on email discussion.</p>
</resolution>
</issue>
<issue>
<issue-num>issue portType extensibility</issue-num>
<title>Should portTypes be extensible?</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic>
</topic>
<status>Closed</status>
<originator>Sanjiva Weerawarana</originator>
<responsible/>
<description>
<p>Some users have asked that portTypes be extensible. We need to
carefully consider whether that is a good thing or not.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Closed. port type extensibility added 20021010.</p>
</resolution>
</issue>
<issue>
<issue-num>issue operation name uniqueness</issue-num>
<title>Need to be able to distinguish between operations with the
same NCName in different portTypes</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic>
</topic>
<status>Closed</status>
<originator>Steve Tuecke</originator>
<responsible/>
<description>
<p>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</p>
</description>
<proposal>
<p> Proposal to make operations top-level constructs ( and hence named
by QName ) presented at November 2002 FTF</p>
</proposal>
<resolution>
<p> 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.</p>
</resolution>
</issue>
<issue>
<issue-num>issue clarify type and element</issue-num>
<title>Clarify use of type= and element= in part with XML Schema
experts.</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic>
</topic>
<status>Closed</status>
<originator>Keith Ballinger</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0030.html">email</a>]
</proposal>
<resolution>
<p>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'.</p>
</resolution>
</issue>
<issue>
<issue-num>issue message parts</issue-num>
<title>Should the message part mechanism be extended to support optional
parts etc.?</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic>
</topic>
<status>Closed</status>
<originator>Sanjiva Weerawarana</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>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.</p>
<p>Per 30 July 2003 meeting in Raleigh, NC, decided to
eliminate message construct and use XML Schema (or some
other type system) directly.</p>
</resolution>
</issue>
<issue>
<issue-num>issue eliminate message</issue-num>
<title> Can we eliminate <message> in favor of a schema mechanism?
</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>
</topic>
<status>Closed</status>
<originator>Keith Ballinger, Jeffrey Schlimmer, Others</originator>
<responsible/>
<description>
<p> 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.</p>
<p>
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 )
</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Original resolution: We will consider this for WSDL 2.0. For WSDL 1.2,
we will not remove the <message> construct.</p>
<p>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.
</p>
</resolution>
</issue>
<issue>
<issue-num>issue references with qname</issue-num>
<title> Should intra-namespace references using only localParts be supported?
</title>
<locus>Part 1</locus>
<requirement/>
<priority/>
<topic>
</topic>
<status>Closed</status>
<originator>Sanjiva Weerawarana</originator>
<responsible/>
<description>
<p> 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. </p>
</description>
<proposal>
</proposal>
<resolution>
<p> 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.</p>
</resolution>
</issue>
<issue>
<issue-num>issue remove optional name of definition</issue-num>
<title> Should we remove the optional name attribute of
<definitions>?
</title>
<locus>Part 1</locus>
<requirement/>
<priority/>
<topic>
</topic>
<status>Closed</status>
<originator>Sanjiva Weerawarana</originator>
<responsible/>
<description>
<p> 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. </p>
</description>
<proposal>
</proposal>
<resolution>
<p>Decided to remove during the July 18th telecon.</p>
</resolution>
</issue>
<issue>
<issue-num>issue require targetnamespace</issue-num>
<title>Require targetNamespace attribute?</title>
<locus>Part 1</locus>
<requirement/>
<priority/>
<topic/>
<status>Closed</status>
<originator>Sanjiva Weerawarana</originator>
<responsible/>
<description>
<p> 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. </p>
</description>
<proposal/>
<resolution>
<p> Accepted during telcon on June 27,
2002.</p>
</resolution>
</issue>
<issue>
<issue-num>70</issue-num>
<title>Confusing description between soap:body and soap:fault</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:jgreif@alumni.princeton.edu">Jeff Greif</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://lists.w3.org/Archives/Public/public-ws-desc-comments/2002Oct/0002.html">email</a>]
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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Remove example; rewrite in primer.</p>
</resolution>
</issue>
<issue>
<issue-num>69</issue-num>
<title>Confusing description between soap:body and soap:fault</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:pyendluri@webmethods.com">Prasad Yendluri</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Nov/0055.html">email</a>]
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".</p>
<p>Current spec for the soap:bind extensions stands as follows:</p>
<p><soap:header message="qname" part="nmtoken" use="literal|encoded"
encodingStyle="uri-list"? namespace="uri"?>*</p>
<p>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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>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. [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0014.html">email</a>]
</p>
</resolution>
</issue>
<issue>
<issue-num>68</issue-num>
<title>Confusing description between soap:body and soap:fault</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:MJones@NetSilicon.com">Matthew Jones</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/public-ws-desc-comments/2002Aug/0000.html">email</a>]
Section 2.5 talks about soap:binding, the first sentence is:</p>
<p>The soap:body element specifies how the message parts appear inside the
SOAP Fault element.</p>
<p>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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Closed 5/21/2004 FTF. Obsolete, parts are gone.</p>
</resolution>
</issue>
<issue>
<issue-num>67</issue-num>
<title>Invoking HTTP GET with no arguments</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:paul@prescod.net">Paul Prescod</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Jul/0107.html">email</a>]
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.</p>
</description>
<proposal>
<p>Make http:operation/@location optional.</p>
</proposal>
<resolution>
<p>Incorporated per [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003May/0053.html">Rennes Meeting</a>].</p>
</resolution>
</issue>
<issue>
<issue-num>66</issue-num>
<title>How to represent the equivalent of hypertext links?</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:rubys@apache.org">Sam Ruby</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Jul/0106.html">email</a>]
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Jul/0107.html">email</a>]
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:</p>
<p>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.</p>
<p>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/.</p>
<p>3) The resulting document contains an element of exactly the same shape
and form as in step (1), and the cycle continues.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>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.</p>
</resolution>
</issue>
<issue>
<issue-num>65</issue-num>
<title>WSDL binding for FTP?</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>FTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:distobj@acm.org">Naresh Agarwal</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Jul/0012.html">email</a>]
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:</p>
<p>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?
</p>
<p>2)"soapAction" <definitions>\<bindings>\<operation>\<soap:operation> will no more be used.</p>
<p>3) "location" attribute <definitions>\<service>\<port>\<soap:address> would be a FTP URL</p>
<p>Am i missing something? Do i need to make any other changes in the WSDL bindings?</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Per 11 Dec 2003 telecon, decided we won't be doing a
SOAP/FTP binding [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0014.html">email</a>].</p>
</resolution>
</issue>
<issue>
<issue-num>64</issue-num>
<title>Operations and HTTP verbs</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:distobj@acm.org">Mark Baker</a>
</originator>
<responsible>Unassigned</responsible>
<description>
[<a href="http://lists.w3.org/Archives/Public/public-ws-desc-comments/2002Jul/0000">email</a>]
<p>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.</p>
<p>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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Adopt Hugo's <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0031.html">proposal</a>; open syntax issues 169, 170.</p>
</resolution>
</issue>
<issue>
<issue-num>63</issue-num>
<title>SOAP binding violates separation of abstract definitions concrete bindings</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:pyendluri@webmethods.com">Prasad Yendluri</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Jun/0006.html">email</a>]
Section 2.3 (Messages) of WSDL spec permits defining parts of
a message using either "type" or "element" attribute:</p>
<pre><definitions .... > <message name="nmtoken"> * <part
name="nmtoken" element="qname"? type="qname"?/> *
</message> </definitions></pre>
<p>Section '2.3.2 Abstract vs. Concrete Messages' also states:</p>
<p>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.</p>
<p>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":</p>
<p>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.</p>
<p>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.</p>
<p>If use is literal, then each part references a concrete
schema definition using either the element or type attribute.</p>
<p>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.</p>
<p>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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>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.</p>
</resolution>
</issue>
<issue>
<issue-num>62</issue-num>
<title>Specify a specific SOAP fault code to be returned</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:jasnell@us.ibm.com">James Snell</a>
</originator>
<responsible>Unassigned</responsible>
<description>
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Jun/0048.html">email</a>]
<p>
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.</p>
<pre><operation name="doWapSheDangDang">
<soap:operation ... />
<input>...</input>
<output>...</output>
<fault name="fault-name">
<soap:fault name="fault-name" use="encoded" encodingStyle="..."
namespace="..." />
</fault>
</operation></pre>
<p>The soap:fault element "specifies the contents of the
contents of the SOAP Fault Details element", it says
absolutely nothing about the fault code.</p>
<p>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.</p>
<p>Just one possible way of addressing this... (I'm sure ya'll
could come up with a better one)</p>
<pre><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></pre>
</description>
<proposal>
</proposal>
<resolution>
<p>Closed 5/21/2004 FTF. Obsolete, ability to specify code/subcodes has already been added.</p>
</resolution>
</issue>
<issue>
<issue-num>61</issue-num>
<title>Additional SOAP binding for HTTP GET-in/SOAP-out</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:dorchard@bea.com">David Orchard</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-tag/2002Jun/0161.html">email</a>]
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.</p>
</description>
<proposal>
</proposal>
<resolution><p>Closed at 5/21/2004 FTF.</p></resolution>
</issue>
<issue>
<issue-num>60</issue-num>
<title>Inconsistency regarding optional parts</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Editorial</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:pyendluri@webmethods.com">Prasad Yendluri</a>
</originator>
<responsible>Unassigned</responsible>
<description>
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Jun/0011.html">email</a>]
<p>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:</p>
<p>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.</p>
<p>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.</p>
</description>
<proposal>
</proposal>
<resolution>Primer will contain new examples.
</resolution>
</issue>
<issue>
<issue-num>59</issue-num>
<title>MIME Binding permits 0 parts in multipart/related</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Editorial</priority>
<topic>MIME</topic>
<status>Closed</status>
<originator>
<a href="mailto:pyendluri@webmethods.com">Prasad Yendluri</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0081.html">email</a>]
A 4.4 MIME Binding Schema permits "zero" parts in multipart/related.</p>
<pre><element name="multipartRelated" type="mime:multipartRelatedType"/>
<complexType name="multipartRelatedType" content="elementOnly">
<element ref="mime:part" minOccurs="0" maxOccurs="unbounded"/>
</complexType></pre>
<p>This is not legal.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>MIME Binding outside the scope of our charter, closing issue with no action.</p>
</resolution>
</issue>
<issue>
<issue-num>58</issue-num>
<title>Permit "message" attribute in mime:content binding?</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>MIME</topic>
<status>Closed</status>
<originator>
<a href="mailto:pyendluri@webmethods.com">Prasad Yendluri</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0081.html">email</a>]
The <mime:content> is defined with a "part" and a "type" attribute spec.
E.g.</p>
<pre><output>
..
<mime:part>
<mime:content part="docs" type="text/html"/>
</mime:part>
</output>
</pre>
<p>
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"/></p>
</description>
<proposal>
</proposal>
<resolution>
<p>MIME Binding outside the scope of our charter, closing issue with no action.</p>
</resolution>
</issue>
<issue>
<issue-num>57</issue-num>
<title>Should Operations permit alternate and multiple responses?</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>
<a href="mailto:pyendluri@webmethods.com">Prasad Yendluri</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0081.html">email</a>]
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.</p>
</description>
<proposal>
</proposal>
<resolution>
<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Jun/0251.html">email</a>
</resolution>
</issue>
<issue>
<issue-num>56</issue-num>
<title>Define means to specify an authentication requirement</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:paul@prescod.net">Paul Prescod</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0123.html">email</a>]
need a way to specify an authentication requirement [in the HTTP binding]</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Closed 5/20/2004 FTF. See resolution of issue 165.</p>
</resolution>
</issue>
<issue>
<issue-num>55</issue-num>
<title>Define binding to HTTP headers</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:paul@prescod.net">Paul Prescod</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0123.html">email</a>]
need a way to set HTTP headers [in the HTTP binding]</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Closed 5/20/2004 FTF.</p>
</resolution>
</issue>
<issue>
<issue-num>54</issue-num>
<title>Allow binding to any HTTP method</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:paul@prescod.net">Paul Prescod</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0123.html">email</a>]
any HTTP method should be allowed [in the HTTP binding]</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Closed 5/20/2004 FTF. Extensibility in the HTTP method will be provided per the proposal at <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0057.html">http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0057.html</a>, with the amendment that the default media type will be x-www-url-encoded.</p>
</resolution>
</issue>
<issue>
<issue-num>53</issue-num>
<title>Allow operations within a binding to use different HTTP methods</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:paul@prescod.net">Paul Prescod</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0123.html">email</a>]
each operation in a binding should choose its own method, not one for all</p>
</description>
<proposal>
<p>Define http:operation/@verb.</p>
</proposal>
<resolution>
<p>Incorporated per [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003May/0053.html">Rennes Meeting</a>].</p>
</resolution>
</issue>
<issue>
<issue-num>52</issue-num>
<title>Allow operation addresses to be absolute</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:paul@prescod.net">Paul Prescod</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0123.html">email</a>]
operation addresses should not be required to be relative</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Closed 5/21/2004 FTF. Closed without action: Can be achieved by putting one operation
per interface and bind the interface to a uri.</p>
</resolution>
</issue>
<issue>
<issue-num>51</issue-num>
<title>Asymmetry between soap:body and soap:header</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:kevin.liu@sap.com">Kevin Liu</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Feb/0023.html">email</a>]
This issue can be viewed as an example our observation that
the binding extension specification is not clearly documented and
not sufficient.</p>
<p>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 ". </p>
<p>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 ". </p>
<p>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.</p>
<p>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> </p>
<p>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. </p>
<p>There is no explanation about:</p>
<p>* Why does soap:header need to have the "message" and "part"
attributes while soap:body can be bound to a particular
input/output message? </p>
<p> * 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?
</p>
<p>* 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?</p>
</description>
<proposal>
</proposal>
<resolution>Fixed.
</resolution>
</issue>
<issue>
<issue-num>50</issue-num>
<title>SOAP examples declare arrays using an obsolete schema syntax</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:kevin.liu@sap.com">Kevin Liu</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Feb/0023.html">email</a>]
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.</p>
<p>References:
Section 3.1 SOAP Examples (example 5)
Section 5.11 MIME Binding example (example 7)</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Removed example; rewrite in primer.</p>
</resolution>
</issue>
<issue>
<issue-num>49</issue-num>
<title>Inconsistency in "soap:header" specification</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Editorial</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:kevin.liu@sap.com">Kevin Liu</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Feb/0023.html">email</a>]
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</p>
<p>References:
Section 3.7 sopa:header and soap:headfault
A 4.2 SOAP Binding Schema</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Fixed.</p>
</resolution>
</issue>
<issue>
<issue-num>48</issue-num>
<title>"use" attribute of "soap:body" should be optional</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Editorial</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:kevin.liu@sap.com">Kevin Liu</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Feb/0023.html">email</a>]
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"</p>
<p>References:
Section 3.3 soap:binding
A 4.2 SOAP Binding Schema</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Resolved at the 22 Sep 2003 consistent with prior decision to
eliminate the use of SOAP encoding.</p>
</resolution>
</issue>
<issue>
<issue-num>47</issue-num>
<title>"soap:operation" should be optional</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Editorial</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:kevin.liu@sap.com">Kevin Liu</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Feb/0023.html">email</a>]
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."</p>
<p>However, in the SOAP Binding schema, no value is specified
for minOccur/maxOccur. It implies that this element is required.</p>
<p>References:
Section 3.4 soap:operation
A 4.2 SOAP Binding Schema</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Closed 5/21/2004 FTF. Schema is obsolete and will be completely rewritten.</p>
</resolution>
</issue>
<issue>
<issue-num>46</issue-num>
<title>"transport" attribute of "soap:binding" should be optional</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Editorial</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:kevin.liu@sap.com">Kevin Liu</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Feb/0023.html">email</a>]
[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"</p>
<p>References:
Section 3.3 soap:binding
A 4.2 SOAP Binding Schema</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Closed 5/21/2004 FTF. Schema is obsolete and will be completely rewritten.</p>
</resolution>
</issue>
<issue>
<issue-num>45</issue-num>
<title>"use" attribute of "fault" should be optional</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Editorial</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:kevin.liu@sap.com">Kevin Liu</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Feb/0023.html">email</a>]
Section 3.6 soap:fault grammar indicates that the use
attribute of fault is required while in the schema use is defined
as optional</p>
<p>References:
Section 3.6 soap:fault
A 4.2 SOAP Binding Schema</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Resolved at the 22 Sep 2003 consistent with prior decision to
eliminate the use of SOAP encoding.</p>
</resolution>
</issue>
<issue>
<issue-num>44</issue-num>
<title>"name" attribute of "soap:fault" is not defined in schema</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Editorial</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:kevin.liu@sap.com">Kevin Liu</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Feb/0023.html">email</a>]
Section 3.6 sopa:fault grammar indicates that fault
has a required name attribute while in the schema no such
attribute defined for faultType</p>
<p>References:
Section 3.6 soap:fault
A 4.2 SOAP Binding Schema</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Closed 5/21/2004 FTF. Schema is obsolete and will be completely rewritten.</p>
</resolution>
</issue>
<issue>
<issue-num>43</issue-num>
<title>Does order matter for the child elements of "definitions"?</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>
<a href="mailto:kevin.liu@sap.com">Kevin Liu</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Feb/0023.html">email</a>]
[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></p>
<p>References:
Section 3.1 SOAP Examples, example 3
Section 4.1 HTTP GET and POST Binding example 6
A 4.1 WSDL Schema</p>
</description>
<proposal>
</proposal>
<resolution>
<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Jun/0251.html">email</a>
</resolution>
</issue>
<issue>
<issue-num>42</issue-num>
<title>Shall "element" attribute of "part" only refer to elements defined in schema?</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>
<a href="mailto:kevin.liu@sap.com">Kevin Liu</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Feb/0023.html">email</a>]
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."</p>
<p>While in the section 3.1 example 4 and example 5, element is used as follow:</p>
<pre><message name="GetTradePriceInput">
<part name="tickerSymbol" element="xsd:string"/>
<part name="time" element="xsd:timeInstant"/>
</message></pre>
<p>References:
Section 2.3 Message
Section 3.1 SOAP Examples</p>
</description>
<proposal>
</proposal>
<resolution>
<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Jun/0251.html">email</a>
</resolution>
</issue>
<issue>
<issue-num>41</issue-num>
<title>Define encoding of attributes in a request URL</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:ryman@ca.ibm.com">Arthur Ryman</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0036.html">email</a>]
[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]</p>
<p>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:</p>
<p>employee=<name>John Doe</name><birthdate>1960-01-01</birthdate></p>
<p>Now suppose that PersonType had an attribute named sex.
[see email above for example]</p>
<p>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:</p>
<p>employee=[sex(male)]<name>John Doe</name><birthdate>1960-01-01</birthdate>
</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Per 13 Feb 2003 teleconference, leave HTTP request URLs segmented, flat,
and (somewhat) human readable.</p>
</resolution>
</issue>
<issue>
<issue-num>40</issue-num>
<title>The binding extension for SOAP is defined in terms of features that interact in a
complex way</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:ryman@ca.ibm.com">Arthur Ryman</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0036.html">email</a>]
The binding extension for SOAP depends on the following features:</p>
<p>* The message part XSD style, either type or element.</p>
<p>* The SOAP style, either RPC or Document.</p>
<p>* The encoding style, either literal or encoded.</p>
<p>* The direction of the message, either input or output.</p>
<p>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.</p>
<p>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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>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.</p>
</resolution>
</issue>
<issue>
<issue-num>39</issue-num>
<title>Binding Extensions Depend on the Structure of the portType</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>
<a href="mailto:ryman@ca.ibm.com">Arthur Ryman</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0036.html">email</a>]
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.</p>
<p>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]</p>
<p>Potential Solutions</p>
<p>* 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.</p>
<p>* 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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p> 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.</p>
</resolution>
</issue>
<issue>
<issue-num>38</issue-num>
<title>Clarify the what kinds of extensibility elements go where.</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>
<a href="mailto:sanjiva@watson.ibm.com">Sanjiva Weerawarana</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Member/w3c-ws-desc/2002Apr/0029.html">email</a>]
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. </p>
</description>
<proposal>
</proposal>
<resolution>
<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Jun/0251.html">email</a>
</resolution>
</issue>
<issue>
<issue-num>37</issue-num>
<title>Should we remove parameter order?</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>
<a href="mailto:sanjiva@watson.ibm.com">Sanjiva Weerawarana</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Member/w3c-ws-desc/2002Apr/0029.html">email</a>]
[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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>
<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Jun/0251.html">email</a>
</p>
</resolution>
</issue>
<issue>
<issue-num>36</issue-num>
<title>Should we remove notification operations?</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>
<a href="mailto:sanjiva@watson.ibm.com">Sanjiva Weerawarana</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://lists.w3.org/Archives/Member/w3c-ws-desc/2002Apr/0029.html">email</a>]
[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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>
<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Jun/0251.html">email</a>
</p>
</resolution>
</issue>
<issue>
<issue-num>35</issue-num>
<title>Should we remove solicit-response operations?</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>
<a href="mailto:sanjiva@watson.ibm.com">Sanjiva Weerawarana</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Member/w3c-ws-desc/2002Apr/0029.html">email</a>]
[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. </p>
</description>
<proposal>
</proposal>
<resolution>
<p>
<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Jun/0251.html">email</a>
</p>
</resolution>
</issue>
<issue>
<issue-num>34</issue-num>
<title>Should portTypes be extensible?</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>
<a href="mailto:sanjiva@watson.ibm.com">Sanjiva Weerawarana</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://lists.w3.org/Archives/Member/w3c-ws-desc/2002Apr/0029.html">email</a>]
Some users have asked that portTypes be extensibile.
We need to carefully consider whether that is a good thing or not. </p>
</description>
<proposal>
</proposal>
<resolution>
<p>
<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Jun/0251.html">email</a>
</p>
</resolution>
</issue>
<issue>
<issue-num>33</issue-num>
<title>Distinction between RPC style and document style</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>
<a href="mailto:waqar.sadiq@eds.com">Waqar Sadiq</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://lists.w3.org/Archives/Member/w3c-ws-desc/2002Apr/0022.html">email</a> and
<a href="http://lists.w3.org/Archives/Member/w3c-ws-desc/2002Apr/0011.html">email</a>]
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.</p>
<p>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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>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.</p>
</resolution>
</issue>
<issue>
<issue-num>32</issue-num>
<title>Will SOAP 1.1 still be supported?</title>
<locus>SOAP 1.1 Binding</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic/>
<status>Active</status>
<originator>
<a href="mailto:moreau@crf.canon.fr">Jean-Jacques Moreau</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0025.html">email</a>]
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?</p>
</description>
<proposal>
</proposal>
<resolution>
</resolution>
</issue>
<issue>
<issue-num>31</issue-num>
<title>'soap:address' insufficient to describe SOAP 1.2 endpoint</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:ruellan@crf.canon.fr">Herve Ruellan</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0024.html">email</a>]
_Background_
WSDL 1.1 uses the soap:address element to specify the destination of the
message.</p>
<p>_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.</p>
<p>_Proposed solution_
The target of a WSDL message should be defined in the soap:binding element.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Closed 5/21/2004 FTF.</p>
</resolution>
</issue>
<issue>
<issue-num>30</issue-num>
<title>soap:body encodingStyle</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:ruellan@crf.canon.fr">Herve Ruellan</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0024.html">email</a>]
[Child aspect already covered by issue 5]</p>
<p>_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).</p>
<p>_Issue_
WSDL 1.1 and SOAP 1.2 does not have the same use of the encodingStyle
attribute.</p>
<p>_Proposed solution_
Change the WSDL 1.1 use of the encodingStyle attribute.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>
<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Sep/0018.html">email</a>
Restrict the value of the encodingStyle attribute to be
either empty (for literal) or a single URI (for encodings like SOAP encoding).</p>
</resolution>
</issue>
<issue>
<issue-num>29</issue-num>
<title>How to specify the structure and ordering of 'soap:body' parts</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:ruellan@crf.canon.fr">Herve Ruellan</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0024.html">email</a>]
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).</p>
<p>_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.</p>
<p>_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...).</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Closed 5/21/2004 FTF. Obsolete - parts are gone.</p>
</resolution>
</issue>
<issue>
<issue-num>28</issue-num>
<title>'transport' cannot fully describe underlying SOAP 1.2 protocol binding</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:ruellan@crf.canon.fr">Herve Ruellan</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0024.html">email</a>]
_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.</p>
<p>_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.</p>
<p>_Proposed solution_
Use the soap:binding element to define which binding is used and </p>
</description>
<proposal>
</proposal>
<resolution>
<p>Closed 5/21/2004 FTF. Obsolete - already have provided the protocol attribute.</p>
</resolution>
</issue>
<issue>
<issue-num>27</issue-num>
<title>Remove 'style' attribute, which no longer works for SOAP 1.2</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:ruellan@crf.canon.fr">Herve Ruellan</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0024.html">email</a>]
_Background_
In SOAP 1.2, RPC is an extension of SOAP, that is a particular use of SOAP.</p>
<p>_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...</p>
<p>_Proposed solution_
Remove the style attribute and create a way for defining which SOAP
extensions are used (see below).</p>
</description>
<proposal>
</proposal>
<resolution>
<p>
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.</p>
</resolution>
</issue>
<issue>
<issue-num>26</issue-num>
<title>Replace transmission primitives by MEPs in operation</title>
<locus>Part 2</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>
<a href="mailto:ruellan@crf.canon.fr">Herve Ruellan</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0024.html">email</a>]
[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.
</p>
<p>
_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).
</p>
<p>
_Proposed solution_
As MEP are almost independant of SOAP 1.2, I would suggest replacing
transmission primitives by MEP.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Per 11 Dec 2003 telecon, decided to close given
Part 2 of the spec
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0014.html">email</a>].</p>
</resolution>
</issue>
<issue>
<issue-num>25</issue-num>
<title>Unclear relationship between XML Schema and SOAP data model</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>
<a href="mailto:jacek@idoox.com">Jacek Kopecky</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0020.html">email</a>]
[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.</p>
<p>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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Removed @use.
@encodingStyle is a hint about how types/schema was generated.</p>
</resolution>
</issue>
<issue>
<issue-num>24</issue-num>
<title>Real difference between literal vs. encoded?</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>
<a href="mailto:waqar.sadiq@eds.com">Waqar Sadiq</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Member/w3c-ws-desc/2002Apr/0011.html">email</a>]
[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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p> 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.</p>
<p>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 <a href="#x97">97</a>.)</p>
</resolution>
</issue>
<issue>
<issue-num>23</issue-num>
<title>Request to support SOAP 1.2</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:moreau@crf.canon.fr">Jean-Jacques Moreau</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0018.html">email</a>]
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?</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Per 11 Dec 2003 telecon, decided to split this
into separate issues. See new issues <a href="#x99">99</a>, <a href="#x100">100</a>, and <a href="#x101">101</a>.
</p>
</resolution>
</issue>
<issue>
<issue-num>22</issue-num>
<title>Specification not XML Infoset based</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>
<a href="mailto:moreau@crf.canon.fr">Jean-Jacques Moreau</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0017.html">email</a>]
Currently, the specification is not XML Infoset based.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Fixed.</p>
</resolution>
</issue>
<issue>
<issue-num>21</issue-num>
<title>Examples use <import> elements inconsistenly</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>
<a href="mailto:moreau@crf.canon.fr">Jean-Jacques Moreau</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0016.html">email</a>]
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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Remove example; rewrite in primer.</p>
</resolution>
</issue>
<issue>
<issue-num>20</issue-num>
<title>Inconsistency in definition of 'soap:header' (contains 'part' or 'parts'?)</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Editorial</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:davec@progress.com">David Cleary</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0012.html">email</a>]
[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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Header now points directly to Schema.</p>
</resolution>
</issue>
<issue>
<issue-num>19</issue-num>
<title>Inconsistency on optionality of 'soap:headerfault'</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Editorial</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:davec@progress.com">David Cleary</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0012.html">email</a>]
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/.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Closed 5/21/2004 FTF. Schema is obsolete and will be completely rewritten.</p>
</resolution>
</issue>
<issue>
<issue-num>18</issue-num>
<title>Default for transport of <soap:binding></title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:gisle@activestate.com">Gisle Aas</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://groups.yahoo.com/group/wsdl/message/582?threaded=1">email</a>]
[see also issue 46]
The _transport_ attribute of <soap:binding> is optional, but it is
not clear to me what the default is.</p>
<p>
Is "http://schemas.xmlsoap.org/soap/http" the default?</p>
<p>If so, shouldn't the schema in section A-4.1 declare this value as
the default?</p>
</description>
<proposal>
</proposal>
<resolution>
<p>soap:transport is mandatory</p>
</resolution>
</issue>
<issue>
<issue-num>17</issue-num>
<title>nowhere to specify actor URI in WSDL ?</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:simon@zaks.demon.co.uk">Simon Fell</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://groups.yahoo.com/group/wsdl/message/638?threaded=1">email</a>]
[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 ?</p>
</description>
<proposal>
<p>
<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Jun/0190.html">email</a>
</p>
</proposal>
<resolution>
<p> As described in proposal above, with minor amendments from Gudge and Jonathan.</p>
</resolution>
</issue>
<issue>
<issue-num>16</issue-num>
<title>Does a binding have to specify all the operations in a portType?</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>
<a href="mailto:simon@zaks.demon.co.uk">Simon Fell</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://groups.yahoo.com/group/wsdl/message/733?threaded=1">email</a>]
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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Fixed.</p>
</resolution>
</issue>
<issue>
<issue-num>15</issue-num>
<title>Missing <document> tag for operation arguments</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>
<a href=" mailto:graham-glass@mindspring.com">Graham Glass</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://lists.w3.org/Archives/Public/xml-dist-app/2001Jun/0197.html">email</a>]
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.</p>
</description>
<proposal>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0031.html">email</a>]
</proposal>
<resolution>
<p>Per 18 Dec 03 telecon, noted that we now allow
documentation everywhere.</p>
</resolution>
</issue>
<issue>
<issue-num>14</issue-num>
<title>Request to support SOAP features</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:gdaniels@macromedia.com">Glen Daniels</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Mar/0091.html">email</a>]
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.</p>
<p>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.</p>
<p>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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Per 11 Dec 2003 telecon, noted that features and
properties are currently included in the draft [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0014.html">email</a>].</p>
</resolution>
</issue>
<issue>
<issue-num>13</issue-num>
<title>Parameter Order missing from schema</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>
<a href="mailto:jacek@idoox.com">Jacek Kopecky</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://groups.yahoo.com/group/wsdl/message/589">email</a>]
This is an editorial issue for WSDL 1.1 - the schema doesn't
declare the parameterOrder attribute.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Removed @parameterOrder.</p>
</resolution>
</issue>
<issue>
<issue-num>12</issue-num>
<title>Bug in schema for "part" attribute</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>
<a href="mailto:gisle@activestate.com">Gisle Aas</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://groups.yahoo.com/group/wsdl/message/563">email</a>]
[see also issue 20]</p>
<p>
According to the schema in section A-4.1 the 'name' attribute of
<part> is optional.</p>
<p>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".</p>
<p>I believe the schema is wrong and that the definition of "partType"
should be changed to:</p>
<pre><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></pre>
</description>
<proposal>
</proposal>
<resolution>
<p>Per 30 July 2003 meeting in Raleigh, NC, decided
to remove message and message/part construct.</p>
</resolution>
</issue>
<issue>
<issue-num>11</issue-num>
<title>Bug in grammar for <import></title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>
<a href="mailto:gisle@activestate.com">Giles Aas</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="">email</a>]
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:</p>
<pre>
<wsdl:import namespace="uri" location="uri"> *
<wsdl:documentation .... />?
</wsdl:import></pre>
<p>In WSDL 1.1 (2001-03-15) it simply says.</p>
<pre><import namespace="uri" location="uri"/>*</pre>
<p>The namespace qualifier for <import> is also missing in the current
text.</p>
</description>
<proposal>
</proposal>
<resolution>Obsolete pseudo grammar.
</resolution>
</issue>
<issue>
<issue-num>10</issue-num>
<title>Example 3 element order bug</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>
<a href="mailto:gisle@activestate.com">Gisle Aas</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://groups.yahoo.com/group/wsdl/message/560">email</a>]
[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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Removed example; rewrite in primer.</p>
</resolution>
</issue>
<issue>
<issue-num>9</issue-num>
<title>Example misses "Soap"</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Editorial</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:gisle@activestate.com">Gisle Aas</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://groups.yahoo.com/group/wsdl/message/557">email</a>]
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:</p>
<pre>tns:StockQuoteSoapBinding</pre>
<p>
The example is missing "Soap" in there.</p>
<p>
<a href="mailto:simon@zaks.demon.co.uk">Simon Fell</a> also notes that examples 2,4 and 5 have the same problem.</p>
</description>
<proposal>
</proposal>
<resolution>Removed example; rewrite in primer.
</resolution>
</issue>
<issue>
<issue-num>8</issue-num>
<title>Inconsistency in definition of attribute extensibility</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>Kevin Liu</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://groups.yahoo.com/group/wsdl/message/412">email</a>]
In section 2.1, extensibility is expilictly stated for all the
elements, but not for attributes. </p>
<p> 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.</p>
</description>
<proposal>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0032.html">email</a>]
</proposal>
<resolution>
<p>Per 18 Dec 03 telecon, same description for
attribute and children extensibility; neither in pseudo syntax
to minimize clutter.</p>
</resolution>
</issue>
<issue>
<issue-num>7</issue-num>
<title>Example incorrectly uses xsd:binary</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Editorial</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Jeff Lansing</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://groups.yahoo.com/group/wsdl/message/446">email</a>]
The sample in <a href="http://www.w3.org/TR/wsdl#_http-e">section 4.1</a> of the spec uses xsd:binary which doesn't exist, its not clear what the
correct type to use in its place would be.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Removed example; rewrite in primer.</p>
</resolution>
</issue>
<issue>
<issue-num>6e</issue-num>
<title>Define behavior for http:urlReplacement "search pattern" with
no corresponding named part in message</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:gisle@activestate.com">Gisle Aas</a>
</originator>
<responsible/>
<description>
<p> [<a href="http://groups.yahoo.com/group/wsdl/message/466">email</a>]
For http:urlReplacement it is not clear what should happen for "search
patterns" where there is no correspondingly named part in the message.</p>
</description>
<proposal>
<p>Strings enclosed within single curly braces MUST be input message part
names; any other strings enclosed within single curly braces are a
fatal error. [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003May/0067.html">email</a>]</p>
</proposal>
<resolution>
<p>Accepted per 29 May 2003 telecon.</p>
</resolution>
</issue>
<issue>
<issue-num>6d</issue-num>
<title>Define encoding for characters outside ASCII in a request URL</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:gisle@activestate.com">Gisle Aas</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://groups.yahoo.com/group/wsdl/message/466">email</a>]
For http:urlReplacement it not not clear what URL escaping should be
done on the replacement text.</p>
<p>- Is an embedded "?" to be expanded into "?" or "%3f".</p>
<p>
- Is an embedded "%3f" to be expanded into "%3f" or "%253f"</p>
</description>
<proposal>
</proposal>
<resolution>
<p>
Per 13 Feb 2003 teleconference, editors to add text compatible with I18N.</p>
</resolution>
</issue>
<issue>
<issue-num>6c</issue-num>
<title>Can a part reference a global element declaration instead of a type</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>
<a href="mailto:gisle@activestate.com">Gisle Aas</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://groups.yahoo.com/group/wsdl/message/466">email</a>]
Is it legal for the part referenced to reference a schema element
instead of a type?</p>
</description>
<proposal>
</proposal>
<resolution>
<p>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).</p>
</resolution>
</issue>
<issue>
<issue-num>6b</issue-num>
<title>Define encoding for characters outside ASCII in a request URL</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:gisle@activestate.com">Gisle Aas</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://groups.yahoo.com/group/wsdl/message/466">email</a>]
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?</p>
</description>
<proposal>
<p> Wait until <a href="http://www.w3.org/International/Group/charmod-edit/#sec-URIs">Charmod</a>
goes to REC, if possible, since it contains
a pretty strong requirement that W3C specifications
"use Internationalized Resource Identifiers
(<a href="http://www.ietf.org/internet-drafts/draft-duerst-iri-00.txt">IRI</a>)
(or an appropriate subset thereof)."</p>
</proposal>
<resolution>
<p>Per 13 Feb 2003 teleconference, editors to add text compatible with I18N.</p>
</resolution>
</issue>
<issue>
<issue-num>6a</issue-num>
<title>Define encoding of complex types in a request URL</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:gisle@activestate.com">Gisle Aas</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://groups.yahoo.com/group/wsdl/message/466">email</a>]
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)?</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Per 13 Feb 2003 teleconference, leave HTTP request URLs segmented, flat,
and (somewhat) human readable.</p>
</resolution>
</issue>
<issue>
<issue-num>5</issue-num>
<title>Encoding Style</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:rineholt@us.ibm.com">Rine Holt</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://groups.yahoo.com/group/wsdl/message/456">email</a>]
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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>
<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Sep/0018.html">email</a>
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</p>
</resolution>
</issue>
<issue>
<issue-num>4</issue-num>
<title>Namespaces</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Matt Long</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://wsdl.SoapWare.Org/stories/storyReader$15">email</a>]
I ran across this example at
http://www.w3.org/2001/03/14-annotated-WSDL-examples</p>
<p>
The example is correct but does emphasize a concern.</p>
<p>1) when a part is typed "element" and referenced to schema</p>
<p>2) and the binding's soap:body "namespace" attribute is used</p>
<p>Spec reads Section 3.5</p>
<p>
...although the namespace attribute only applies to content not
explicitly</p>
<p>
defined by the abstract types. ...</p>
<p>
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.</p>
<p>
This seems confusing and it would seem in the interests of best
practices to either</p>
<p>
1) declare the namespace attribute of the soap:body element equal
to the intended namespace</p>
<p>or</p>
<p>
2) omit the namespace attribute *if* the element is explictly
declared in schema.</p>
<p>
(I would think (1) would clear any garbled confusion in either
case).</p>
</description>
<proposal>
</proposal>
<resolution>
<p>
<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Jul/0076.html">email</a>
</p>
</resolution>
</issue>
<issue>
<issue-num>3</issue-num>
<title>How can arrays be declared?</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>?</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://wsdl.SoapWare.Org/stories/storyReader$14">email</a>]<br/>
Possibly one of the most talked about parts of WSDL:</p>
<ul>
<li>What is the standard way to describe an array?</li>
<li>How many other valid ways are there to describe an array?</li>
<li>How do i define more complex types?</li>
<li>Does the new WSDL 1.1 approach to arrays support all the different array types in SOAP?</li>
</ul>
<p> [needs review]</p>
</description>
<proposal>
</proposal>
<resolution>Per 11 Dec 2003 telecon, closed because we don't
deal with the SOAP data model or its encoding [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0014.html">email</a>].
</resolution>
</issue>
<issue>
<issue-num>2</issue-num>
<title>Allow SOAPAction for bindings other than SOAP</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:gdaniels@macromedia.com">Glen Daniels</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [SOAPAction has been deprecated, as of SOAP 1.2]
<quote section="3.4 soap:operation"></p>
<p>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.</p>
<p><quote></p>
<p>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?</p>
</description>
<proposal>
</proposal>
<resolution>
<p> Per <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0060.html">4
Nov 2003 face-to-face</a>, decided to simplify SOAP binding
extension to just <wsoap:action uri="xs:anyURI" />.</p>
</resolution>
</issue>
<issue>
<issue-num>1</issue-num>
<title>How to specify an empty SOAP action</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:simon@zaks.demon.co.uk">Simon Fell</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [SOAPAction has been deprecated, as of SOAP 1.2]
<quote section="3.4 soap:operation"></p>
<p>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.</p>
<p><quote></p>
<p>Does this mean the SOAPAction value should include the quotes
needed ?, i.e. if you're expecting a SOAP request</p>
<pre>POST ....
SOAPAction: "/foo/bar"</pre>
<p>do you include the quotes in the soap:operation ?, e.g. </p>
<pre><soap:operation soapAction="/foo/bar" /></pre>
<p>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.</p>
<pre>POST ....
SOAPAction: </pre>
</description>
<proposal>
</proposal>
<resolution>
<p>Closed 5/21/2004 FTF. No @soapAction will mean no soapaction header.</p>
</resolution>
</issue>
<!-- Maintainers -->
<maintainer>
<initials>JJM</initials>
<fullname>Jean-Jacques Moreau (for now)</fullname>
<uri/>
</maintainer>
<maintainer>
<initials>JCS</initials>
<fullname>Jeffrey Schlimmer</fullname>
<uri/>
</maintainer>
<maintainer>
<initials>JM</initials>
<fullname>Jonathan Marsh</fullname>
<uri/>
</maintainer>
</issues>
\ No newline at end of file
--- 1 ----
! <?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='wsd-issues-html.xsl'?>
<!DOCTYPE issues SYSTEM "wsd-issues.dtd">
<issues update="$Date$">
<!--
<issue>
<issue-num>2@@</issue-num>
<title>@@@</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Active</status>
<originator>@@@</originator>
<responsible/>
<description>
<p>[<a href="@@@">email</a>]</p>
</description>
<proposal/>
<resolution/>
</issue>
-->
<issue>
<issue-num>252</issue-num>
<title>Syntax of media type annotation</title>
<locus>Media type description</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Active</status>
<originator>Jonathan marsh</originator>
<responsible/>
<description>
<p>Should the expected media type be an attribute instead of an appinfo annotation?
WG substantially in favor of this if tooling doesn't prevent it.</p>
</description>
<proposal/>
<resolution/>
</issue>
<issue>
<issue-num>251</issue-num>
<title>Schemas for SOAP and HTTP Binding</title>
<locus>Part 3</locus>
<requirement></requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>Asir</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0304.html">email</a>] The schema for SOAP Binding [1] is old and out of sync with Part 3. What is
the schemaLocation for the schema for HTTP Binding?</p>
</description>
<proposal/>
<resolution><p>Editors to update these schemas.</p></resolution>
</issue>
<issue>
<issue-num>250</issue-num>
<title>Properties within wsoap:module</title>
<locus>Part 3</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Asir</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0302.html">email</a>]</p>
</description>
<proposal/>
<resolution><p>Accepted.</p></resolution>
</issue>
<issue>
<issue-num>249</issue-num>
<title>HTTP binding mismatch and identification missing</title>
<locus>Part 3</locus>
<requirement></requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>Hugo</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0285.html">email</a>]</p>
</description>
<proposal/>
<resolution><p>Accepted.</p></resolution>
</issue>
<issue>
<issue-num>248</issue-num>
<title>Property component's dependency on XML Schema</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Roberto</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0283.html">email</a>]</p>
</description>
<proposal/>
<resolution><p>Proposed resolution adopted.</p></resolution>
</issue>
<issue>
<issue-num>246</issue-num>
<title>HTTP binding and interface operation MEP</title>
<locus>Part 3</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Hugo</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0279.html">email</a>]</p>
</description>
<proposal/>
<resolution><p>Proposed resolution adopted.</p></resolution>
</issue>
<issue>
<issue-num>245</issue-num>
<title>Define expectedMediaTypeItem to be RFC 2616 Accepts header</title>
<locus>Media Type Description</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Hugo</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0263.html">email</a>]</p>
</description>
<proposal/>
<resolution>
<p>Accepted the addition of the "q" parameter and the ability to specify "*/*".
Items will remain a schema list, easily translated to the comma-separated list of RFC2616.
</p>
</resolution>
</issue>
<issue>
<issue-num>244</issue-num>
<title>Decouple SOAP Version from SOAP Binding?</title>
<locus>SOAP 1.1</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Active</status>
<originator>Asir</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0250.html">email</a>]</p>
</description>
<proposal/>
<resolution/>
</issue>
<issue>
<issue-num>243</issue-num>
<title>Component reference vs. QName</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Asir</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0249.html">email</a>]</p>
</description>
<proposal/>
<resolution><p>Proposed resolution adopted.</p></resolution>
</issue>
<issue>
<issue-num>242</issue-num>
<title>Binding accepts header and output serialization </title>
<locus>Media type description</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Hugo</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0005.html">email</a>]</p>
</description>
<proposal/>
<resolution><p>Reference Accepts header meaning (not just value) similarity to Accepts header.</p></resolution>
</issue>
<issue>
<issue-num>241</issue-num>
<title>AD Feature: HTTP header conflicts</title>
<locus>Part 2</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Hugo</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0131.html">email</a>]</p>
</description>
<proposal/>
<resolution><p>Indicate error for AD HTTP binding in case of conflict.</p></resolution>
</issue>
<issue>
<issue-num>240</issue-num>
<title>input serialization flexibility</title>
<locus>Part 3</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>DaveO</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0073.html">email</a>]</p>
</description>
<proposal/>
<resolution><p>Accepted.</p></resolution>
</issue>
<issue>
<issue-num>239</issue-num>
<title>Part 1 Editorial Issues</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>Asir</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0110.html">email</a>]</p>
</description>
<proposal/>
<resolution><p>Accepted.</p></resolution>
</issue>
<issue>
<issue-num>238</issue-num>
<title>Consistent placement of <feature> and <property></title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>Sanjiva</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0267.html">email</a>]</p>
</description>
<proposal/>
<resolution><p>Accepted.</p></resolution>
</issue>
<issue>
<issue-num>237</issue-num>
<title>Editorial issues with Part 3</title>
<locus>Part 3</locus>
<requirement></requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>Hugo</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0011.html">email</a>]</p>
</description>
<proposal/>
<resolution><p>Move pseudo-schema up front.</p></resolution>
</issue>
<issue>
<issue-num>236</issue-num>
<title>MTOM/XOP support</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>Umit</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0038.html">email</a>]</p>
</description>
<proposal/>
<resolution><p>Accepted.</p></resolution>
</issue>
<issue>
<issue-num>235</issue-num>
<title>Definition of Fault</title>
<locus>Part 1/Part 2</locus>
<requirement></requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>MarkN</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0138.html">email</a>]
* A short, formal definition of what a Fault is, in WSDL terms, may be
useful (not necessarily in this document, but somewhere).</p>
</description>
<proposal>
<p>Add to part one text that relates fault syntax to the semantic of
application fault.</p>
</proposal>
<resolution><p>Proposal accepted.</p></resolution>
</issue>
<issue>
<issue-num>234</issue-num>
<title>Ruleset terminology</title>
<locus>Part 2</locus>
<requirement></requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>MarkN</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0138.html">email</a>]
* Section 2 uses "generation" in reference to Faults, which seems to have
a different meaning than in SOAP. When A SOAP Fault is generated, it is
not necessarily transmitted on the wire; here, the implication seems
to be that it is. Suggest using "Fault transmission," "Fault delivery,"
or "Fault destination" throughout instead. This would make the first
sentences in the section something like: "WSDL patterns specify the
destination and transmission of any Faults generated in a message
exchange using standard rules. The most common such rules are
defined here and referenced by patterns later in this document.
A Fault, regardless of the rule in effect, terminates the message
exchange it occurs in."</p>
</description>
<proposal>
<p>fault propagation rulset</p>
</proposal>
<resolution><p>Accepted.</p></resolution>
</issue>
<issue>
<issue-num>233</issue-num>
<title>Dynamically override Fault destination?</title>
<locus>Part 2</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>MarkN</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0138.html">email</a>]
* 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.</p>
</description>
<proposal/>
<resolution>
<p>Add informative note in part
2 could describing how various extensions may effect message
delivery including delivery of faults</p>
</resolution>
</issue>
<issue>
<issue-num>232</issue-num>
<title>Differentiate our MEPs from underlying protocol MEPs</title>
<locus>Part 2</locus>
<requirement></requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>MarkN</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0138.html">email</a>]
* 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</p>
</description>
<proposal/>
<resolution><p>Accepted.</p></resolution>
</issue>
<issue>
<issue-num>231</issue-num>
<title>Clarify "patterns"</title>
<locus>Part 2</locus>
<requirement></requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>MarkN</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0138.html">email</a>]
* 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')..."</p>
</description>
<proposal>
<p>Begin the introduction with "Web Services Description Language (WSDL) message
exchange patterns (hereafter, 'patterns')..."</p>
</proposal>
<resolution><p>Accepted.</p></resolution>
</issue>
<issue>
<issue-num>230</issue-num>
<title>{label} vs. {message label}</title>
<locus>Part 1/Part 2</locus>
<requirement></requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>MarkN</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0189.html">email</a>]
Part 2 refers to {label} properties, whereas part one uses {message label}; should these be the same?
</p>
</description>
<proposal/>
<resolution>
<p>Editorial: Use {message label} in Part 2.</p>
</resolution>
</issue>
<issue>
<issue-num>229</issue-num>
<title>useOperationWebMethod</title>
<locus>Part 3</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>WG</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0257.html">wg discussion</a> relative to issue 169.]</p>
</description>
<proposal>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0241.html">rationale</a>,
<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0053.html">proposal</a>.]</p>
</proposal>
<resolution><p>Closed with no action</p></resolution>
</issue>
<issue>
<issue-num>228</issue-num>
<title>Should f&p be allowed in more places?</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>WG</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0257.html">wg discussion</a> relative to issues 157, 167.]</p>
</description>
<proposal>
<p>Definitions, Interface Fault, Binding Fault seem to be the only remaining candidates.</p>
</proposal>
<resolution>
<p>Add f&p to Interface Faults, Binding Faults, and Fault References.</p>
</resolution>
</issue>
<issue>
<issue-num>227</issue-num>
<title>Description of Binding Operation component</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>MarkN</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0200.html
">email</a>] 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."</p>
<p>This doesn't hold; the binding operation isn't constrained to a single
concrete message format, and also describes protocol details.</p>
</description>
<proposal>
<p>"The Binding Operation component describes the concrete message
format(s) and protocol interaction(s) associated with a particular
interface operation for a given endpoint."</p>
</proposal>
<resolution><p>Accepted.</p></resolution>
</issue>
<issue>
<issue-num>226</issue-num>
<title>Cross-binding HTTP features</title>
<locus>Part 3</locus>
<requirement></requirement>
<priority>Editorial</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>Asir</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0080.html">email</a>]</p>
</description>
<proposal>
<p>WG believes this can be resolved editorially.</p>
</proposal>
<resolution><p>Accepted.</p></resolution>
</issue>
<issue>
<issue-num>225</issue-num>
<title>Non-XML type system extensibility.</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Mark Nottingham</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0060.html">email</a>]
- 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."</p>
<p>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?</p>
<p>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"?</p>
<p>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.</p>
</description>
<proposal>
<p>[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.</p>
</proposal>
<resolution>
<p>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.</p>
</resolution>
</issue>
<issue>
<issue-num>224</issue-num>
<title>Formalize component model</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Mark Nottingham</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0060.html">email</a>]
- 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. </p>
</description>
<proposal>
<p>[Mark] I suggest adding a section detailing the principles and notation
of the component model.</p>
</proposal>
<resolution>
<p><a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0085.html">proposal</a> accepted.</p>
</resolution>
</issue>
<issue>
<issue-num>223</issue-num>
<title>Import/include processing model</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Mark Nottingham</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0060.html">email</a>]
- 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. </p>
</description>
<proposal>
<p>[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.</p>
</proposal>
<resolution>
<p><a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0085.html">proposal</a> accepted.</p>
</resolution>
</issue>
<issue>
<issue-num>222</issue-num>
<title>Name[space] for the intended semantics</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>Mark Nottingham</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0060.html">email</a>]
- 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?)</p>
</description>
<proposal>
<p>[Jonathan] Accept above edit.</p>
</proposal>
<resolution>
<p>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."</p>
</resolution>
</issue>
<issue>
<issue-num>221</issue-num>
<title>Identify components by URI</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Mark Nottingham</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0060.html">email</a>]
- 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.</p>
</description>
<proposal>
<p>[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.</p>
</proposal>
<resolution>
<p>Proposal withdrawn.</p>
</resolution>
</issue>
<issue>
<issue-num>220</issue-num>
<title>Document interface extension semantics</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>Mark Nottingham</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0060.html">email</a>]
- 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.</p>
</description>
<proposal/>
<resolution><p>Accepted.</p></resolution>
</issue>
<issue>
<issue-num>219</issue-num>
<title>Actual value vs. normalized value</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Mark Nottingham</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0060.html">email</a>]
- Table 2-2 (and elsewhere): What is an "actual value"? Does this
imply that it is not the [normalized value]?</p>
</description>
<proposal>
<p>[Jonathan] Consistify our info-speak.</p>
</proposal>
<resolution>
<p>Determined that actual value is the correct term; we will
include or import defn of "actual value" from XML Schema.</p>
</resolution>
</issue>
<issue>
<issue-num>218</issue-num>
<title>Justify interface faults.</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Mark Nottingham</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0060.html">email</a>]
- 2.3.1: Why is it advantageous to define a fault at the Interface
level, if it's just repeating information in the operations? </p>
</description>
<proposal>
<p>[Mark] I suggest either removing this functionality or better motivating it.</p>
<p>Concrete <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0276.html">proposal</a>.</p>
</proposal>
<resolution>
<p>Proposal accepted, including Mark's amendment, plus note that
errors are an open set.</p>
</resolution>
</issue>
<issue>
<issue-num>217</issue-num>
<title>Syntax for multiple styles</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Mark Nottingham</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0060.html">email</a>]
- 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").</p>
</description>
<proposal>
<p>[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.</p>
</proposal>
<resolution>
<p>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.</p>
</resolution>
</issue>
<issue>
<issue-num>216</issue-num>
<title>RPC and XML Schema not orthogonal</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Mark Nottingham</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0060.html">email</a>]
- 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.</p>
</description>
<proposal>
<p>[Mark] I suggest rewriting to the effect that other message
definitions are allowed, as long as they are functionally equivalent.</p>
</proposal>
<resolution>
<p>Proposed resolution accepted, with a friendly amendment not to lose the MUST.</p>
</resolution>
</issue>
<issue>
<issue-num>215</issue-num>
<title>Clarify rule obviation</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>Mark Nottingham</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0060.html">email</a>]
- 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.</p>
</description>
<proposal/>
<resolution><p>Accepted.</p></resolution>
</issue>
<issue>
<issue-num>214</issue-num>
<title>Refine "properties" terminology</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Mark Nottingham</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0060.html">email</a>]
- 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. </p>
</description>
<proposal>
<p>[Mark] Suggest using a distinguished term (perhaps
"attributes"?).</p>
</proposal>
<resolution><p>No action</p></resolution>
</issue>
<issue>
<issue-num>213</issue-num>
<title>Refine component model property constraints</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>Mark Nottingham</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0060.html">email</a>]
- 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.</p>
</description>
<proposal>
<p>[Mark] I suggest expanding the content model of each component
property in the property lists, and removing redundant syntactic
constraints from the infoset mappings.</p>
<p>Also see <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0095.html">email</a>.</p>
</proposal>
<resolution><p>Accepted.</p></resolution>
</issue>
<issue>
<issue-num>212</issue-num>
<title>Explain using bindings across all operations</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Mark Nottingham</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0060.html">email</a>]
- 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? </p>
</description>
<proposal>
<p>[Mark] I suggest that this requirement was dropped, and
guidance given on specifying generic operations.</p>
</proposal>
<resolution><p>No action</p></resolution>
</issue>
<issue>
<issue-num>211</issue-num>
<title>Omit interface message in binding?</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>Mark Nottingham</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0060.html">email</a>]
- 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.</p>
</description>
<proposal/>
<resolution><p>Accepted.</p></resolution>
</issue>
<issue>
<issue-num>210</issue-num>
<title>Refine equivalence algorithm</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Mark Nottingham</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0060.html">email</a>]
- 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)?</p>
</description>
<proposal>
<p><a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0195.html">email</a>,
plus <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0199.html">amendment</a>.</p>
</proposal>
<resolution>
<p>Proposals accepted, plus a reference to charmod for string eq.</p>
</resolution>
</issue>
<issue>
<issue-num>209</issue-num>
<title>Reference frag ids from media type registration</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>Mark Nottingham</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0060.html">email</a>]
- A.1: The "fragment identifiers" section of the media type registration
needs to list the mechanism described in C.2.</p>
</description>
<proposal>
<p>[Jonathan] accept.</p>
</proposal>
<resolution>
<p>Fix the link to point to App C, and associated clarifications to the text.</p>
</resolution>
</issue>
<issue>
<issue-num>208</issue-num>
<title>Misc. editorial comments</title>
<locus>Part 1</locus>
<requirement></requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>Mark Nottingham</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0060.html">email</a>]</p>
<p>- 2.1.2: Is the pseudo-schema normative? Where are its vocabulary and
rules explained?</p>
<p>- 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).</p>
<p>- 2.2.2.3: There needs to be a description of, or references to, the
properties here (e.g., {message references})</p>
<p>- 2.3.1: "execution of an operation of the interface." -> "execution of
*any* operation of the interface." ?</p>
<p>- 2.3.1: "The reason... is because that" Poor English.</p>
<p>- 2.3.1: "If a non-XML type system is in use... then additional
properties would need to be added..." Poor English.</p>
<p>- 2.3.1: "...to allow associating such.." Poor English.</p>
<p>- 2.3.1: "to allow associating such message types with the message
reference" Shouldn't that be *fault* reference?</p>
<p>- 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.</p>
<p>- 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.</p>
<p>- 2.5.1: "element" is used often, but not defined; is this Element
Information Item?</p>
<p>- 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.</p>
<p>- 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..."</p>
<p>- 2.6.2.1: "The ref attribute information item refers to a fault
component." Shouldn't this be "*interface* fault component."?</p>
<p>- 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.</p>
<p>- 2.13: Shouldn't 2.14 Endpoints come before this section?</p>
<p>- 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.</p>
</description>
<proposal>
<p>[Jonathan] Editors adopt as much as possible, come back to WG with any that
require discussion.</p>
</proposal>
<resolution><p>Accepted.</p></resolution>
</issue>
<issue>
<issue-num>207</issue-num>
<title>How to mark which elements to optimize</title>
<locus>Part 3</locus>
<requirement></requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Hugo</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0089.html">email</a>]
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.</p>
</description>
<proposal><p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0007.html">email</a>]
One way we could approach this would be to have a xop:optimize element
under binding, which references to the elements to be optimized:</p>
<pre><![CDATA[<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>]]></pre>
<p>Solicit input on this from XMLP WG, perhaps any hints should be defined by them.</p></proposal>
<resolution>
<p><a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0139.html">proposal</a> accepted.</p>
</resolution>
</issue>
<issue>
<issue-num>206</issue-num>
<title>Annotations and schema component model.</title>
<locus>Media type description</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>WG</originator>
<responsible/>
<description>
<p>[19 May FTF] How do annotations show up in component model? (currently
limited to a "binary information element")</p>
</description>
<proposal/>
<resolution><p>Obsolete and duplicate.</p></resolution>
</issue>
<issue>
<issue-num>205</issue-num>
<title>Explain priority</title>
<locus>Media type description</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>WG</originator>
<responsible/>
<description>
<p>[19 May FTF] Pattern includes use of priority -- either explain
relationship or get rid of it.</p>
</description>
<proposal/>
<resolution><p>Obsolete. Closed with no action.</p></resolution>
</issue>
<issue>
<issue-num>204</issue-num>
<title>Why default to */* instead of to "no effect"?</title>
<locus>Media type description</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>WG</originator>
<responsible/>
<description>
<p>[19 May FTF] Explain why */* AND absence means this is opaque
application data (i.e. application/octet-stream.</p>
</description>
<proposal/>
<resolution><p>Removed that sentence from the spec.</p></resolution>
</issue>
<issue>
<issue-num>203</issue-num>
<title>Limited to base64encoded?</title>
<locus>Media type description</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>WG</originator>
<responsible/>
<description>
<p>[19 May FTF] Explain why this proposal is limited to base64encoded?</p>
</description>
<proposal/>
<resolution><p>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.
</p></resolution>
</issue>
<issue>
<issue-num>202</issue-num>
<title>More examples</title>
<locus>Media type description</locus>
<requirement></requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>WG</originator>
<responsible/>
<description>
<p>[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?</p>
</description>
<proposal/>
<resolution><p>Accepted, editors to add more examples (valid and runnable) illustrating each significant feature.</p></resolution>
</issue>
<issue>
<issue-num>201</issue-num>
<title>Name of mediaType</title>
<locus>Media type description</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>WG</originator>
<responsible/>
<description>
<p>[19 May FTF] Consider changing name from mediaType to contentType</p>
</description>
<proposal/>
<resolution><p>Obsolete.</p></resolution>
</issue>
<issue>
<issue-num>200</issue-num>
<title>Where should appInfo go?</title>
<locus>Media type description</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>WG</originator>
<responsible/>
<description>
<p>[19 May FTF] Where should the annotation appear, on the type and/or the element?</p>
</description>
<proposal/>
<resolution><p>Say in the spec that this annotation can appear on element declarations and complex type definitions, where these types are derived from base64binary.</p></resolution>
</issue>
<issue>
<issue-num>199</issue-num>
<title>mismatch between the media type attribute and the actual data</title>
<locus>Media type description</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>WG</originator>
<responsible/>
<description>
<p>[19 May FTF] Possible error conditions: mismatch between the media type
attribute and the actual data.</p>
</description>
<proposal/>
<resolution><p>Out of scope what to do when messages don't match the description. Close with no action.</p></resolution>
</issue>
<issue>
<issue-num>198</issue-num>
<title>mismatch between value of media type attribute and pattern</title>
<locus>Media type description</locus>
<requirement></requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>WG</originator>
<responsible/>
<description>
<p>[19 May FTF] Mismatch between value of media type attribute and pattern -- says nothing about the data.</p>
</description>
<proposal/>
<resolution><p>Out of scope what to do when messages don't match the description. Close with no action.</p></resolution>
</issue>
<issue>
<issue-num>197</issue-num>
<title>Don't override interface feature requiredness in binding</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Umit</originator>
<responsible/>
<description>
<p>May 2004 FTF: Don't like the ability to override a required feature in the interface with a non-required one in the binding.</p>
</description>
<proposal/>
<resolution>
<p>Add to primer a note saying essentially "Note
that overriding in the binding features required at the interface
can cause unexpected results."</p>
</resolution>
</issue>
<issue>
<issue-num>196</issue-num>
<title>Module operation at operation level versus input/output level</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Asir</originator>
<responsible/>
<description>
<p>Spec review at FTF</p>
</description>
<proposal/>
<resolution>
<p>No change. We will keep modules at i/o level.</p>
</resolution>
</issue>
<issue>
<issue-num>195</issue-num>
<title>Property value merging</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>DaveO</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0040.html">email</a>]</p>
</description>
<proposal/>
<resolution>
<p>Closed with no action.</p>
</resolution>
</issue>
<issue>
<issue-num>194</issue-num>
<title>Why interleave wsdl: and wsoap: namespaced elements?</title>
<locus>Part 1, Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Glen</originator>
<responsible/>
<description>
<p>Spec review at FTF:</p>
</description>
<proposal/>
<resolution>
<p>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.</p>
</resolution>
</issue>
<issue>
<issue-num>193</issue-num>
<title>Module declaration at different levels</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Youenn</originator>
<responsible/>
<description>
<p>Spec review at FTF: </p>
</description>
<proposal/>
<resolution>
<p>Resolved to allow soap:module at i/o, ops, and binding - module determines what the layers mean.</p>
</resolution>
</issue>
<issue>
<issue-num>192</issue-num>
<title>2.4.1, 2.5.1 "increasing specificity" -> "decreasing ..."</title>
<locus>Part 3</locus>
<requirement/>
<priority>Editorial</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Amy</originator>
<responsible/>
<description>
<p>Spec review at FTF:</p>
</description>
<proposal/>
<resolution>
<p>Accepted.</p>
</resolution>
</issue>
<issue>
<issue-num>191</issue-num>
<title>Relationship of SOAP MEPs and WSDL MEPs</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Hugo</originator>
<responsible/>
<description>
<p>Spec review at FTF: </p>
</description>
<proposal/>
<resolution>
<p>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.</p>
</resolution>
</issue>
<issue>
<issue-num>190</issue-num>
<title>Layering of SOAP webMethod on top of HTTP binding</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>DaveO</originator>
<responsible/>
<description>
<p>Spec review at FTF: </p>
</description>
<proposal/>
<resolution><p>Closed at 5/21/2004 FTF.</p></resolution>
</issue>
<issue>
<issue-num>189</issue-num>
<title>Binding message content to URI</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>DaveO</originator>
<responsible/>
<description>
<p>Spec review at FTF: </p>
</description>
<proposal>
<p><a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0276.html">email</a>.
Counterproposal at <a href=" http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0210.html">email</a>.</p>
</proposal>
<resolution>
<p>Part 1 and 2b and counterproposal adopted. Part 2a and 3 rejected.</p>
</resolution>
</issue>
<issue>
<issue-num>188</issue-num>
<title>wsoap:address vs. http:address?</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>DaveO</originator>
<responsible/>
<description>
<p>Spec reveiw at FTF: </p>
</description>
<proposal/>
<resolution><p>Closed at 5/21/2004 FTF.</p></resolution>
</issue>
<issue>
<issue-num>187</issue-num>
<title>Interaction between MEPdefault and webMethodDefault</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Youenn</originator>
<responsible/>
<description>
<p>Spec review at FTF: </p>
</description>
<proposal/>
<resolution><p>Closed at 5/21/2004 FTF. Obsolete since webMethodDefault is removed in issue resolution of Issue 190.</p></resolution>
</issue>
<issue>
<issue-num>186</issue-num>
<title>Interaction and placement of soap:header and soap:module</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Umit</originator>
<responsible/>
<description>
<p>Spec review at FTF</p>
</description>
<proposal/>
<resolution>
<p>Removed soap:header (Issue 185), placement of soap:module will not change.</p>
</resolution>
</issue>
<issue>
<issue-num>185</issue-num>
<title>Eliminate soap:header</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Sanjiva</originator>
<responsible/>
<description>
<p>Spec review at FTF.</p>
</description>
<proposal/>
<resolution>
<p>Remove soap:header - use soap:module for this.</p>
</resolution>
</issue>
<issue>
<issue-num>184</issue-num>
<title>MTOM serialization into SOAP body</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Ugo</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0055.html">email</a>]</p>
</description>
<proposal/>
<resolution><p>Closed at 5/21/2004 FTF: Wording will be updated to ensure MTOM is not precluded.</p></resolution>
</issue>
<issue>
<issue-num>183</issue-num>
<title>wsoap:prefix</title>
<locus>Part 3</locus>
<requirement/>
<priority>Editorial</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Sanjiva</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0042.html">email</a>]</p>
</description>
<proposal/>
<resolution>
<p>will use wsoap: convention instead of wsoap12:.</p>
</resolution>
</issue>
<issue>
<issue-num>182</issue-num>
<title>defaultMEP inheritance-syntax or model?</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Jonathan</originator>
<responsible/>
<description>
<p>Spec review at FTF: defaultMEP and defaultWebMethod appear in the component model: is there semantics associated with using defaults instead of local attributes?</p>
</description>
<proposal/>
<resolution>
<p>No difference - default* will be removed from the spec, XML mapping updated to propogate the defaults into the corresponding property.</p>
</resolution>
</issue>
<issue>
<issue-num>181</issue-num>
<title>Bind to other protocols</title>
<locus>Part 3</locus>
<requirement/>
<priority>Editorial</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>JJM</originator>
<responsible/>
<description>
<p>Spec review at FTF: text implies only SOAP HTTP protocol can be used.</p>
</description>
<proposal/>
<resolution>
<p>Resolved to fix wording to make it clear other transports were possible
(when they have been defined and given a URI.)</p>
</resolution>
</issue>
<issue>
<issue-num>180</issue-num>
<title>Inconsistent propogation of soap:module and features & properties</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Roberto</originator>
<responsible/>
<description>
<p>Spec review at FTF.</p>
</description>
<proposal/>
<resolution>
<p>Resolved to use inside-out lexical scoping:nearest enclosing scope wins (as opposed to highest level of "required" as previously.</p>
</resolution>
</issue>
<issue>
<issue-num>179</issue-num>
<title>PUT & DELETE need to be added</title>
<locus>Part 3</locus>
<requirement/>
<priority>Editorial</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Hugo</originator>
<responsible/>
<description>
<p>Spec review at FTF: PUT & DELETE decision not reflected in draft.</p>
</description>
<proposal/>
<resolution>
<p>Added to EDTODO.</p>
</resolution>
</issue>
<issue>
<issue-num>178</issue-num>
<title>Track operation safety</title>
<locus>Test suite</locus>
<requirement/>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Active</status>
<originator>TAG</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0028.html">email</a>]</p>
</description>
<proposal/>
<resolution/>
</issue>
<issue>
<issue-num>177</issue-num>
<title>Normative dependence on XML Schema 1.0 precludes XML 1.1</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>JJM</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0011.html
">email</a>]</p>
</description>
<proposal>
<p><a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0049.html">proposal</a>, plus
a note warning people that changes in Schema support for XML 1.1 might cause this to change prior
to Recommendation.</p>
</proposal>
<resolution>
<p>Proposal adopted, with a note that "processing of documents encoded
in XML 1.1 is not a conformance requirement".</p>
</resolution>
</issue>
<issue>
<issue-num>176</issue-num>
<title>Can a WSDL 2.0 XML 1.1 document contain (or reference), a XML Schema 1.0 type description? </title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>JJM</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0011.html">email</a>]</p>
</description>
<proposal/>
<resolution>
<p><a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0049.html">proposal</a> accepted.</p>
</resolution>
</issue>
<issue>
<issue-num>175</issue-num>
<title>Is it valid for a XML 1.1 document to import or include a XML 1.0 document (and vice versa)?</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Paul</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0012.html">email</a>]</p>
</description>
<proposal/>
<resolution>
<p><a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0049.html">proposal</a> accepted.</p>
</resolution>
</issue>
<issue>
<issue-num>174</issue-num>
<title>Tie WSDL conformance to XML conformance?</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Arthur</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0032.html">email</a>]</p>
</description>
<proposal/>
<resolution>
<p><a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0049.html">proposal</a> accepted.</p>
</resolution>
</issue>
<issue>
<issue-num>173</issue-num>
<title>Convert nested subcodes into a flat list (attribute)</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Paul</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0022.html">email</a>]</p>
</description>
<proposal/>
<resolution>
<p>Closed 5/21/2004 FTF.</p>
</resolution>
</issue>
<issue>
<issue-num>172</issue-num>
<title>Change wsoap:code/wsoap:value to an attribute</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Sanjiva</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0081.html">email</a>] </p>
</description>
<proposal>
<p>Change:</p>
<pre><![CDATA[ <wsoap:code>
<wsoap:value>xs:QName</wsoap:value>
<wsoap:subcode>
<wsoap:value>xs:QName</wsoap:value>
<wsoap:subcode>...</wsoap:subcode>
</wsoap:subcode>?
</wsoap:code>]]></pre>
<p>to</p>
<pre><![CDATA[
<wsoap:code value="xs:QName">
<wsoap:subcode value="xs:QName">
<wsoap:subcode>...</wsoap:subcode>
</wsoap:subcode>?
</wsoap:code>]]></pre>
<p>This makes the syntax more consistent with the rest of the
SOAP binding which is rather attribute-heavy.</p>
</proposal>
<resolution>
<p>Proposal accepted.</p>
</resolution>
</issue>
<issue>
<issue-num>171</issue-num>
<title>Indicate XML version for XML in SOAP and HTTP bindings?</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>WG</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal>
<p>[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?</p>
</proposal>
<resolution><p>Closed with no action: XML serialization is not constrained by WSDL.</p></resolution>
</issue>
<issue>
<issue-num>170</issue-num>
<title>Shortcut syntax for synchronizing webMethod and HTTP verb</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>David Orchard/Mark Baker</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0035.html">email</a>] David Orchard proposes a syntax. WG on 22 April 2004 discusses this as a shortcut syntax issue. [Precursor <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0007.html">email</a> from Mark Baker]</p>
</description>
<proposal>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0035.html">email</a>] 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"...</p>
</proposal>
<resolution><p>Closed at 5/21/2004 FTF. Obsolete: webMethod has been removed.</p></resolution>
</issue>
<issue>
<issue-num>169</issue-num>
<title>Syntax for webMethod - property or attribute?</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>David Orchard/Mark Baker/WSDL WG</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0053.html">email</a>] David Orchard proposed an attribute-based syntax for Web Method, rather than the generic <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0031.html">property syntax</a> proposed by Hugo.</p>
</description>
<proposal>
<p>wsdl:interface/wsdl:operation/@webMethod (?)</p>
</proposal>
<resolution><p>Closed with no action</p></resolution>
</issue>
<issue>
<issue-num>168</issue-num>
<title>Which operation</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Mark Baker</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0044.html">email</a>] Is the Operation being invoked indicated by the name of the wsdl:operation, or by the operation of the binding? Spec is unclear.</p>
</description>
<proposal/>
<resolution><p>Unique GED requirement addresses this, commenter agrees he's unlikely to get more.</p></resolution>
</issue>
<issue>
<issue-num>167</issue-num>
<title>Synchronize pseudo-schema</title>
<locus>Part 1</locus>
<requirement/>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>Hugo</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0047.html">email</a>] Pseudo-schema doesn't quite match the draft.</p>
</description>
<proposal/>
<resolution>
<p>Part 1, Part 3, schema, and pseudo-schema all need to be synchronized about where f&p are allowed. See issue 157.</p>
</resolution>
</issue>
<issue>
<issue-num>166</issue-num>
<title>Binding of Faults in HTTP Binding</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>Hugo</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0032.html">email</a>]</p>
</description>
<proposal>
<p>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.</p>
<p>For the HTTP status code, I think that we have 3 options:</p>
<ul>
<li>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, ...);</li>
<li>have faults be returned with specific HTTP error codes: e.g., faults
are returned with a 4xx or 5xx status code.</li>
<li>offer it to be specified as a property of the HTTP binding with an
attribute on the http:operation element.</li>
</ul>
<p>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.</p>
</proposal>
<resolution><p>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.</p></resolution>
</issue>
<issue>
<issue-num>165</issue-num>
<title>HTTPS support</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>Youenn</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0304.html">email</a>] "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 <a href="#x56">issue 56</a>.</p>
</description>
<proposal/>
<resolution>
<p>Closed 5/20/2004 FTF. Will add http:authenticationType and http:authenticationRealm to endpoint.</p>
</resolution>
</issue>
<issue>
<issue-num>164</issue-num>
<title>Support for HTTP chunking and other HTTP options</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>Youenn</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0303.html">email</a>]. 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?</p>
</description>
<proposal>
<p>Prasad suggests a space-separated list of supported HTTP options.</p>
</proposal>
<resolution>
<p>Closed 5/20/2004 FTF. Will support an http:transfer-coding attribute on bindings.</p>
</resolution>
</issue>
<issue>
<issue-num>163</issue-num>
<title>Publishing WSDL 2.0 schema</title>
<locus>Media type description</locus>
<requirement/>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>Media Type TF</originator>
<responsible/>
<description>
<p>We need a WSDL 2.0 published schema to refer to to fix the table"</p>
</description>
<proposal/>
<resolution>
<p>http://www.w3.org/2004/03/wsdl</p>
</resolution>
</issue>
<issue>
<issue-num>162</issue-num>
<title>Allowing other choices for mediaType values</title>
<locus>Media type description</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Media Type TF</originator>
<responsible/>
<description>
<p>Should other choices be allowed to represent media-type values? Even if allowed, should this specification utilize them?</p>
</description>
<proposal/>
<resolution><p>Obsolete. IANA media types are sufficient.</p></resolution>
</issue>
<issue>
<issue-num>161</issue-num>
<title>Should media-type values allow wild cards</title>
<locus>Media type description</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Media Type TF</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal/>
<resolution><p>wildcards (/*) are allowed. */* is not at this point (see issue 245).</p></resolution>
</issue>
<issue>
<issue-num>160</issue-num>
<title>Formalize processing model</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Jacek</originator>
<responsible/>
<description>
<p>Should we describe reasonable paths through document for the purpose of concretely defining processor conformance? Alternatively should we just rely on document conformance?</p>
</description>
<proposal>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0265.html">email</a>]</p>
</proposal>
<resolution>
<p>Accepted <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0206.html">proposal</a>.</p>
</resolution>
</issue>
<issue>
<issue-num>159</issue-num>
<title>Messages with mixed Body content or multiple element content</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>WG</originator>
<responsible/>
<description>
<p>@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? [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0247.html">email</a>]</p>
</description>
<proposal/>
<resolution>
<p>No new facilities. Add a note pointing out that our SOAP
binding only allows a single element in the body.</p>
</resolution>
</issue>
<issue>
<issue-num>158</issue-num>
<title>Setting HTTP headers in the HTTP binding</title>
<locus>Part 3</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>Philipe Le Hegaret
</originator>
<responsible/>
<description>
<p>From issue 85, there remains an open question about facilities for setting HTTP headers within the HTTP binding.</p>
</description>
<proposal/>
<resolution>
<p>Subsumed by adopting proposal for Issue 112.</p>
</resolution>
</issue>
<issue>
<issue-num>157</issue-num>
<title>f&p at the service level</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Glen</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0186.html">email</a>]</p>
</description>
<proposal>
<p>Allow f&p markup within <wsdl:service></p>
</proposal>
<resolution>
<p>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.</p>
</resolution>
</issue>
<issue>
<issue-num>156</issue-num>
<title>Endpoints and QNames</title>
<locus>Part 1</locus>
<requirement/>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>Ugo Corda</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0242.html">email</a>]</p>
</description>
<proposal>
</proposal>
<resolution>
<p>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).</p>
</resolution>
</issue>
<issue>
<issue-num>155</issue-num>
<title>Out patterns in HTTP binding</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>Philippe</originator>
<responsible/>
<description>
<p>[<a href="http://www.w3.org/2004/01/21-httpbinding.html">proposal</a>] Doesn't list the Out patterns for the moment. Waiting to see how the dicussion on addressing is going to stabilize.
</p>
</description>
<proposal>
<p>Plan to revisit this after competing SOAP 1.2 HTTP binding Output operations .</p>
</proposal>
<resolution><p>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.</p></resolution>
</issue>
<issue>
<issue-num>154</issue-num>
<title>Multi-part post in HTTP binding</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>Philippe</originator>
<responsible/>
<description>
<p>[<a href="http://www.w3.org/2004/01/21-httpbinding.html">proposal</a>] Do we want the "multipart/related" format? </p>
</description>
<proposal>
<p>Use XOP. Plan to revisit this after competing SOAP 1.2 HTTP binding XOP support.</p>
</proposal>
<resolution>
<p>XOP is SOAP-specific. Use case appears marginal. Close with no action.</p>
</resolution>
</issue>
<issue>
<issue-num>153</issue-num>
<title>Base URI for operation/@location in HTTP binding</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>Philippe</originator>
<responsible/>
<description>
<p>[<a href="http://www.w3.org/2004/01/21-httpbinding.html">proposal</a>] Should it be relative to the address of the service or to the [base URI] property of the location element information item? </p>
</description>
<proposal>
</proposal>
<resolution>
<p>@location will be relative to the address of the service.</p>
</resolution>
</issue>
<issue>
<issue-num>152</issue-num>
<title>Importing the targetNamespace</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Jacek</originator>
<responsible/>
<description>
<p>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?</p>
</description>
<proposal>
<p/>
</proposal>
<resolution>
<p>No action: keep consistent with Schema, disallow imports of the targetNamepace.</p>
</resolution>
</issue>
<issue>
<issue-num>151</issue-num>
<title>Reference attribute name consistency</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>WSD WG</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0067.html">email</a>]</p>
</proposal>
<resolution>
<p>Proposal accepted.</p>
</resolution>
</issue>
<issue>
<issue-num>150</issue-num>
<title>Indicating empty bodies</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>DaveO, WG</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0138.html">email</a>], 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.</p>
</description>
<proposal>
<p/>
</proposal>
<resolution>
<p>
<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0091.html">Proposal</a> accepted (#empty changed to #none)</p>
</resolution>
</issue>
<issue>
<issue-num>149</issue-num>
<title>Duplicate features with conflicting @required</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Jonathan Marsh</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0208.html">email</a>]</p>
</description>
<proposal>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0209.html">email</a> Conflicts should be allowed with the required="true" taking precedence.</p>
</proposal>
<resolution>
<p>clarify that the strongest value wins.</p>
</resolution>
</issue>
<issue>
<issue-num>148</issue-num>
<title>Double check URI comparison algorithm and relative URI use</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Jonathan Marsh</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0180.html">email</a>]</p>
</description>
<proposal>
<p>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.</p>
</proposal>
<resolution>
<p>Change all URIs EXCEPT import/@location and
include/@location to absolute URIs at the XML document
level.</p>
</resolution>
</issue>
<issue>
<issue-num>147</issue-num>
<title>HTTP binding uses static content-type header</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>Youenn</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0131.html">email</a>, <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0137.html">email</a>]</p>
</description>
<proposal/>
<resolution>
<p>Closed 5/20/2004 FTF. http:inputSerialization and http:outputSerialization attributes will be added, per the proposal at <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0057.html">http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0057.html</a>.</p>
</resolution>
</issue>
<issue>
<issue-num>146</issue-num>
<title>should WSDL be able to describe an operation with *anything* in the message?</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Jacek</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0110.html">email</a>]</p>
</description>
<proposal>
<p>element="" (no GED) means anything goes.</p>
</proposal>
<resolution>
<p>
<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0091.html">Proposal</a> accepted (#empty changed to #none)</p>
</resolution>
</issue>
<issue>
<issue-num>145</issue-num>
<title>How can you tell which type system is in use?</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Bijan Parsia</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0046.html">email</a>]</p>
</description>
<proposal>
<p>TBD</p>
</proposal>
<resolution>
<p>No action, mooted by resolution of issue 143.</p>
</resolution>
</issue>
<issue>
<issue-num>144</issue-num>
<title>Why can't message reference simpleTypes?</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Bijan Parsia</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0046.html">email</a>]</p>
</description>
<proposal>
<p>TBD</p>
</proposal>
<resolution>
<p>No action, mooted by resolution of issue 143.</p>
</resolution>
</issue>
<issue>
<issue-num>143</issue-num>
<title>Referencing other type systems</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Bijan Parsia</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0046.html">email</a>]</p>
</description>
<proposal>
<p>
<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0229.html">email</a>
</p>
</proposal>
<resolution>
<p>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.</p>
</resolution>
</issue>
<issue>
<issue-num>142</issue-num>
<title>Name of "message" property on Message|Fault Reference component</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Bijan Parsia</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0046.html">email</a>]</p>
</description>
<proposal>
<p>TBD</p>
</proposal>
<resolution>
<p>Rename {message} property to {element}.</p>
</resolution>
</issue>
<issue>
<issue-num>141</issue-num>
<title>Should WSDL say anything about whitespace in SOAP:Body?</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Jacek</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0083.html">email</a>]</p>
</description>
<proposal>
<p>TBD</p>
</proposal>
<resolution>
<p>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.</p>
</resolution>
</issue>
<issue>
<issue-num>140</issue-num>
<title>Version attribute proposal</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Tom Jordahl</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0049.html">email</a>]</p>
</description>
<proposal>
<p>See email for complete proposal.</p>
</proposal>
<resolution>
<p>No action.</p>
</resolution>
</issue>
<issue>
<issue-num>139</issue-num>
<title>Non-deterministic schema</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Martin Gudgin</originator>
<responsible/>
<description>
<p>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. [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0045.html">email</a>]</p>
</description>
<proposal>
<p>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! </p>
</proposal>
<resolution>
<p>Adopted proposed resolution</p>
</resolution>
</issue>
<issue>
<issue-num>138</issue-num>
<title>Second level xs:import</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>DaveO</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0137.html">email</a>]</p>
</description>
<proposal>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0022.html">email</a>]</p>
</proposal>
<resolution>
<p>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.</p>
</resolution>
</issue>
<issue>
<issue-num>137</issue-num>
<title>Properties should not be limited to simple types</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Glen</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0034.html">email</a>]</p>
</description>
<proposal>
<p>Changing the xs:anySimpleType in section 2.7.2.3 to xs:anyType, and
appropriately reword the text in table 2-7.</p>
</proposal>
<resolution>
<p>Proposed resolution accepted.</p>
</resolution>
</issue>
<issue>
<issue-num>136</issue-num>
<title>Add in-optional-out MEP</title>
<locus>Part 2</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Yaron</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0166.html">email</a>]</p>
</description>
<proposal>
<p/>
</proposal>
<resolution>
<p>Accept the addition of the in-optional-out MEP to Part 2.</p>
</resolution>
</issue>
<issue>
<issue-num>135</issue-num>
<title>WSDL Specification readability</title>
<locus>Part 1</locus>
<requirement/>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>DaveO</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0160.html">email</a>]</p>
</description>
<proposal>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0059.html">email</a>]</p>
</proposal>
<resolution>
<p>Proposal rejected, will pursue a stylistic solution insteead. Issue reclassified as Editorial.
Editorial work rejected.</p>
</resolution>
</issue>
<issue>
<issue-num>134</issue-num>
<title>Proposal for adding Compositors</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Umit, et al</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0153.html">email</a>]</p>
</description>
<proposal/>
<resolution>
<p>Closed with no action.</p>
</resolution>
</issue>
<issue>
<issue-num>133</issue-num>
<title>Why aren't two input/output elements allowed to share the same @element value?</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>DaveO</originator>
<responsible/>
<description>
<p>
<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0139.html">email</a>]</p>
</description>
<proposal>
<p/>
</proposal>
<resolution>
<p>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).</p>
</resolution>
</issue>
<issue>
<issue-num>132</issue-num>
<title>Message attribute optional</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>DaveO</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0138.html">email</a>]</p>
</description>
<proposal>
<p/>
</proposal>
<resolution>
<p>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).</p>
</resolution>
</issue>
<issue>
<issue-num>131</issue-num>
<title>Treatment of optional extensions</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>DaveO</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0136.html">email</a>]</p>
</description>
<proposal/>
<resolution>
<p>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.</p>
</resolution>
</issue>
<issue>
<issue-num>130</issue-num>
<title>Need async request/response HTTP binding</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>DaveO</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0135.html">email</a>]</p>
</description>
<proposal>
<p/>
</proposal>
<resolution><p>Closed with no action.</p></resolution>
</issue>
<issue>
<issue-num>129</issue-num>
<title>Allow multiple values for import/include locations</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Yaron</originator>
<responsible/>
<description>
<p>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?</p>
<p>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. [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0119.html">email</a>]</p>
</description>
<proposal/>
<resolution>
<p>Closed with no action.</p>
</resolution>
</issue>
<issue>
<issue-num>128</issue-num>
<title>Two imports for the same namespace illegal?</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Yaron</originator>
<responsible/>
<description>
<p>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.</p>
<p>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? [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0119.html">email</a>]</p>
</description>
<proposal>
<p/>
</proposal>
<resolution>
<p>Add to spec to explicitly allow >2 imports
from same ns.</p>
</resolution>
</issue>
<issue>
<issue-num>127</issue-num>
<title>Behavior if import/include fails</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Yaron</originator>
<responsible/>
<description>
<p>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? [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0119.html">email</a>]</p>
</description>
<proposal>
<p/>
</proposal>
<resolution>
<p>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).</p>
</resolution>
</issue>
<issue>
<issue-num>126</issue-num>
<title>Confusion between binding and element names</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Yaron</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0118.html">email</a>]</p>
</description>
<proposal/>
<resolution>
<p>No consensus to change. Closed with no action.</p>
</resolution>
</issue>
<issue>
<issue-num>125</issue-num>
<title>Make messageReference mandatory</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Yaron</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0117.html">email</a>]</p>
</description>
<proposal>
<p/>
</proposal>
<resolution>
<p>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.</p>
</resolution>
</issue>
<issue>
<issue-num>124</issue-num>
<title>Semantics of mandatory properties and features</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Yaron</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0116.html">email</a>]</p>
</description>
<proposal/>
<resolution>
<p>Editors to clarify the spec to say that wsdl:required
attribute means that a feature must be understood and
it must be engaged.</p>
</resolution>
</issue>
<issue>
<issue-num>123</issue-num>
<title>Requiring all operations to be bound</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Yaron</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0115.html">email</a>] Might be reopening Issue 16.</p>
</description>
<proposal/>
<resolution>
<p>Further clarify the spec to make clear that all operations must be bound.</p>
</resolution>
</issue>
<issue>
<issue-num>122</issue-num>
<title>messageReference semantics on binding</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Yaron</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0114.html">email</a>]</p>
</description>
<proposal>
<p/>
</proposal>
<resolution>
<p>Intention expressed by Yaron is correct. Editors will add clarification.</p>
</resolution>
</issue>
<issue>
<issue-num>121</issue-num>
<title>Broken resolution of NCNAME or QNAME</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Yaron</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0113.html">email</a>]</p>
</description>
<proposal>
<p/>
</proposal>
<resolution>
<p>Editors to add clarification text with regards to issue 121.</p>
</resolution>
</issue>
<issue>
<issue-num>120</issue-num>
<title>Operation name feature</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Umit</originator>
<responsible/>
<description>
<p>Operation name feature <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0082.html">proposal</a>.</p>
</description>
<proposal>
<p/>
</proposal>
<resolution>
<p>Closed with no action.</p>
</resolution>
</issue>
<issue>
<issue-num>119</issue-num>
<title>Renaming @messageReference</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Bijan at Jan 04 FTF</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0013.html">FTF minutes</a>]</p>
</description>
<proposal>
<p>Rename @messageReference to @label.</p>
</proposal>
<resolution>
<p>Accepted, along with editorial license to adjust names in the component model accordingly.</p>
</resolution>
</issue>
<issue>
<issue-num>118</issue-num>
<title>Renaming @message</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Bijan at Jan 04 FTF</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0013.html">FTF minutes</a>]</p>
</description>
<proposal>
<p>Rename @message to @element.</p>
</proposal>
<resolution>
<p>Accepted.</p>
</resolution>
</issue>
<issue>
<issue-num>117</issue-num>
<title>Marking operations as 'safe'
</title>
<locus>Part 1</locus>
<requirement>
</requirement>
<priority>Design
</priority>
<topic/>
<status>Closed</status>
<originator>TAG</originator>
<responsible/>
<description>
</description>
<proposal>
<p>Marking operations as 'safe' </p>
</proposal>
<resolution>
<p>Add optional Boolean "safe" attribute to
interface operation, corresponding property in the
component model.</p>
</resolution>
</issue>
<issue>
<issue-num>116</issue-num>
<title>Renaming the label of MEPs</title>
<locus>Part 2</locus>
<requirement>
</requirement>
<priority>Design
</priority>
<topic/>
<status>Closed</status>
<originator>Jonathan Marsh
</originator>
<responsible/>
<description>
</description>
<proposal>
<p>Change MEP labels from A and B to IN and OUT</p>
</proposal>
<resolution>
<p>Proposed resolution accepted.</p>
</resolution>
</issue>
<issue>
<issue-num>115</issue-num>
<title>Improving on-the-wire conformance</title>
<locus>Part 1</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Jonathan Marsh
</originator>
<responsible/>
<description>
<p>Is there something we can do to improve conformance on
the wire between WSDL-based agents? This would prevent
us from getting immediately profiled.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Added conformance section delineating processor and document conformance.</p>
</resolution>
</issue>
<issue>
<issue-num>114</issue-num>
<title>Name of wsoap:fault/@name
</title>
<locus>Part 3</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Jonathan Marsh
</originator>
<responsible/>
<description>
<p>Open issue on the name of wsoap:fault/@name and
outfault/@name (should indicate that it is a reference,
not defining a name)</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Closed 5/21/2004 FTF. Obsolete, already fixed.</p>
</resolution>
</issue>
<issue>
<issue-num>113</issue-num>
<title>Operation style
</title>
<locus>Part 1</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Jacek Kopecki
</originator>
<responsible/>
<description>
<p>
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0054.html">email</a>].
</p>
</description>
<proposal>
<p>I'm here proposing an alternate approach to
indicating operation styles (not using the 'style' attribute).</p>
</proposal>
<resolution>
<p>Issue withdrawn after successfully resolving Issue 98.</p>
</resolution>
</issue>
<issue>
<issue-num>112</issue-num>
<title>New headers/body style?
</title>
<locus>Part 1</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Yaron Goland
</originator>
<responsible/>
<description>
<p>
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0069.html">email</a>].
</p>
</description>
<proposal>
<p>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.</p>
<p>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.</p>
<p>
<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0167.html">Revised proposal</a>, <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0170.html">friendly amendment</a>.
</p>
</proposal>
<resolution>
<p><a href="">Proposal</a> adopted as a feature (not required, built-in, or mandated by conformance.) Will go in Part 2.</p>
</resolution>
</issue>
<issue>
<issue-num>111</issue-num>
<title>Simplified syntax?
</title>
<locus>Part 1</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Yaron Goland
</originator>
<responsible/>
<description>
</description>
<proposal>
<p>
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0071.html">email</a>].
</p>
<p>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.</p>
</proposal>
<resolution>
<p>No Action.</p>
</resolution>
</issue>
<issue>
<issue-num>110</issue-num>
<title>Full URLReplacement?</title>
<locus>Part 3</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>Philippe Le Hegaret
</originator>
<responsible/>
<description>
<p>
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0051.html">email</a>].
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0059.html">email</a>].
</p>
</description>
<proposal>
<p>Should we allow complete URL replacement (changes to
portions of the URL other than query parameters) or only query parameter
mechanism?</p>
<p>Question raised as to whether all possible schemas can be encoded in a
URL, or only a restricted subset.</p>
<p>Should only RPC style be encoded?</p>
<p>Call it something other than RPC?</p>
<p>Will we support the body in text/xml encoding only, or also alternate
x-www-url-encoded (forms encoding) syntax?</p>
<p>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.</p>
<p>1) Is it good practice to extract part of your content to parameterize
your URI? If not, what is the best way?</p>
<p>2) Do we want to name the "restricted-to-simpleTypes RPC" style with a
URI ala the RPC styls?</p>
<p>3) What if you start using fragids?</p>
</proposal>
<resolution>
<p>Addressed by Philippe's comprehensive proposal, adopted on March 25 2004.</p>
</resolution>
</issue>
<issue>
<issue-num>109</issue-num>
<title>WSDL versioning
</title>
<locus>Part 1</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Paul Downey
</originator>
<responsible/>
<description>
<p>
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0016.html">email</a>].
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0076.html">email</a>].
</p>
</description>
<proposal>
<p>In the Interface Description section of the charter there is the following:</p>
<p>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. </p>
<p>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.</p>
<p>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.</p>
<p>Has this issue been lost, or is our reading of the charter incorrect ?</p>
</proposal>
<resolution>
<p>Joint TF with Schema and WSDL to investigate whether best practices can be developed, which will be included in the Primer.</p>
</resolution>
</issue>
<issue>
<issue-num>108</issue-num>
<title>Properties and schema other than XSD
</title>
<locus>Part 1</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Roberto Chinnici
</originator>
<responsible/>
<description>
<p>
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0006.html">email</a>].
</p>
</description>
<proposal>
<p>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.</p>
</proposal>
<resolution>
<p>Accept proposal</p>
</resolution>
</issue>
<issue>
<issue-num>107</issue-num>
<title>Schema for vector, matrix, array
</title>
<locus>Primer</locus>
<requirement>
</requirement>
<priority>Editorial</priority>
<topic/>
<status>Active</status>
<originator>Paul Downey
</originator>
<responsible/>
<description>
<p>
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0048.html">email</a>].
</p>
</description>
<proposal>
<p>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.
</p>
<p>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. </p>
</proposal>
<resolution/>
</issue>
<issue>
<issue-num>106</issue-num>
<title>Using RDF in WSDL
</title>
<locus>RDF Mapping</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Active</status>
<originator>Jacek Kopecky
</originator>
<responsible/>
<description>
<p>
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003May/0076.html">email</a>].
</p>
<p>How can RDF statements (including OWL statements) be represented in WSDL?</p>
</description>
<proposal>
</proposal>
<resolution/>
</issue>
<issue>
<issue-num>105</issue-num>
<title>Abstract Faults
</title>
<locus>Part 1</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Paul Downey
</originator>
<responsible/>
<description>
<p>
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0046.html">email</a>].
</p>
</description>
<proposal>
<p>Proposal to hoist faults into the interface alongside operations.</p>
</proposal>
<resolution>
<p>Accept <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0064.html">Paul's proposal</a> 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.</p>
</resolution>
</issue>
<issue>
<issue-num>104</issue-num>
<title>Appendix E cleanup
</title>
<locus>Part 1</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Jacek Kopecky
</originator>
<responsible/>
<description>
<p>
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0136.html">email</a>].
</p>
</description>
<proposal>
<p>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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
</proposal>
<resolution>
<p>Issue factored into issues 143, 144, 145.</p>
</resolution>
</issue>
<issue>
<issue-num>103</issue-num>
<title>Proposal for combining the two attribute operation styles to one
</title>
<locus>Part 1</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Jacek Kopecky
</originator>
<responsible/>
<description>
<p>
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. [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0164.html">email</a>].
</p>
</description>
<proposal>
</proposal>
<resolution>Close issue 103 as irrelevant since styles are removed.</resolution>
</issue>
<issue>
<issue-num>102</issue-num>
<title>Schemas in imported WSDL
</title>
<locus>Part 1</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Allen Brookes
</originator>
<responsible/>
<description>
<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? [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0109.html">email</a>].
</p>
</description>
<proposal>
</proposal>
<resolution>Issue 102 closed with Glen's wording and with "root"
changed to "importing".</resolution>
</issue>
<issue>
<issue-num>101</issue-num>
<title>Support SOAP 1.2 transport binding framework
</title>
<locus>Part 3</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Jacek Kopecky
</originator>
<responsible/>
<description>
<p>
Issue <a href="#x23">23</a> 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 [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0014.html">email</a>].
</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Closed 5/21/2004 FTF. Already handled by @protocol and F&P.</p>
</resolution>
</issue>
<issue>
<issue-num>100</issue-num>
<title>Support SOAP 1.2 RPC</title>
<locus>Part 3</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Jacek Kopecky
</originator>
<responsible/>
<description>
<p>
Issue <a href="#x23">23</a> 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 [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0014.html">email</a>].
</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Closed 5/21/2004 FTF. Can't support without a SOAP data model
schema language (see issue 97).</p>
</resolution>
</issue>
<issue>
<issue-num>99</issue-num>
<title>Support SOAP 1.2 data model and encoding</title>
<locus>Part 3</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Jacek Kopecky
</originator>
<responsible/>
<description>
<p>
Issue <a href="#x23">23</a> 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 [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0014.html">email</a>].
(See related issue <a href="#x97">97</a>.)
</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Closed 5/21/2004 FTF. Resolved as duplicate of 97.</p>
</resolution>
</issue>
<issue>
<issue-num>98</issue-num>
<title> > 1 style per interface
</title>
<locus>Part 1, 3</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Jacek Kopecky
</originator>
<responsible/>
<description>
<p>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? </p>
</description>
<proposal>
</proposal>
<resolution>Make @style an unordered list of URIs</resolution>
</issue>
<issue>
<issue-num>97</issue-num>
<title>Schema language for SOAP encoding</title>
<locus>Part 3</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Jacek Kopecky
</originator>
<responsible/>
<description>
<p>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?</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Closed 5/21/2004 FTF. We will not do this new schema language
for soap data model.</p>
</resolution>
</issue>
<issue>
<issue-num>96</issue-num>
<title>Support for SOAP intermediaries
</title>
<locus>Part 3</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Jean-Jacques Moreau [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0331.html">email</a>]
</originator>
<responsible/>
<description>
<p>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?</p>
<p>[See also a followup message from Ugo Corda, pointing to additional
potential issues <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0004.html">email</a>]</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Closed 5/19/2004 FTF.</p>
</resolution>
</issue>
<issue>
<issue-num>95</issue-num>
<title>service/@name required?
</title>
<locus>Part 1</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>5 Nov 2003 f2f
</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal>
</proposal>
<resolution>@name optional for the standalone service type use. it
will be required inside the context of a wsdl document.
we may be able to describe in the schema as well as in
the spec but we should check for side effect. Close
issue 95.</resolution>
</issue>
<issue>
<issue-num>94</issue-num>
<title>Include cycles
</title>
<locus>Part 1</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Amy Lewis [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0056.html">email</a>]
</originator>
<responsible/>
<description>
<p>What happens if the same location is included twice or if
there are include cycles? The XMLSchema spec explicitly
permits them.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Per 18 Dec 2003 telecon, decided to make multiple
includes same as one. [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0019.html">email</a>].</p>
</resolution>
</issue>
<issue>
<issue-num>93</issue-num>
<title>Uniqueness across wsdl:definitions
</title>
<locus>Primer</locus>
<requirement>
</requirement>
<priority>Editorial</priority>
<topic/>
<status>Active</status>
<originator>Sanjiva Weerawarana
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0146.html">email</a>]
</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal>
<p>Per 2 Oct 2003 telecon, decided to include
recommended practice re: use of namespace across documents in
primer.</p>
</proposal>
<resolution/>
</issue>
<issue>
<issue-num>92</issue-num>
<title>Layering message patterns
</title>
<locus>Part 2</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>FABLET Youenn
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0176.html">email</a>]
</originator>
<responsible/>
<description>
<p>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</p>
</description>
<proposal/>
<resolution>
<p>Obsoleted by MEP work now completed.</p>
</resolution>
</issue>
<issue>
<issue-num>91</issue-num>
<title>MEP terminology
</title>
<locus>Part 1, 2, 3</locus>
<requirement>
</requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>David Booth
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0061.html">email</a>]
</originator>
<responsible/>
<description/>
<proposal/>
<resolution>Issue 91 is closed, editors will use the term "Message
Exchange Pattern" rather than "Message Pattern".</resolution>
</issue>
<issue>
<issue-num>90</issue-num>
<title>Use WSA terms?
</title>
<locus>Part 1, 2, 3</locus>
<requirement>
</requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>David Booth
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0068.html">email</a>]
</originator>
<responsible/>
<description/>
<proposal/>
<resolution>
<p>Accepted, editors to use WSA terms when possible.</p>
</resolution>
</issue>
<issue>
<issue-num>89</issue-num>
<title>Binding message references in component model
</title>
<locus>Part 1, 2, 3</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Roberto Chinnici
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0077.html">email</a>]
</originator>
<responsible/>
<description/>
<proposal/>
<resolution>Close issue 89 by changing the namespace of wsoap:fault
to wsdl:fault, and add a corresponding component in the
abstract model.</resolution>
</issue>
<issue>
<issue-num>88</issue-num>
<title>Rename wsdl:operation to wsdl:messageExchange?
</title>
<locus>Part 1, 3</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Savas Parastatidis
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0024.html">email</a>]
</originator>
<responsible/>
<description/>
<proposal/>
<resolution>
<p>Per 30 Oct 2003 teleconference, decided not to change the name
of this element.</p>
</resolution>
</issue>
<issue>
<issue-num>87</issue-num>
<title>Redundant direction information
</title>
<locus>Part 1, 2</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Raised at 10 Sep 2003 <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0045.html">e-mail</a>.
</originator>
<responsible/>
<description>
<p>Redundant direction information between children of
operation/{input, output} and direction information in MEP URI.</p>
</description>
<proposal/>
<resolution>Close issue #87 with no action.</resolution>
</issue>
<issue>
<issue-num>86</issue-num>
<title>New @soapActionURI?</title>
<locus>Part 3</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Raised at 4 Sep 2003 <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0018.html">teleconference</a>.
</originator>
<responsible/>
<description>
<p>Should we define a new binding element for @soapActionURI?</p>
</description>
<proposal/>
<resolution>
<p>Closed 5/21/2004 FTF. Obsolete - we already have added soapAction attribute.</p>
</resolution>
</issue>
<issue>
<issue-num>85</issue-num>
<title>HTTP binding depends on message/part</title>
<locus>Part 3</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>Philipe Le Hegaret
</originator>
<responsible/>
<description>
<p>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?</p>
</description>
<proposal/>
<resolution>
<p>URL replacement syntax incorported. New issue 158 openned to track HTTP headers portion of this issue.</p>
</resolution>
</issue>
<issue>
<issue-num>84</issue-num>
<title>SOAP header faults needed?</title>
<locus>Part 3</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Sanjiva Weerawana</originator>
<responsible/>
<description>
<p>Do we need to define SOAP header faults? Are they
currently in use? If so, are we defining them correctly?</p>
</description>
<proposal/>
<resolution>
<p>Closed 5/21/2004 FTF. Obsolete: SOAP header faults are already gone.</p>
</resolution>
</issue>
<issue>
<issue-num>83</issue-num>
<title>Interaction between binding extensions
</title>
<locus>Part 1, 3</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Glen Daniels
</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal/>
<resolution>Issue 83 is closed with no action.</resolution>
</issue>
<issue>
<issue-num>82</issue-num>
<title>Relax binding syntax
</title>
<locus>Part 1</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Glen Daniels
</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal/>
<resolution>given the changes to the syntax, we close issue 82 with no
action.</resolution>
</issue>
<issue>
<issue-num>81</issue-num>
<title>Account for interface inheritance
</title>
<locus>Part 1</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Philipe Le Hegaret
</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal>Duplicate of 76?</proposal>
<resolution>Issue 81 closed without action, no compelling
scenario and workaround exists.</resolution>
</issue>
<issue>
<issue-num>80</issue-num>
<title>Inappropriate binding component name
</title>
<locus>Part 1</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>David Booth
</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal/>
<resolution>Keep "binding", close issue 80 with no action.</resolution>
</issue>
<issue>
<issue-num>79</issue-num>
<title>How much validation?
</title>
<locus>Part 1, 2</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Umit Ulcinap
</originator>
<responsible/>
<description>
<p>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?</p>
</description>
<proposal/>
<resolution>
<p>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)</p>
</resolution>
</issue>
<issue>
<issue-num>78</issue-num>
<title>Implied value for interface/.*put
</title>
<locus>Part 1, 2</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Sanjiva Weerawana
</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal/>
<resolution>
<p>Per 4 Sep 2003 <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0018.html">teleconference</a>,
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.</p>
</resolution>
</issue>
<issue>
<issue-num>77</issue-num>
<title>[local name] for interface/.*put
</title>
<locus>Part 1, 2</locus>
<requirement>
</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Sanjiva Weerawana
</originator>
<responsible/>
<description>
<p>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).</p>
</description>
<proposal/>
<resolution>
<p>Per 11 Sep 2003 telecon, decided to use 'messageReference'.</p>
</resolution>
</issue>
<issue>
<issue-num>76</issue-num>
<title>Pointing to derived interfaces</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>WG</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal/>
<resolution>Duplicate of issue 81</resolution>
</issue>
<issue>
<issue-num>75</issue-num>
<title>Incoherence between WSA and WSD MEPs</title>
<locus>Part 2</locus>
<requirement/>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>Someone @ XMLEurope2003</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal/>
<resolution>
<p>Issue is obsolete - Patterns and MEPs have converged</p>
</resolution>
</issue>
<issue>
<issue-num>74</issue-num>
<title>Clarify name for parts in SOAP binding</title>
<locus>Part 3</locus>
<requirement/>
<priority>Editorial</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Carl Binding</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/public-ws-desc-comments/2003Mar/0001.html">email</a>]
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?</p>
</description>
<proposal/>
<resolution>
<p>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.</p>
</resolution>
</issue>
<issue>
<issue-num>73</issue-num>
<title>Clarify Fault versus Body in SOAP binding</title>
<locus>Part 3</locus>
<requirement/>
<priority>Editorial</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Carl Binding</originator>
<responsible/>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/public-ws-desc-comments/2003Mar/0001.html">email</a>]
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.</p>
</description>
<proposal/>
<resolution>
<p>Closed 5/21/2004 FTF. Obsolete - text has been completely rewritten.</p>
</resolution>
</issue>
<issue>
<issue-num>72</issue-num>
<title>Describe XMLP attachments</title>
<locus>Part 3</locus>
<requirement/>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Jonathan Marsh</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal/>
<resolution>
<p>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.</p>
</resolution>
</issue>
<issue>
<issue-num>71</issue-num>
<title>Optional message content in http:urlReplacement</title>
<locus>Part 3</locus>
<requirement>R128</requirement>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>David Orchard</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal>
<p>The current HTTP binding now defines how only some
parts may map into the request URI and meets revised R128
wording. [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003May/0068.html">email</a>]</p>
</proposal>
<resolution>
<p>Accepted per 29 May 2003 teleconference.</p>
</resolution>
</issue>
<issue>
<issue-num>issue toplevel element name uniqueness</issue-num>
<title>Should all top-level elements' names be unique across the
target namespace?</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic>
</topic>
<status>Closed</status>
<originator>Eric Prud'hommeaux</originator>
<responsible/>
<description>
<p>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?</p>
</description>
<proposal>
</proposal>
<resolution>
<p> Resolved at November 2002 FTF. WSDL 1.2 will retain multiple
symbol spaces, one for each top level construct.</p>
</resolution>
</issue>
<issue>
<issue-num>issue transition documentation</issue-num>
<title>Do we need to provide user documentation describing the
transition between WSDL 1.1 and WSDL 1.2?</title>
<locus>Both</locus>
<requirement/>
<priority>Editorial</priority>
<topic>
</topic>
<status>Closed</status>
<originator>Jonathan Marsh</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p> Resolved to add a non-normative appendix detailing the changes
from 1.1 to 1.2</p>
</resolution>
</issue>
<issue>
<issue-num>issue add include</issue-num>
<title>Should we add an "include" mechanism?</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic>
</topic>
<status>Closed</status>
<originator>Sanjiva Weerawarana</originator>
<responsible/>
<description>
<p>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?</p>
</description>
<proposal/>
<resolution>
<p>No include will be added.</p>
<p>Issue re-opened. Discussed at November 2002 FTF. Resolved to
add a wsdl:include mechanism that works like xs:include sans
chameleon behaviour.</p>
</resolution>
</issue>
<issue>
<issue-num>issue clarify import</issue-num>
<title>Clarify semantics of import.</title>
<locus/>
<requirement/>
<priority>Editorial</priority>
<topic>
</topic>
<status>Closed</status>
<originator>Sanjiva Weerawarana</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>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.</p>
</resolution>
</issue>
<issue>
<issue-num>issue importing documents in same namespace</issue-num>
<title>Should imports of documents in the same namespace be
possible?</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic>
</topic>
<status>Closed</status>
<originator>Sanjiva Weerawarana</originator>
<responsible/>
<description>
<p>WSDL 1.1 allows imports to documents in the same
namespace. The constraint text:
</p>
<p>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. </p>
<p> in the spec disallows this</p>
</description>
<proposal>
</proposal>
<resolution>
<p> Resolved at November 2002 FTF that wsdl:import will work exactly
like xs:import.</p>
</resolution>
</issue>
<issue>
<issue-num>issue service type</issue-num>
<title>Should we have an abstract view of a service?</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic>
</topic>
<status>Closed</status>
<originator>Sanjiva Weerawarana</originator>
<responsible/>
<description>
<p>WSDL defines a service as a collection of ports, but there is no
abstract analog.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Introduced serviceTypes at June 2002 F2F. removed again at September
2002 FTF.</p>
</resolution>
</issue>
<issue>
<issue-num>issue multiple services</issue-num>
<title>Should a single WSDL file only define one service?</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic>
</topic>
<status>Closed</status>
<originator>Sanjiva Weerawarana</originator>
<responsible/>
<description>
<p>WSDL 1.1 supports having multiple services in a single WSDL
file. This has caused confusion amongst users.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Allow multiple services, where each MAY be of
a different service type. (At the June F2F.)</p>
</resolution>
</issue>
<issue>
<issue-num>issue implements attribute</issue-num>
<title>Should there be an implements attribute on 'service'</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic>
</topic>
<status>Closed</status>
<originator>Sanjiva Weerawarana</originator>
<responsible/>
<description>
<p>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?</p>
</description>
<proposal>
</proposal>
<resolution>
<p> resolved at November 2002 FTF NOT to add an implements attribute
to the service element</p>
</resolution>
</issue>
<issue>
<issue-num>issue fault name uniqueness</issue-num>
<title>Should faults be named with QNames?</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic>
</topic>
<status>Closed</status>
<originator>Sanjiva Weerawarana</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal>
</proposal>
<resolution>
Close issue-fault-name-uniqueness - works just like
operations (no change to spec).
</resolution>
</issue>
<issue>
<issue-num>issue allow nonxml typesystems</issue-num>
<title>Allow non-XML type systems?</title>
<locus>part 1</locus>
<requirement/>
<priority>Design</priority>
<topic>
</topic>
<status>Closed</status>
<originator>September 2002 Face-to-face</originator>
<responsible/>
<description>
<p>Do we want to allow WSDL 1.2 to use type systems which are NOT
XML based</p>
</description>
<proposal>
<p> non-XML type systems are allowed via extensibility attributes of
message/part elements.</p>
</proposal>
<resolution>Fixed.
</resolution>
</issue>
<issue>
<issue-num>issue operation patterns</issue-num>
<title>Should more operation patterns be supported?</title>
<locus>Part 1</locus>
<requirement/>
<priority/>
<topic>
</topic>
<status>Closed</status>
<originator>Prasad Yendluri</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>This issue is closed by leaving it to the realm of
orchestration languages and applications. June 11, 2002 (at
face-to-face).</p>
</resolution>
</issue>
<issue>
<issue-num>issue extensible message exchange patterns</issue-num>
<title>Should we have a mechanism to define extensible message
exchange patterns?</title>
<locus>part 1</locus>
<requirement/>
<priority/>
<topic>
</topic>
<status>Closed</status>
<originator>Glen Daniels</originator>
<responsible/>
<description>
<p>See http://lists.w3.org/Archives/Public/www-ws-desc/2002May/0271.html</p>
</description>
<proposal>
</proposal>
<resolution>
<p>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).</p>
<p>
Further discussion on this issue occured during the November 2002 FTF.
</p>
<p>
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 )
</p>
</resolution>
</issue>
<issue>
<issue-num>issue require type match for in out parameters</issue-num>
<title>For a part to be an in/out parameter, the type must
match.</title>
<locus>Part 1</locus>
<requirement/>
<priority/>
<topic>
</topic>
<status>Closed</status>
<originator>Jacek Kopecky</originator>
<responsible/>
<description>
<p>For a parameter to be considered in/out it must also be the case
that the parts be of exactly the same type.</p>
</description>
<proposal>
</proposal>
<resolution>
<p> Unknown. Issue is closed but no resolution is recorded. May be
related to removal of parameterOrder</p>
</resolution>
</issue>
<issue>
<issue-num>issue remove parameter order</issue-num>
<title>Should we remove parameter order?</title>
<locus>part 1</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>
</topic>
<status>Closed</status>
<originator>Sanjiva Weerawarana</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p> Resolved at September 2002 Face-to-face, Alex, VA to remove
paramterOrder attribute</p>
</resolution>
</issue>
<issue>
<issue-num>issue remove notification operations</issue-num>
<title>Should we remove notification operations?</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>
</topic>
<status>Closed</status>
<originator>Sanjiva Weerawarana</originator>
<responsible/>
<description>
<p>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.
</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Per the 20-22 Jan 2003 face to face meeting, there will be a one-way, output-only MEP.</p>
</resolution>
</issue>
<issue>
<issue-num>issue remove solicit response operations</issue-num>
<title>Should we remove solicit-response operations?</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic>
</topic>
<status>Closed</status>
<originator>Sanjiva Weerawarana</originator>
<responsible/>
<description>
<p>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.
</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Per the 20-22 Jan 2003 face to face meeting, there will be a output-input MEP.</p>
</resolution>
</issue>
<issue>
<issue-num>issue operation overloading</issue-num>
<title>Should operation overloading be disallowed?</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic>
</topic>
<status>Closed</status>
<originator>Joyce Yang</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Do not allow operation overloading. See minutes
for telecon on June 27, 2002 and follow-on email discussion.</p>
</resolution>
</issue>
<issue>
<issue-num>issue portType extensibility</issue-num>
<title>Should portTypes be extensible?</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic>
</topic>
<status>Closed</status>
<originator>Sanjiva Weerawarana</originator>
<responsible/>
<description>
<p>Some users have asked that portTypes be extensible. We need to
carefully consider whether that is a good thing or not.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Closed. port type extensibility added 20021010.</p>
</resolution>
</issue>
<issue>
<issue-num>issue operation name uniqueness</issue-num>
<title>Need to be able to distinguish between operations with the
same NCName in different portTypes</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic>
</topic>
<status>Closed</status>
<originator>Steve Tuecke</originator>
<responsible/>
<description>
<p>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</p>
</description>
<proposal>
<p> Proposal to make operations top-level constructs ( and hence named
by QName ) presented at November 2002 FTF</p>
</proposal>
<resolution>
<p> 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.</p>
</resolution>
</issue>
<issue>
<issue-num>issue clarify type and element</issue-num>
<title>Clarify use of type= and element= in part with XML Schema
experts.</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic>
</topic>
<status>Closed</status>
<originator>Keith Ballinger</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0030.html">email</a>]
</proposal>
<resolution>
<p>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'.</p>
</resolution>
</issue>
<issue>
<issue-num>issue message parts</issue-num>
<title>Should the message part mechanism be extended to support optional
parts etc.?</title>
<locus>Part 1</locus>
<requirement/>
<priority>Design</priority>
<topic>
</topic>
<status>Closed</status>
<originator>Sanjiva Weerawarana</originator>
<responsible/>
<description>
<p>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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>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.</p>
<p>Per 30 July 2003 meeting in Raleigh, NC, decided to
eliminate message construct and use XML Schema (or some
other type system) directly.</p>
</resolution>
</issue>
<issue>
<issue-num>issue eliminate message</issue-num>
<title> Can we eliminate <message> in favor of a schema mechanism?
</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>
</topic>
<status>Closed</status>
<originator>Keith Ballinger, Jeffrey Schlimmer, Others</originator>
<responsible/>
<description>
<p> 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.</p>
<p>
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 )
</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Original resolution: We will consider this for WSDL 2.0. For WSDL 1.2,
we will not remove the <message> construct.</p>
<p>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.
</p>
</resolution>
</issue>
<issue>
<issue-num>issue references with qname</issue-num>
<title> Should intra-namespace references using only localParts be supported?
</title>
<locus>Part 1</locus>
<requirement/>
<priority/>
<topic>
</topic>
<status>Closed</status>
<originator>Sanjiva Weerawarana</originator>
<responsible/>
<description>
<p> 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. </p>
</description>
<proposal>
</proposal>
<resolution>
<p> 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.</p>
</resolution>
</issue>
<issue>
<issue-num>issue remove optional name of definition</issue-num>
<title> Should we remove the optional name attribute of
<definitions>?
</title>
<locus>Part 1</locus>
<requirement/>
<priority/>
<topic>
</topic>
<status>Closed</status>
<originator>Sanjiva Weerawarana</originator>
<responsible/>
<description>
<p> 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. </p>
</description>
<proposal>
</proposal>
<resolution>
<p>Decided to remove during the July 18th telecon.</p>
</resolution>
</issue>
<issue>
<issue-num>issue require targetnamespace</issue-num>
<title>Require targetNamespace attribute?</title>
<locus>Part 1</locus>
<requirement/>
<priority/>
<topic/>
<status>Closed</status>
<originator>Sanjiva Weerawarana</originator>
<responsible/>
<description>
<p> 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. </p>
</description>
<proposal/>
<resolution>
<p> Accepted during telcon on June 27,
2002.</p>
</resolution>
</issue>
<issue>
<issue-num>70</issue-num>
<title>Confusing description between soap:body and soap:fault</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:jgreif@alumni.princeton.edu">Jeff Greif</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://lists.w3.org/Archives/Public/public-ws-desc-comments/2002Oct/0002.html">email</a>]
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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Remove example; rewrite in primer.</p>
</resolution>
</issue>
<issue>
<issue-num>69</issue-num>
<title>Confusing description between soap:body and soap:fault</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:pyendluri@webmethods.com">Prasad Yendluri</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Nov/0055.html">email</a>]
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".</p>
<p>Current spec for the soap:bind extensions stands as follows:</p>
<p><soap:header message="qname" part="nmtoken" use="literal|encoded"
encodingStyle="uri-list"? namespace="uri"?>*</p>
<p>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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>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. [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0014.html">email</a>]
</p>
</resolution>
</issue>
<issue>
<issue-num>68</issue-num>
<title>Confusing description between soap:body and soap:fault</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:MJones@NetSilicon.com">Matthew Jones</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/public-ws-desc-comments/2002Aug/0000.html">email</a>]
Section 2.5 talks about soap:binding, the first sentence is:</p>
<p>The soap:body element specifies how the message parts appear inside the
SOAP Fault element.</p>
<p>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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Closed 5/21/2004 FTF. Obsolete, parts are gone.</p>
</resolution>
</issue>
<issue>
<issue-num>67</issue-num>
<title>Invoking HTTP GET with no arguments</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:paul@prescod.net">Paul Prescod</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Jul/0107.html">email</a>]
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.</p>
</description>
<proposal>
<p>Make http:operation/@location optional.</p>
</proposal>
<resolution>
<p>Incorporated per [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003May/0053.html">Rennes Meeting</a>].</p>
</resolution>
</issue>
<issue>
<issue-num>66</issue-num>
<title>How to represent the equivalent of hypertext links?</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:rubys@apache.org">Sam Ruby</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Jul/0106.html">email</a>]
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Jul/0107.html">email</a>]
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:</p>
<p>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.</p>
<p>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/.</p>
<p>3) The resulting document contains an element of exactly the same shape
and form as in step (1), and the cycle continues.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>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.</p>
</resolution>
</issue>
<issue>
<issue-num>65</issue-num>
<title>WSDL binding for FTP?</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>FTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:distobj@acm.org">Naresh Agarwal</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Jul/0012.html">email</a>]
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:</p>
<p>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?
</p>
<p>2)"soapAction" <definitions>\<bindings>\<operation>\<soap:operation> will no more be used.</p>
<p>3) "location" attribute <definitions>\<service>\<port>\<soap:address> would be a FTP URL</p>
<p>Am i missing something? Do i need to make any other changes in the WSDL bindings?</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Per 11 Dec 2003 telecon, decided we won't be doing a
SOAP/FTP binding [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0014.html">email</a>].</p>
</resolution>
</issue>
<issue>
<issue-num>64</issue-num>
<title>Operations and HTTP verbs</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:distobj@acm.org">Mark Baker</a>
</originator>
<responsible>Unassigned</responsible>
<description>
[<a href="http://lists.w3.org/Archives/Public/public-ws-desc-comments/2002Jul/0000">email</a>]
<p>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.</p>
<p>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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Adopt Hugo's <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0031.html">proposal</a>; open syntax issues 169, 170.</p>
</resolution>
</issue>
<issue>
<issue-num>63</issue-num>
<title>SOAP binding violates separation of abstract definitions concrete bindings</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:pyendluri@webmethods.com">Prasad Yendluri</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Jun/0006.html">email</a>]
Section 2.3 (Messages) of WSDL spec permits defining parts of
a message using either "type" or "element" attribute:</p>
<pre><definitions .... > <message name="nmtoken"> * <part
name="nmtoken" element="qname"? type="qname"?/> *
</message> </definitions></pre>
<p>Section '2.3.2 Abstract vs. Concrete Messages' also states:</p>
<p>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.</p>
<p>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":</p>
<p>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.</p>
<p>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.</p>
<p>If use is literal, then each part references a concrete
schema definition using either the element or type attribute.</p>
<p>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.</p>
<p>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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>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.</p>
</resolution>
</issue>
<issue>
<issue-num>62</issue-num>
<title>Specify a specific SOAP fault code to be returned</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:jasnell@us.ibm.com">James Snell</a>
</originator>
<responsible>Unassigned</responsible>
<description>
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Jun/0048.html">email</a>]
<p>
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.</p>
<pre><operation name="doWapSheDangDang">
<soap:operation ... />
<input>...</input>
<output>...</output>
<fault name="fault-name">
<soap:fault name="fault-name" use="encoded" encodingStyle="..."
namespace="..." />
</fault>
</operation></pre>
<p>The soap:fault element "specifies the contents of the
contents of the SOAP Fault Details element", it says
absolutely nothing about the fault code.</p>
<p>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.</p>
<p>Just one possible way of addressing this... (I'm sure ya'll
could come up with a better one)</p>
<pre><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></pre>
</description>
<proposal>
</proposal>
<resolution>
<p>Closed 5/21/2004 FTF. Obsolete, ability to specify code/subcodes has already been added.</p>
</resolution>
</issue>
<issue>
<issue-num>61</issue-num>
<title>Additional SOAP binding for HTTP GET-in/SOAP-out</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:dorchard@bea.com">David Orchard</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-tag/2002Jun/0161.html">email</a>]
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.</p>
</description>
<proposal>
</proposal>
<resolution><p>Closed at 5/21/2004 FTF.</p></resolution>
</issue>
<issue>
<issue-num>60</issue-num>
<title>Inconsistency regarding optional parts</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Editorial</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:pyendluri@webmethods.com">Prasad Yendluri</a>
</originator>
<responsible>Unassigned</responsible>
<description>
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Jun/0011.html">email</a>]
<p>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:</p>
<p>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.</p>
<p>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.</p>
</description>
<proposal>
</proposal>
<resolution>Primer will contain new examples.
</resolution>
</issue>
<issue>
<issue-num>59</issue-num>
<title>MIME Binding permits 0 parts in multipart/related</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Editorial</priority>
<topic>MIME</topic>
<status>Closed</status>
<originator>
<a href="mailto:pyendluri@webmethods.com">Prasad Yendluri</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0081.html">email</a>]
A 4.4 MIME Binding Schema permits "zero" parts in multipart/related.</p>
<pre><element name="multipartRelated" type="mime:multipartRelatedType"/>
<complexType name="multipartRelatedType" content="elementOnly">
<element ref="mime:part" minOccurs="0" maxOccurs="unbounded"/>
</complexType></pre>
<p>This is not legal.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>MIME Binding outside the scope of our charter, closing issue with no action.</p>
</resolution>
</issue>
<issue>
<issue-num>58</issue-num>
<title>Permit "message" attribute in mime:content binding?</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>MIME</topic>
<status>Closed</status>
<originator>
<a href="mailto:pyendluri@webmethods.com">Prasad Yendluri</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0081.html">email</a>]
The <mime:content> is defined with a "part" and a "type" attribute spec.
E.g.</p>
<pre><output>
..
<mime:part>
<mime:content part="docs" type="text/html"/>
</mime:part>
</output>
</pre>
<p>
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"/></p>
</description>
<proposal>
</proposal>
<resolution>
<p>MIME Binding outside the scope of our charter, closing issue with no action.</p>
</resolution>
</issue>
<issue>
<issue-num>57</issue-num>
<title>Should Operations permit alternate and multiple responses?</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>
<a href="mailto:pyendluri@webmethods.com">Prasad Yendluri</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0081.html">email</a>]
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.</p>
</description>
<proposal>
</proposal>
<resolution>
<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Jun/0251.html">email</a>
</resolution>
</issue>
<issue>
<issue-num>56</issue-num>
<title>Define means to specify an authentication requirement</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:paul@prescod.net">Paul Prescod</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0123.html">email</a>]
need a way to specify an authentication requirement [in the HTTP binding]</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Closed 5/20/2004 FTF. See resolution of issue 165.</p>
</resolution>
</issue>
<issue>
<issue-num>55</issue-num>
<title>Define binding to HTTP headers</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:paul@prescod.net">Paul Prescod</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0123.html">email</a>]
need a way to set HTTP headers [in the HTTP binding]</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Closed 5/20/2004 FTF.</p>
</resolution>
</issue>
<issue>
<issue-num>54</issue-num>
<title>Allow binding to any HTTP method</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:paul@prescod.net">Paul Prescod</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0123.html">email</a>]
any HTTP method should be allowed [in the HTTP binding]</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Closed 5/20/2004 FTF. Extensibility in the HTTP method will be provided per the proposal at <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0057.html">http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0057.html</a>, with the amendment that the default media type will be x-www-url-encoded.</p>
</resolution>
</issue>
<issue>
<issue-num>53</issue-num>
<title>Allow operations within a binding to use different HTTP methods</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:paul@prescod.net">Paul Prescod</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0123.html">email</a>]
each operation in a binding should choose its own method, not one for all</p>
</description>
<proposal>
<p>Define http:operation/@verb.</p>
</proposal>
<resolution>
<p>Incorporated per [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003May/0053.html">Rennes Meeting</a>].</p>
</resolution>
</issue>
<issue>
<issue-num>52</issue-num>
<title>Allow operation addresses to be absolute</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:paul@prescod.net">Paul Prescod</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0123.html">email</a>]
operation addresses should not be required to be relative</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Closed 5/21/2004 FTF. Closed without action: Can be achieved by putting one operation
per interface and bind the interface to a uri.</p>
</resolution>
</issue>
<issue>
<issue-num>51</issue-num>
<title>Asymmetry between soap:body and soap:header</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:kevin.liu@sap.com">Kevin Liu</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Feb/0023.html">email</a>]
This issue can be viewed as an example our observation that
the binding extension specification is not clearly documented and
not sufficient.</p>
<p>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 ". </p>
<p>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 ". </p>
<p>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.</p>
<p>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> </p>
<p>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. </p>
<p>There is no explanation about:</p>
<p>* Why does soap:header need to have the "message" and "part"
attributes while soap:body can be bound to a particular
input/output message? </p>
<p> * 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?
</p>
<p>* 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?</p>
</description>
<proposal>
</proposal>
<resolution>Fixed.
</resolution>
</issue>
<issue>
<issue-num>50</issue-num>
<title>SOAP examples declare arrays using an obsolete schema syntax</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:kevin.liu@sap.com">Kevin Liu</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Feb/0023.html">email</a>]
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.</p>
<p>References:
Section 3.1 SOAP Examples (example 5)
Section 5.11 MIME Binding example (example 7)</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Removed example; rewrite in primer.</p>
</resolution>
</issue>
<issue>
<issue-num>49</issue-num>
<title>Inconsistency in "soap:header" specification</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Editorial</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:kevin.liu@sap.com">Kevin Liu</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Feb/0023.html">email</a>]
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</p>
<p>References:
Section 3.7 sopa:header and soap:headfault
A 4.2 SOAP Binding Schema</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Fixed.</p>
</resolution>
</issue>
<issue>
<issue-num>48</issue-num>
<title>"use" attribute of "soap:body" should be optional</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Editorial</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:kevin.liu@sap.com">Kevin Liu</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Feb/0023.html">email</a>]
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"</p>
<p>References:
Section 3.3 soap:binding
A 4.2 SOAP Binding Schema</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Resolved at the 22 Sep 2003 consistent with prior decision to
eliminate the use of SOAP encoding.</p>
</resolution>
</issue>
<issue>
<issue-num>47</issue-num>
<title>"soap:operation" should be optional</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Editorial</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:kevin.liu@sap.com">Kevin Liu</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Feb/0023.html">email</a>]
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."</p>
<p>However, in the SOAP Binding schema, no value is specified
for minOccur/maxOccur. It implies that this element is required.</p>
<p>References:
Section 3.4 soap:operation
A 4.2 SOAP Binding Schema</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Closed 5/21/2004 FTF. Schema is obsolete and will be completely rewritten.</p>
</resolution>
</issue>
<issue>
<issue-num>46</issue-num>
<title>"transport" attribute of "soap:binding" should be optional</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Editorial</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:kevin.liu@sap.com">Kevin Liu</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Feb/0023.html">email</a>]
[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"</p>
<p>References:
Section 3.3 soap:binding
A 4.2 SOAP Binding Schema</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Closed 5/21/2004 FTF. Schema is obsolete and will be completely rewritten.</p>
</resolution>
</issue>
<issue>
<issue-num>45</issue-num>
<title>"use" attribute of "fault" should be optional</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Editorial</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:kevin.liu@sap.com">Kevin Liu</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Feb/0023.html">email</a>]
Section 3.6 soap:fault grammar indicates that the use
attribute of fault is required while in the schema use is defined
as optional</p>
<p>References:
Section 3.6 soap:fault
A 4.2 SOAP Binding Schema</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Resolved at the 22 Sep 2003 consistent with prior decision to
eliminate the use of SOAP encoding.</p>
</resolution>
</issue>
<issue>
<issue-num>44</issue-num>
<title>"name" attribute of "soap:fault" is not defined in schema</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Editorial</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:kevin.liu@sap.com">Kevin Liu</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Feb/0023.html">email</a>]
Section 3.6 sopa:fault grammar indicates that fault
has a required name attribute while in the schema no such
attribute defined for faultType</p>
<p>References:
Section 3.6 soap:fault
A 4.2 SOAP Binding Schema</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Closed 5/21/2004 FTF. Schema is obsolete and will be completely rewritten.</p>
</resolution>
</issue>
<issue>
<issue-num>43</issue-num>
<title>Does order matter for the child elements of "definitions"?</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>
<a href="mailto:kevin.liu@sap.com">Kevin Liu</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Feb/0023.html">email</a>]
[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></p>
<p>References:
Section 3.1 SOAP Examples, example 3
Section 4.1 HTTP GET and POST Binding example 6
A 4.1 WSDL Schema</p>
</description>
<proposal>
</proposal>
<resolution>
<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Jun/0251.html">email</a>
</resolution>
</issue>
<issue>
<issue-num>42</issue-num>
<title>Shall "element" attribute of "part" only refer to elements defined in schema?</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>
<a href="mailto:kevin.liu@sap.com">Kevin Liu</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Feb/0023.html">email</a>]
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."</p>
<p>While in the section 3.1 example 4 and example 5, element is used as follow:</p>
<pre><message name="GetTradePriceInput">
<part name="tickerSymbol" element="xsd:string"/>
<part name="time" element="xsd:timeInstant"/>
</message></pre>
<p>References:
Section 2.3 Message
Section 3.1 SOAP Examples</p>
</description>
<proposal>
</proposal>
<resolution>
<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Jun/0251.html">email</a>
</resolution>
</issue>
<issue>
<issue-num>41</issue-num>
<title>Define encoding of attributes in a request URL</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:ryman@ca.ibm.com">Arthur Ryman</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0036.html">email</a>]
[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]</p>
<p>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:</p>
<p>employee=<name>John Doe</name><birthdate>1960-01-01</birthdate></p>
<p>Now suppose that PersonType had an attribute named sex.
[see email above for example]</p>
<p>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:</p>
<p>employee=[sex(male)]<name>John Doe</name><birthdate>1960-01-01</birthdate>
</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Per 13 Feb 2003 teleconference, leave HTTP request URLs segmented, flat,
and (somewhat) human readable.</p>
</resolution>
</issue>
<issue>
<issue-num>40</issue-num>
<title>The binding extension for SOAP is defined in terms of features that interact in a
complex way</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:ryman@ca.ibm.com">Arthur Ryman</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0036.html">email</a>]
The binding extension for SOAP depends on the following features:</p>
<p>* The message part XSD style, either type or element.</p>
<p>* The SOAP style, either RPC or Document.</p>
<p>* The encoding style, either literal or encoded.</p>
<p>* The direction of the message, either input or output.</p>
<p>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.</p>
<p>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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>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.</p>
</resolution>
</issue>
<issue>
<issue-num>39</issue-num>
<title>Binding Extensions Depend on the Structure of the portType</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>
<a href="mailto:ryman@ca.ibm.com">Arthur Ryman</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0036.html">email</a>]
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.</p>
<p>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]</p>
<p>Potential Solutions</p>
<p>* 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.</p>
<p>* 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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p> 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.</p>
</resolution>
</issue>
<issue>
<issue-num>38</issue-num>
<title>Clarify the what kinds of extensibility elements go where.</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>
<a href="mailto:sanjiva@watson.ibm.com">Sanjiva Weerawarana</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Member/w3c-ws-desc/2002Apr/0029.html">email</a>]
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. </p>
</description>
<proposal>
</proposal>
<resolution>
<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Jun/0251.html">email</a>
</resolution>
</issue>
<issue>
<issue-num>37</issue-num>
<title>Should we remove parameter order?</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>
<a href="mailto:sanjiva@watson.ibm.com">Sanjiva Weerawarana</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Member/w3c-ws-desc/2002Apr/0029.html">email</a>]
[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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>
<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Jun/0251.html">email</a>
</p>
</resolution>
</issue>
<issue>
<issue-num>36</issue-num>
<title>Should we remove notification operations?</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>
<a href="mailto:sanjiva@watson.ibm.com">Sanjiva Weerawarana</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://lists.w3.org/Archives/Member/w3c-ws-desc/2002Apr/0029.html">email</a>]
[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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>
<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Jun/0251.html">email</a>
</p>
</resolution>
</issue>
<issue>
<issue-num>35</issue-num>
<title>Should we remove solicit-response operations?</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>
<a href="mailto:sanjiva@watson.ibm.com">Sanjiva Weerawarana</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Member/w3c-ws-desc/2002Apr/0029.html">email</a>]
[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. </p>
</description>
<proposal>
</proposal>
<resolution>
<p>
<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Jun/0251.html">email</a>
</p>
</resolution>
</issue>
<issue>
<issue-num>34</issue-num>
<title>Should portTypes be extensible?</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>
<a href="mailto:sanjiva@watson.ibm.com">Sanjiva Weerawarana</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://lists.w3.org/Archives/Member/w3c-ws-desc/2002Apr/0029.html">email</a>]
Some users have asked that portTypes be extensibile.
We need to carefully consider whether that is a good thing or not. </p>
</description>
<proposal>
</proposal>
<resolution>
<p>
<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Jun/0251.html">email</a>
</p>
</resolution>
</issue>
<issue>
<issue-num>33</issue-num>
<title>Distinction between RPC style and document style</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>
<a href="mailto:waqar.sadiq@eds.com">Waqar Sadiq</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://lists.w3.org/Archives/Member/w3c-ws-desc/2002Apr/0022.html">email</a> and
<a href="http://lists.w3.org/Archives/Member/w3c-ws-desc/2002Apr/0011.html">email</a>]
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.</p>
<p>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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>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.</p>
</resolution>
</issue>
<issue>
<issue-num>32</issue-num>
<title>Will SOAP 1.1 still be supported?</title>
<locus>SOAP 1.1 Binding</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic/>
<status>Active</status>
<originator>
<a href="mailto:moreau@crf.canon.fr">Jean-Jacques Moreau</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0025.html">email</a>]
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?</p>
</description>
<proposal>
</proposal>
<resolution>
</resolution>
</issue>
<issue>
<issue-num>31</issue-num>
<title>'soap:address' insufficient to describe SOAP 1.2 endpoint</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:ruellan@crf.canon.fr">Herve Ruellan</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0024.html">email</a>]
_Background_
WSDL 1.1 uses the soap:address element to specify the destination of the
message.</p>
<p>_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.</p>
<p>_Proposed solution_
The target of a WSDL message should be defined in the soap:binding element.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Closed 5/21/2004 FTF.</p>
</resolution>
</issue>
<issue>
<issue-num>30</issue-num>
<title>soap:body encodingStyle</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:ruellan@crf.canon.fr">Herve Ruellan</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0024.html">email</a>]
[Child aspect already covered by issue 5]</p>
<p>_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).</p>
<p>_Issue_
WSDL 1.1 and SOAP 1.2 does not have the same use of the encodingStyle
attribute.</p>
<p>_Proposed solution_
Change the WSDL 1.1 use of the encodingStyle attribute.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>
<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Sep/0018.html">email</a>
Restrict the value of the encodingStyle attribute to be
either empty (for literal) or a single URI (for encodings like SOAP encoding).</p>
</resolution>
</issue>
<issue>
<issue-num>29</issue-num>
<title>How to specify the structure and ordering of 'soap:body' parts</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:ruellan@crf.canon.fr">Herve Ruellan</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0024.html">email</a>]
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).</p>
<p>_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.</p>
<p>_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...).</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Closed 5/21/2004 FTF. Obsolete - parts are gone.</p>
</resolution>
</issue>
<issue>
<issue-num>28</issue-num>
<title>'transport' cannot fully describe underlying SOAP 1.2 protocol binding</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:ruellan@crf.canon.fr">Herve Ruellan</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0024.html">email</a>]
_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.</p>
<p>_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.</p>
<p>_Proposed solution_
Use the soap:binding element to define which binding is used and </p>
</description>
<proposal>
</proposal>
<resolution>
<p>Closed 5/21/2004 FTF. Obsolete - already have provided the protocol attribute.</p>
</resolution>
</issue>
<issue>
<issue-num>27</issue-num>
<title>Remove 'style' attribute, which no longer works for SOAP 1.2</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:ruellan@crf.canon.fr">Herve Ruellan</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0024.html">email</a>]
_Background_
In SOAP 1.2, RPC is an extension of SOAP, that is a particular use of SOAP.</p>
<p>_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...</p>
<p>_Proposed solution_
Remove the style attribute and create a way for defining which SOAP
extensions are used (see below).</p>
</description>
<proposal>
</proposal>
<resolution>
<p>
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.</p>
</resolution>
</issue>
<issue>
<issue-num>26</issue-num>
<title>Replace transmission primitives by MEPs in operation</title>
<locus>Part 2</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>
<a href="mailto:ruellan@crf.canon.fr">Herve Ruellan</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0024.html">email</a>]
[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.
</p>
<p>
_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).
</p>
<p>
_Proposed solution_
As MEP are almost independant of SOAP 1.2, I would suggest replacing
transmission primitives by MEP.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Per 11 Dec 2003 telecon, decided to close given
Part 2 of the spec
[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0014.html">email</a>].</p>
</resolution>
</issue>
<issue>
<issue-num>25</issue-num>
<title>Unclear relationship between XML Schema and SOAP data model</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>
<a href="mailto:jacek@idoox.com">Jacek Kopecky</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0020.html">email</a>]
[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.</p>
<p>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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Removed @use.
@encodingStyle is a hint about how types/schema was generated.</p>
</resolution>
</issue>
<issue>
<issue-num>24</issue-num>
<title>Real difference between literal vs. encoded?</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>
<a href="mailto:waqar.sadiq@eds.com">Waqar Sadiq</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Member/w3c-ws-desc/2002Apr/0011.html">email</a>]
[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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p> 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.</p>
<p>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 <a href="#x97">97</a>.)</p>
</resolution>
</issue>
<issue>
<issue-num>23</issue-num>
<title>Request to support SOAP 1.2</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:moreau@crf.canon.fr">Jean-Jacques Moreau</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0018.html">email</a>]
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?</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Per 11 Dec 2003 telecon, decided to split this
into separate issues. See new issues <a href="#x99">99</a>, <a href="#x100">100</a>, and <a href="#x101">101</a>.
</p>
</resolution>
</issue>
<issue>
<issue-num>22</issue-num>
<title>Specification not XML Infoset based</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>
<a href="mailto:moreau@crf.canon.fr">Jean-Jacques Moreau</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0017.html">email</a>]
Currently, the specification is not XML Infoset based.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Fixed.</p>
</resolution>
</issue>
<issue>
<issue-num>21</issue-num>
<title>Examples use <import> elements inconsistenly</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>
<a href="mailto:moreau@crf.canon.fr">Jean-Jacques Moreau</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0016.html">email</a>]
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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Remove example; rewrite in primer.</p>
</resolution>
</issue>
<issue>
<issue-num>20</issue-num>
<title>Inconsistency in definition of 'soap:header' (contains 'part' or 'parts'?)</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Editorial</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:davec@progress.com">David Cleary</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0012.html">email</a>]
[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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Header now points directly to Schema.</p>
</resolution>
</issue>
<issue>
<issue-num>19</issue-num>
<title>Inconsistency on optionality of 'soap:headerfault'</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Editorial</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:davec@progress.com">David Cleary</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0012.html">email</a>]
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/.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Closed 5/21/2004 FTF. Schema is obsolete and will be completely rewritten.</p>
</resolution>
</issue>
<issue>
<issue-num>18</issue-num>
<title>Default for transport of <soap:binding></title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:gisle@activestate.com">Gisle Aas</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://groups.yahoo.com/group/wsdl/message/582?threaded=1">email</a>]
[see also issue 46]
The _transport_ attribute of <soap:binding> is optional, but it is
not clear to me what the default is.</p>
<p>
Is "http://schemas.xmlsoap.org/soap/http" the default?</p>
<p>If so, shouldn't the schema in section A-4.1 declare this value as
the default?</p>
</description>
<proposal>
</proposal>
<resolution>
<p>soap:transport is mandatory</p>
</resolution>
</issue>
<issue>
<issue-num>17</issue-num>
<title>nowhere to specify actor URI in WSDL ?</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:simon@zaks.demon.co.uk">Simon Fell</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://groups.yahoo.com/group/wsdl/message/638?threaded=1">email</a>]
[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 ?</p>
</description>
<proposal>
<p>
<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Jun/0190.html">email</a>
</p>
</proposal>
<resolution>
<p> As described in proposal above, with minor amendments from Gudge and Jonathan.</p>
</resolution>
</issue>
<issue>
<issue-num>16</issue-num>
<title>Does a binding have to specify all the operations in a portType?</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>
<a href="mailto:simon@zaks.demon.co.uk">Simon Fell</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://groups.yahoo.com/group/wsdl/message/733?threaded=1">email</a>]
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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Fixed.</p>
</resolution>
</issue>
<issue>
<issue-num>15</issue-num>
<title>Missing <document> tag for operation arguments</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>
<a href=" mailto:graham-glass@mindspring.com">Graham Glass</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://lists.w3.org/Archives/Public/xml-dist-app/2001Jun/0197.html">email</a>]
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.</p>
</description>
<proposal>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0031.html">email</a>]
</proposal>
<resolution>
<p>Per 18 Dec 03 telecon, noted that we now allow
documentation everywhere.</p>
</resolution>
</issue>
<issue>
<issue-num>14</issue-num>
<title>Request to support SOAP features</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:gdaniels@macromedia.com">Glen Daniels</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Mar/0091.html">email</a>]
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.</p>
<p>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.</p>
<p>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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Per 11 Dec 2003 telecon, noted that features and
properties are currently included in the draft [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0014.html">email</a>].</p>
</resolution>
</issue>
<issue>
<issue-num>13</issue-num>
<title>Parameter Order missing from schema</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>
<a href="mailto:jacek@idoox.com">Jacek Kopecky</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://groups.yahoo.com/group/wsdl/message/589">email</a>]
This is an editorial issue for WSDL 1.1 - the schema doesn't
declare the parameterOrder attribute.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Removed @parameterOrder.</p>
</resolution>
</issue>
<issue>
<issue-num>12</issue-num>
<title>Bug in schema for "part" attribute</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>
<a href="mailto:gisle@activestate.com">Gisle Aas</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://groups.yahoo.com/group/wsdl/message/563">email</a>]
[see also issue 20]</p>
<p>
According to the schema in section A-4.1 the 'name' attribute of
<part> is optional.</p>
<p>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".</p>
<p>I believe the schema is wrong and that the definition of "partType"
should be changed to:</p>
<pre><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></pre>
</description>
<proposal>
</proposal>
<resolution>
<p>Per 30 July 2003 meeting in Raleigh, NC, decided
to remove message and message/part construct.</p>
</resolution>
</issue>
<issue>
<issue-num>11</issue-num>
<title>Bug in grammar for <import></title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>
<a href="mailto:gisle@activestate.com">Giles Aas</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="">email</a>]
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:</p>
<pre>
<wsdl:import namespace="uri" location="uri"> *
<wsdl:documentation .... />?
</wsdl:import></pre>
<p>In WSDL 1.1 (2001-03-15) it simply says.</p>
<pre><import namespace="uri" location="uri"/>*</pre>
<p>The namespace qualifier for <import> is also missing in the current
text.</p>
</description>
<proposal>
</proposal>
<resolution>Obsolete pseudo grammar.
</resolution>
</issue>
<issue>
<issue-num>10</issue-num>
<title>Example 3 element order bug</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>
<a href="mailto:gisle@activestate.com">Gisle Aas</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p>[<a href="http://groups.yahoo.com/group/wsdl/message/560">email</a>]
[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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Removed example; rewrite in primer.</p>
</resolution>
</issue>
<issue>
<issue-num>9</issue-num>
<title>Example misses "Soap"</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Editorial</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:gisle@activestate.com">Gisle Aas</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://groups.yahoo.com/group/wsdl/message/557">email</a>]
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:</p>
<pre>tns:StockQuoteSoapBinding</pre>
<p>
The example is missing "Soap" in there.</p>
<p>
<a href="mailto:simon@zaks.demon.co.uk">Simon Fell</a> also notes that examples 2,4 and 5 have the same problem.</p>
</description>
<proposal>
</proposal>
<resolution>Removed example; rewrite in primer.
</resolution>
</issue>
<issue>
<issue-num>8</issue-num>
<title>Inconsistency in definition of attribute extensibility</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Editorial</priority>
<topic/>
<status>Closed</status>
<originator>Kevin Liu</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://groups.yahoo.com/group/wsdl/message/412">email</a>]
In section 2.1, extensibility is expilictly stated for all the
elements, but not for attributes. </p>
<p> 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.</p>
</description>
<proposal>[<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0032.html">email</a>]
</proposal>
<resolution>
<p>Per 18 Dec 03 telecon, same description for
attribute and children extensibility; neither in pseudo syntax
to minimize clutter.</p>
</resolution>
</issue>
<issue>
<issue-num>7</issue-num>
<title>Example incorrectly uses xsd:binary</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Editorial</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>Jeff Lansing</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://groups.yahoo.com/group/wsdl/message/446">email</a>]
The sample in <a href="http://www.w3.org/TR/wsdl#_http-e">section 4.1</a> of the spec uses xsd:binary which doesn't exist, its not clear what the
correct type to use in its place would be.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Removed example; rewrite in primer.</p>
</resolution>
</issue>
<issue>
<issue-num>6e</issue-num>
<title>Define behavior for http:urlReplacement "search pattern" with
no corresponding named part in message</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:gisle@activestate.com">Gisle Aas</a>
</originator>
<responsible/>
<description>
<p> [<a href="http://groups.yahoo.com/group/wsdl/message/466">email</a>]
For http:urlReplacement it is not clear what should happen for "search
patterns" where there is no correspondingly named part in the message.</p>
</description>
<proposal>
<p>Strings enclosed within single curly braces MUST be input message part
names; any other strings enclosed within single curly braces are a
fatal error. [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003May/0067.html">email</a>]</p>
</proposal>
<resolution>
<p>Accepted per 29 May 2003 telecon.</p>
</resolution>
</issue>
<issue>
<issue-num>6d</issue-num>
<title>Define encoding for characters outside ASCII in a request URL</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:gisle@activestate.com">Gisle Aas</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://groups.yahoo.com/group/wsdl/message/466">email</a>]
For http:urlReplacement it not not clear what URL escaping should be
done on the replacement text.</p>
<p>- Is an embedded "?" to be expanded into "?" or "%3f".</p>
<p>
- Is an embedded "%3f" to be expanded into "%3f" or "%253f"</p>
</description>
<proposal>
</proposal>
<resolution>
<p>
Per 13 Feb 2003 teleconference, editors to add text compatible with I18N.</p>
</resolution>
</issue>
<issue>
<issue-num>6c</issue-num>
<title>Can a part reference a global element declaration instead of a type</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>
<a href="mailto:gisle@activestate.com">Gisle Aas</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://groups.yahoo.com/group/wsdl/message/466">email</a>]
Is it legal for the part referenced to reference a schema element
instead of a type?</p>
</description>
<proposal>
</proposal>
<resolution>
<p>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).</p>
</resolution>
</issue>
<issue>
<issue-num>6b</issue-num>
<title>Define encoding for characters outside ASCII in a request URL</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:gisle@activestate.com">Gisle Aas</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://groups.yahoo.com/group/wsdl/message/466">email</a>]
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?</p>
</description>
<proposal>
<p> Wait until <a href="http://www.w3.org/International/Group/charmod-edit/#sec-URIs">Charmod</a>
goes to REC, if possible, since it contains
a pretty strong requirement that W3C specifications
"use Internationalized Resource Identifiers
(<a href="http://www.ietf.org/internet-drafts/draft-duerst-iri-00.txt">IRI</a>)
(or an appropriate subset thereof)."</p>
</proposal>
<resolution>
<p>Per 13 Feb 2003 teleconference, editors to add text compatible with I18N.</p>
</resolution>
</issue>
<issue>
<issue-num>6a</issue-num>
<title>Define encoding of complex types in a request URL</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:gisle@activestate.com">Gisle Aas</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://groups.yahoo.com/group/wsdl/message/466">email</a>]
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)?</p>
</description>
<proposal>
</proposal>
<resolution>
<p>Per 13 Feb 2003 teleconference, leave HTTP request URLs segmented, flat,
and (somewhat) human readable.</p>
</resolution>
</issue>
<issue>
<issue-num>5</issue-num>
<title>Encoding Style</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:rineholt@us.ibm.com">Rine Holt</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://groups.yahoo.com/group/wsdl/message/456">email</a>]
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.</p>
</description>
<proposal>
</proposal>
<resolution>
<p>
<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Sep/0018.html">email</a>
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</p>
</resolution>
</issue>
<issue>
<issue-num>4</issue-num>
<title>Namespaces</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>Matt Long</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://wsdl.SoapWare.Org/stories/storyReader$15">email</a>]
I ran across this example at
http://www.w3.org/2001/03/14-annotated-WSDL-examples</p>
<p>
The example is correct but does emphasize a concern.</p>
<p>1) when a part is typed "element" and referenced to schema</p>
<p>2) and the binding's soap:body "namespace" attribute is used</p>
<p>Spec reads Section 3.5</p>
<p>
...although the namespace attribute only applies to content not
explicitly</p>
<p>
defined by the abstract types. ...</p>
<p>
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.</p>
<p>
This seems confusing and it would seem in the interests of best
practices to either</p>
<p>
1) declare the namespace attribute of the soap:body element equal
to the intended namespace</p>
<p>or</p>
<p>
2) omit the namespace attribute *if* the element is explictly
declared in schema.</p>
<p>
(I would think (1) would clear any garbled confusion in either
case).</p>
</description>
<proposal>
</proposal>
<resolution>
<p>
<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Jul/0076.html">email</a>
</p>
</resolution>
</issue>
<issue>
<issue-num>3</issue-num>
<title>How can arrays be declared?</title>
<locus>Part 1</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic/>
<status>Closed</status>
<originator>?</originator>
<responsible>Unassigned</responsible>
<description>
<p> [<a href="http://wsdl.SoapWare.Org/stories/storyReader$14">email</a>]<br/>
Possibly one of the most talked about parts of WSDL:</p>
<ul>
<li>What is the standard way to describe an array?</li>
<li>How many other valid ways are there to describe an array?</li>
<li>How do i define more complex types?</li>
<li>Does the new WSDL 1.1 approach to arrays support all the different array types in SOAP?</li>
</ul>
<p> [needs review]</p>
</description>
<proposal>
</proposal>
<resolution>Per 11 Dec 2003 telecon, closed because we don't
deal with the SOAP data model or its encoding [<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0014.html">email</a>].
</resolution>
</issue>
<issue>
<issue-num>2</issue-num>
<title>Allow SOAPAction for bindings other than SOAP</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:gdaniels@macromedia.com">Glen Daniels</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [SOAPAction has been deprecated, as of SOAP 1.2]
<quote section="3.4 soap:operation"></p>
<p>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.</p>
<p><quote></p>
<p>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?</p>
</description>
<proposal>
</proposal>
<resolution>
<p> Per <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0060.html">4
Nov 2003 face-to-face</a>, decided to simplify SOAP binding
extension to just <wsoap:action uri="xs:anyURI" />.</p>
</resolution>
</issue>
<issue>
<issue-num>1</issue-num>
<title>How to specify an empty SOAP action</title>
<locus>Part 3</locus>
<requirement>n/a</requirement>
<priority>Design</priority>
<topic>SOAP/HTTP</topic>
<status>Closed</status>
<originator>
<a href="mailto:simon@zaks.demon.co.uk">Simon Fell</a>
</originator>
<responsible>Unassigned</responsible>
<description>
<p> [SOAPAction has been deprecated, as of SOAP 1.2]
<quote section="3.4 soap:operation"></p>
<p>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.</p>
<p><quote></p>
<p>Does this mean the SOAPAction value should include the quotes
needed ?, i.e. if you're expecting a SOAP request</p>
<pre>POST ....
SOAPAction: "/foo/bar"</pre>
<p>do you include the quotes in the soap:operation ?, e.g. </p>
<pre><soap:operation soapAction="/foo/bar" /></pre>
<p>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.</p>
<pre>POST ....
SOAPAction: </pre>
</description>
<proposal>
</proposal>
<resolution>
<p>Closed 5/21/2004 FTF. No @soapAction will mean no soapaction header.</p>
</resolution>
</issue>
<!-- Maintainers -->
<maintainer>
<initials>JJM</initials>
<fullname>Jean-Jacques Moreau (for now)</fullname>
<uri/>
</maintainer>
<maintainer>
<initials>JCS</initials>
<fullname>Jeffrey Schlimmer</fullname>
<uri/>
</maintainer>
<maintainer>
<initials>JM</initials>
<fullname>Jonathan Marsh</fullname>
<uri/>
</maintainer>
</issues>
\ No newline at end of file
Index: wsd-issues.html
===================================================================
RCS file: /sources/public/2002/ws/desc/issues/wsd-issues.html,v
retrieving revision 1.94
retrieving revision 1.95
diff -C2 -d -r1.94 -r1.95
*** wsd-issues.html 1 Aug 2004 16:47:11 -0000 1.94
--- wsd-issues.html 3 Aug 2004 07:33:09 -0000 1.95
***************
*** 42,82 ****
</tr>
<tr>
! <td><a href="#x161">161</a></td><td>Active</td><td>Media type description</td><td></td><td>Design</td><td></td><td>Should media-type values allow wild cards</td>
! </tr>
! <tr>
! <td><a href="#x162">162</a></td><td>Active</td><td>Media type description</td><td></td><td>Design</td><td></td><td>Allowing other choices for mediaType values</td>
! </tr>
! <tr>
! <td><a href="#x198">198</a></td><td>Active</td><td>Media type description</td><td></td><td>Design</td><td></td><td>mismatch between value of media type attribute and pattern</td>
! </tr>
! <tr>
! <td><a href="#x199">199</a></td><td>Active</td><td>Media type description</td><td></td><td>Design</td><td></td><td>mismatch between the media type attribute and the actual data</td>
! </tr>
! <tr>
! <td><a href="#x200">200</a></td><td>Active</td><td>Media type description</td><td></td><td>Design</td><td></td><td>Where should appInfo go?</td>
! </tr>
! <tr>
! <td><a href="#x201">201</a></td><td>Active</td><td>Media type description</td><td></td><td>Design</td><td></td><td>Name of mediaType</td>
! </tr>
! <tr>
! <td><a href="#x202">202</a></td><td>Active</td><td>Media type description</td><td></td><td>Editorial</td><td></td><td>More examples</td>
! </tr>
! <tr>
! <td><a href="#x203">203</a></td><td>Active</td><td>Media type description</td><td></td><td>Design</td><td></td><td>Limited to base64encoded?</td>
! </tr>
! <tr>
! <td><a href="#x204">204</a></td><td>Active</td><td>Media type description</td><td></td><td>Design</td><td></td><td>Why default to */* instead of to "no effect"?</td>
! </tr>
! <tr>
! <td><a href="#x205">205</a></td><td>Active</td><td>Media type description</td><td></td><td>Design</td><td></td><td>Explain priority</td>
! </tr>
! <tr>
! <td><a href="#x206">206</a></td><td>Active</td><td>Media type description</td><td></td><td>Design</td><td></td><td>Annotations and schema component model.</td>
! </tr>
! <tr>
! <td><a href="#x242">242</a></td><td>Active</td><td>Media type description</td><td></td><td>Design</td><td></td><td>Binding accepts header and output serialization </td>
! </tr>
! <tr>
! <td><a href="#x245">245</a></td><td>Active</td><td>Media Type Description</td><td></td><td>Design</td><td></td><td>Define expectedMediaTypeItem to be RFC 2616 Accepts header</td>
</tr>
<tr>
--- 42,46 ----
</tr>
<tr>
! <td><a href="#x252">252</a></td><td>Active</td><td>Media type description</td><td></td><td>Design</td><td></td><td>Syntax of media type annotation</td>
</tr>
<tr>
***************
*** 6228,6234 ****
</tr>
</tbody>
! <tbody class="Active">
<tr>
! <td valign="top" rowspan="5"><b><a name="x161">161</a></b></td><td>Media type description</td><td></td><td></td><td>Design</td><td>Active</td><td>Media Type TF</td><td></td>
</tr>
<tr>
--- 6192,6198 ----
</tr>
</tbody>
! <tbody class="Closed">
<tr>
! <td valign="top" rowspan="5"><b><a name="x161">161</a></b></td><td>Media type description</td><td></td><td></td><td>Design</td><td>Closed</td><td>Media Type TF</td><td></td>
</tr>
<tr>
***************
*** 6248,6257 ****
</tr>
<tr>
! <td colspan="7"><b>Resolution:</b> </td>
</tr>
</tbody>
! <tbody class="Active">
<tr>
! <td valign="top" rowspan="5"><b><a name="x162">162</a></b></td><td>Media type description</td><td></td><td></td><td>Design</td><td>Active</td><td>Media Type TF</td><td></td>
</tr>
<tr>
--- 6212,6223 ----
</tr>
<tr>
! <td colspan="7"><b>Resolution:</b>
! <p>wildcards (/*) are allowed. */* is not at this point (see issue 245).</p>
! </td>
</tr>
</tbody>
! <tbody class="Closed">
<tr>
! <td valign="top" rowspan="5"><b><a name="x162">162</a></b></td><td>Media type description</td><td></td><td></td><td>Design</td><td>Closed</td><td>Media Type TF</td><td></td>
</tr>
<tr>
***************
*** 6271,6275 ****
</tr>
<tr>
! <td colspan="7"><b>Resolution:</b> </td>
</tr>
</tbody>
--- 6237,6243 ----
</tr>
<tr>
! <td colspan="7"><b>Resolution:</b>
! <p>Obsolete. IANA media types are sufficient.</p>
! </td>
</tr>
</tbody>
***************
*** 7212,7218 ****
</tr>
</tbody>
! <tbody class="Active">
<tr>
! <td valign="top" rowspan="5"><b><a name="x198">198</a></b></td><td>Media type description</td><td></td><td></td><td>Design</td><td>Active</td><td>WG</td><td></td>
</tr>
<tr>
--- 7180,7186 ----
</tr>
</tbody>
! <tbody class="Closed">
<tr>
! <td valign="top" rowspan="5"><b><a name="x198">198</a></b></td><td>Media type description</td><td></td><td></td><td>Design</td><td>Closed</td><td>WG</td><td></td>
</tr>
<tr>
***************
*** 7232,7241 ****
</tr>
<tr>
! <td colspan="7"><b>Resolution:</b> </td>
</tr>
</tbody>
! <tbody class="Active">
<tr>
! <td valign="top" rowspan="5"><b><a name="x199">199</a></b></td><td>Media type description</td><td></td><td></td><td>Design</td><td>Active</td><td>WG</td><td></td>
</tr>
<tr>
--- 7200,7211 ----
</tr>
<tr>
! <td colspan="7"><b>Resolution:</b>
! <p>Out of scope what to do when messages don't match the description. Close with no action.</p>
! </td>
</tr>
</tbody>
! <tbody class="Closed">
<tr>
! <td valign="top" rowspan="5"><b><a name="x199">199</a></b></td><td>Media type description</td><td></td><td></td><td>Design</td><td>Closed</td><td>WG</td><td></td>
</tr>
<tr>
***************
*** 7256,7265 ****
</tr>
<tr>
! <td colspan="7"><b>Resolution:</b> </td>
</tr>
</tbody>
! <tbody class="Active">
<tr>
! <td valign="top" rowspan="5"><b><a name="x200">200</a></b></td><td>Media type description</td><td></td><td></td><td>Design</td><td>Active</td><td>WG</td><td></td>
</tr>
<tr>
--- 7226,7237 ----
</tr>
<tr>
! <td colspan="7"><b>Resolution:</b>
! <p>Out of scope what to do when messages don't match the description. Close with no action.</p>
! </td>
</tr>
</tbody>
! <tbody class="Closed">
<tr>
! <td valign="top" rowspan="5"><b><a name="x200">200</a></b></td><td>Media type description</td><td></td><td></td><td>Design</td><td>Closed</td><td>WG</td><td></td>
</tr>
<tr>
***************
*** 7279,7288 ****
</tr>
<tr>
! <td colspan="7"><b>Resolution:</b> </td>
</tr>
</tbody>
! <tbody class="Active">
<tr>
! <td valign="top" rowspan="5"><b><a name="x201">201</a></b></td><td>Media type description</td><td></td><td></td><td>Design</td><td>Active</td><td>WG</td><td></td>
</tr>
<tr>
--- 7251,7262 ----
</tr>
<tr>
! <td colspan="7"><b>Resolution:</b>
! <p>Say in the spec that this annotation can appear on element declarations and complex type definitions, where these types are derived from base64binary.</p>
! </td>
</tr>
</tbody>
! <tbody class="Closed">
<tr>
! <td valign="top" rowspan="5"><b><a name="x201">201</a></b></td><td>Media type description</td><td></td><td></td><td>Design</td><td>Closed</td><td>WG</td><td></td>
</tr>
<tr>
***************
*** 7302,7311 ****
</tr>
<tr>
! <td colspan="7"><b>Resolution:</b> </td>
</tr>
</tbody>
! <tbody class="Active">
<tr>
! <td valign="top" rowspan="5"><b><a name="x202">202</a></b></td><td>Media type description</td><td></td><td></td><td>Editorial</td><td>Active</td><td>WG</td><td></td>
</tr>
<tr>
--- 7276,7287 ----
</tr>
<tr>
! <td colspan="7"><b>Resolution:</b>
! <p>Obsolete.</p>
! </td>
</tr>
</tbody>
! <tbody class="Closed">
<tr>
! <td valign="top" rowspan="5"><b><a name="x202">202</a></b></td><td>Media type description</td><td></td><td></td><td>Editorial</td><td>Closed</td><td>WG</td><td></td>
</tr>
<tr>
***************
*** 7327,7336 ****
</tr>
<tr>
! <td colspan="7"><b>Resolution:</b> </td>
</tr>
</tbody>
! <tbody class="Active">
<tr>
! <td valign="top" rowspan="5"><b><a name="x203">203</a></b></td><td>Media type description</td><td></td><td></td><td>Design</td><td>Active</td><td>WG</td><td></td>
</tr>
<tr>
--- 7303,7314 ----
</tr>
<tr>
! <td colspan="7"><b>Resolution:</b>
! <p>Accepted, editors to add more examples (valid and runnable) illustrating each significant feature.</p>
! </td>
</tr>
</tbody>
! <tbody class="Closed">
<tr>
! <td valign="top" rowspan="5"><b><a name="x203">203</a></b></td><td>Media type description</td><td></td><td></td><td>Design</td><td>Closed</td><td>WG</td><td></td>
</tr>
<tr>
***************
*** 7350,7359 ****
</tr>
<tr>
! <td colspan="7"><b>Resolution:</b> </td>
</tr>
</tbody>
! <tbody class="Active">
<tr>
! <td valign="top" rowspan="5"><b><a name="x204">204</a></b></td><td>Media type description</td><td></td><td></td><td>Design</td><td>Active</td><td>WG</td><td></td>
</tr>
<tr>
--- 7328,7339 ----
</tr>
<tr>
! <td colspan="7"><b>Resolution:</b>
! <p>Added hexBinary as well.</p>
! </td>
</tr>
</tbody>
! <tbody class="Closed">
<tr>
! <td valign="top" rowspan="5"><b><a name="x204">204</a></b></td><td>Media type description</td><td></td><td></td><td>Design</td><td>Closed</td><td>WG</td><td></td>
</tr>
<tr>
***************
*** 7374,7383 ****
</tr>
<tr>
! <td colspan="7"><b>Resolution:</b> </td>
</tr>
</tbody>
! <tbody class="Active">
<tr>
! <td valign="top" rowspan="5"><b><a name="x205">205</a></b></td><td>Media type description</td><td></td><td></td><td>Design</td><td>Active</td><td>WG</td><td></td>
</tr>
<tr>
--- 7354,7365 ----
</tr>
<tr>
! <td colspan="7"><b>Resolution:</b>
! <p>Removed that sentence from the spec.</p>
! </td>
</tr>
</tbody>
! <tbody class="Closed">
<tr>
! <td valign="top" rowspan="5"><b><a name="x205">205</a></b></td><td>Media type description</td><td></td><td></td><td>Design</td><td>Closed</td><td>WG</td><td></td>
</tr>
<tr>
***************
*** 7398,7407 ****
</tr>
<tr>
! <td colspan="7"><b>Resolution:</b> </td>
</tr>
</tbody>
! <tbody class="Active">
<tr>
! <td valign="top" rowspan="5"><b><a name="x206">206</a></b></td><td>Media type description</td><td></td><td></td><td>Design</td><td>Active</td><td>WG</td><td></td>
</tr>
<tr>
--- 7380,7391 ----
</tr>
<tr>
! <td colspan="7"><b>Resolution:</b>
! <p>Obsolete. Closed with no action.</p>
! </td>
</tr>
</tbody>
! <tbody class="Closed">
<tr>
! <td valign="top" rowspan="5"><b><a name="x206">206</a></b></td><td>Media type description</td><td></td><td></td><td>Design</td><td>Closed</td><td>WG</td><td></td>
</tr>
<tr>
***************
*** 7422,7426 ****
</tr>
<tr>
! <td colspan="7"><b>Resolution:</b> </td>
</tr>
</tbody>
--- 7406,7412 ----
</tr>
<tr>
! <td colspan="7"><b>Resolution:</b>
! <p>Obsolete and duplicate.</p>
! </td>
</tr>
</tbody>
***************
*** 8581,8587 ****
</tr>
</tbody>
! <tbody class="Active">
<tr>
! <td valign="top" rowspan="5"><b><a name="x242">242</a></b></td><td>Media type description</td><td></td><td></td><td>Design</td><td>Active</td><td>Hugo</td><td></td>
</tr>
<tr>
--- 8567,8573 ----
</tr>
</tbody>
! <tbody class="Closed">
<tr>
! <td valign="top" rowspan="5"><b><a name="x242">242</a></b></td><td>Media type description</td><td></td><td></td><td>Design</td><td>Closed</td><td>Hugo</td><td></td>
</tr>
<tr>
***************
*** 8601,8605 ****
</tr>
<tr>
! <td colspan="7"><b>Resolution:</b> </td>
</tr>
</tbody>
--- 8587,8593 ----
</tr>
<tr>
! <td colspan="7"><b>Resolution:</b>
! <p>Reference Accepts header meaning (not just value) similarity to Accepts header.</p>
! </td>
</tr>
</tbody>
***************
*** 8652,8658 ****
</tr>
</tbody>
! <tbody class="Active">
<tr>
! <td valign="top" rowspan="5"><b><a name="x245">245</a></b></td><td>Media Type Description</td><td></td><td></td><td>Design</td><td>Active</td><td>Hugo</td><td></td>
</tr>
<tr>
--- 8640,8646 ----
</tr>
</tbody>
! <tbody class="Closed">
<tr>
! <td valign="top" rowspan="5"><b><a name="x245">245</a></b></td><td>Media Type Description</td><td></td><td></td><td>Design</td><td>Closed</td><td>Hugo</td><td></td>
</tr>
<tr>
***************
*** 8672,8676 ****
</tr>
<tr>
! <td colspan="7"><b>Resolution:</b> </td>
</tr>
</tbody>
--- 8660,8668 ----
</tr>
<tr>
! <td colspan="7"><b>Resolution:</b>
! <p>Accepted the addition of the "q" parameter and the ability to specify "*/*".
! Items will remain a schema list, easily translated to the comma-separated list of RFC2616.
! </p>
! </td>
</tr>
</tbody>
***************
*** 8801,8804 ****
--- 8793,8820 ----
</tr>
</tbody>
+ <tbody class="Active">
+ <tr>
+ <td valign="top" rowspan="5"><b><a name="x252">252</a></b></td><td>Media type description</td><td></td><td></td><td>Design</td><td>Active</td><td>Jonathan marsh</td><td></td>
+ </tr>
+ <tr>
+ <td colspan="7"><b>Title:</b> Syntax of media type annotation</td>
+ </tr>
+ <tr>
+ <td colspan="7"><b>Description:</b>
+ <p>Should the expected media type be an attribute instead of an appinfo annotation?
+ WG substantially in favor of this if tooling doesn't prevent it.</p>
+
+ [<a href="http://www.w3.org/Search/Mail/Public/search?type-index=www-ws-desc&index-type=t&keywords=%22Issue+252%22&search=Search">Search</a> or
+ <a href="http://www.google.com/search?num=50&hl=en&ie=UTF-8&as_qdr=all&q=%2Bwww-ws-desc+%2B%22issue+252%22+site%3Alists.w3.org&btnG=Search">Google</a> WG archive for relevant posts.]
+
+ </td>
+ </tr>
+ <tr>
+ <td colspan="7"><b>Proposal:</b> </td>
+ </tr>
+ <tr>
+ <td colspan="7"><b>Resolution:</b> </td>
+ </tr>
+ </tbody>
</table>
<h2>
Received on Tuesday, 3 August 2004 03:33:13 UTC