You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
1888 lines
62 KiB
1888 lines
62 KiB
<!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 <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> © 2002 <a
|
|
href="http://www.w3.org/"><abbr title=
|
|
"World Wide Web Consortium">W3C</abbr></a><sup>®</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 />
|
|
2.1 <a href="#nonNormDefs">Non-normative
|
|
definitions</a><br />
|
|
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 />
|
|
4.1 <a href="#genreqs">General</a><br />
|
|
4.2 <a href=
|
|
"#simplicity">Simplicity</a><br />
|
|
4.3 <a href="#interfdesc">Interface
|
|
Description</a><br />
|
|
4.4 <a href="#desintwserv">Description of
|
|
Interactions with a Service</a><br />
|
|
4.5 <a href="#messages">Messages and
|
|
Types</a><br />
|
|
4.6 <a href="#servicetypes">Service
|
|
Types</a><br />
|
|
4.7 <a href=
|
|
"#binddesc">InterfaceBindings</a><br />
|
|
4.8 <a href=
|
|
"#reusable">Reusability</a><br />
|
|
4.9 <a href=
|
|
"#extensible">Extensibility</a><br />
|
|
4.10 <a href=
|
|
"#versioning">Versioning</a><br />
|
|
4.11 <a href="#security">Security</a><br />
|
|
4.12 <a href="#semanweb">Mapping to the
|
|
Semantic Web</a><br />
|
|
5 <a href="#external">Requirements from other W3C WGs</a><br />
|
|
5.1 <a href="#N10625">XML
|
|
Protocol</a><br />
|
|
5.2 <a href="#N10628">XForms</a><br />
|
|
5.3 <a href="#N1062B">RDF</a><br />
|
|
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 &
|
|
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é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>
|
|
|