- From: Jonathan Marsh <jonathanMarsh@dev.w3.org>
- Date: Wed, 08 Sep 2004 18:49:14 +0000
- To: public-ws-desc-eds@w3.org
Update of /sources/public/2002/ws/desc/requirements
In directory hutz:/tmp/cvs-serv19158/requirements
Modified Files:
ws-desc-reqs.html ws-desc-reqs.xml
Log Message:
Deprecated R031 on intermediares.
Index: ws-desc-reqs.html
===================================================================
RCS file: /sources/public/2002/ws/desc/requirements/ws-desc-reqs.html,v
retrieving revision 1.14
retrieving revision 1.15
diff -C2 -d -r1.14 -r1.15
*** ws-desc-reqs.html 29 Oct 2003 01:42:06 -0000 1.14
--- ws-desc-reqs.html 8 Sep 2004 18:49:12 -0000 1.15
***************
*** 1,389 ****
! <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"><html lang="en"><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; }
!
! dt.label { display: run-in; }
!
! li, p { margin-top: 0.3em;
! margin-bottom: 0.3em; }
!
! .diff-chg { background-color: orange; }
! .diff-del { background-color: red; text-decoration: line-through;}
! .diff-add { background-color: lime; }
!
! table { empty-cells: show; }
!
! table caption {
! font-weight: normal;
! font-style: italic;
! text-align: left;
! margin-bottom: .5em;
! }
!
! 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 rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/base.css"><link rel="alternate" title="" href="" type=""><link rel="contents" href="#contents"></head><body><div class="head">
! <h1>Web Services Description Requirements</h1>
! <h2>Editors' copy $Date$ @@ @@@@ @@@@</h2><dl><dt>This version:</dt><dd><a href="ws-desc-reqs.html">ws-desc-reqs.html</a></dd><dt>Latest version:</dt><dd><a href="http://www.w3.org/2002/ws/desc/wsdl20-patterns">http://www.w3.org/2002/ws/desc/wsdl20-patterns</a></dd><dt>Previous versions:</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=""></a>.</p><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © @@@@ <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.lcs.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a hrf="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>, <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-software">software licensing</a> rules apply.</p></div><hr><div>
! <h2><a name="abstract">Abstract</a></h2><p>
! This document describes the Web Services Description Working
! Group's requirements for the Web Services Description
! specification.
! </p></div><div>
! <h2><a name="status">Status of this Document</a></h2><p><strong>This document is an editors' copy that has
! no official standing.</strong></p><p></p></div><hr><div class="toc">
! <h2><a name="shortcontents">Short Table of Contents</a></h2><p class="toc">1. <a href="#notations">Notations</a><br>2. <a href="#definitions">Definitions</a><br>3. <a href="#relationship2charter">Relationship to WG Charter</a><br>4. <a href="#requirements">Requirements</a><br>5. <a href="#external">Requirements from other W3C WGs</a><br>A. <a href="#IDAV133B">References</a><br>B. <a href="#IDA3433B">Acknowledgments</a> (Non-Normative)<br>C. <a href="#Change-log">Change Log</a> (Non-Normative)<br></p></div><hr><div class="toc">
! <h2><a name="contents">Table of Contents</a></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="#messages">Messages and Types</a><br> 4.4 <a href="#interfdesc">Interface Description</a><br> 4.5 <a href="#desintwserv">Description of Interactions with a WSDLService</a><br> 4.6 <a href="#binddesc">InterfaceBindings</a><br> 4.7 <a href="#reusable">Reusability</a><br> 4.8 <a href="#extensible">Extensibility</a><br> 4.9 <a href="#versioning">Versioning</a><br> 4.10 <a href="#security">Security</a><br> 4.11 <a href="#semanweb">Mapping to the Semantic Web</a><br>5. <a href="#external">Requirements fom other W3C WGs</a><br> 5.1 <a href="#IDAG133B">XML Protocol</a><br> 5.2 <a href="#IDAO133B">XForms</a><br> 5.3 <a href="#IDAQ133B">RDF</a><br> 5.4 <a href="#IDAS133B">P3P</a><br></p>
! <h3><a name="appendix" id="appendix">Appendices</a></h3><p class="toc">A. <a href="#IDAV133B">References</a><br>B. <a href="#IDA3433B">Acknowledgments</a> (Non-Normative)<br>C. <a href="#Change-log">Change Log</a> (Non-Normative)<br></p></div><hr><div class="body"><div class="div1">
! <h2><a 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 [<cite><a href="#RFC2119">IETF RFC 2119</a></cite>]. (Changes from [<cite><a href="#RFC2119">IETF RFC 2119</a></cite>] 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(s) <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 trulyoptional. <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 [<cite><a href="#WSDCharter">WSD Charter</a></cite>]), or 'WG' (from WG discussion).</p></li></ul></div><div class="div1">
! <h2><a name="definitions"></a>2. Definitions</h2><p>
! The definitions in this section are drawn from [<cite><a href="#WSAGLOSS">WSA Glossary</a></cite>] and [<cite><a href="#WSDL11">WSDL 1.1</a></cite>].
! They 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 name="nonNormDefs"></a>2.1 Non-normative definitions</h3><dl><dt class="label">Web service</dt><dd><p>[<a name="web_service" title="Web service">Definition</a>:
! A <b>Web service</b> is a software system identified by a URI [<cite><a href="#RFC2396">IETF RFC 2396</a></cite>],
! whose public interfaces and bindings are defined and described using XML.
! Its definition can be discovered by other software systems.
! These systems may then interact with the Web service in a manner prescribed by its definition,
! using XML based messages conveyed by Internet protocols.
! ]</p></dd><dt class="label">Client</dt><dd><p>[<a name="client" title="Client">Definition</a>:
! A system entity making use of a <a title="Web service" href="#web_service">Web service</a>.
! ]</p></dd></dl></div><div class="div2">
! <h3><a name="normDefs"></a>2.2 Normative definitions</h3><dl><dt class="label">Message</dt><dd><p>[<a name="Message" title="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 name="Operation" title="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 name="Interface" title="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 name="InterfaceBinding" title="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 name="EndPoint" title="EndPoint">Definition</a>: An association
! between a fully-specified <a title="InterfaceBinding" href="#InterfaceBinding">InterfaceBinding</a> and a
! network address, specified by a URI [<cite><a href="#RFC2396">IETF RFC 2396</a></cite>], 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">WSDLService</dt><dd><p>[<a name="WSDLService" title="WSDLService">Definition</a>:
! A collection of <a title="EndPoint" href="#EndPoint">EndPoints</a> is called
! <b>WSDLService</b>.]</p></dd></dl></div></div><div class="div1">
! <h2><a name="relationship2charter"></a>3. Relationship to WG Charter</h2><p>
! The Web Services Description WG Charter [<cite><a href="#WSDCharter">WSD Charter</a></cite>] 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 [<cite><a href="#WSDCharter">WSD Charter</a></cite>] to be in-scope per the
! Charter.</p><p>Reviewers and readers should be familiar with
! the Web Services Description WG Charter [<cite><a href="#WSDCharter">WSD Charter</a></cite>] because it provides the critical context for
! the requirements and any discussion of them.</p></div><div class="div1">
! <h2><a name="requirements"></a>4. Requirements</h2><div class="div2">
! <h3><a 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 [<cite><a href="#InfoSet">XML Information Set</a></cite>] model (similar to the SOAP
! 1.2 specifications [<cite><a href="#SOAP12">SOAP 1.2 Part 1</a></cite>]). (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 [<cite><a href="#XMLSchema1">XML Schema Part 1</a></cite>]. (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 [<cite><a href="#WSDL11">WSDL 1.1</a></cite>]. (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. Lst 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 [<cite><a href="#XMLSchema1">XML Schema Part 1</a></cite>]. (Last revised 10 Apr 2002. Redundant with R005, don't need each individual issue listed in the requirements doc. The WG already have 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 interactionwith 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
! [<cite><a href="#WSDL11">WSDL 1.1</a></cite>] 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
! [<cite><a href="#XMLSchema1">XML Schema Part 1</a></cite>]: 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 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 posible, 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 moularity 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 name="messages"></a>4.3 Messages and Types</h3><dl><dt class="Accepted">R127</dt><dd class="Accepted"><p>Message definitions MUST describe constraints on Message content using a machine-readable type-description language such as XML Schema. (From DO. Last discussed 22 Jan 2003.)</p></dd><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">R130</dt><dd class="Accepted"><p>The description language SHOULD allow describing messages with optional content. (From DO. Last discussed 22 Jan 2003.)</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 WSDLServices. (From PP. Last discussed 11 April, 2002.)</p></dd><dt class="Accepted">R134</dt><dd class="Accepted"><p>
! The description language SHOULD allow
! associating an Interface and/or an
! InterfaceBinding with a WSDLService
! reference. (From WG discussion. Last discussed
! 23 Sep 2003.)
! </p></dd><dt class="Accepted">R135</dt><dd class="Accepted"><p>
! The description language SHOULD define
! how to serialize a WSDLService
! reference. (From WG discussion. Last discussed
! 23 Sep 2003.)
! </p></dd><dt class="Accepted">R136</dt><dd class="Accepted"><p>
! The description language SHOULD define
! a means to interpret QNames from outside the
! context of a Web service description. (From WG
! discussion. Last discussed 23 Sep 2003.)
! </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 [<cite><a href="#WSDL11">WSDL 1.1</a></cite>]) 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><dtclass="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.)</></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 name="interfdesc"></a>4.4 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 astract policies required or offered by Web 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 instace, 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="Accepted">R118</dt><dd class="Accepted"><p>The description language SHOULD provide for reuse of a group of Interfaces. (From JS. Last discussed 22 Jan 2003.)</p></dd><dt class="Accepted">R058</dt><dd class="Accepted"><p>The description language SHOULD provide for extension of a group of Interfaces. (From JS. Last discussed 22 Jan 2003.)</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 083 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><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 discared 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 handlig. 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><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. [<cite><a href="#WSDL11">WSDL 1.1</a></cite>] 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 WSDLService 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, 100.)</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 name="desintwserv"></a>4.5 Description of Interactions with a WSDLService</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 WSDLService 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 WSDLService. (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">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 Messageor even a separate definition entity. (From IS. Last discussed 12 April 2002.)</p></dd><dt class="Accepted">R131</dt><dd class="Accepted"><p>The WG SHOULD define components that may be used within Messages to refer to other WSDL components. (From DO. See also R085 and R120. Last discussed 6 Feb 2003.)</p></dd><dt class="Rejected">R110</dt><dd class="Rejected"><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. Last discussed 22 Jan 2003. Overly specific.)</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="Cient" 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">lient</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/ordescribing 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 name="binddesc"></a>4.6 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">R128</dt><dd class="Accepted"><p>InterfaceBindings SHOULD provide for mapping Message content to WSDLService location URIs. (From DO. Last discussed 22 Jan 2003.)</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 characteristis. (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 [<cite><a href="#RFC2616">IETF RFC 2616</a></cite>] 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 [<cite><a href="#RFC2616">IETF RFC 2616</a></cite>]. (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
! [<cite><a href="#SOAP12">SOAP 1.2 Part 1</a></cite>], 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 WSDLService. (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="Draft">DR132</dt><dd class="Draft"><p>
! [Draft]
! The description language MUST allow reusing
! transport and wire representation information
! across interfaces.
! (From SW. Last discussed 31 July 2003.)
! </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="Accepted">R129</dt><dd class="Accepted"><p>The description language SHOULD allow specifying the MIME media type of message content. (From DO. Last discussed 6 Feb 2003.)</p></dd><dt class="Rejected">R133</dt><dd class="Rejected"><p>
! [Rejected]
! The description language MUST allow the use of
! separate binding constructs to describe
! operation-specific binding details for inherited
! operations.
! (From SG. Last discussed 31 July 2003. WG
! recognizes the scenario of site-wide binding
! details but believes existing lexical include
! mechanisms (external entities, XInclude 1.0) are
! sufficient.)
! </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 orattachment 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><t 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 [<cite><a href="#SOAP12">SOAP 1.2 Part 1</a></cite>] (the XML-based protocol produced
! by the XML Protocol Working Group) carried over HTTP/1.1
! [<cite><a href="#RFC2616">IETF RFC 2616</a></cite>], 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, [<cite><a href="#WSDL11">WSDL 1.1</a></cite>] 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
! [<cite><a href="#SOAP12">SOAP 1.2 Part 1</a></cite>]. (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] [<cite><a href="#WSDL11">WSDL 1.1</a></cite>] 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 appropiate support.)</p></dd></dl></div><div class="div2">
! <h3><a name="reusable"></a>4.7 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><dt class="Rejected">R126</dt><dd class="Rejected"><p>[Rejected] The description language SHOULD provide for validation of WSD documents
! that are entirely abstract and MUST not contain non-abstract information and
! provide for validation of WSD documents that are entirely concrete and MUST
! not contain abstract information. (From DO. Last discussed 22 Jan 2003. Usages of WSDL should reference components of interest (and subsequently referenced components) and ignore others.)</p></dd></dl></div><div class="div2">
! <h3><a name="extensible"></a>4.8 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
! [<cite><a href="#RFC2046">IETF RFC 2046</a></cite>]: 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 name="versioning"></a>4.9 Versioning</h3><dl><dt class="Accepted">R075</dt><dd class="Accepted"><p>The description language MUST allow identifying versions of WSDLServices. (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 name="security"></a>4.10 Security</h3><dl><dt class="Accepted">R115</dt><dd class="Accepted"><p>The WG specification(s) SHOULD define an equivalence relation on WSDLService 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 name="semanweb"></a>4.11 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 [<cite><a href="#RDF">RDF</a></cite>]. (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 [<cite><a href="#RFC2396">IETF RFC 2396</a></cite>]. (From the Semantic Web. Last discussed 11 June 2002.)</p></dd></dl></div></div><div class="div1">
! <h2><a 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>5.1 XML Protocol</h3><dl><dt class="Accepted">R137</dt><dd class="Accepted"><p>The description language SHOULD be able
! to describe messages using the MTOM attachments
! mechanism, if the MTOM work is completed in time
! for inclusion in WSDL 2.0. (From XML Protocol
! Working Group. Last discussed 23 Oct 2003.)
! </p></dd></dl></div><div class="div2">
! <h3>5.2 XForms</h3></div><div class="div2">
! <h3>5.3 RDF</h3></div><div class="div2">
! <h3>5.4 P3P</h3></div></div></div><div class="back"><div class="div1">
! <h2>A. References</h2><dl><dt class="label"><a name="RDF"></a>[RDF] </dt><dd><cite><a href="http://www.w3.org/TR/1999/REC-rdf-syntax-19990222">Resource Description Framework (RDF) Model and Syntax
! Specification</a></cite>, 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 name="RFC2046"></a>[IETF RFC 2046] </dt><dd><cite><a href="http://www.ietf.org/rfc/rfc2046.txt">Multipurpose Internet Mail Extensions
! (MIME) Part Two: Media Types</a></cite>, 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 name="RFC2119"></a>[IETF RFC 2119] </dt><dd><cite><a href="http://www.ietf.org/rfc/rfc2119.txt">Key words for use in RFCs to Indicate Requirement
! Levels</a></cite>, S. Bradner, Author. Internet Engineering Task
! Force, June 1999. Available at http://www.ietf.org/rfc/rfc2119.txt.</dd><dt class="label"><a name="RFC2396"></a>[IETF RFC 2396] </dt><dd><cite><a href="http://www.ietf.org/rfc/rfc2396.txt">Uniform Resource Identifiers (URI): Generic Syntax</a></cite>, 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 name="RFC2616"></a>[IETF RFC 2616] </dt><dd><cite><a href="http://www.ietf.org/rfc/rfc2616.txt">Hypertext Transfer Protocol -- HTTP/1.1</a></cite>,
! 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 name="SOAP12"></a>[SOAP 1.2 Part 1] </dt><dd><cite><a href="http://www.w3.org/TR/2002/WD-soap12-part1-20020626/">SOAP Version 1.2 Part 1: Messaging
! Framework</a></cite>, 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 name="WSDCharter"></a>[WSD Charter] </dt><dd><cite><a href="http://www.w3.org/2002/01/ws-desc-charter">Web Services Description Working Group
! Charter</a></cite>, 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 name="WSDL11"></a>[WSDL 1.1] </dt><dd><cite><a href="http://www.w3.org/TR/2001/NOTE-wsdl-20010315">Web Services Description Language
! (WSDL) 1.1</a></cite>, 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 name="WSAGLOSS"></a>[WSA Glossary] </dt><dd><cite><a href="http://www.w3.org/TR/2002/WD-ws-gloss-20021114/">Web Services Glossary</a></cite>, A. Brown and H. Haas, Editors.
! World Wide Web Consortium, 14 November 2002.
! This version of the Web Services Glossary is http://www.w3.org/TR/2002/WD-ws-gloss-20021114/.
! The <a href="http://www.w3.org/TR/ws-gloss/">latest version of the Web Services Glossary</a>
! is available at http://www.w3.org/TR/ws-gloss/.
! </dd><dt class="label"><a name="XML"></a>[XML 1.0] </dt><dd><cite><a href="http://www.w3.org/TR/2000/REC-xml-20001006">Extensible Markup Language (XML) 1.0 (Second
! Edition)</a></cite>, 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 name="InfoSet"></a>[XML Information Set] </dt><dd><cite><a href="http://www.w3.org/TR/2001/REC-xml-infoset-20011024">XML Information Set</a></cite>, 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 name="XMLSchema1"></a>[XML Schema Part 1] </dt><dd><cite><a href="http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/">XML Schema Part 1: Structures</a></cite>,
! 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 name="IDA3433B"></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 class="div1">
! <h2><a name="Change-log"></a>C. Change Log (Non-Normative)</h2><a name=""></a><br><table border="1" cellpadding="2" cellspacing="0" xmlns:xlink="http://www.w3.org/1999/xlink"><tbody><tr><th rowspan="1" colspan="1">Date</th><th rowspan="1" colspan="1">Editor</th><th rowspan="1" colspan="1">Change</th></tr><tr><td rowspan="1" colspan="1">28 Oct 2003</td><td rowspan="1" colspan="1">JS</td><td rowspan="1" colspan="1">Marked R137 SHOULD per 23 Oct telecon.</td></tr><tr><td rowspan="1" colspan="1">25 Oct 2003</td><td rowspan="1" colspan="1">JS</td><td rowspan="1" colspan="1">Marked R137 accepted per 23 Oct telecon.</td></tr><tr><td rowspan="1" colspan="1">24 Oct 2003</td><td rowspan="1" colspan="1">JS</td><td rowspan="1" colspan="1">Added DR137.</td></tr><tr><td rowspan="1" colspan="1">1 Oct 2003</td><td rowspan="1" colspan="1">JS</td><td rowspan="1" colspan="1">Per <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0219.html">23
! Sep meeting minutes</a>, marked R134, R135, and
! R136 as accepted.</td></tr><tr><td rowspan="1" colspan="1">23 Sep 2003</td><td rowspan="1" colspan="1">JS</td><td rowspan="1" colspan="1">Per 23 Sep meeting, added DR134, DR135,
! DR136.</td></tr><tr><td rowspan="1" colspan="1">31 July 2003</td><td rowspan="1" colspan="1">JS</td><td rowspan="1" colspan="1">Per 31 Jul meeting, added DR132,
! DR133. Marked DR133 as rejected.
! </td></tr><tr><td rowspan="1" colspan="1">12 Feb 2003</td><td rowspan="1" colspan="1">JS</td><td rowspan="1" colspan="1">Per 6 Feb telecon, revised glossary to align with Web Services Architecture WG, substituted "wsdl service" for "service" to avoid confusion, and accepted R129 and R131.</td></tr><tr><td rowspan="1" colspan="1">22 Jan 2003</td><td rowspan="1" colspan="1">JS</td><td rowspan="1" colspan="1">Per 22 Jan face-to-face meeting, revised R118, R085; added R126, R127, R128, R129, R130, R131; cut R110.</td></tr><tr><td rowspan="1" colspan="1">17 Oct 2002</td><td rowspan="1" colspan="1">JS</td><td rowspan="1" colspan="1">Per 17 Oct teleconference, revised R046, R054, R067, R115 in response to public comments.</td></tr><tr><td rowspan="1" colspan="1">26 Sep 2002</td><td rowspan="1" colspan="1">JS</td><td rowspan="1" colspan="1">Per 26 Sep teleconference, accepted R125.</td></tr><tr><td rowspan="1" colspan="1">10 Jul 2002</td><td rowspan="1" colspan="1">JS</td><td rowspan="1" colspan="1">Per 17 un teleconference, added new requirements R124 and R125.</td></tr><tr><td rowspan="1" colspan="1">19 Jun 2002</td><td rowspan="1" colspan="1">JS</td><td rowspan="1" colspan="1">Per 11 Jun face-to-face meeting, added new requirements R122 and R123; accepted R042, R120, and R123; and rejected R121 and R122.</td></tr><tr><td rowspan="1" colspan="1">24 Apr 2002</td><td rowspan="1" colspan="1">JS</td><td rowspan="1" colspan="1">Per 18 Apr teleconference, reworded R001, added R121, and made a grammar pass over all accepted requirements. Hid rejected requirements for clarity (but retained in the XML source).</td></tr><tr><td rowspan="1" colspan="1">17 Apr 2002</td><td rowspan="1" colspan="1">JM</td><td rowspan="1" colspan="1">Reflected April FTF decisions.</td></tr><tr><td rowspan="1" colspan="1">5 Apr 2002</td><td rowspan="1" colspan="1">JS</td><td rowspan="1" colspan="1">Per 4 Apr teleconference, accepted 2 requirements, rejected 4, and revised the wording of 2. Added new requirement R114.</td></tr><tr><td rowspn="1" colspan="1">3 Apr 2002</td><td rowspan="1" colspan="1">JS</td><td rowspan="1" colspan="1">Per 28 Mar teleconference, accepted 4 requirements and rejected 10. Added new requirement R113. Marked proposed simplification of requirements in Sections 4.5 and 4.9.</td></tr><tr><td rowspan="1" colspan="1">26 Mar 2002</td><td rowspan="1" colspan="1">JS</td><td rowspan="1" colspan="1">Per 21 Mar teleconference, updated definitions and wording of requirements to use the new definitions. Marked proposed simplification of requirements in Sections 4.6 and 4.7; split R111 out of R061. Added new requirement R112. Added meta data for expected time frame of requirement.</td></tr><tr><td rowspan="1" colspan="1">19 Mar 2002</td><td rowspan="1" colspan="1">JS</td><td rowspan="1" colspan="1">Added definitions proposed by dbooth. </td></tr><tr><td rowspan="1" colspan="1">12 Mar 2002</td><td rowspan="1" colspan="1">JS</td><td rowspan="1" colspan="1">Per 7 Mar teleconference, accepted 3 requirements and rejected 7. </td></tr>tr><td rowspan="1" colspan="1">4 Mar 2002</td><td rowspan="1" colspan="1">JS</td><td rowspan="1" colspan="1">Per 28 Feb teleconference, accepted 5 requirements, rejected 6, and added R109. Marked proposed simplification of requirements in Section 4.2. Added R110 for newly submitted requirement.</td></tr><tr><td rowspan="1" colspan="1">25 Feb 2002</td><td rowspan="1" colspan="1">JS</td><td rowspan="1" colspan="1">Per 21 Feb teleconference, added NR prefix for non requirements, accepted 5 requirements and rejected 4. Added R102 through R108 for newly submitted requirements.</td></tr><tr><td rowspan="1" colspan="1">20 Feb 2002</td><td rowspan="1" colspan="1">JS</td><td rowspan="1" colspan="1">Added R081 through R097. Assigned initial priorities ala [<cite><a href="#RFC2119">IETF RFC 2119</a></cite>].</td></tr><tr><td rowspan="1" colspan="1">13 Feb 2002</td><td rowspan="1" colspan="1">JM</td><td rowspan="1" colspan="1">Created</td></tr></tbody></table><br></div></div></body></html>
\ No newline at end of file
--- 1 ----
! <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"><html lang="en"><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; }
dt.label { display: run-in; }
li, p { margin-top: 0.3em;
margin-bottom: 0.3em; }
.diff-chg { background-color: orange; }
.diff-del { background-color: red; text-decoration: line-through;}
.diff-add { background-color: lime; }
table { empty-cells: show; }
table caption {
font-weight: normal;
font-style: italic;
text-align: left;
margin-bottom: .5em;
}
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 rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/base.css"><link rel="alternate" title="" href="" type=""><link rel="contents" href="#contents"></head><body><div class="head">
<h1>Web Services Description Requirements</h1>
<h2>Editors' copy $Date$ @@ @@@@ @@@@</h2><dl><dt>This version:</dt><dd><a href="ws-desc-reqs.html">ws-desc-reqs.html</a></dd><dt>Latest version:</dt><dd><a href="http://www.w3.org/2002/ws/desc/wsdl20-patterns">http://www.w3.org/2002/ws/desc/wsdl20-patterns</a></dd><dt>Previous versions:</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=""></a>.</p><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © @@@@ <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.lcs.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href"http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>, <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-software">software licensing</a> rules apply.</p></div><hr><div>
<h2><a name="abstract">Abstract</a></h2><p>
This document describes the Web Services Description Working
Group's requirements for the Web Services Description
specification.
</p></div><div>
<h2><a name="status">Status of this Document</a></h2><p><strong>This document is an editors' copy that has
no official standing.</strong></p><p></p></div><hr><div class="toc">
<h2><a name="shortcontents">Short Table of Contents</a></h2><p class="toc">1. <a href="#notations">Notations</a><br>2. <a href="#definitions">Definitions</a><br>3. <a href="#relationship2charter">Relationship to WG Charter</a><br>4. <a href="#requirements">Requirements</a><br>5. <a href="#external">Requirements from other W3C WGs</a><br>A. <a href="#IDAY1HYB">References</a><br>B. <a href="#IDAA5HYB">Acknowledgments</a> (Non-Normative)<br>C. <a href="#Change-log">Change Log</a> (Non-Normative)<br></p></div><hr><div class="toc">
<h2><a name="contents">Table of Contents</a></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="#messages">Messages and Types</a><br> 4.4 <a href="#interfdesc">Interface Description</a><br> 4.5 <a href="#desintwserv">Description of Interactions with a WSDLService</a><br> 4.6 <a href="#binddesc">InterfaceBindings</a><br> 4.7 <a href="#reusable">Reusability</a><br> 4.8 <a href="#extensible">Extensibility</a><br> 4.9 <a href="#versioning">Versioning</a><br> 4.10 <a href="#security">Security</a><br> 4.11 <a href="#semanweb">Mapping to the Semantic Web</a><br>5. <a href="#external">Requirements fro other W3C WGs</a><br> 5.1 <a href="#IDAJ1HYB">XML Protocol</a><br> 5.2 <a href="#IDAR1HYB">XForms</a><br> 5.3 <a href="#IDAT1HYB">RDF</a><br> 5.4 <a href="#IDAV1HYB">P3P</a><br></p>
<h3><a name="appendix" id="appendix">Appendices</a></h3><p class="toc">A. <a href="#IDAY1HYB">References</a><br>B. <a href="#IDAA5HYB">Acknowledgments</a> (Non-Normative)<br>C. <a href="#Change-log">Change Log</a> (Non-Normative)<br></p></div><hr><div class="body"><div class="div1">
<h2><a 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 [<cite><a href="#RFC2119">IETF RFC 2119</a></cite>]. (Changes from [<cite><a href="#RFC2119">IETF RFC 2119</a></cite>] 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(s) <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 otional. <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 [<cite><a href="#WSDCharter">WSD Charter</a></cite>]), or 'WG' (from WG discussion).</p></li></ul></div><div class="div1">
<h2><a name="definitions"></a>2. Definitions</h2><p>
The definitions in this section are drawn from [<cite><a href="#WSAGLOSS">WSA Glossary</a></cite>] and [<cite><a href="#WSDL11">WSDL 1.1</a></cite>].
They 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 name="nonNormDefs"></a>2.1 Non-normative definitions</h3><dl><dt class="label">Web service</dt><dd><p>[<a name="web_service" title="Web service">Definition</a>:
A <b>Web service</b> is a software system identified by a URI [<cite><a href="#RFC2396">IETF RFC 2396</a></cite>],
whose public interfaces and bindings are defined and described using XML.
Its definition can be discovered by other software systems.
These systems may then interact with the Web service in a manner prescribed by its definition,
using XML based messages conveyed by Internet protocols.
]</p></dd><dt class="label">Client</dt><dd><p>[<a name="client" title="Client">Definition</a>:
A system entity making use of a <a title="Web service" href="#web_service">Web service</a>.
]</p></dd></dl></div><div class="div2">
<h3><a name="normDefs"></a>2.2 Normative definitions</h3><dl><dt class="label">Message</dt><dd><p>[<a name="Message" title="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 name="Operation" title="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 name="Interface" title="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 name="InterfaceBinding" title="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 name="EndPoint" title="EndPoint">Definition</a>: An association
between a fully-specified <a title="InterfaceBinding" href="#InterfaceBinding">InterfaceBinding</a> and a
network address, specified by a URI [<cite><a href="#RFC2396">IETF RFC 2396</a></cite>], 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">WSDLService</dt><dd><p>[<a name="WSDLService" title="WSDLService">Definition</a>:
A collection of <a title="EndPoint" href="#EndPoint">EndPoints</a> is called
<b>WSDLService</b>.]</p></dd></dl></div></div><div class="div1">
<h2><a name="relationship2charter"></a>3. Relationship to WG Charter</h2><p>
The Web Services Description WG Charter [<cite><a href="#WSDCharter">WSD Charter</a></cite>] 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 [<cite><a href="#WSDCharter">WSD Charter</a></cite>] to be in-scope per the
Charter.</p><p>Reviewers and readers should be familiar with
the Web Services Description WG Charter [<cite><a href="#WSDCharter">WSD Charter</a></cite>] because it provides the critical context for
the requirements and any discussion of them.</p></div><div class="div1">
<h2><a name="requirements"></a>4. Requirements</h2><div class="div2">
<h3><a 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 [<cite><a href="#InfoSet">XML Information Set</a></cite>] model (similar to the SOAP
1.2 specifications [<cite><a href="#SOAP12">SOAP 1.2 Part 1</a></cite>]). (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 [<cite><a href="#XMLSchema1">XML Schema Part 1</a></cite>]. (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 [<cite><a href="#WSDL11">WSDL 1.1</a></cite>]. (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. Las 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 [<cite><a href="#XMLSchema1">XML Schema Part 1</a></cite>]. (Last revised 10 Apr 2002. Redundant with R005, don't need each individual issue listed in the requirements doc. The WG already have 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 wth 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
[<cite><a href="#WSDL11">WSDL 1.1</a></cite>] 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
[<cite><a href="#XMLSchema1">XML Schema Part 1</a></cite>]: 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 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 possile, 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 moduarity 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 name="messages"></a>4.3 Messages and Types</h3><dl><dt class="Accepted">R127</dt><dd class="Accepted"><p>Message definitions MUST describe constraints on Message content using a machine-readable type-description language such as XML Schema. (From DO. Last discussed 22 Jan 2003.)</p></dd><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">R130</dt><dd class="Accepted"><p>The description language SHOULD allow describing messages with optional content. (From DO. Last discussed 22 Jan 2003.)</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 WSDLServices. (From PP. Last discussed 11 April, 2002.)</p></dd><dt class="Accepted">R134</dt><dd class="Accepted"><p>
The description language SHOULD allow
associating an Interface and/or an
InterfaceBinding with a WSDLService
reference. (From WG discussion. Last discussed
23 Sep 2003.)
</p></dd><dt class="Accepted">R135</dt><dd class="Accepted"><p>
The description language SHOULD define
how to serialize a WSDLService
reference. (From WG discussion. Last discussed
23 Sep 2003.)
</p></dd><dt class="Accepted">R136</dt><dd class="Accepted"><p>
The description language SHOULD define
a means to interpret QNames from outside the
context of a Web service description. (From WG
discussion. Last discussed 23 Sep 2003.)
</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 [<cite><a href="#WSDL11">WSDL 1.1</a></cite>]) 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 cass="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 name="interfdesc"></a>4.4 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 absract policies required or offered by Web 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 instanc, 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="Accepted">R118</dt><dd class="Accepted"><p>The description language SHOULD provide for reuse of a group of Interfaces. (From JS. Last discussed 22 Jan 2003.)</p></dd><dt class="Accepted">R058</dt><dd class="Accepted"><p>The description language SHOULD provide for extension of a group of Interfaces. (From JS. Last discussed 22 Jan 2003.)</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 R03 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><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 discarde 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><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. [<cite><a href="#WSDL11">WSDL 1.1</a></cite>] 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 WSDLService 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, R10.)</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 name="desintwserv"></a>4.5 Description of Interactions with a WSDLService</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 WSDLService 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 WSDLService. (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">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 o even a separate definition entity. (From IS. Last discussed 12 April 2002.)</p></dd><dt class="Accepted">R131</dt><dd class="Accepted"><p>The WG SHOULD define components that may be used within Messages to refer to other WSDL components. (From DO. See also R085 and R120. Last discussed 6 Feb 2003.)</p></dd><dt class="Rejected">R110</dt><dd class="Rejected"><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. Last discussed 22 Jan 2003. Overly specific.)</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="Clint" 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">Clent</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 dscribing 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 name="binddesc"></a>4.6 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">R128</dt><dd class="Accepted"><p>InterfaceBindings SHOULD provide for mapping Message content to WSDLService location URIs. (From DO. Last discussed 22 Jan 2003.)</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 [<cite><a href="#RFC2616">IETF RFC 2616</a></cite>] 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 [<cite><a href="#RFC2616">IETF RFC 2616</a></cite>]. (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
[<cite><a href="#SOAP12">SOAP 1.2 Part 1</a></cite>], 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 WSDLService. (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="Draft">DR132</dt><dd class="Draft"><p>
[Draft]
The description language MUST allow reusing
transport and wire representation information
across interfaces.
(From SW. Last discussed 31 July 2003.)
</p></dd><dt class="Rejected">R031</dt><dd class="Rejected"><p>[Rejected] The WG specification(s) SHOULD support SOAP 1.2 intermediaries. (From JJM. Last discussed 2 August 2004.)</p><p>1) Although WSDL does not provide explicit support for intermediaries, it is possible using existing extension mechanisms to indicate that intermediaries are in use and configurable</p><p>2) We do not have a clear understanding of what would be needed in order to more fully support intermediaries</p><p>3) Insufficient support in the WG to pursue this further Proposal is to amend the requirements doc by deprecating/greying-out the requirement and adding the above text.</p></dd><dt class="Accepted">R129</dt><dd class="Accepted"><p>The description language SHOULD allow specifying the MIME media type of message content. (From DO. Last discussed 6 Feb 2003.)</p></dd><dt class="Rejected">R133</dt><dd class="Rejected"><p>
[Rejected]
The description language MUST allow the use of
separate binding constructs to describe
operation-specific binding details for inherited
operations.
(From SG. Last discussed 31 July 2003. WG
recognizes the scenario of site-wide binding
details but believes existing lexical include
mechanisms (external entities, XInclude 1.0) are
sufficient.)
</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 atachment 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><dtclass="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 [<cite><a href="#SOAP12">SOAP 1.2 Part 1</a></cite>] (the XML-based protocol produced
by the XML Protocol Working Group) carried over HTTP/1.1
[<cite><a href="#RFC2616">IETF RFC 2616</a></cite>], 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, [<cite><a href="#WSDL11">WSDL 1.1</a></cite>] 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
[<cite><a href="#SOAP12">SOAP 1.2 Part 1</a></cite>]. (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] [<cite><a href="#WSDL11">WSDL 1.1</a></cite>] 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 approprite support.)</p></dd></dl></div><div class="div2">
<h3><a name="reusable"></a>4.7 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><dt class="Rejected">R126</dt><dd class="Rejected"><p>[Rejected] The description language SHOULD provide for validation of WSD documents
that are entirely abstract and MUST not contain non-abstract information and
provide for validation of WSD documents that are entirely concrete and MUST
not contain abstract information. (From DO. Last discussed 22 Jan 2003. Usages of WSDL should reference components of interest (and subsequently referenced components) and ignore others.)</p></dd></dl></div><div class="div2">
<h3><a name="extensible"></a>4.8 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
[<cite><a href="#RFC2046">IETF RFC 2046</a></cite>]: 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 name="versioning"></a>4.9 Versioning</h3><dl><dt class="Accepted">R075</dt><dd class="Accepted"><p>The description language MUST allow identifying versions of WSDLServices. (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 name="security"></a>4.10 Security</h3><dl><dt class="Accepted">R115</dt><dd class="Accepted"><p>The WG specification(s) SHOULD define an equivalence relation on WSDLService 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 name="semanweb"></a>4.11 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 [<cite><a href="#RDF">RDF</a></cite>]. (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 [<cite><a href="#RFC2396">IETF RFC 2396</a></cite>]. (From the Semantic Web. Last discussed 11 June 2002.)</p></dd></dl></div></div><div class="div1">
<h2><a 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>5.1 XML Protocol</h3><dl><dt class="Accepted">R137</dt><dd class="Accepted"><p>The description language SHOULD be able
to describe messages using the MTOM attachments
mechanism, if the MTOM work is completed in time
for inclusion in WSDL 2.0. (From XML Protocol
Working Group. Last discussed 23 Oct 2003.)
</p></dd></dl></div><div class="div2">
<h3>5.2 XForms</h3></div><div class="div2">
<h3>5.3 RDF</h3></div><div class="div2">
<h3>5.4 P3P</h3></div></div></div><div class="back"><div class="div1">
<h2>A. References</h2><dl><dt class="label"><a name="RDF"></a>[RDF] </dt><dd><cite><a href="http://www.w3.org/TR/1999/REC-rdf-syntax-19990222">Resource Description Framework (RDF) Model and Syntax
Specification</a></cite>, 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 name="RFC2046"></a>[IETF RFC 2046] </dt><dd><cite><a href="http://www.ietf.org/rfc/rfc2046.txt">Multipurpose Internet Mail Extensions
(MIME) Part Two: Media Types</a></cite>, 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 name="RFC2119"></a>[IETF RFC 2119] </dt><dd><cite><a href="http://www.ietf.org/rfc/rfc2119.txt">Key words for use in RFCs to Indicate Requirement
Levels</a></cite>, S. Bradner, Author. Internet Engineering Task
Force, June 1999. Available at http://www.ietf.org/rfc/rfc2119.txt.</dd><dt class="label"><a name="RFC2396"></a>[IETF RFC 2396] </dt><dd><cite><a href="http://www.ietf.org/rfc/rfc2396.txt">Uniform Resource Identifiers (URI): Generic Syntax</a></cite>, 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 name="RFC2616"></a>[IETF RFC 2616] </dt><dd><cite><a href="http://www.ietf.org/rfc/rfc2616.txt">Hypertext Transfer Protocol -- HTTP/1.1</a></cite>,
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 name="SOAP12"></a>[SOAP 1.2 Part 1] </dt><dd><cite><a href="http://www.w3.org/TR/2002/WD-soap12-part1-20020626/">SOAP Version 1.2 Part 1: Messaging
Framework</a></cite>, 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 name="WSDCharter"></a>[WSD Charter] </dt><dd><cite><a href="http://www.w3.org/2002/01/ws-desc-charter">Web Services Description Working Group
Charter</a></cite>, 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 name="WSDL11"></a>[WSDL 1.1] </dt><dd><cite><a href="http://www.w3.org/TR/2001/NOTE-wsdl-20010315">Web Services Description Language
(WSDL) 1.1</a></cite>, 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 name="WSAGLOSS"></a>[WSA Glossary] </dt><dd><cite><a href="http://www.w3.org/TR/2002/WD-ws-gloss-20021114/">Web Services Glossary</a></cite>, A. Brown and H. Haas, Editors.
World Wide Web Consortium, 14 November 2002.
This version of the Web Services Glossary is http://www.w3.org/TR/2002/WD-ws-gloss-20021114/.
The <a href="http://www.w3.org/TR/ws-gloss/">latest version of the Web Services Glossary</a>
is available at http://www.w3.org/TR/ws-gloss/.
</dd><dt class="label"><a name="XML"></a>[XML 1.0] </dt><dd><cite><a href="http://www.w3.org/TR/2000/REC-xml-20001006">Extensible Markup Language (XML) 1.0 (Second
Edition)</a></cite>, 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 name="InfoSet"></a>[XML Information Set] </dt><dd><cite><a href="http://www.w3.org/TR/2001/REC-xml-infoset-20011024">XML Information Set</a></cite>, 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 name="XMLSchema1"></a>[XML Schema Part 1] </dt><dd><cite><a href="http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/">XML Schema Part 1: Structures</a></cite>,
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 name="IDAA5HYB"></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 class="div1">
<h2><a name="Change-log"></a>C. Change Log (Non-Normative)</h2><a name=""></a><br><table border="1" cellpadding="2" cellspacing="0" xmlns:xlink="http://www.w3.org/1999/xlink"><tbody><tr><th rowspan="1" colspan="1">Date</th><th rowspan="1" colspan="1">Editor</th><th rowspan="1" colspan="1">Change</th></tr><tr><td rowspan="1" colspan="1">8 Sept 2004</td><td rowspan="1" colspan="1">J Marsh</td><td rowspan="1" colspan="1">Marked R031 as Rejected per 2 Sept telecon.</td></tr><tr><td rowspan="1" colspan="1">28 Oct 2003</td><td rowspan="1" colspan="1">JS</td><td rowspan="1" colspan="1">Marked R137 SHOULD per 23 Oct telecon.</td></tr><tr><td rowspan="1" colspan="1">25 Oct 2003</td><td rowspan="1" colspan="1">JS</td><td rowspan="1" colspan="1">Marked R137 accepted per 23 Oct telecon.</td></tr><tr><td rowspan="1" colspan="1">24 Oct 2003</td><td rowspan="1" colspan="1">JS</td><td rowspan="1" colspan="1">Added DR137.</td></tr><tr><td rowspan="1" colspan="1">1 Oct 2003</td><td rowspan="1" colspan="1">JS</td><td rowspan=1" colspan="1">Per <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0219.html">23
Sep meeting minutes</a>, marked R134, R135, and
R136 as accepted.</td></tr><tr><td rowspan="1" colspan="1">23 Sep 2003</td><td rowspan="1" colspan="1">JS</td><td rowspan="1" colspan="1">Per 23 Sep meeting, added DR134, DR135,
DR136.</td></tr><tr><td rowspan="1" colspan="1">31 July 2003</td><td rowspan="1" colspan="1">JS</td><td rowspan="1" colspan="1">Per 31 Jul meeting, added DR132,
DR133. Marked DR133 as rejected.
</td></tr><tr><td rowspan="1" colspan="1">12 Feb 2003</td><td rowspan="1" colspan="1">JS</td><td rowspan="1" colspan="1">Per 6 Feb telecon, revised glossary to align with Web Services Architecture WG, substituted "wsdl service" for "service" to avoid confusion, and accepted R129 and R131.</td></tr><tr><td rowspan="1" colspan="1">22 Jan 2003</td><td rowspan="1" colspan="1">JS</td><td rowspan="1" colspan="1">Per 22 Jan face-to-face meeting, revised R118, R085; added R126, R127, R128, R129, R130, R131; cut R110.</td></tr><tr><td rowspan="1" colspan="1">17 Oct 2002</td><td rowspan="1" colspan="1">JS</td><td rowspan="1" colspan="1">Per 17 Oct teleconference, revised R046, R054, R067, R115 in response to public comments.</td></tr><tr><td rowspan="1" colspan="1">26 Sep 2002</td><td rowspan="1" colspan="1">JS</td><td rowspan="1" colspan="1">Per 26 Sep teleconference, accepted R125.</td></tr><tr><td rowspan="1" colspan="1">10 Jul 2002</td><td rowspan="1" colspan="1">JS</td><td rowspan="1" colspan="1">Per 17 Ju teleconference, added new requirements R124 and R125.</td></tr><tr><td rowspan="1" colspan="1">19 Jun 2002</td><td rowspan="1" colspan="1">JS</td><td rowspan="1" colspan="1">Per 11 Jun face-to-face meeting, added new requirements R122 and R123; accepted R042, R120, and R123; and rejected R121 and R122.</td></tr><tr><td rowspan="1" colspan="1">24 Apr 2002</td><td rowspan="1" colspan="1">JS</td><td rowspan="1" colspan="1">Per 18 Apr teleconference, reworded R001, added R121, and made a grammar pass over all accepted requirements. Hid rejected requirements for clarity (but retained in the XML source).</td></tr><tr><td rowspan="1" colspan="1">17 Apr 2002</td><td rowspan="1" colspan="1">JM</td><td rowspan="1" colspan="1">Reflected April FTF decisions.</td></tr><tr><td rowspan="1" colspan="1">5 Apr 2002</td><td rowspan="1" colspan="1">JS</td><td rowspan="1" colspan="1">Per 4 Apr teleconference, accepted 2 requirements, rejected 4, and revised the wording of 2. Added new requirement R114.</td></tr><tr><td rowspan"1" colspan="1">3 Apr 2002</td><td rowspan="1" colspan="1">JS</td><td rowspan="1" colspan="1">Per 28 Mar teleconference, accepted 4 requirements and rejected 10. Added new requirement R113. Marked proposed simplification of requirements in Sections 4.5 and 4.9.</td></tr><tr><td rowspan="1" colspan="1">26 Mar 2002</td><td rowspan="1" colspan="1">JS</td><td rowspan="1" colspan="1">Per 21 Mar teleconference, updated definitions and wording of requirements to use the new definitions. Marked proposed simplification of requirements in Sections 4.6 and 4.7; split R111 out of R061. Added new requirement R112. Added meta data for expected time frame of requirement.</td></tr><tr><td rowspan="1" colspan="1">19 Mar 2002</td><td rowspan="1" colspan="1">JS</td><td rowspan="1" colspan="1">Added definitions proposed by dbooth. </td></tr><tr><td rowspan="1" colspan="1">12 Mar 2002</td><td rowspan="1" colspan="1">JS</td><td rowspan="1" colspan="1">Per 7 Mar teleconference, accepted 3 requirements and rejected 7. </td></tr><t><td rowspan="1" colspan="1">4 Mar 2002</td><td rowspan="1" colspan="1">JS</td><td rowspan="1" colspan="1">Per 28 Feb teleconference, accepted 5 requirements, rejected 6, and added R109. Marked proposed simplification of requirements in Section 4.2. Added R110 for newly submitted requirement.</td></tr><tr><td rowspan="1" colspan="1">25 Feb 2002</td><td rowspan="1" colspan="1">JS</td><td rowspan="1" colspan="1">Per 21 Feb teleconference, added NR prefix for non requirements, accepted 5 requirements and rejected 4. Added R102 through R108 for newly submitted requirements.</td></tr><tr><td rowspan="1" colspan="1">20 Feb 2002</td><td rowspan="1" colspan="1">JS</td><td rowspan="1" colspan="1">Added R081 through R097. Assigned initial priorities ala [<cite><a href="#RFC2119">IETF RFC 2119</a></cite>].</td></tr><tr><td rowspan="1" colspan="1">13 Feb 2002</td><td rowspan="1" colspan="1">JM</td><td rowspan="1" colspan="1">Created</td></tr></tbody></table><br></div></div></body></html>
\ No newline at end of file
Index: ws-desc-reqs.xml
===================================================================
RCS file: /sources/public/2002/ws/desc/requirements/ws-desc-reqs.xml,v
retrieving revision 1.36
retrieving revision 1.37
diff -C2 -d -r1.36 -r1.37
*** ws-desc-reqs.xml 29 Oct 2003 01:42:05 -0000 1.36
--- ws-desc-reqs.xml 8 Sep 2004 18:49:12 -0000 1.37
***************
*** 950,957 ****
</def>
</gitem>
! <gitem role="Accepted">
<label>R031</label>
<def>
! <p>The WG specification(s) SHOULD support SOAP 1.2 intermediaries. (From JJM. Last discussed 11 April 2002.)</p>
</def>
</gitem>
--- 950,960 ----
</def>
</gitem>
! <gitem role="Rejected">
<label>R031</label>
<def>
! <p>[Rejected] The WG specification(s) SHOULD support SOAP 1.2 intermediaries. (From JJM. Last discussed 2 August 2004.)</p>
! <p>1) Although WSDL does not provide explicit support for intermediaries, it is possible using existing extension mechanisms to indicate that intermediaries are in use and configurable</p>
! <p>2) We do not have a clear understanding of what would be needed in order to more fully support intermediaries</p>
! <p>3) Insufficient support in the WG to pursue this further Proposal is to amend the requirements doc by deprecating/greying-out the requirement and adding the above text.</p>
</def>
</gitem>
***************
*** 1499,1502 ****
--- 1502,1510 ----
</tr>
<tr>
+ <td>8 Sept 2004</td>
+ <td>J Marsh</td>
+ <td>Marked R031 as Rejected per 2 Sept telecon.</td>
+ </tr>
+ <tr>
<td>28 Oct 2003</td>
<td>JS</td>
Received on Wednesday, 8 September 2004 18:49:15 UTC