WD-ws-desc-reqs-20021028 61.9 KB

Raw Blame History Permalink

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="en" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content=
"text/html; charset=ISO-8859-1" />
<title>Web Services Description Requirements</title>
<style type="text/css">
code           { font-family: monospace; }

div.constraint,
div.issue,
div.note,
div.notice     { margin-left: 2em; }

li p           { margin-top: 0.3em;
                 margin-bottom: 0.3em; }

div.exampleInner pre { margin-left: 1em;
                       margin-top: 0em; margin-bottom: 0em}
div.exampleOuter {border: 4px double gray;
                  margin: 0em; padding: 0em}
div.exampleInner { background-color: #d5dee3;
                   border-top-width: 4px;
                   border-top-style: double;
                   border-top-color: #d3d3d3;
                   border-bottom-width: 4px;
                   border-bottom-style: double;
                   border-bottom-color: #d3d3d3;
                   padding: 4px; margin: 0em }
div.exampleWrapper { margin: 4px }
div.exampleHeader { font-weight: bold;
                    margin: 4px}

      .Accepted {}
      .Rejected {background-color: #DDDDDD; display: none}
      .Draft {background-color: #DDFFFF}

</style>

<link type="text/css" rel="stylesheet" href=
"http://www.w3.org/StyleSheets/TR/W3C-WD.css" />
</head>
<body>
<div class="head">
<p><a href="http://www.w3.org/"><img width="72" height="48" alt=
"W3C" src="http://www.w3.org/Icons/w3c_home" /></a></p>

<h1><a id="title" name="title"></a>Web Services Description
Requirements</h1>

<h2><a id="w3c-doctype" name="w3c-doctype"></a>W3C Working Draft 28
October 2002</h2>

<dl>
<dt>This version:</dt>

<dd><a href=
"http://www.w3.org/TR/2002/WD-ws-desc-reqs-20021028">http://www.w3.org/TR/2002/WD-ws-desc-reqs-20021028</a></dd>

<dt>Latest version:</dt>

<dd><a href=
"http://www.w3.org/TR/ws-desc-reqs">http://www.w3.org/TR/ws-desc-reqs</a></dd>

<dt>Previous version:</dt>

<dd><a href=
"http://www.w3.org/TR/2002/WD-ws-desc-reqs-20020429">http://www.w3.org/TR/2002/WD-ws-desc-reqs-20020429</a></dd>

<dt>Editor:</dt>

<dd>Jeffrey C. Schlimmer, Microsoft</dd>
</dl>

<p>This document is also available in these non-normative formats:
<a href=
"http://www.w3.org/TR/2002/WD-ws-desc-reqs-20021028/ws-desc-reqs.xml">
XML</a>, <a href=
"http://www.w3.org/TR/2002/WD-ws-desc-reqs-20021028/ws-desc-reqs.ps">
PS</a>, <a href=
"http://www.w3.org/TR/2002/WD-ws-desc-reqs-20021028/ws-desc-reqs.pdf">
PDF</a>, and&nbsp;<a href=
"http://www.w3.org/TR/2002/WD-ws-desc-reqs-20021028/ws-desc-reqs.txt">
TXT</a>.</p>

<p class="copyright"><a href=
"http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Copyright">Copyright</a>&nbsp;&copy;&nbsp;2002&nbsp;<a
 href="http://www.w3.org/"><abbr title=
"World Wide Web Consortium">W3C</abbr></a><sup>&reg;</sup> (<a
href="http://www.lcs.mit.edu/"><abbr title=
"Massachusetts Institute of Technology">MIT</abbr></a>, <a href=
"http://www.inria.fr/"><abbr title=
"Institut National de Recherche en Informatique et Automatique"
lang="fr" xml:lang="fr">INRIA</abbr></a>, <a href=
"http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a
href=
"http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Legal_Disclaimer">
liability</a>, <a href=
"http://www.w3.org/Consortium/Legal/ipr-notice-20000612#W3C_Trademarks">
trademark</a>, <a href=
"http://www.w3.org/Consortium/Legal/copyright-documents-19990405">document
use</a>, and <a href=
"http://www.w3.org/Consortium/Legal/copyright-software-19980720">software
licensing</a> rules apply.</p>
</div>

<hr />
<div>
<h2><a id="abstract" name="abstract"></a>Abstract</h2>

<p>This document describes the Web Services Description Working
Group's requirements for the Web Services Description
specification.</p>
</div>

<div>
<h2><a id="status" name="status"></a>Status of this Document</h2>

<p>This is a <a href=
"http://www.w3.org/Consortium/Process-20010719/tr.html#last-call">W3C
Last Call Working Draft</a> of the Web Services Description
Requirements document. It is a <a href=
"http://www.w3.org/2002/01/ws-desc-charter">chartered</a>
deliverable of the <a href="http://www.w3.org/2002/ws/desc/">Web
Services Description Working Group (WG)</a>, which is part of the
<a href="http://www.w3.org/2002/ws/Activity">Web Services
Activity</a>. This document represents the current consensus within
the Working Group about Web Services Description requirements. The
Working Group does not intend to take this document further than
Last Call, except to update this document in response to comments
and requests from other Working Groups and the public.</p>

<p>The Last Call review period ends on 31 December 2002. Comments
on this document should be sent to <a href=
"mailto:public-ws-desc-comments@w3.org">public-ws-desc-comments@w3.org</a>
(<a href=
"http://lists.w3.org/Archives/Public/public-ws-desc-comments/">public
archive</a>). It is inappropriate to send discussion emails to this
address.</p>

<p>Discussion of this document takes place on the public <a href=
"mailto:www-ws-desc@w3.org">www-ws-desc@w3.org</a> mailing list (<a
href="http://lists.w3.org/Archives/Public/www-ws-desc/">public
archive</a>) per the email communication rules in the <a href=
"http://www.w3.org/2002/01/ws-desc-charter">Web Services
Description Working Group Charter</a>.</p>

<p>Patent disclosures relevant to this specification may be found
on the Working Group's <a href=
"http://www.w3.org/2002/ws/desc/2/04/24-IPR-statements.html" rel=
"disclosure">patent disclosure page</a>.</p>

<p>This is a public W3C Working Draft. It is a draft document and
may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use W3C Working Drafts as reference
material or to cite them as other than "work in progress". A list
of all <a href="http://www.w3.org/TR/">W3C technical reports</a>
can be found at http://www.w3.org/TR.</p>
</div>

<div class="toc">
<h2><a id="contents" name="contents"></a>Table of Contents</h2>

<p class="toc">1 <a href="#notations">Notations</a><br />
2 <a href="#definitions">Definitions</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;2.1 <a href="#nonNormDefs">Non-normative
definitions</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;2.2 <a href="#normDefs">Normative
definitions</a><br />
3 <a href="#relationship2charter">Relationship to WG
Charter</a><br />
4 <a href="#requirements">Requirements</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;4.1 <a href="#genreqs">General</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;4.2 <a href=
"#simplicity">Simplicity</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;4.3 <a href="#interfdesc">Interface
Description</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;4.4 <a href="#desintwserv">Description of
Interactions with a Service</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;4.5 <a href="#messages">Messages and
Types</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;4.6 <a href="#servicetypes">Service
Types</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;4.7 <a href=
"#binddesc">InterfaceBindings</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;4.8 <a href=
"#reusable">Reusability</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;4.9 <a href=
"#extensible">Extensibility</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;4.10 <a href=
"#versioning">Versioning</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;4.11 <a href="#security">Security</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;4.12 <a href="#semanweb">Mapping to the
Semantic Web</a><br />
5 <a href="#external">Requirements from other W3C WGs</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;5.1 <a href="#N10625">XML
Protocol</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;5.2 <a href="#N10628">XForms</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;5.3 <a href="#N1062B">RDF</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;5.4 <a href="#N1062E">P3P</a><br />
</p>

<h3><a id="appendices" name="appendices"></a>Appendices</h3>

<p class="toc">A <a href="#N10632">References</a><br />
B <a href="#N10717">Acknowledgments</a> (Non-Normative)<br />
</p>
</div>

<hr />
<div class="body">
<div class="div1">
<h2><a id="notations" name="notations"></a>1 Notations</h2>

<p>The following terminology and typographical conventions have
been used in this document.</p>

<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted in a manner similar to that
described in <a href="#RFC2119">[IETF RFC 2119]</a>. (Changes from
<a href="#RFC2119">[IETF RFC 2119]</a> are indicated with
<em>emphasis</em>.)</p>

<dl>
<dt class="label">MUST, REQUIRED, SHALL</dt>

<dd>
<p>The <em>requirement</em> is an absolute requirement. The
specification <em>produced by the WG must address this
requirement</em>.</p>
</dd>

<dt class="label">SHOULD, RECOMMENDED</dt>

<dd>
<p>There may exist valid reasons <em>for the WG</em> to ignore
<em>this requirement</em>, but the implications <em>of doing
so</em> must be understood and weighed before doing so.</p>
</dd>

<dt class="label">MAY, OPTIONAL</dt>

<dd>
<p>The <em>requirement</em> is truly optional. <em>The WG</em> may
choose to omit the <em>requirement for the sake of scope or
schedule</em>.</p>
</dd>
</dl>

<p>For the sake of process and clarity, each requirement is
annotated with meta data.</p>

<ul>
<li>
<p>Each requirement has an identification number. The numbers are
arbitrary and do not imply any ordering or significance.</p>
</li>

<li>
<p>Draft requirements are annotated to indicate their review status
within the WG:</p>

<dl>
<dt class="label">[Draft]</dt>

<dd>
<p>A candidate requirement the WG is actively considering but has
<em>not</em> yet reached consensus on.</p>
</dd>
</dl>
</li>

<li>
<p>To indicate their source, requirements may be annotated with the
initials of the original submitter, 'Charter' (from <a href=
"#WSDCharter">[WSD Charter]</a>), or 'WG' (from WG discussion).</p>
</li>
</ul>
</div>

<div class="div1">
<h2><a id="definitions" name="definitions"></a>2 Definitions</h2>

<p>The definitions in this section are drawn primarily from <a
href="#WSDL11">[WSDL 1.1]</a> and are intended to be used for
purposes of discussion. They are not intended to constrain the
results of the WG.</p>

<div class="div2">
<h3><a id="nonNormDefs" name="nonNormDefs"></a>2.1 Non-normative
definitions</h3>

<dl>
<dt class="label">Web Service</dt>

<dd>
<p>[<a title="Web Service" id="web_service" name=
"web_service">Definition</a>: A <b>Web Service</b> is a software
application identified by a URI <a href="#RFC2396">[IETF RFC
2396]</a>, whose interfaces and binding are capable of being
defined, described and discovered by XML artifacts and supports
direct interactions with other software applications using XML
based messages via Internet-based protocols. ]</p>
</dd>

<dt class="label">Client</dt>

<dd>
<p>[<a title="Client" id="client" name="client">Definition</a>: A
<b>Client</b> is a software that makes use of a <a title=
"Web Service" href="#web_service">Web Service</a>, acting as its
'user' or 'customer'.]</p>
</dd>
</dl>
</div>

<div class="div2">
<h3><a id="normDefs" name="normDefs"></a>2.2 Normative
definitions</h3>

<dl>
<dt class="label">Message</dt>

<dd>
<p>[<a title="Message" id="Message" name="Message">Definition</a>:
A <b>Message</b> is the basic unit of communication between a <a
title="Web Service" href="#web_service">Web Service</a> and a <a
title="Client" href="#client">Client</a>; data to be communicated
to or from a Web Service as a single logical transmission.]</p>
</dd>

<dt class="label">Operation</dt>

<dd>
<p>[<a title="Operation" id="Operation" name=
"Operation">Definition</a>: A sequence of <a title="Message" href=
"#Message">Messages</a> related to a single <a title="Web Service"
href="#web_service">Web Service</a> action is called an
<b>Operation</b>.]</p>
</dd>

<dt class="label">Interface (AKA Port Type)</dt>

<dd>
<p>[<a title="Interface" id="Interface" name=
"Interface">Definition</a>: A logical grouping of <a title=
"Operation" href="#Operation">operations</a>. An <b>Interface</b>
represents an abstract <a title="Web Service" href=
"#web_service">Web Service</a> type, independent of transmission
protocol and data format.]</p>
</dd>

<dt class="label">InterfaceBinding</dt>

<dd>
<p>[<a title="InterfaceBinding" id="InterfaceBinding" name=
"InterfaceBinding">Definition</a>: An association between an <a
title="Interface" href="#Interface">Interface</a>, a concrete
protocol and/or a data format. An <b>InterfaceBinding</b> specifies
the protocol and/or data format to be used in transmitting <a
title="Message" href="#Message">Messages</a> defined by the
associated Interface.]</p>
</dd>

<dt class="label">EndPoint (AKA Port)</dt>

<dd>
<p>[<a title="EndPoint" id="EndPoint" name=
"EndPoint">Definition</a>: An association between a fully-specified
<a title="InterfaceBinding" href=
"#InterfaceBinding">InterfaceBinding</a> and a network address,
specified by a URI <a href="#RFC2396">[IETF RFC 2396]</a>, that may
be used to communicate with an instance of a <a title="Web Service"
href="#web_service">Web Service</a>. An <b>EndPoint</b> indicates a
specific location for accessing a Web Service using a specific
protocol and data format.]</p>
</dd>

<dt class="label">Service</dt>

<dd>
<p>[<a title="Service" id="Service" name="Service">Definition</a>:
A collection of <a title="EndPoint" href="#EndPoint">EndPoints</a>
is called <b>Service</b>.]</p>
</dd>
</dl>
</div>
</div>

<div class="div1">
<h2><a id="relationship2charter" name="relationship2charter"></a>3
Relationship to WG Charter</h2>

<p>The Web Services Description WG Charter <a href=
"#WSDCharter">[WSD Charter]</a> has two sections describing what is
in-scope and what is out-of-scope of the problem space defined for
the WG. The WG considers all the requirements in <a href=
"http://www.w3.org/2002/01/ws-desc-charter#scope">Section 1</a> of
<a href="#WSDCharter">[WSD Charter]</a> to be in-scope per the
Charter.</p>

<p>Reviewers and readers should be familiar with the Web Services
Description WG Charter <a href="#WSDCharter">[WSD Charter]</a>
because it provides the critical context for the requirements and
any discussion of them.</p>
</div>

<div class="div1">
<h2><a id="requirements" name="requirements"></a>4
Requirements</h2>

<div class="div2">
<h3><a id="genreqs" name="genreqs"></a>4.1 General</h3>

<dl>
<dt class="Accepted">R001</dt>

<dd class="Accepted">
<p>The description language MUST allow any programming model,
transport, or protocol for communication between peers. (From the
Charter. Last revised 23 Apr 2002.)</p>
</dd>

<dt class="Accepted">R004</dt>

<dd class="Accepted">
<p>The WG specification(s) MUST describe constructs using the <a
href="#InfoSet">[XML Information Set]</a> model (similar to the
SOAP 1.2 specifications <a href="#SOAP12">[SOAP 1.2 Part 1]</a>).
(From JS. Last revised 21 Feb 2002.)</p>
</dd>

<dt class="Accepted">R099</dt>

<dd class="Accepted">
<p>Processors of the description language MUST support XML Schema
(http://www.w3.org/2001/XMLSchema). See also <a href=
"#XMLSchema1">[XML Schema Part 1]</a>. (From WG discussion. Last
discussed 21 Feb 2002.)</p>
</dd>

<dt class="Accepted">R100</dt>

<dd class="Accepted">
<p>The description language MUST allow other type systems besides
XML Schema (http://www.w3.org/2001/XMLSchema) via extensibility.
(From WG discussion. Last discussed 21 Feb 2002.)</p>
</dd>

<dt class="Accepted">R098</dt>

<dd class="Accepted">
<p>The WG specification(s) schema and examples MUST be written in
XML Schema and SHOULD be written in the latest public W3C XML
Schema Recommendation. (From WG discussion. Last revised 28 Feb
2002.)</p>
</dd>

<dt class="Accepted">R005</dt>

<dd class="Accepted">
<p>The WG specification(s) MUST correct errors/inconsistencies in
<a href="#WSDL11">[WSDL 1.1]</a>. (From KL. Last revised 10 Apr
2002.)</p>
</dd>

<dt class="Accepted">R007</dt>

<dd class="Accepted">
<p>The WG specification(s) MUST provide detailed examples,
including on-the-wire messages. (From KL. Last revised 10 Apr
2002.)</p>
</dd>

<dt class="Accepted">R003</dt>

<dd class="Accepted">
<p>The WG specification(s) SHOULD use available XML technologies.
(From JS. Last revised 10 Apr 2002.)</p>
</dd>

<dt class="Accepted">R105</dt>

<dd class="Accepted">
<p>The WG specification(s) SHOULD support Web Services that operate
on resource constrained devices. (From YF. Last discussed 10 Apr
2002.)</p>
</dd>

<dt class="Accepted">R010</dt>

<dd class="Accepted">
<p>The WG specification(s) SHOULD use consistent terminology across
all sections of the specification(s). (From KL. Last revised 10 Apr
2002.)</p>
</dd>

<dt class="Accepted">R124</dt>

<dd class="Accepted">
<p>The WG MUST register a MIME type for WSDL (perhaps
application/wsdl+xml). (From WG discussion. Last revised 27 Jun
2002.)</p>
</dd>

<dt class="Rejected">R006</dt>

<dd class="Rejected">
<p>[Rejected, KL] Provide better specification for document name
and linking. <a href=
"http://www.w3.org/TR/2001/NOTE-wsdl-20010315#_document-n">WSDL 1.1
Section 2.1.1</a> is over simple. More detailed specification
should be provided to define how the import mechanism works,
especially how it is related to the import and include mechanism
defined in the XML Schema specification <a href="#XMLSchema1">[XML
Schema Part 1]</a>. (Last revised 10 Apr 2002. Redundant with R005,
don't need each individual issue listed in the requirements doc.
The WG already has two issues in its issues document for clarifying
import, and adding include.)</p>
</dd>

<dt class="Rejected">R009</dt>

<dd class="Rejected">
<p>[Rejected, KL] Enable easy Interaction with Upper layers in the
Web Services stack. Additional technologies will be required in the
future to complete the Web Services architecture. As one of the
fundamental layers of the Web Services stack, though WSDL should
not depend on any other layers, one of the design goals of WSDL
should be easy interaction with upper layers, such as Services
composition layers. (Last revised 10 Apr 2002. Success is not
measurable.)</p>
</dd>

<dt class="Rejected">R103</dt>

<dd class="Rejected">
<p>[Rejected, YF] WSDL specifications should be clear and easy to
understand. This clarity implies that considerable editorial effort
will be required in the structuring of the narrative through both
outline/overview and normative reference material. (Last revised 10
Apr 2002. A specification should be precise. Clear and easy to
understand are both very subjective)</p>
</dd>

<dt class="Rejected">R008</dt>

<dd class="Rejected">
<p>[Rejected, KL] Support up-to-date XML Schema. In all <a href=
"#WSDL11">[WSDL 1.1]</a> examples, the October 2000 version of the
XML schema is used: http://www.w3.org/2000/10/XMLSchema. We
understand that the 10/2000 schema was the most up-to-dated schema
available at the time WSDL1.1 was released. However, in future
versions of WSDL specification, the W3C Recommendation version of
the XML schema should be used. The recommendation was released in
May 2001 <a href="#XMLSchema1">[XML Schema Part 1]</a>:
http://www.w3.org/2001/XMLSchema. (Last discussed 21 Feb 2002.
Replaced with R098, R099, and R100.)</p>
</dd>
</dl>
</div>

<div class="div2">
<h3><a id="simplicity" name="simplicity"></a>4.2 Simplicity</h3>

<dl>
<dt class="Accepted">R013</dt>

<dd class="Accepted">
<p>The WG specification(s) MUST be simple to understand and
implement correctly. The description language MUST be simple to
use. (From the Charter. Last discussed 7 Mar 2002.)</p>
</dd>

<dt class="Accepted">R014</dt>

<dd class="Accepted">
<p>The WG specification(s) SHOULD be compatible with existing Web
infrastructure. (From the Charter. Last discussed 7 Mar 2002.)</p>
</dd>

<dt class="Rejected">R011</dt>

<dd class="Rejected">
<p>[Rejected, Charter] Focus must be put on simplicity, modularity
and decentralization. (Last discussed 21 Feb 2002. Replaced with
R013, R102, R027.)</p>
</dd>

<dt class="Rejected">R016</dt>

<dd class="Rejected">
<p>[Rejected, JS] Be simple to understand and implement correctly;
comparable to other widespread Web solutions. (Last discussed 21
Feb 2002. Replaced with R013.)</p>
</dd>

<dt class="Rejected">R017</dt>

<dd class="Rejected">
<p>[Rejected, JS] Specification shall be as lightweight as
possible, keeping parts that are mandatory to a minimum. (Last
discussed 7 Mar 2002. Covered by R013.)</p>
</dd>

<dt class="Rejected">R018</dt>

<dd class="Rejected">
<p>[Rejected, JS] Optional parts of the specification should be
orthogonal to each other allowing non-conflicting configurations to
be implemented. (Last discussed 7 Mar 2002. Good goal, but
unnecessary as a specific requirement.)</p>
</dd>

<dt class="Rejected">R019</dt>

<dd class="Rejected">
<p>[Rejected, YF] Facilitate the creation of simple applications
(fast and easy writing for simple apps). (Last discussed 7 Mar
2002. Merged in R013.)</p>
</dd>

<dt class="Rejected">R020</dt>

<dd class="Rejected">
<p>[Rejected, YF] Be possible to compare easily two WSDL Web
Services. (Last discussed 7 Mar 2002. May raise intractable
semantic issues.)</p>
</dd>

<dt class="Rejected">R102</dt>

<dd class="Rejected">
<p>[Rejected, YF] Since WSDL is intended to be a foundation service
description language, its definition should remain simple and
stable over time. Explicit use of modularity and layering in the
resulting design will help assure longevity. Such a framework will
allow subsequent extension of the design while leaving the
foundation of the design intact. (Last discussed 7 Mar 2002.
Adequately covered by 'simple' in R013.)</p>
</dd>

<dt class="Rejected">R104</dt>

<dd class="Rejected">
<p>[Rejected, YF] The WSDL specification must clearly identify
conformance requirements in a way that enables the conformance of
an implementation of the specification to be tested (see also the
W3C Conformance requirements (W3C members only)). (Last discussed 7
Mar 2002. Adequately covered by 'correct' in R013.)</p>
</dd>
</dl>
</div>

<div class="div2">
<h3><a id="interfdesc" name="interfdesc"></a>4.3 Interface
Description</h3>

<dl>
<dt class="Accepted">R021</dt>

<dd class="Accepted">
<p>The description language MUST describe the Messages accepted and
generated by the Web Service. (From the Charter. Last revised 21
Feb 2002.)</p>
</dd>

<dt class="Accepted">R022</dt>

<dd class="Accepted">
<p>The description language MUST allow describing application-level
error Messages (AKA faults) generated by the Web Service. (From the
Charter. Last revised 28 Feb 2002.)</p>
</dd>

<dt class="Accepted">R054</dt>

<dd class="Accepted">
<p>The description language MUST describe Messages independent from
their use in message exchange patterns and/or InterfaceBindings.
(From YF. Last revised 17 Oct 2002.)</p>
</dd>

<dt class="Accepted">R041</dt>

<dd class="Accepted">
<p>The description language MUST allow describing sets of
Operations that form a logical group. (From JS. Last revised 28 Feb
2002.)</p>
</dd>

<dt class="Accepted">R116</dt>

<dd class="Accepted">
<p>The description language MUST allow describing abstract policies
required or offered by Services. (From GD. Last revised 11 Apr
2002.)</p>
</dd>

<dt class="Accepted">R083</dt>

<dd class="Accepted">
<p>The description language MUST separate design-time from run-time
information. (From JS. Last discussed 11 Apr 2002.)</p>
</dd>

<dt class="Accepted">R026</dt>

<dd class="Accepted">
<p>The description language MUST provide human-readable comment
capabilities. (From the Charter. Last discussed 28 Feb 2002.)</p>
</dd>

<dt class="Accepted">R123</dt>

<dd class="Accepted">
<p>The content model for human-readable comment capabilities MUST
be open. (From RD. Last discussed 11 June 2002.)</p>
</dd>

<dt class="Accepted">R042</dt>

<dd class="Accepted">
<p>The description language SHOULD allow deriving one Interface
from another by extension of the logical group of Messages. (From
JS. Last discussed 11 June 2002.)</p>
</dd>

<dt class="Accepted">R117</dt>

<dd class="Accepted">
<p>The description language SHOULD allow specifying QoS-like
policies and mechanisms of a Web Service. For instance, an
indication of how long it is going to take a Web Service to process
the request. (From WG discussion. Last discussed 12 April
2002.)</p>
</dd>

<dt class="Rejected">R109</dt>

<dd class="Rejected">
<p>[Rejected, JS] The language must describe Interfaces separate
from their concrete protocol, transport, data format or wire format
deployment. (See also R046.) (Last discussed 7 Mar 2002. Covered by
R071. ?I think we wrote this to respond to the partition
description across multiple files (R071) but then discarded the
other requirement (described in the wording of this requirement)
that underlies the definition of an Interface versus an
InterfaceBinding?)</p>
</dd>

<dt class="Rejected">R032</dt>

<dd class="Rejected">
<p>[Rejected, WS] In a lot of cases, it is important for the server
to expose some service-wide properties/attributes. These
properties/attributes have the service-level scope and could be
used to describe either some QoS parameters or some application
specific characteristics. As an example, a service may want to
expose an attribute which describes the version number of the
service. Hence, WSDL should be able to model service level
attributes/properties. (Last discussed 11 April 2002. Covered by
R117, R116, R075.)</p>
</dd>

<dt class="Rejected">R112</dt>

<dd class="Rejected">
<p>[Rejected, SK] A Web Service description should be able to
define extensible mechanisms for capturing meta-information
associated with a message. A WS description allows it to publish
the message interactions it is capable of handling. However, this
description alone does not capture any meta-information associated
with the message interaction definitions. The message interactions
are meaningful in a given business domain, or more precisely, as
defined as part of W3C work on ontology. Some of the examples of
the meta-information are:</p>

<ol type="1">
<li>
<p>Some messages of a WS may require authentication
information.</p>
</li>

<li>
<p>Some messages of a WS may deal with in a particular Business
Domain. For instance, submitPO, may be an overloaded message where
one such message primarily deals with RosettaNet.</p>
</li>

<li>
<p>QoS parameters</p>
</li>
</ol>

<p>(Last discussed 11 April 2002. Covered by R117, R116, and
others.)</p>
</dd>

<dt class="Rejected">R035</dt>

<dd class="Rejected">
<p>[Rejected, KL] Distinction between interface definition and
implementation definition. A description of a Web Service can be
logically divided into three parts: Data type definition, Service
Interface definition and Service Implementation definition. The
data type definition can be viewed as part of the Service Interface
Definition. Analogous to defining an abstract interface in a
programming language and having many concrete implementations, a
service interface definition can be instantiated and referenced by
multiple service implementers. <a href="#WSDL11">[WSDL 1.1]</a>
specification implies such a division by providing the mechanism
for dividing a service definition into multiple WSDL documents. <a
href="http://www.w3.org/TR/2001/NOTE-wsdl-20010315#_style">WSDL1.1
Section 2.1.2, Authoring Style</a>, shows an example of separating
a complete service definition into three documents: data type
definition, abstract definitions and specific service bindings.
However, this distinction is not clear and reference to each unit
is very difficult. To facilitate easier allocation of
responsibilities among different organizations (such as standard
bodies and service providers) or among different teams within an
organization (such as teams related to the different stages of a
service's life-cycle: design time/development time, configuration
time and run time), a better distinction between Interface
definition and Implementation definition should be made in the
specification. Elements such as Message, PortType, Operation are
abstract interface definitions, and are usually defined at design
time. Elements such as InterfaceBinding and Services usually get
their value at configuration/deployment/run time. Mixing all these
elements together is at least confusing to many people. (Last
discussed 11 April 2002. Covered by R083.)</p>
</dd>

<dt class="Rejected">R089</dt>

<dd class="Rejected">
<p>[Rejected, KB] Describe Web Services Operations in an abstract
format using the XML type system. (Last discussed 11 April, 2002.
Covered by R099.)</p>
</dd>

<dt class="Rejected">R090</dt>

<dd class="Rejected">
<p>[Rejected, KB] Group logically related Operations together into
abstract Interface types. (Last discussed 11 April, 2002. Covered
by R041.)</p>
</dd>

<dt class="Rejected">R023</dt>

<dd class="Rejected">
<p>[Rejected, Charter] The data exchanged is usually typed and
structured. This increases interoperability by having applications
agreeing on semantics and also provides some level of error
detection. It is expected that developers will want to use
different mechanisms for describing data types and structures,
depending on the purpose of the Web service. The WG should allow
different mechanisms, and must define one based on XML Schema.
(Last discussed 21 Feb 2002. Covered by R021, R090, R100.)</p>
</dd>

<dt class="Rejected">R033</dt>

<dd class="Rejected">
<p>[Rejected, YF] Support abstract interfaces. (Last discussed 28
Feb 2002. Replaced by R109.)</p>
</dd>

<dt class="Rejected">R034</dt>

<dd class="Rejected">
<p>[Rejected, YF] Support interfaces derived from abstract
interfaces. (Last discussed 28 Feb 2002. Replaced by R109.)</p>
</dd>

<dt class="Rejected">R101</dt>

<dd class="Rejected">
<p>[Rejected, KL] The final WSDL specification should be divided
into two parts: the first part only focuses on the core interface
definition language, and the second part addresses the binding
extensions. This requirement concurs with the Charter's requirement
for two separate deliverables. (Last discussed 28 Feb 2002. Concern
that this over constrains the specification process.)</p>
</dd>
</dl>
</div>

<div class="div2">
<h3><a id="desintwserv" name="desintwserv"></a>4.4 Description of
Interactions with a Service</h3>

<dl>
<dt class="Accepted">R036</dt>

<dd class="Accepted">
<p>The description language MUST allow describing the functionality
associated with one-way messages (to and from the service
described), request-response, solicit-response, and faults. (From
the Charter. Last revised 28 Feb 2002.)</p>
</dd>

<dt class="Accepted">R044</dt>

<dd class="Accepted">
<p>The description language SHOULD allow describing both
application data and context data of a Service. (From PF. Last
discussed 12 April 2002.)</p>
</dd>

<dt class="Accepted">R097</dt>

<dd class="Accepted">
<p>The description language SHOULD allow describing asynchronous
message exchange patterns. (From IS. Last discussed 11 April
2002.)</p>
</dd>

<dt class="Accepted">R110</dt>

<dd class="Accepted">
<p>The description language SHOULD allow indicating how long a Web
Service is going to take to process the request. This is just a
hint to the <a title="Client" href="#client">Client</a>, and the
Web Service would not be obligated to respect what it advertised.
(From WV. Special case of R117.)</p>
</dd>

<dt class="Accepted">R094</dt>

<dd class="Accepted">
<p>The description language MAY allow describing events and
output-oriented Operations. The description language MAY be very
specific about events, defining a special type of a Message or even
a separate definition entity. (From IS. Last discussed 12 April
2002.)</p>
</dd>

<dt class="Rejected">R040</dt>

<dd class="Rejected">
<p>[Rejected, JS] Describe arbitrary Message exchanges. (Last
discussed 11 April 2002. Out of scope.)</p>
</dd>

<dt class="Rejected">R045</dt>

<dd class="Rejected">
<p>[Rejected, PF] WSDL is typically used to capture the Web Server
requirements on the <a title="Client" href="#client">Client</a>.
For example, the Web Server will expect to see certain SOAP
headers. When WSDL is used in higher protocols, such as an
orchestration language, each side of the exchange may wish to
publish their requirements, and the <a title="Client" href=
"#client">Client</a> may have a requirement on the Web Server. For
example, the <a title="Client" href="#client">Client</a> may
require the Web Server to set a particular header on the response.
In WSDL today, there is an option to try to map this into the
'out-in' or 'out' interactions, by treating them as the
'conjugates' of the corresponding 'in-out' or 'in-only' Operations.
However, this is unsatisfactory, as these interactions are not well
defined, and there is no way to specify that an out-in is actually
the conjugate of an in-out, or simply another Operation that has
the same messages in the opposite order. It would be more
satisfactory if the concept of 'conjugates' was exposed directly so
that the <a title="Client" href="#client">Client</a> side of an
interaction could publish their requirements. This could be used by
proposal such as flow or orchestration languages. (Last discussed
12 April 2002. Out of scope as a feature - move to use cases.)</p>
</dd>

<dt class="Rejected">R037</dt>

<dd class="Rejected">
<p>[Rejected, JJM] Must describe SOAP 1.2 MEP (Message Exchange
Pattern) (charter says: "must [...] describe [...] one-way
Messages, [...] request-response") (Last discussed 28 Feb 2002.
Covered by R036.)</p>
</dd>

<dt class="Rejected">R038</dt>

<dd class="Rejected">
<p>[Rejected, JS] Must be able to describe simple one-way Messages,
i.e., either incoming or outgoing (event) Messages. (Last discussed
28 Feb 2002. Covered by R036.)</p>
</dd>

<dt class="Rejected">R039</dt>

<dd class="Rejected">
<p>[Rejected, JS] Must be able to describe simple
request-response-fault Message exchange. (Last discussed 28 Feb
2002. Covered by R036.)</p>
</dd>

<dt class="Rejected">R122</dt>

<dd class="Rejected">
<p>The description language MAY allow restricting and/or describing
the possible flow of Messages between the Web Service and a Client.
The description language MAY in particular allow describing what
applicative Fault refers to what incorrect call flow. (Last
discussed 11 June 2002. Beyond WG scope.)</p>
</dd>
</dl>
</div>

<div class="div2">
<h3><a id="messages" name="messages"></a>4.5 Messages and
Types</h3>

<dl>
<dt class="Accepted">R046</dt>

<dd class="Accepted">
<p>The description language MUST describe Messages independent from
transfer encodings. (From JS. Last discussed 17 Oct 2002.)</p>
</dd>

<dt class="Accepted">R085</dt>

<dd class="Accepted">
<p>The description language SHOULD allow describing Messages that
include references (URIs) to typed referents, both values and
Services. (From PP. Last discussed 11 April, 2002.)</p>
</dd>

<dt class="Rejected">R051</dt>

<dd class="Rejected">
<p>[Rejected, JS] Be able to describe Messages that include arrays
and nested arrays. (Last discussed 11 April 2002. Subsumed by
R100.)</p>
</dd>

<dt class="Rejected">R047</dt>

<dd class="Rejected">
<p>[Rejected, JS] Be able to describe the semantic content of
messages. (Last revised 11 April 2002. Out of scope.)</p>
</dd>

<dt class="Rejected">R096</dt>

<dd class="Rejected">
<p>[Rejected, IS] Be able to describe references to other Web
Services (remote) or other Interfaces (EndPoints, local to this
WSDL doc) that can be used as parts in Message definitions.
Currently (as of <a href="#WSDL11">[WSDL 1.1]</a>) Message parts
refer to data types (described in one or the other schema). The
part must also be able to refer to a remote Web Service (WSDL
URL/Service/Port) or a local Web Service/EndPoint qualified names.
This has to be made clear as part of the standard for WS <a title=
"Client" href="#client">Client</a>s and Web Service providers.
(Last discussed 11 April 2002, covered by R085.)</p>
</dd>

<dt class="Rejected">R055</dt>

<dd class="Rejected">
<p>[Rejected, YF] Support grouping functionalities (Operations)
that share the same Message-exchange pattern and transport
InterfaceBinding. (Last discussed 11 April, 2002. Unclear what
problem this "solution" is targeted at.)</p>
</dd>

<dt class="Rejected">R053</dt>

<dd class="Rejected">
<p>[Rejected, JR] Be able to classify/categorize [individual]
Operations. With the usage of XML schema in the ELEMENT attribute
of the PART element (current WSDL spec), it is possible to use a
type system as a kind of taxonomy for a semantically enriched
description of parameters. To automatically search a suitable Web
Service respectively Operation from a set of Web Service
descriptions, it is not enough only to consider the parameters but
also a kind of Operation "type" (something like a taxonomy on
Operations). So I would suggest a kind of ELEMENT or TYPE attribute
for Operations. (Last discussed 11 April 2002. Out of scope.)</p>
</dd>

<dt class="Rejected">R093</dt>

<dd class="Rejected">
<p>[Rejected, IS] Be able to accommodate namespace clusters with
data types (schemas) and Interface definitions (Message / EndPoint
/ InterfaceBinding). I.e., Service may have several namespaces with
types and several other namespaces with Message/EndPoint
definitions. That is pretty important for expressing proper OO
model of a Service. Very few framework implementations pay
attention to this. (In many cases namespaces are flattened out
which results in name conflicts.) I guess it is so because
namespaces of various type definitions and Message / EndPoint /
InterfaceBinding definitions have never been emphasized as a
requirement really. (Last discussed 11 April, 2002. This
requirement seems to be addressed to poor/incomplete
implementations of namespaces.)</p>
</dd>

<dt class="Rejected">R048</dt>

<dd class="Rejected">
<p>[Rejected, JS] Must be able to describe Messages using XML
Schema simple and complex types. (Last discussed 11 April 2002.
Covered by R099.)</p>
</dd>

<dt class="Rejected">R049</dt>

<dd class="Rejected">
<p>[Rejected, JS] Be able to describe Messages using other info
sets. (Last discussed 11 April, 2002. Covered by R100.)</p>
</dd>
</dl>
</div>

<div class="div2">
<h3><a id="servicetypes" name="servicetypes"></a>4.6 Service
Types</h3>

<dl>
<dt class="Accepted">R118</dt>

<dd class="Accepted">
<p>The description language SHOULD group Interfaces into a Service
type. (From JS. Last discussed 12 April 2002.)</p>
</dd>

<dt class="Accepted">R058</dt>

<dd class="Accepted">
<p>The description language SHOULD allow deriving one Service type
from another by extension of the logical group of
InterfaceBindings. (From JS. Last discussed 12 April 2002.)</p>
</dd>

<dt class="Rejected">R106</dt>

<dd class="Rejected">
<p>[Rejected, PM] Ability to associate a network address with an
InterfaceBinding at runtime. For example, it is possible to have a
Interface that supports Operations like "Register" and "Notify"
where a user will provide an email address that a Web Service can
send notifications to when the user registers with the Service. So
the network address for the "Notify" Operation needs to be
dynamically populated at runtime. (Last discussed 12 April 2002,
Covered by R083 and R085, move to use cases.)</p>
</dd>

<dt class="Rejected">R057</dt>

<dd class="Rejected">
<p>[Rejected, JS] Be able to name an instance of a EndPoint
independent of its address. (Last discussed 12 April 2002. Needs
clarification.)</p>
</dd>

<dt class="Rejected">R056</dt>

<dd class="Rejected">
<p>[Rejected, JS] Be able to describe a logical group of
fully-specified InterfaceBindings without specifying a network
address that may be used to communicate with the instance of the
InterfaceBinding. That is, be able to describe a Service type.
(Prescribes a specific means to fulfill R106.) (Last discussed 12
April 2002, probably covered by R118.)</p>
</dd>
</dl>
</div>

<div class="div2">
<h3><a id="binddesc" name="binddesc"></a>4.7 InterfaceBindings</h3>

<dl>
<dt class="Accepted">R081</dt>

<dd class="Accepted">
<p>The description language MUST describe EndPoint location using
URIs. (From JS.)</p>
</dd>

<dt class="Accepted">R114</dt>

<dd class="Accepted">
<p>The description language MUST allow unambiguously mapping any
on-the-wire Message to an Operation. (From WG discussion. Last
revised 4 Apr 2002.)</p>
</dd>

<dt class="Accepted">R060</dt>

<dd class="Accepted">
<p>The description language MUST allow specifying an association
between an Interface and one or more concrete protocols and/or data
formats. (From the Charter. Last revised 12 Apr 2002.)</p>
</dd>

<dt class="Accepted">R068</dt>

<dd class="Accepted">
<p>The description language MUST allow binding of transport
characteristics independently of data marshalling characteristics.
(From PF. Last discussed 12 April 2002.)</p>
</dd>

<dt class="Accepted">R052</dt>

<dd class="Accepted">
<p>The description language MUST allow describing InterfaceBindings
to other protocols besides those described in the specification.
(From JS. Last revised 11 April 2002.)</p>
</dd>

<dt class="Accepted">R111</dt>

<dd class="Accepted">
<p>The WG MUST provide a normative description of the
InterfaceBinding for HTTP/1.1 <a href="#RFC2616">[IETF RFC
2616]</a> GET and POST. (From the Charter. Last revised 28 Mar
2002.)</p>
</dd>

<dt class="Accepted">R066</dt>

<dd class="Accepted">
<p>The description language MUST allow binding Interfaces to
transports other than HTTP/1.1 <a href="#RFC2616">[IETF RFC
2616]</a>. (From JS. Last discussed 12 April 2002.)</p>
</dd>

<dt class="Accepted">R028</dt>

<dd class="Accepted">
<p>The description language MUST allow describing the structure of
incoming and outgoing SOAP 1.2 messages <a href="#SOAP12">[SOAP 1.2
Part 1]</a>, including the contents, encoding, target, and
optionality of SOAP 1.2 Header and Body blocks, SOAP RPC blocks,
and SOAP Faults. (From JJM. Last revised 12 Apr 2002.)</p>
</dd>

<dt class="Accepted">R113</dt>

<dd class="Accepted">
<p>The description language MUST allow describing which SOAP
features are offered by or required by an Operation or a Service.
(From GD. Last revised 4 Apr 2002.)</p>
</dd>

<dt class="Accepted">R065</dt>

<dd class="Accepted">
<p>The WG MUST provide a normative description of the
InterfaceBinding for SOAP 1.2 over HTTP/1.1. (From JS. Last revised
28 Mar 2002.)</p>
</dd>

<dt class="Accepted">R062</dt>

<dd class="Accepted">
<p>The WG specification(s) MUST ensure that the SOAP 1.2
InterfaceBinding is capable of describing transports other than
HTTP. (From the Charter. Last revised 28 Mar 2002.)</p>
</dd>

<dt class="Accepted">R125</dt>

<dd class="Accepted">
<p>The normative description of the InterfaceBinding for SOAP 1.2
MUST support the SOAP 1.2 MEP for HTTP GET in and HTTP SOAP out.
(From TAG. Last discussed 26 Sep 2002.)</p>
</dd>

<dt class="Accepted">R031</dt>

<dd class="Accepted">
<p>The WG specification(s) SHOULD support SOAP 1.2 intermediaries.
(From JJM. Last discussed 11 April 2002.)</p>
</dd>

<dt class="Rejected">R025</dt>

<dd class="Rejected">
<p>[Rejected, Charter] The WG will make sure that SOAP 1.2
extensibility mechanism can be expressed. (Last discussed 11 April
2002. Covered by R113.)</p>
</dd>

<dt class="Rejected">R107</dt>

<dd class="Rejected">
<p>[Rejected, JJ] Based on the XML Protocol Usage Scenario (2.14
S21 Incremental parsing/processing of SOAP messages) and other
requirements (a SOAP processor returning a large amount of data as
attachment or message) there is a need for a SOAP processor and the
SOAP client proxies to be constructed with the notion of data
streaming in mind so that applications can scale well. (Especially
in the case of dynamic proxy and stub creation scenarios.) This
requirement for the SOAP processors imposed a requirement on the
WSDL to be descriptive enough (like MIME binding or some kind of
extension) to describe so that the Service Provider will do
incremental parsing and processing of data (input) and the client
can process the return message or attachment the same way. Without
this description most of the toolkits will find it difficult to use
this SOAP processor advantages for scalability and/or fail in
interoperability. (Last discussed 12 April 2002. Covered by
R117.)</p>
</dd>

<dt class="Rejected">R082</dt>

<dd class="Rejected">
<p>[Rejected, JS] Be able to describe the address for specific
EndPoint instances within a Service. (Last discussed 12 April.
Covered by R081.)</p>
</dd>

<dt class="Rejected">R086</dt>

<dd class="Rejected">
<p>[Rejected, PP] Support all HTTP methods (verbs), including
WebDAV and allow the use of non-standard HTTP methods. (Last
discussed 12 April 2002. Out of Scope.)</p>
</dd>

<dt class="Rejected">R029</dt>

<dd class="Rejected">
<p>[Rejected, JJM] Describe SOAP 1.2 Header and Body's content
type. (Charter says: "must define [a mechanism for describing data
types and structures] based on XML Schema" and "take into account
ending work going on in XML Protocol".) (Last discussed 28 Mar
2002. Covered adequately by R028.)</p>
</dd>

<dt class="Rejected">R030</dt>

<dd class="Rejected">
<p>[Rejected, JJM] Describe SOAP 1.2 RPC parameters types (ibid.).
(Last discussed 28 Mar 2002. Duplicate of R028.)</p>
</dd>

<dt class="Rejected">R061</dt>

<dd class="Rejected">
<p>[Rejected, Charter] It is expected that in the near-term future,
Web Services will be accessed largely through SOAP Version 1.2 <a
href="#SOAP12">[SOAP 1.2 Part 1]</a> (the XML-based protocol
produced by the XML Protocol Working Group) carried over HTTP/1.1
<a href="#RFC2616">[IETF RFC 2616]</a>, or by means of simple
HTTP/1.1 GET and POST requests. Therefore, (a) the WG will provide
a normative InterfaceBinding for SOAP Version 1.2 over HTTP, and
(b) the WG should provide a normative InterfaceBinding for HTTP/1.1
GET and POST requests. (Last discussed 28 Mar 2002. Covered by R065
and R111, respectively.)</p>
</dd>

<dt class="Rejected">R063</dt>

<dd class="Rejected">
<p>[Rejected, JJM] Ensure that SOAP 1.2 bindings to SMTP or BEEP
(for example) can be described. (Charter says: "ensure that other
SOAP bindings can be described".) (Last discussed 28 Mar 2002.
Adequately covered by R062.)</p>
</dd>

<dt class="Rejected">R064</dt>

<dd class="Rejected">
<p>[Rejected, JS] Be able to describe the wire format of Messages,
including, but not limited to, XML, ASCII, binary, or some
combination. (Last discussed 28 Mar 2002. Out of scope; should
unambiguously refer to wire format but not describe wire format per
se.)</p>
</dd>

<dt class="Rejected">R069</dt>

<dd class="Rejected">
<p>[Rejected, KL] Better Specification for InterfaceBinding
Extensions. In addition to the core service definition framework,
<a href="#WSDL11">[WSDL 1.1]</a> introduces specific
InterfaceBinding extensions for SOAP 1.1, HTTP GET/POST, and MIME,
and nothing precludes the use of other InterfaceBinding extensions.
To keep the core service definition framework simple, a separate
and more detailed specification or technical report should be
dedicated for various InterfaceBindings. (Last discussed 28 Mar
2002. Technical requirement merged into R066; editorial
prescription over constrains the specification process.)</p>
</dd>

<dt class="Rejected">R077</dt>

<dd class="Rejected">
<p>[Rejected, JS] Be able to describe SOAP 1.2 Messages <a href=
"#SOAP12">[SOAP 1.2 Part 1]</a>. (Last discussed 28 Mar 2002.
Covered by R028.)</p>
</dd>

<dt class="Rejected">R078</dt>

<dd class="Rejected">
<p>[Rejected, JS] The WG will provide a normative description of
SOAP 1.2 Messages. (Last discussed 28 Mar 2002. Covered by
R065.)</p>
</dd>

<dt class="Rejected">R079</dt>

<dd class="Rejected">
<p>[Rejected, JS] Be able to describe SOAP 1.2 Header elements and
Body elements. (Last discussed 28 Mar 2002. Covered by R028.)</p>
</dd>

<dt class="Rejected">R080</dt>

<dd class="Rejected">
<p>[Rejected, JS] Be able to describe SOAP 1.2 Faults. (Last
discussed 28 Mar 2002. Covered by R028.)</p>
</dd>

<dt class="Rejected">R087</dt>

<dd class="Rejected">
<p>[Rejected, FC] <a href="#WSDL11">[WSDL 1.1]</a> defines services
and operations and their bindings to various protocols. However,
the details of how an operation is identified (either generally or
specifically in particular bindings) is, shall we say, rather
vague. As a result, some implementations use the namespace &amp;
element of the first child of Body (in SOAP RPC), others use
SOAPAction header (in SOAP over HTTP), others use only the
namespace, others the element name, others attempt to match the
message type, etc. As a result, interoperability suffers.</p>

<p>It seems like a normative model (at least) for operation
determination is necessary for interoperability between clients and
servers from different vendors. This may be a requirement to define
such a requirement for all defined bindings, as opposed to
something that can be completely specified in the description. But
I believe that such a requirement exists. (Last discussed 4 Apr
2002. Pulled out part that is not covered by R065 into R114.)</p>
</dd>

<dt class="Rejected">R091</dt>

<dd class="Rejected">
<p>[Rejected, KB] Apply specific wire-format serializations
(InterfaceBindings) for Service types. (Last discussed 4 Apr 2002.
Covered by R065, R111, and R067.)</p>
</dd>

<dt class="Rejected">R092</dt>

<dd class="Rejected">
<p>[Rejected, KB] Apply in an orthogonal manner specific
transport(s) for an InterfaceBinding. (Last discussed 4 Apr 2002.
Confusion about the intention of this requirement; perhaps a
requirement for partial InterfaceBindings?)</p>
</dd>

<dt class="Rejected">R108</dt>

<dd class="Rejected">
<p>[Rejected, MW] Must be able to describe messages that include
binary data, where the binary data is transmitted efficiently.
(Last discussed 4 Apr 2002. Consider this requirement to be
discussing attachments, and consider attachments as part of
providing a quality InterfaceBinding to SOAP per R065, R062. If
there are attachments for other InterfaceBindings, then it's up to
those bindings to provide appropriate support.)</p>
</dd>
</dl>
</div>

<div class="div2">
<h3><a id="reusable" name="reusable"></a>4.8 Reusability</h3>

<dl>
<dt class="Accepted">R071</dt>

<dd class="Accepted">
<p>The description language MUST allow partitioning a description
across multiple files. (From JS.)</p>
</dd>

<dt class="Accepted">R072</dt>

<dd class="Accepted">
<p>The description language MUST allow using a description fragment
in more than one description. (From JS. Last discussed 12 April
2002.)</p>
</dd>

<dt class="Rejected">R073</dt>

<dd class="Rejected">
<p>[Rejected, YF] Support reusability of WSDL documents or parts of
documents. (Last discussed 12 April 2002. Covered by R072.)</p>
</dd>
</dl>
</div>

<div class="div2">
<h3><a id="extensible" name="extensible"></a>4.9 Extensibility</h3>

<dl>
<dt class="Accepted">R012</dt>

<dd class="Accepted">
<p>The description language MUST support the kind of extensibility
actually seen on the Web: disparity of document formats and
protocols used to communicate, mixing of XML vocabularies using XML
namespaces, development of solutions in a distributed environment
without a central authority, etc. In particular, the description
language MUST support distributed extensibility. (From the Charter.
Last discussed 12 April 2002.)</p>
</dd>

<dt class="Accepted">R067</dt>

<dd class="Accepted">
<p>The description language MUST allow for extension in description
language components, including at least message, port type,
binding, and service. (From WG discussion. Last discussed 17 Oct
2002.)</p>
</dd>

<dt class="Accepted">R074</dt>

<dd class="Accepted">
<p>The description language MUST allow indicating whether a given
extension is required or optional. (From JS. Last discussed 12
April 2002.)</p>
</dd>

<dt class="Rejected">R121</dt>

<dd class="Rejected">
<p>The description language SHOULD be able to be easily integrated
into other markup languages. This may involve the following types
of considerations: media types <a href="#RFC2046">[IETF RFC
2046]</a>: which should be used for a compound type, schema
wildcarding in the host markup language, containment semantics: how
the interpretation of WSDL is affected by different containing
elements, fragment identifiers: how references that cross namespace
boundaries work. (From MB. Last discussed 11 June 2002. Beyond WG
scope.)</p>
</dd>

<dt class="Rejected">R015</dt>

<dd class="Rejected">
<p>[Rejected, JJM] Must support an open content model. (Charter
says: "must support distributed extensibility" and "will look into
extending Interface descriptions in a decentralized fashion".)
(Last discussed 12 April 2002. Prescribes a specific (but
plausible) means to fulfill R012 and R067.)</p>
</dd>

<dt class="Rejected">R027</dt>

<dd class="Rejected">
<p>[Rejected, Charter] Developers are likely to want to extend the
functionality of an existing Web Service. The WG will look into
extending interface descriptions in a decentralized fashion, i.e.,
without priori agreement with the original interface designers.
(Last discussed 12 April 2002. Covered by R058.)</p>
</dd>

<dt class="Rejected">R043</dt>

<dd class="Rejected">
<p>[Rejected, JS] Be able to extend Interfaces using mechanisms not
explicitly identified in the spec. (Last discussed 12 April 2002.
Merged into R067.)</p>
</dd>

<dt class="Rejected">R050</dt>

<dd class="Rejected">
<p>[Rejected, JS] Be able to extend Message descriptions using
mechanisms not explicitly identified in the spec. (Merged into
R067.)</p>
</dd>

<dt class="Rejected">R059</dt>

<dd class="Rejected">
<p>[Rejected, JS] Be able to extend Service descriptions using
mechanisms not explicitly identified in the spec. (Merged into
R067.)</p>
</dd>

<dt class="Rejected">R095</dt>

<dd class="Rejected">
<p>[Rejected, IS] Extensible meta definitions. Be able to include
<em>typed</em> metadata attributes for any definition element:
Message, Operation, Interface, InterfaceBinding, EndPoint, and
Service. The attributes may also be hierarchical (i.e., defined in
another namespace). (Last discussed 12 April 2002. Attributes is
overly prescriptive; definition elements requirement merged in
R067; use of namespaces covered by R012.)</p>
</dd>
</dl>
</div>

<div class="div2">
<h3><a id="versioning" name="versioning"></a>4.10 Versioning</h3>

<dl>
<dt class="Accepted">R075</dt>

<dd class="Accepted">
<p>The description language MUST allow identifying versions of
Services. (From PF. Last discussed 12 April 2002.)</p>
</dd>

<dt class="Accepted">R119</dt>

<dd class="Accepted">
<p>The description language MUST allow identifying versions of
descriptions. (From PF. Last discussed 12 April 2002.)</p>
</dd>

<dt class="Rejected">R076</dt>

<dd class="Rejected">
<p>[Rejected, FC] It would be good to allow for versioning of
something smaller than a WSDL document. I suspect that tools
vendors will "compose" these documents, and they may sometimes
contain information about a number of unrelated services (or, more
correctly, services that are related in ways other than application
semantics (tool vendor, server location, etc)). It would be good if
Web Services themselves were versioned, the Web Services being the
semantic "unit" being defined. (Last discussed 12 April 2002.
Duplicate of R075.)</p>
</dd>
</dl>
</div>

<div class="div2">
<h3><a id="security" name="security"></a>4.11 Security</h3>

<dl>
<dt class="Accepted">R115</dt>

<dd class="Accepted">
<p>The WG specification(s) SHOULD define an equivalence relation on
Service descriptions. (From SW. Last discussed 17 Oct 2002.)</p>
</dd>

<dt class="Rejected">R084</dt>

<dd class="Rejected">
<p>[Rejected, JS] Compliance must not preclude building
implementations that are resistant to attacks. (Last revised 10 Apr
2002. Vague.)</p>
</dd>

<dt class="Rejected">R088</dt>

<dd class="Rejected">
<p>[Rejected, DM] The specification MAY document how a WSDL
document can be signed, using XMLDsig, so that a potential user of
the WSDL document can establish trust in the information conveyed
about the web service. (Last revised 10 Apr 2002.)</p>
</dd>
</dl>
</div>

<div class="div2">
<h3><a id="semanweb" name="semanweb"></a>4.12 Mapping to the
Semantic Web</h3>

<dl>
<dt class="Accepted">R070</dt>

<dd class="Accepted">
<p>The WG specification(s) MUST allow providing a mapping from the
description language to <a href="#RDF">[RDF]</a>. (From the
Charter. Last revised 11 April, 2002.)</p>
</dd>

<dt class="Accepted">R120</dt>

<dd class="Accepted">
<p>The description language MUST ensure that all conceptual
elements in the description of Messages are addressable by a URI
reference <a href="#RFC2396">[IETF RFC 2396]</a>. (From the
Semantic Web. Last discussed 11 June 2002.)</p>
</dd>
</dl>
</div>
</div>

<div class="div1">
<h2><a id="external" name="external"></a>5 Requirements from other
W3C WGs</h2>

<p>These are requirements submitted by other W3C Working Groups and
Activities.</p>

<dl>
<dt class="Rejected">R024</dt>

<dd class="Rejected">
<p>[Rejected, Charter] The WG will also take into account the
encoding work going on in the XML Protocol Working Group. (Last
discussed 11 April 2002, This is not a requirement on the
specifications we produce, it is a requirement on the behavior of
the Working Group.)</p>
</dd>

<dt class="Rejected">R002</dt>

<dd class="Rejected">
<p>[Rejected, JS] Coordinate with <a href=
"http://www.w3.org/XML">W3C XML Activity</a> and XML Coordination
Group. (Last discussed 11 April 2002, This is not a requirement on
the specifications we produce, it is a requirement on the behavior
of the Working Group.)</p>
</dd>
</dl>

<div class="div2">
<h3><a id="N10625" name="N10625"></a>5.1 XML Protocol</h3>
</div>

<div class="div2">
<h3><a id="N10628" name="N10628"></a>5.2 XForms</h3>
</div>

<div class="div2">
<h3><a id="N1062B" name="N1062B"></a>5.3 RDF</h3>
</div>

<div class="div2">
<h3><a id="N1062E" name="N1062E"></a>5.4 P3P</h3>
</div>
</div>
</div>

<div class="back">
<div class="div1">
<h2><a id="N10632" name="N10632"></a>A References</h2>

<dl>
<dt class="label"><a id="RDF" name="RDF"></a>RDF</dt>

<dd><a href=
"http://www.w3.org/TR/1999/REC-rdf-syntax-19990222"><cite>Resource
Description Framework (RDF) Model and Syntax
Specification</cite></a>, Ora Lassila, R. Swick, Editors. World
Wide Web Consortium, 22 February 1999. This version of the Resource
Description Framework Model and Syntax Recommendation is
http://www.w3.org/TR/1999/REC-rdf-syntax-19990222. The <a href=
"http://www.w3.org/TR/REC-rdf-syntax/">latest version of Resource
Description Framework Model and Syntax</a> is available at
http://www.w3.org/TR/REC-rdf-syntax.</dd>

<dt class="label"><a id="RFC2046" name="RFC2046"></a>IETF RFC
2046</dt>

<dd><a href=
"http://www.ietf.org/rfc/rfc2046.txt"><cite>Multipurpose Internet
Mail Extensions (MIME) Part Two: Media Types</cite></a>, N. Freed,
N. Borenstein Author. Internet Engineering Task Force, November
1996. Available at http://www.ietf.org/rfc/rfc2046.txt.</dd>

<dt class="label"><a id="RFC2119" name="RFC2119"></a>IETF RFC
2119</dt>

<dd><a href="http://www.ietf.org/rfc/rfc2119.txt"><cite>Key words
for use in RFCs to Indicate Requirement Levels</cite></a>, S.
Bradner, Author. Internet Engineering Task Force, June 1999.
Available at http://www.ietf.org/rfc/rfc2119.txt.</dd>

<dt class="label"><a id="RFC2396" name="RFC2396"></a>IETF RFC
2396</dt>

<dd><a href="http://www.ietf.org/rfc/rfc2396.txt"><cite>Uniform
Resource Identifiers (URI): Generic Syntax</cite></a>, T.
Berners-Lee, R. Fielding, L. Masinter, Authors. Internet
Engineering Task Force, August 1998. Available at
http://www.ietf.org/rfc/rfc2396.txt.</dd>

<dt class="label"><a id="RFC2616" name="RFC2616"></a>IETF RFC
2616</dt>

<dd><a href="http://www.ietf.org/rfc/rfc2616.txt"><cite>Hypertext
Transfer Protocol -- HTTP/1.1</cite></a>, R. Fielding, J. Gettys,
J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee,
Authors. Internet Engineering Task Force, June 1999. Available at
http://www.ietf.org/rfc/rfc2616.txt.</dd>

<dt class="label"><a id="SOAP12" name="SOAP12"></a>SOAP 1.2 Part
1</dt>

<dd><a href=
"http://www.w3.org/TR/2002/WD-soap12-part1-20020626/"><cite>SOAP
Version 1.2 Part 1: Messaging Framework</cite></a>, M. Gudgin, M.
Hadley, N. Mendelsohn, J-J. Moreau, and H. F. Nielsen, Editors.
World Wide Web Consortium, 26 June 2002. This version of the SOAP
Version 1.2 Part 1 Specification is
http://www.w3.org/TR/2002/WD-soap12-part1-20020626. The <a href=
"http://www.w3.org/TR/soap12-part1/">latest version of SOAP Version
1.2 Part 1</a> is available at
http://www.w3.org/TR/soap12-part1.</dd>

<dt class="label"><a id="WSDCharter" name="WSDCharter"></a>WSD
Charter</dt>

<dd><a href="http://www.w3.org/2002/01/ws-desc-charter"><cite>Web
Services Description Working Group Charter</cite></a>, J. Marsh, P.
Le H&eacute;garet. World Wide Web Consortium, 26 January 2002.
Available at http://www.w3.org/2002/01/ws-desc-charter.</dd>

<dt class="label"><a id="WSDL11" name="WSDL11"></a>WSDL 1.1</dt>

<dd><a href=
"http://www.w3.org/TR/2001/NOTE-wsdl-20010315"><cite>Web Services
Description Language (WSDL) 1.1</cite></a>, E. Christensen, F.
Curbera, G. Meredith, and S. Weerawarana, Authors. World Wide Web
Consortium, 15 March 2002. This version of the Web Services
Description Language Specification is
http://www.w3.org/TR/2001/NOTE-wsdl-20010315. The <a href=
"http://www.w3.org/TR/wsdl">latest version of Web Services
Description Language</a> is available at
http://www.w3.org/TR/wsdl.</dd>

<dt class="label"><a id="XML" name="XML"></a>XML 1.0</dt>

<dd><a href=
"http://www.w3.org/TR/2000/REC-xml-20001006"><cite>Extensible
Markup Language (XML) 1.0 (Second Edition)</cite></a>, T. Bray, J.
Paoli, C. M. Sperberg-McQueen, and E. Maler, Editors. World Wide
Web Consortium, 10 February 1998, revised 6 October 2000. This
version of the XML 1.0 Recommendation is
http://www.w3.org/TR/2000/REC-xml-20001006. The <a href=
"http://www.w3.org/TR/REC-xml">latest version of XML 1.0</a> is
available at http://www.w3.org/TR/REC-xml.</dd>

<dt class="label"><a id="InfoSet" name="InfoSet"></a>XML
Information Set</dt>

<dd><a href=
"http://www.w3.org/TR/2001/REC-xml-infoset-20011024"><cite>XML
Information Set</cite></a>, J. Cowan and R. Tobin, Editors. World
Wide Web Consortium, 24 October 2001. This version of the XML
Information Set Recommendation is
http://www.w3.org/TR/2001/REC-xml-infoset-20011024. The <a href=
"http://www.w3.org/TR/xml-infoset">latest version of XML
Information Set</a> is available at
http://www.w3.org/TR/xml-infoset.</dd>

<dt class="label"><a id="XMLSchema1" name="XMLSchema1"></a>XML
Schema Part 1</dt>

<dd><a href=
"http://www.w3.org/TR/2001/REC-xmlschema-1-20010502"><cite>XML
Schema Part 1: Structures</cite></a>, H. Thompson, D. Beech, M.
Maloney, and N. Mendelsohn, Editors. World Wide Web Consortium, 2
May 2001. This version of the XML Part 1 Recommendation is
http://www.w3.org/TR/2001/REC-xmlschema-1-20010502. The <a href=
"http://www.w3.org/TR/xmlschema-1/">latest version of XML Schema
Part 1</a> is available at http://www.w3.org/TR/xmlschema-1.</dd>
</dl>
</div>

<div class="div1">
<h2><a id="N10717" name="N10717"></a>B Acknowledgments
(Non-Normative)</h2>

<p>This document is the work of the W3C Web Services Description
Working Group.</p>

<p>The people who have contributed to discussions on <a href=
"mailto:www-ws-desc@w3.org">www-ws-desc@w3.org</a> are also
gratefully acknowledged.</p>
</div>
</div>
</body>
</html>