You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
1378 lines
64 KiB
1378 lines
64 KiB
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<html lang="en"><head><META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"><title>XML Protocol (XMLP) 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; }
|
|
|
|
p.diff-chg,
|
|
li.diff-chg,
|
|
h1.diff-chg,
|
|
h2.diff-chg,
|
|
h3.diff-chg,
|
|
h4.diff-chg,
|
|
h5.diff-chg,
|
|
h6.diff-chg,
|
|
td.diff-chg,
|
|
tr.diff-chg { background-color: orange; }
|
|
p.diff-del,
|
|
li.diff-del,
|
|
h1.diff-del,
|
|
h2.diff-del,
|
|
h3.diff-del,
|
|
h4.diff-del,
|
|
h5.diff-del,
|
|
h6.diff-del,
|
|
td.diff-del,
|
|
tr.diff-del { background-color: red; text-decoration: line-through;}
|
|
p.diff-add,
|
|
p.diff-add,
|
|
h1.diff-add,
|
|
h2.diff-add,
|
|
h3.diff-add,
|
|
h4.diff-add,
|
|
h5.diff-add,
|
|
h6.diff-add,
|
|
td.diff-add,
|
|
tr.diff-add { background-color: lime; }
|
|
table { empty-cells: show; }
|
|
|
|
|
|
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}
|
|
</style><link type="text/css" rel="stylesheet" href="http://www.w3.org/StyleSheets/TR/W3C-WG-NOTE.css"></head><body>
|
|
<div class="head"><p><a href="http://www.w3.org/"><img width="72" height="48" alt="W3C" src="http://www.w3.org/Icons/w3c_home"></a></p>
|
|
<h1>XML Protocol (XMLP) Requirements</h1>
|
|
<h2>W3C Working Group Note 28 July 2003</h2><dl><dt>This version:</dt><dd>
|
|
<a href="http://www.w3.org/TR/2003/NOTE-xmlp-reqs-20030728">http://www.w3.org/TR/2003/NOTE-xmlp-reqs-20030728</a>
|
|
</dd><dt>Latest version:</dt><dd>
|
|
<a href="http://www.w3.org/TR/xmlp-reqs">http://www.w3.org/TR/xmlp-reqs</a>
|
|
</dd><dt>Previous versions:</dt><dd>
|
|
<a href="http://www.w3.org/TR/2002/WD-xmlp-reqs-20020626">http://www.w3.org/TR/2002/WD-xmlp-reqs-20020626</a>
|
|
</dd><dt>Editors:</dt>
|
|
<dd>Vidur Apparao, Netscape</dd>
|
|
<dd>Alex Ceponkus, Bowstreet</dd>
|
|
<dd>Paul Cotton, Microsoft</dd>
|
|
<dd>David Ezell, Hewlett Packard</dd>
|
|
<dd>David Fallside, IBM</dd>
|
|
<dd>Martin Gudgin, DevelopMentor</dd>
|
|
<dd>Oisin Hurley, IONA Technologies</dd>
|
|
<dd>John Ibbotson, IBM</dd>
|
|
<dd>R. Alexander Milowski, Lexica, LLC</dd>
|
|
<dd>Kevin Mitchell, XMLSolutions</dd>
|
|
<dd>Jean-Jacques Moreau, Canon</dd>
|
|
<dd>Eric Newcomer, IONA Technologies</dd>
|
|
<dd>Henrik Frystyk Nielsen, Microsoft</dd>
|
|
<dd>Bob Lojek, Intalio</dd>
|
|
<dd>Mark Nottingham, Akamai Technologies</dd>
|
|
<dd>Waqar Sadiq, Vitria Technology Inc.</dd>
|
|
<dd>Stuart Williams, Hewlett Packard</dd>
|
|
<dd>Amr Yassin, Philips Research</dd>
|
|
</dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> ©2003 <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 XML Protocol Working Group's requirements
|
|
for the XML Protocol (XMLP) specification.</p>
|
|
</div><div>
|
|
<h2><a name="status">Status of this Document</a></h2>
|
|
<p>
|
|
<em>This section describes the status of this document at the time
|
|
of its publication. Other documents may supersede this document. The latest
|
|
status of this document series is maintained at the W3C.</em>
|
|
</p>
|
|
<p>
|
|
The XML Protocol Working Group (WG) has decided to discontinue work on the XML Protocol Requirements, and on this document.
|
|
The WG developed the XML Protocol Requirements as a guide for evaluating candidate protocols and
|
|
for reasoning about the development of the protocol itself. The WG believes the XML Protocol
|
|
Requirement document has well served its purpose in this regard, and it no longer intends to do
|
|
any further work on it.</p>
|
|
<p>
|
|
The changes since last revision are links update for the Working Group Charter, the link to the IPR
|
|
declaration and the publication as a Working Group Note per
|
|
<a href="http://www.w3.org/2003/06/Process-20030618/process.html#tr-end">W3C Process Document, Section 7.5</a>.</p>
|
|
|
|
<p>Discussion of this document takes place on the public <<a href="mailto:xml-dist-app@w3.org">xml-dist-app@w3.org</a>> mailing list (Archives
|
|
<a href="#xml-dist-app">[4]</a>) per the
|
|
<a href="http://www.w3.org/2002/10/XML-Protocol-Charter#email">email
|
|
communication rules</a> in the XML Protocol Working Group Charter
|
|
<a href="#xmlp-charter">[3]</a>.</p>
|
|
|
|
<p>Patent disclosures relevant to this specification may be found on the Working Group's <a href="http://www.w3.org/2000/xp/Group/2/10/16-IPR-statements.html">patent disclosure page</a>.</p>
|
|
|
|
<p>This Note has been endorsed by the W3C XML Protocol Working Group, but has not
|
|
been reviewed or endorsed by W3C Members.</p>
|
|
<p>The XML Protocol Working Group is part of the <a href="http://www.w3.org/2002/ws/Activity">Web Services Activity</a>.</p>
|
|
<p>A <a href="http://www.w3.org/TR/">list of all W3C technical reports</a> can be found
|
|
at http://www.w3.org/TR/.</p>
|
|
</div>
|
|
<hr><div class="toc">
|
|
<h2><a name="shortcontents">Short Table of Contents</a></h2><p class="toc">1. <a href="#N345">Notations</a><br>2. <a href="#N800">Relationship to WG Charter</a><br>3. <a href="#N396">Requirements on Requirements</a><br>4. <a href="#N435">Requirements</a><br>5. <a href="#N2100">Requirements from other W3C WGs</a><br>6. <a href="#N2690">Usage Scenarios</a><br>7. <a href="#N2678">References</a><br>A. <a href="#N2672">Acknowledgments</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="#N345">Notations</a><br>2. <a href="#N800">Relationship to WG Charter</a><br>3. <a href="#N396">Requirements on Requirements</a><br>4. <a href="#N435">Requirements</a><br> 4.1 <a href="#N443">General Requirements</a><br> 4.2 <a href="#N673">Simplicity and Stability</a><br> 4.2.1 <a href="#N674">The XMLP Specification Documents</a><br> 4.2.2 <a href="#N675">The XMLP Technologies</a><br> 4.3 <a href="#N774">Data Encapsulation and Evolvability</a><br> 4.4 <a href="#N1136">Intermediaries</a><br> 4.4.1 <a href="#N1137">Transport Intermediaries</a><br> 4.4.2 <a href="#N1138">Processing Intermediaries</a><br> 4.5 <a href="#N400">Data Representation</a><br> 4.6 <a href="#N1423">Protocol Bindings</a><br> 4.7 <a href="#N1595">Convention for RPC</a><br>5. <a href="#N2100">Requirements from other W3C WGs</a><br> 5.1 <a href="#N2200">XForms Requirements</a><br> 5.2 <a href="#N1573">P3P Requirements</a><br> 5.3 <a href="#L5908">RDF and UML Requirements</a><br>6. <a href="#N2690">Usage Scenarios</a><br>7. <a href="#N2678">References</a><br></p>
|
|
<h3><a id="appendix" name="appendix">Appendix</a></h3><p class="toc">A. <a href="#N2672">Acknowledgments</a> (Non-Normative)<br></p></div><hr><div class="body">
|
|
<div class="div1">
|
|
|
|
<h2><a name="N345"></a>1. Notations</h2>
|
|
<p>The following terminology and typographical conventions have been used
|
|
in this document.</p>
|
|
<p>Each requirement and scenario has a three digit number with a prefix
|
|
indicating the status as follows:</p>
|
|
<ul>
|
|
<li>
|
|
<p>A "<b>DR</b>nnn" notation indicates a requirement that the
|
|
WG is actively considering (<em>has not</em> reached <em>rough</em>
|
|
consensus within the WG)</p>
|
|
</li>
|
|
<li>
|
|
<p>An "<b>R</b>nnn" notation indicates a requirement that the
|
|
WG is not actively considering at present (<em>has</em> reached
|
|
<em>rough</em> consensus within the WG)</p>
|
|
</li>
|
|
<li>
|
|
<p>A "<b>DS</b>nnn" notation indicates a usage scenario that
|
|
the WG is actively considering (<em>has not</em> reached <em>rough</em>
|
|
consensus within the WG)</p>
|
|
</li>
|
|
<li>
|
|
<p>An "<b>S</b>nnn" notation indicates a usage scenario that
|
|
the WG is not actively considering at present (<em>has rough</em> consensus
|
|
within the WG)</p>
|
|
</li>
|
|
</ul>
|
|
<p>The numbers used to identify requirements are arbitrary and does not
|
|
imply any ordering or significance.</p>
|
|
<p>The document includes several verbatim quotes from the XML Protocol WG
|
|
Charter <a href="#xmlp-charter">[3]</a> which provide context for the
|
|
requirements. The quoted text is <em>emphasized</em> and prefixed with
|
|
<b>Charter</b>.</p>
|
|
</div>
|
|
<div class="div1">
|
|
|
|
<h2><a name="N800"></a>2. Relationship to WG Charter</h2>
|
|
<p>The XML Protocol WG Charter <a href="#xmlp-charter">[3]</a> has two
|
|
sections describing what is
|
|
<a href="http://www.w3.org/2002/10/XML-Protocol-Charter#scope">in-scope</a>
|
|
and what is
|
|
<a href="http://www.w3.org/2002/10/XML-Protocol-Charter#outofscope">out-of-scope</a>
|
|
of the problem space defined for the WG. The WG considers all the requirements
|
|
in <a href="#N435"><b>4. Requirements</b></a> to be in-scope per the Charter.</p>
|
|
<p>Reviewers and readers should be familiar with the XML Protocol WG
|
|
Charter <a href="#xmlp-charter">[3]</a> because it provides the critical context
|
|
for the requirements and any discussion of them.</p>
|
|
</div>
|
|
<div class="div1">
|
|
|
|
<h2><a name="N396"></a>3. Requirements on Requirements</h2>
|
|
<dl>
|
|
|
|
<dt class="label"><a name="z900"></a>R900</dt>
|
|
<dd>
|
|
<p>The XMLP requirements must include usage scenarios that describe
|
|
how XMLP is used in various environments (see <a href="#N2690"><b>6. Usage Scenarios</b></a>). The set
|
|
of usage scenarios must represent the expected range of XMLP's use. The
|
|
scenarios must be used as design cases during the development of XML Protocol,
|
|
and it must be possible to determine whether or not the XML Protocol design
|
|
enables each scenario. In addition, the usage scenarios are intended to help a
|
|
technically competent person understand the role of XMLP.</p>
|
|
</dd>
|
|
|
|
</dl>
|
|
</div>
|
|
<div class="div1">
|
|
|
|
<h2><a name="N435"></a>4. Requirements</h2>
|
|
<div class="div2">
|
|
|
|
<h3><a name="N443"></a>4.1 General Requirements</h3>
|
|
<p>
|
|
<em>
|
|
<b>Charter:</b>
|
|
"The envelope and the serialization mechanisms
|
|
developed by the Working Group may not preclude any programming model nor
|
|
assume any particular mode of communication between peers."
|
|
</em>
|
|
</p>
|
|
<dl>
|
|
|
|
<dt class="label"><a name="z500"></a>R500</dt>
|
|
<dd>
|
|
<p>The specification will make reasonable efforts to support (but
|
|
not define) a broad range of programming models suitable for the applications
|
|
intended for XMLP.</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="z501"></a>R501</dt>
|
|
<dd>
|
|
<p>The specification will make reasonable efforts to support (but
|
|
not define) a broad range of protocol bindings between communicating peers (see
|
|
also section <a href="#N1423"><b>4.6 Protocol Bindings</b></a>).</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="z502"></a>R502</dt>
|
|
<dd>
|
|
<p>The specification developed by the Working Group must support
|
|
either directly or via well defined extension mechanisms different messaging
|
|
patterns and scenarios. The specification will directly support One-way and
|
|
Request-response patterns as part of permanently and intermittently connected
|
|
scenarios. The specification will not preclude the development of other
|
|
patterns at either the application or transport layers. Examples of such
|
|
patterns may include publish-subscribe or multicast delivery. All patterns and
|
|
scenarios will be described by relevant usage scenarios (see
|
|
<a href="#N2690"><b>6. Usage Scenarios</b></a>).</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="z503"></a>R503</dt>
|
|
<dd>
|
|
<p>The Working Group will coordinate with the
|
|
<a href="http://www.w3.org/XML/Activity">W3C XML Activity</a> through the
|
|
<a href="http://www.w3.org/XML/Group/">XML Coordination Group</a> (W3C members only) and
|
|
shall use available XML technologies whenever possible. If there are cases
|
|
where this is not possible, the reasons must be documented thoroughly.</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="z504"></a>R504</dt>
|
|
<dd>
|
|
<p>The specification developed by the XML Protocol Working Group
|
|
WG <a href="#xmlp-wg">[2]</a> shall be as lightweight as possible keeping parts
|
|
that are mandatory to the minimum. Optional parts of the specification should
|
|
be orthogonal to each other allowing non-conflicting configurations to be
|
|
implemented.</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="z505"></a>R505</dt>
|
|
<dd>
|
|
<p>The specification must be suitable for use between
|
|
communicating parties that do <em>not</em> have <em>a priori
|
|
</em>knowledge of each other.</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="z506"></a>R506</dt>
|
|
<dd>
|
|
<p>The specification must focus on the encapsulation and
|
|
representation of data being transferred between parties capable of generating
|
|
and/or accepting an XMLP envelope.</p>
|
|
</dd>
|
|
|
|
</dl>
|
|
</div>
|
|
<div class="div2">
|
|
|
|
<h3><a name="N673"></a>4.2 Simplicity and Stability</h3>
|
|
<p>
|
|
<em>
|
|
<b>Charter:</b>
|
|
"Focus must be put on simplicity and modularity and
|
|
must support the kind of extensibility actually seen on the Web. In particular,
|
|
it must support distributed extensibility where the communicating parties do
|
|
not have a priori knowledge of each other."
|
|
</em>
|
|
</p>
|
|
<p>
|
|
<em>
|
|
<b>Charter:</b>
|
|
"Simplicity is a key element in making distributed
|
|
systems easy to understand, implement, maintain, and evolve. Modularity and
|
|
layering are two important design principles for achieving simplicity. Although
|
|
simplicity can only be measured in relative terms, the Working Group must
|
|
ensure that the complexity of any solution produced is comparable to that of
|
|
other current and widespread Web solutions."
|
|
</em>
|
|
</p>
|
|
<p>
|
|
<em>
|
|
<b>Charter:</b>
|
|
"Another important aspect of simplicity is ease of
|
|
deployment. The Working Group will look at various ways of deploying XML
|
|
Protocol in a manner that is compatible with the existing Web
|
|
infrastructure."
|
|
</em>
|
|
</p>
|
|
<p>Over the years, many different companies and individuals have proven
|
|
the ability to design and implement workable open protocols for distributed
|
|
computing that operate largely within organizational boundaries. The design
|
|
center for XMLP must include the interoperation of systems across
|
|
organizational boundaries. The aim is to exploit Web philosophy and Web design
|
|
principles in order to help foster widespread decentralized computing on the
|
|
Web.</p>
|
|
<dl>
|
|
|
|
<dt class="label"><a name="z307"></a>R307</dt>
|
|
<dd>
|
|
<p>XMLP must be suitable for widespread use across organizational
|
|
boundaries in support of the application usage scenarios supplied elsewhere in
|
|
this document (see <a href="#N2690"><b>6. Usage Scenarios</b></a>). This suitability requirement
|
|
implies simplicity in the language of the XMLP specification, which itself
|
|
describes a technology that is simple to understand and to implement correctly
|
|
(see also <b>[<a href="#z301">R301</a>]</b>, <b>[<a href="#z301">R301</a>]</b>). Although simplicity
|
|
can only be measured in relative terms, the Working Group should ensure that
|
|
the complexity of any solution produced is comparable to that of other current
|
|
and widespread Web solutions.</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="z308"></a>R308</dt>
|
|
<dd>
|
|
<p>Since XMLP is intended to be a foundation protocol, its
|
|
definition should remain simple and stable over time. Explicit use of
|
|
modularity and layering in the resulting design will help assure longevity.
|
|
Such a framework will allow subsequent extension of the design while leaving
|
|
the foundation of the design intact. (<b>[<a href="#z300">R300 (absorbs old DRs: DR023, DR053,
|
|
DR088)</a>]</b> and
|
|
<b>[<a href="#z302">R302 (Absorbs old DR's: DR107)</a>]</b> relate to stability).</p>
|
|
</dd>
|
|
|
|
</dl>
|
|
<p>Requirements for simplicity and stability arise in the context of
|
|
the specification documents and in the context of the protocol technologies
|
|
being defined.</p>
|
|
<p>Simplicity in XMLP implies that many potentially important features
|
|
are out of scope for XMLP proper. However, the XML Protocol Working Group
|
|
recognizes that providing consistent ways to support these out of scope
|
|
features will help keep XMLP stable.</p>
|
|
<p>Examples of such features are:</p>
|
|
<ol>
|
|
<li>
|
|
<p>message authentication and encryption (perhaps using SMIME, SSL,
|
|
or digital signatures), </p>
|
|
</li>
|
|
<li>
|
|
<p>sessions and transactions (possibly by providing globally unique
|
|
identifiers for messages), and </p>
|
|
</li>
|
|
<li>
|
|
<p>service definition and discovery. </p>
|
|
</li>
|
|
</ol>
|
|
<p>Facilities to support features like these may resemble SOAP/1.1
|
|
<a href="#soap11">[7]</a> facilities such as the "Header" element.</p>
|
|
<div class="div3">
|
|
|
|
<h4><a name="N674"></a>4.2.1 The XMLP Specification Documents</h4>
|
|
<dl>
|
|
|
|
<dt class="label"><a name="z300"></a>R300 (absorbs old DRs: DR023, DR053,
|
|
DR088)</dt>
|
|
<dd>
|
|
<p>The requirements that XMLP support the use of layering and
|
|
be modular, extensible, and transport independent imply that there is an
|
|
architectural design model behind XMLP. This architecture and the extensibility
|
|
framework must be explicitly defined (<b>[<a href="#z308">R308</a>]</b> references
|
|
modularity, <b>[<a href="#z302">R302 (Absorbs old DR's: DR107)</a>]</b> and <b>[<a href="#z700a">R700a Requirement for Extensibility</a>]</b> reference
|
|
extensibility, <b>[<a href="#z502">R502</a>]</b> and <b>[<a href="#z600">R600</a>]</b> reference
|
|
transport neutrality).</p>
|
|
<p> In this context, layering refers to both XMLP's support of
|
|
XMLP modules (the layer(s) "above") as well as the capability of XMLP to define
|
|
services required (the layer(s) "below") for implementation across a variety of
|
|
underlying protocols</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="z301"></a>R301</dt>
|
|
<dd>
|
|
<p>The XMLP 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.</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="z301a"></a>R301a</dt>
|
|
<dd>
|
|
<p>The XMLP specification must clearly identify conformance
|
|
requirements in a way that enables the conformance of an implementation of the
|
|
specification to be tested (see also <a href="#w3c-conformance">[12]</a>).</p>
|
|
</dd>
|
|
|
|
</dl>
|
|
</div>
|
|
<div class="div3">
|
|
|
|
<h4><a name="N675"></a>4.2.2 The XMLP Technologies</h4>
|
|
<dl>
|
|
|
|
<dt class="label"><a name="z302"></a>R302 (Absorbs old DR's: DR107)</dt>
|
|
<dd>
|
|
<p>XMLP must support extensibility of vocabulary between
|
|
communicating parties in a way that allows for decentralized extensibility
|
|
without prior agreement. The WG must demonstrate through usage scenarios that
|
|
the solution supports decentralized extensibility in a modular and layered
|
|
manner (see <a href="#N2690"><b>6. Usage Scenarios</b></a>).</p>
|
|
<p> To date the web has been enormously successful because it
|
|
has enabled the creators of web services adapt the user interfaces they provide
|
|
to human users of the web. A goal of XMLP is to achieve similar levels of
|
|
evolvability, extensibility and adaptability for interfaces between web
|
|
services.</p>
|
|
</dd>
|
|
|
|
</dl>
|
|
<dl>
|
|
|
|
<dt class="label"><a name="z304"></a>R304</dt>
|
|
<dd>
|
|
<p>XMLP should facilitate the creation of simple applications.
|
|
Simple applications are often characterized by message exchange patterns such
|
|
as one-way (or event), and two-way (or synchronous) request response
|
|
interactions. The specification should make such simple exchange applications
|
|
as easy as possible to create and to use.</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="z306"></a>R306 (Absorbs old DRs: DR090)</dt>
|
|
<dd>
|
|
<p>XMLP and applications of XMLP must be easy to
|
|
deploy—especially in systems already supporting XML technologies like XML
|
|
namespaces <a href="#XMLNS">[10]</a> and XML schemas <a href="#XMLSchemaP1">[8]</a>
|
|
<a href="#XMLSchemaP2">[9]</a>.</p>
|
|
<p> The ease with which XMLP applications can be deployed will
|
|
be crucial to the success of XMLP. The design of the protocol architecture must
|
|
be sensitive to the issues arising in the full spectrum of deployment
|
|
environments ranging from resource constrained embedded devices (appliances)
|
|
through high performance service engines.</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="z309"></a>R309</dt>
|
|
<dd>
|
|
<p>The specification should make reasonable efforts to support
|
|
applications that operate on resource constrained devices. Even though any
|
|
practical device is resource constrained in any number of dimensions including
|
|
but not limited to bandwidth, computational power and storage, the term
|
|
"resource constrained device" often refers to hand-portable devices. This
|
|
document does not attempt to define the term "resource constrained" nor what
|
|
the constraints are for the available resources.</p>
|
|
</dd>
|
|
|
|
</dl>
|
|
</div>
|
|
</div>
|
|
<div class="div2">
|
|
|
|
<h3><a name="N774"></a>4.3 Data Encapsulation and Evolvability</h3>
|
|
<p>
|
|
<em>
|
|
<b>Charter:</b>
|
|
"For two peers to communicate in a distributed
|
|
environment, they must first agree on a unit of communication. The XML Protocol
|
|
Working Group must define such a unit by defining an encapsulation language
|
|
that allows for applications to independently introduce extensions and new
|
|
features. In this context, the following requirements for extensions and
|
|
features must be met:"
|
|
</em>
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
<em>
|
|
"They are or can be orthogonal to other
|
|
extensions."
|
|
</em>
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<em>
|
|
"They can be deployed automatically and dynamically across
|
|
the Web with no prior coordination and no central authority."
|
|
</em>
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
<em>
|
|
"The sender can require that the recipient either obeys
|
|
the semantics defined by an extension or aborts the processing of the
|
|
message."
|
|
</em>
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
<dl>
|
|
|
|
<dt class="label"><a name="z701a"></a>R701a Requirement for Encapsulation</dt>
|
|
<dd>
|
|
<p>The XMLP specification must define the concept of an envelope
|
|
or outermost syntactical construct or structure within which all other
|
|
syntactical elements of the message must be enclosed. The envelope must be
|
|
described with XML Schema <a href="#XMLSchemaP1">[8]</a>
|
|
<a href="#XMLSchemaP2">[9]</a>.</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="z701b"></a>R701b Requirement for Encapsulation</dt>
|
|
<dd>
|
|
<p>The XMLP specification must also define a processing model
|
|
that defines what it means to properly process an XMLP envelope or produce a
|
|
fault. This processing model must be independent of any extensions carried
|
|
within the envelope. The processing model must apply equally to intermediaries
|
|
as well as ultimate destinations of an XMLP envelope.</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="z700a"></a>R700a Requirement for Extensibility</dt>
|
|
<dd>
|
|
<p id="z700">The XMLP specification must define a mechanism or
|
|
mechanisms that allow applications to submit application-specific content or
|
|
information for delivery by XMLP. In forming the standard for the mechanisms,
|
|
the XMLP specification may consider support for:</p>
|
|
<ul>
|
|
<li>
|
|
<p>carrying application specific payloads inside the XMLP
|
|
envelope,</p>
|
|
</li>
|
|
<li>
|
|
<p>referring to application specific payloads outside the
|
|
XMLP envelope,</p>
|
|
</li>
|
|
<li>
|
|
<p>carrying nested XMLP envelopes as application specific
|
|
data within the XMLP envelope,</p>
|
|
</li>
|
|
<li>
|
|
<p>referring to XMLP envelopes as application specific data
|
|
outside the XMLP envelope</p>
|
|
</li>
|
|
</ul>
|
|
<p>Regarding the handling of binary data in particular, the XML
|
|
Protocol WG Charter <a href="#xmlp-charter">[3]</a> has the following to say:</p>
|
|
<p>
|
|
<em>
|
|
<b>Charter:</b>
|
|
"Note that XML Namespaces provide a flexible
|
|
and lightweight mechanism for handling language mixing as long as those
|
|
languages are expressed in XML. In contrast, there is only very rudimentary
|
|
support (base-64 encodings etc.) for including data languages expressed in
|
|
binary formats. Such formats include commonly used image formats like PNG, JPEG
|
|
etc. Although it is inconceivable to imagine a Web without such data formats,
|
|
it is not considered a priority of this Working Group to solve this problem.
|
|
This is in part because other organizations (e.g.
|
|
<a href="http://www.ebxml.org">ebXML</a> and
|
|
<a href="http://www.rosettanet.org">RosettaNet</a>) are already addressing the issue
|
|
using an approach based on MIME multipart. The Working Group can consider
|
|
solutions proposed by other groups as a matter of low priority, if there is
|
|
sufficient interest."
|
|
</em>
|
|
</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="z700b"></a>R700b Requirement for Extensibility</dt>
|
|
<dd>
|
|
<p>To manage the mechanisms, the XMLP specification must define a
|
|
set of directives which will unambiguously indicate to an XMLP processor which
|
|
extensions are optional and which are mandatory so that it can:</p>
|
|
<ul>
|
|
<li>
|
|
<p>process all of the extensions in an XMLP envelope or
|
|
fail,</p>
|
|
</li>
|
|
<li>
|
|
<p>process a subset of the extensions in an XMLP envelope or
|
|
fail.</p>
|
|
</li>
|
|
</ul>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="z700c"></a>R700c Requirement for Extensibility</dt>
|
|
<dd>
|
|
<p>In both cases above, the XMLP processor must fail in a
|
|
standard and predictable fashion.</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="z702"></a>R702 Requirement for Evolution</dt>
|
|
<dd>
|
|
<p>The XMLP specification must define the concept of protocol
|
|
evolution and define a mechanism or mechanisms for identifying XMLP revisions.
|
|
This mechanism or mechanisms must ensure that an XMLP processor, by simple
|
|
inspection of an XMLP envelope, may determine whether or not the envelope is
|
|
compatible with its processing ability. The specification must define the
|
|
concepts of backwards compatible and backwards incompatible evolution.</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="z703a"></a>R703a Requirement for Encapsulation of Error
|
|
Information</dt>
|
|
<dd>
|
|
<p>The XMLP specification must define a means to convey error
|
|
information as a fault. The capability of XMLP carrying a fault message must
|
|
not depend on any particular protocol binding.</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="z703b"></a>R703b Requirement for Encapsulation of
|
|
Status</dt>
|
|
<dd>
|
|
<p>The XMLP specification must define a mechanism or mechanisms
|
|
to allow the transfer of status information within an XMLP message without
|
|
resort to use of XMLP fault messages or dependence on any particular
|
|
interaction model.</p>
|
|
</dd>
|
|
|
|
</dl>
|
|
</div>
|
|
<div class="div2">
|
|
|
|
<h3><a name="N1136"></a>4.4 Intermediaries</h3>
|
|
<p>
|
|
<em>
|
|
<b>Charter:</b>
|
|
"Intermediaries are essential parts of building
|
|
distributed systems that scale to the Web. Intermediaries can act in different
|
|
capacities ranging from proxies, caches, store-and-forward hops, to gateways.
|
|
Experience from HTTP <a href="#RFC2616">[6]</a> and other protocols has shown that
|
|
intermediaries cannot be implicitly defined but must be an explicit part of the
|
|
message path model for any data encapsulation language. Therefore, the Working
|
|
Group must ensure that the data encapsulation language supports composability
|
|
both in the vertical (within a peer) as well as in the horizontal (between
|
|
peers)."
|
|
</em>
|
|
</p>
|
|
<p>Because XMLP separates the message envelope from the transport
|
|
binding, two types of intermediaries are possible; transport intermediaries and
|
|
processing intermediaries.</p>
|
|
<div class="div3">
|
|
|
|
<h4><a name="N1137"></a>4.4.1 Transport Intermediaries</h4>
|
|
<p>Transport intermediaries are interposed by a transport binding, as
|
|
part of the message exchange pattern that it implies. They do not define a
|
|
processing model for messages; they only operate as part of the transport
|
|
binding, as a message routing mechanism and cannot be addressed from within an
|
|
XMLP envelope.</p>
|
|
<dl>
|
|
|
|
<dt class="label"><a name="z803"></a>R803</dt>
|
|
<dd>
|
|
<p>XMLP must not preclude the use of transport bindings that
|
|
define transport intermediary roles such as store-and-forward, proxy and
|
|
gateway.</p>
|
|
</dd>
|
|
|
|
</dl>
|
|
</div>
|
|
<div class="div3">
|
|
|
|
<h4><a name="N1138"></a>4.4.2 Processing Intermediaries</h4>
|
|
<p>Processing intermediaries are full XMLP processors; they process
|
|
the message, but are not the ultimate recipient of it. They may be colocated
|
|
with transport intermediaries, using them as a routing mechanism, or they may
|
|
use in-message routing mechanisms.</p>
|
|
<dl>
|
|
|
|
<dt class="label"><a name="z811"></a>R811</dt>
|
|
<dd>
|
|
<p>XMLP must define and accommodate processing
|
|
intermediaries.</p>
|
|
</dd>
|
|
|
|
</dl>
|
|
<p>To enable the interposition of processing intermediaries into the
|
|
message path, two core requirements must be met:</p>
|
|
<dl>
|
|
|
|
<dt class="label"><a name="z806"></a>R806</dt>
|
|
<dd>
|
|
<p>Targeting - XMLP must define mechanisms that allow XMLP
|
|
processors, including intermediaries, to identify XMLP extensions which they
|
|
are eligible to process.</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="z808"></a>R808</dt>
|
|
<dd>
|
|
<p>Reporting - XMLP must enable the generation of status and/or
|
|
error messages by processing intermediaries, and enable propagation and proper
|
|
identification of status and/or error messages through processing
|
|
intermediaries.</p>
|
|
</dd>
|
|
|
|
</dl>
|
|
<p>In addition</p>
|
|
<dl>
|
|
|
|
<dt class="label"><a name="z802"></a>R802</dt>
|
|
<dd>
|
|
<p>XMLP must also enable processing intermediaries to locate
|
|
and process XMLP extensions intended for them without processing the entire
|
|
message.</p>
|
|
</dd>
|
|
|
|
</dl>
|
|
</div>
|
|
</div>
|
|
<div class="div2">
|
|
|
|
<h3><a name="N400"></a>4.5 Data Representation</h3>
|
|
<p>
|
|
<em>
|
|
<b>Charter:</b>
|
|
"With the introduction of XML and Resource
|
|
Description Framework (RDF) schema languages, and the existing capabilities of
|
|
object and type modeling languages such as Unified Modeling Language (UML),
|
|
applications can model data at either a syntactic or a more abstract level. In
|
|
order to propagate these data models in a distributed environment, it is
|
|
required that data conforming to a syntactic schema can be transported
|
|
directly, and that data conforming to an abstract schema can be converted to
|
|
and from XML for transport."
|
|
</em>
|
|
</p>
|
|
<p>
|
|
<em>
|
|
<b>Charter:</b>
|
|
"The Working Group should propose a mechanism for
|
|
serializing data representing non-syntactic data models in a manner that
|
|
maximizes the interoperability of independently developed Web applications.
|
|
Furthermore, as data models change, the serialization of such data models may
|
|
also change. Therefore it is important that the data encapsulation and data
|
|
representation mechanisms are designed to be orthogonal."
|
|
</em>
|
|
</p>
|
|
<p>
|
|
<em>
|
|
<b>Charter:</b>
|
|
"Examples of relationships that will have to be
|
|
serialized include subordinate relationships known from attachments and
|
|
manifests. Any general mechanism produced by the Working Group for serializing
|
|
data models must also be able to support this particular case."
|
|
</em>
|
|
</p>
|
|
<dl>
|
|
|
|
<dt class="label"><a name="z400"></a>R400</dt>
|
|
<dd>
|
|
<p>The XMLP data encapsulation and data representation mechanisms
|
|
must be orthogonal.</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="z401"></a>R401</dt>
|
|
<dd>
|
|
<p>The XMLP data representation must support using XML Schema
|
|
simple and complex types <a href="#XMLSchemaP1">[8]</a>
|
|
<a href="#XMLSchemaP2">[9]</a>.</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="z402"></a>R402</dt>
|
|
<dd>
|
|
<p>The XMLP data representation must be able to serialize data
|
|
based on data models not directly representable by XML Schema simple and
|
|
complex types. These data models include object graphs and directed labeled
|
|
graphs. It must be possible to reconstruct the original data from the data
|
|
representation.</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="z403"></a>R403</dt>
|
|
<dd>
|
|
<p>Data serialized according to the XMLP data representation may
|
|
contain references to data outside the serialization. These references must be
|
|
Uniform Resource Identifiers (URIs) <a href="#RFC2396">[5]</a>.</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="z404"></a>R404</dt>
|
|
<dd>
|
|
<p>The XMLP data representation must be able to encode arrays
|
|
which may be nested.</p>
|
|
</dd>
|
|
|
|
</dl>
|
|
</div>
|
|
<div class="div2">
|
|
|
|
<h3><a name="N1423"></a>4.6 Protocol Bindings</h3>
|
|
<p>
|
|
<em>
|
|
<b>Charter:</b>
|
|
"A mechanism for using HTTP transport in the context
|
|
of an XML Protocol. This does not mean that HTTP is the only transport
|
|
mechanism that can be used for the technologies developed, nor that support for
|
|
HTTP transport is mandatory. This component merely addresses the fact that HTTP
|
|
transport is expected to be widely used, and so should be addressed by this
|
|
Working Group."
|
|
</em>
|
|
</p>
|
|
<p>
|
|
<em>
|
|
<b>Charter:</b>
|
|
"Mapping onto existing application layer protocols
|
|
may lead to scalability problems, security problems and semantic complications
|
|
when the application semantics defined by those protocols interfere with the
|
|
semantics defined by an XML Protocol. The WG may consider issuing a warning
|
|
about the possible problems of reusing non-safe "transports" like SMTP and
|
|
others. A mapping onto transport services other than HTTP will only be started
|
|
if enough interest is shown and time is available."
|
|
</em>
|
|
</p>
|
|
<p>
|
|
<em>
|
|
<b>Charter:</b>
|
|
"General transport issues were investigated by the
|
|
HTTP-NG Activity, which designed a general transport mechanism for handling
|
|
out-of-order delivery of message streams between two peers. While we do
|
|
strongly encourage work to be undertaken in this area, it is expected that work
|
|
in this area will be done in collaboration with the
|
|
<a href="http://www.ietf.org">IETF</a> and not as part of this Working
|
|
Group"
|
|
</em>
|
|
</p>
|
|
<dl>
|
|
|
|
<dt class="label"><a name="z600"></a>R600</dt>
|
|
<dd>
|
|
<p>The XMLP specification must not mandate any dependency on
|
|
specific features or mechanisms provided by a particular transport protocol
|
|
beyond the basic requirement that the transport protocol must have the ability
|
|
to deliver the XMLP envelope as a whole unit. This requirement does not
|
|
preclude a mapping or binding to a transport protocol taking advantages of such
|
|
features. It is intended to ensure that the basic XMLP specification will be
|
|
transport neutral.</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="z604"></a>R604</dt>
|
|
<dd>
|
|
<p>The XMLP specification must consider the scenario where an
|
|
XMLP message may be routed over possibly many different transport or
|
|
application protocols as it moves between intermediaries on the message path.
|
|
This requirement implies it must be possible to apply many transport or
|
|
application protocol bindings to the XMLP message without information loss from
|
|
the XMLP message content.</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="z608"></a>R608</dt>
|
|
<dd>
|
|
<p>The XMLP binding mechanism should not preclude the possibility
|
|
of constructing bindings to protocols that provide a security mechanism.</p>
|
|
<p>Typical examples of such protocols are SSL providing a secure
|
|
channel,and S/MIME which provides a secure wrapper. It should be possible to
|
|
specify XMLP bindings for such security protocols.</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="z609"></a>R609</dt>
|
|
<dd>
|
|
<p>The XMLP specification may mandate the use of a specific
|
|
character encoding, such as UTF-8, at some point in the future.</p>
|
|
<p>The Working Group is aware of the complexity resulting in the
|
|
use of a large set of character encodings and is actively seeking feedback in
|
|
this area. Until all the feedback has been evaluated, the Working Group will
|
|
not make a decision in favor of restriction.</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="z612"></a>R612</dt>
|
|
<dd>
|
|
<p>The XMLP specification must provide a normative description of
|
|
the default binding of XMLP to HTTP <a href="#RFC2616">[6]</a>. This binding,
|
|
while normative, is not to be exclusive. The binding provided by the Working
|
|
Group will respect the semantics of HTTP and will demonstrate that it can
|
|
co-exist with existing HTTP/1.0 and HTTP/1.1 implementations.</p>
|
|
</dd>
|
|
|
|
</dl>
|
|
</div>
|
|
<div class="div2">
|
|
|
|
<h3><a name="N1595"></a>4.7 Convention for RPC</h3>
|
|
<p>
|
|
<em>
|
|
<b>Charter:</b>
|
|
"A convention for the content of the envelope when
|
|
used for RPC (Remote Procedure Call) applications. The protocol aspects of this
|
|
should be coordinated closely with the
|
|
<a href="http://www.ietf.org">IETF</a> and make an effort to leverage any work
|
|
they are doing"
|
|
</em>
|
|
</p>
|
|
<dl>
|
|
|
|
<dt class="label"><a name="z200"></a>R200</dt>
|
|
<dd>
|
|
<p>XMLP must contain a convention for representing calls and
|
|
replies between RPC (Remote Procedure Call) applications and services. The
|
|
conventions must include the following:</p>
|
|
<ol>
|
|
<li>
|
|
<p>Complete and unique identification, by means of URI syntax
|
|
<a href="#RFC2396">[5]</a>, of the program, service or object and procedure or
|
|
method to be called.</p>
|
|
</li>
|
|
<li>
|
|
<p>Enable support for matching response messages to request
|
|
messages for cases in which matching is not provided by the underlying protocol
|
|
binding.</p>
|
|
</li>
|
|
<li>
|
|
<p>The ability to specify the parameters to a call in a
|
|
request message and the results of a call in a reply messages.</p>
|
|
</li>
|
|
<li>
|
|
<p>Provisions for specifying errors in a reply message (see
|
|
also <b>[<a href="#z703a">R703a Requirement for Encapsulation of Error
|
|
Information</a>]</b> and <b>[<a href="#z703b">R703b Requirement for Encapsulation of
|
|
Status</a>]</b>)</p>
|
|
</li>
|
|
</ol>
|
|
<p>Where possible, an attempt will be made to leverage any
|
|
related work done by the
|
|
<a href="http://www.ietf.org">IETF</a>.</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="z201"></a>R201</dt>
|
|
<dd>
|
|
<p>The RPC conventions within XMLP should use the Data
|
|
Representation model discussed in <a href="#N400"><b>4.5 Data Representation</b></a> to represent parameters
|
|
to a call in the request message and results of the call in the reply message.
|
|
It must be convenient to create straightforward mappings of the data types to a
|
|
wide variety of widely deployed programming languages and object systems.</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="z202"></a>R202</dt>
|
|
<dd>
|
|
<p>XMLP should allow applications to include custom encodings for
|
|
data types used for parameters and results in RPC messages.</p>
|
|
</dd>
|
|
|
|
</dl>
|
|
</div>
|
|
</div>
|
|
<div class="div1">
|
|
|
|
<h2><a name="N2100"></a>5. Requirements from other W3C WGs</h2>
|
|
<p>These are requirements submitted by other W3C Working Groups and
|
|
Activities.</p>
|
|
<div class="div2">
|
|
|
|
<h3><a name="N2200"></a>5.1 XForms Requirements</h3>
|
|
<p>XForms models the data to be obtained from the user, specifies how a
|
|
user interface for obtaining the data is declared using XHTML markup, and
|
|
finally specifies how the populated data is shipped backed to the server. The
|
|
[SEND] subgroup is responsible for the interactions between the XForms client
|
|
and the backend server.</p>
|
|
<p>The work on [SEND] could be a replacement for the various methods
|
|
for posting data to an HTTP server such as application/x-www-form-urlencoded or
|
|
multipart/form-data.</p>
|
|
<p>Requirements:</p>
|
|
<ol>
|
|
<li>
|
|
<p>An XForms client needs to send and receive well-formed XML data
|
|
that has been defined through the XForms specification. For example, XML data
|
|
will be "sent" when the user agent is done filling out an XForm or XML data
|
|
will be "received" when a server ships out initial values for populating a
|
|
form.</p>
|
|
</li>
|
|
<li>
|
|
<p>An XForms client needs to send/receive partially completed XML
|
|
data to/from the server for persistence. This functionality will allow a user
|
|
agent to "save" or "load" a form in progress. Therefore, the XML data may not
|
|
fully conform to a schema when only partially completed.</p>
|
|
</li>
|
|
<li>
|
|
<p>An XForms client needs to be able to send/receive arbitrary
|
|
binary content along with the XML data. This will be used to support features
|
|
such as the "file upload" feature available in many WWW browsers. There needs
|
|
to be support for both 'in-band' (i.e. the binary data is within the XML data
|
|
in an XML compatible encoding such as base64) and 'out-of-band' data (i.e. the
|
|
binary data is available at some other location, and the XML data refers to the
|
|
other location).</p>
|
|
</li>
|
|
</ol>
|
|
</div>
|
|
<div class="div2">
|
|
|
|
<h3><a name="N1573"></a>5.2 P3P Requirements</h3>
|
|
<p>These are the requirements that the XML Protocol WG
|
|
<a href="#xmlp-wg">[2]</a> has received from the
|
|
<a href="http://www.w3.org/P3P/">P3P WG</a>
|
|
<a href="http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2000Oct/0065.html">:</a>
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
<p>It must be possible to associate a P3P Privacy Policy with an
|
|
XMLP message.</p>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
<div class="div2">
|
|
|
|
<h3><a name="L5908"></a>5.3 RDF and UML Requirements</h3>
|
|
<p>The XML Protocol WG has not directly received a set of requirements
|
|
from the
|
|
<a href="http://www.w3.org/RDF/">RDF WG</a> and from the UML group similar to what
|
|
was received from the
|
|
<a href="#N1573">P3P</a> and the
|
|
<a href="#N2200">XForms WGs</a>.
|
|
However, the WG believes that <b>[<a href="#z402">R402</a>]</b> and
|
|
<a href="http://www.w3.org/2002/10/XML-Protocol-Charter#representation">section
|
|
1.4 of the XML Protocol WG charter</a> addresses the primary concerns of
|
|
these groups. The WG has dealt with these concerns as part of
|
|
<a href="http://www.w3.org/2000/xp/Group/xmlp-issues#x29">issue 29</a>.</p>
|
|
</div>
|
|
</div>
|
|
<div class="div1">
|
|
|
|
<h2><a name="N2690"></a>6. Usage Scenarios</h2>
|
|
<p>Usage scenarios are intended to provide representative examples of
|
|
situations where XMLP might be applicable. The purpose of usage scenarios is to
|
|
help ensure that XMLP is capable of dealing with applications and services
|
|
actually seen in the Web. Hence, usage scenario specifications should be at a
|
|
coarse-grain level of an end user's desired XML document/message interchange,
|
|
rather than at a detailed, implementation or transport specific level. Usage
|
|
scenarios often make assumptions about the specific environments in which the
|
|
use cases are described that the requirements cannot.</p>
|
|
<p>In other words, the requirements are explicitly targeted to the design
|
|
of XMLP; usage scenarios are targeted to systems in which XMLP is most likely
|
|
part of an overall solution. Not all requirements need to be referenced by an
|
|
example usage scenario, since, in addition to higher-level, application
|
|
specific requirements for use, there are internal, architectural requirements
|
|
independent of any specific higher-level use (e.g., using XML, schemas, and
|
|
namespaces imposes certain requirements irrespective of use).</p>
|
|
<dl>
|
|
|
|
<dt class="label"><a name="s1"></a>S1 Fire-and-forget to single receiver</dt>
|
|
<dd>
|
|
<p>A sender wishes to send an unacknowledged message to a single
|
|
receiver (e.g. send a stock price update every 15 minutes)</p>
|
|
<div class="note"><p class="prefix"><b>Note:</b></p>
|
|
<p>S1 Originates from splitting the
|
|
<a href="http://www.ebxml.org">ebXML</a> use case 1.1 into 2 scenarios (S1 and
|
|
S2).</p>
|
|
</div>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="s2"></a>S2 Fire-and-forget to multiple receivers</dt>
|
|
<dd>
|
|
<p>A sender wishes to send unacknowledged messages to a set of
|
|
receivers (e.g. send a stock price update every 15 minutes)</p>
|
|
<div class="note"><p class="prefix"><b>Note:</b></p>
|
|
<p>S2 Originates from splitting the
|
|
<a href="http://www.ebxml.org">ebXML</a> use case 1.1 into 2 scenarios (S1 and
|
|
S2). Note that S2 may be decomposed into Multiple instances of S1 under the
|
|
control of some "higher-level" process such as multicast or
|
|
publish/subscribe.</p>
|
|
</div>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="s3"></a>S3 Request-response</dt>
|
|
<dd>
|
|
<p>Two parties wish to conduct electronic business by the exchange
|
|
of business documents. The sending party packages one or more documents into a
|
|
request message which is then sent to the receiving party. The receiving party
|
|
then processes the message contents and responds to the sending party. Examples
|
|
of the sending party's documents may be purchase order requests, manufacturing
|
|
information and patient healthcase information. Examples of the receiving
|
|
party's responses may include order confirmations, change control information
|
|
and contractual acknowledgements.</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="s4"></a>S4 Remote Procedure Call (RPC)</dt>
|
|
<dd>
|
|
<p>The sender invokes the service by passing parameters that are
|
|
serialised into a message for transmission to the receiving server.</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="s5"></a>S5 Request with acknowledgement</dt>
|
|
<dd>
|
|
<p>A sender wishes to reliably exchange data with a receiver. It
|
|
wishes to be notified of the status of the data delivery to the receiver. The
|
|
status may take the form of:</p>
|
|
<ol>
|
|
<li>
|
|
<p>The data has been successfully delivered to the receiver,
|
|
or</p>
|
|
</li>
|
|
<li>
|
|
<p>Some failure has occurred which prevents the sucessful
|
|
delivery to the receiver.</p>
|
|
</li>
|
|
</ol>
|
|
<div class="note"><p class="prefix"><b>Note:</b></p>
|
|
<p>This scenario does not imply that reliable message delivery
|
|
will be supported by the XMLP core specification.</p>
|
|
</div>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="s6"></a>S6 Request with encrypted payload</dt>
|
|
<dd>
|
|
<p>A sender wishes to exchange data with a receiver and has agreed
|
|
to encrypt the payload. The sending and receiving applications agree on the
|
|
encryption methodology. Data is encrypted by the originating application and
|
|
sent to the receiver via XMLP.The data reaches the receiving application
|
|
untouched, and may then be decrypted in the agreed-upon manner.</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="s7"></a>S7 Third part intermediary</dt>
|
|
<dd>
|
|
<p>A blind auction marketplace serves as a broker between buyers
|
|
and suppliers. Buyers submit their requirements to the marketplace hub, which
|
|
broadcasts this information to multiple suppliers. Suppliers respond to the
|
|
marketplace hub where the information is logged and ultimately delivered to the
|
|
buyer.</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="s8"></a>S8 Conversational message exchange</dt>
|
|
<dd>
|
|
<p>Two partners are engaged in a long-running process which
|
|
involves multiple message exchanges. Examples of such processes may be complex
|
|
supply chain management, dynamic manufacturing scheduling or information
|
|
retrieval. There may be multiple instances of the same process in progress
|
|
between the same two partners.</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="s10"></a>S10 Message header and payload encryption</dt>
|
|
<dd>
|
|
<p>Two trading partners engaged in a message exchange may agree to
|
|
cryptographically sign and verify either the message header, the routing
|
|
header(s) and/ or the payload. The sender or originating application may
|
|
perform the siging of the payload. The sending message extension signs the
|
|
message header. A routing header may be appended to the message header. The
|
|
routing header may also be signed by a message service extension.</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="s11"></a>S11 Communication via multiple intermediaries</dt>
|
|
<dd>
|
|
<p>An intermediary forwards a message to the ultimate receiver on
|
|
behalf of an initial sender. The initial sender wishes to enforce the
|
|
non-repudiation property of the route. Any intermediate message service
|
|
extension that appends a routing message must log the routing header
|
|
information. Signed routing headers and the message headers must be logged at
|
|
the intermediary which passes the message to the ultimate receiver to provide
|
|
the evidence of non-repudiation.</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="s17"></a>DS17 Asynchronous messaging</dt>
|
|
<dd>
|
|
<p>A sender sends a message asynchronously to a receiver expecting
|
|
some response at a later time. The sender tags the request with an identifier
|
|
allowing the response to be correlated with the originating request. The sender
|
|
may also tag the message with an identifier for another service (other than the
|
|
originating sender) which will be the recipient of the response.</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="s19"></a>S19 Sending non-XML data</dt>
|
|
<dd>
|
|
<p>A digital camera wishes to transmit image data over a wireless
|
|
link using XMLP to a remote server. The binary image data (non-XML) accompanies
|
|
the message. The digital camara represents a situation in which connections
|
|
from the receiver to the sender may not be permitted due to device limitations
|
|
or firewalls.</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="s20"></a>S20 Multiple asynchronous responses</dt>
|
|
<dd>
|
|
<p>An application requests some information from a server, which is
|
|
returned at a later time in multiple responses. This can be because the
|
|
requested information was not available all at once (e.g., distributed web
|
|
searches). (based on <a href="#mail1">[13]</a>)</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="s21"></a>S21 Incremental parsing/processing of XMLP
|
|
messages</dt>
|
|
<dd>
|
|
<p>An XMLP sender generates a lengthy XMLP message that is
|
|
incrementally transmitted and received by an XMLP receiver. The XMLP receiver
|
|
processes the body as it is received (e.g., employing a SAX-style XML parser on
|
|
the body as it arrives). Note that the entire message need not be present at
|
|
one time at any point in its existence.</p>
|
|
<p>This would be particularly helpful for memory-limited
|
|
processors. It is also very efficient for services which are consistent with
|
|
incremental, real-time transformations of the data, direct archiving of
|
|
received data, etc. It would also be useful in scenarios in which voluminous
|
|
body data can be directly transduced into application data structures or events
|
|
by an XMLP (module) processor. In particular, there is no need for the explicit
|
|
construction of a DOM model of the data. Support for XMLP data models might
|
|
still be possible even with incremental processing if the models are
|
|
incrementally constructible (copied in its entirety from <a href="#mail2">[14]</a>)</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="s23"></a>S23 Event notification</dt>
|
|
<dd>
|
|
<p>An application subscribes to notifications of certain named
|
|
events from an event source. When such events occur, notifications are sent
|
|
back to the originating application (first party notification) or to another
|
|
application (third party notification). For example, an application can
|
|
subscribe to notification of various aspects of a printer's status (e.g.,
|
|
running out of paper, ink etc.). The notifications of such events could be
|
|
delivered to a management application (based on: See item 2 of
|
|
<a href="#mail3">[15]</a>)</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="s24"></a>DS24 Caching</dt>
|
|
<dd>
|
|
<p>Some applications may wish to make caching possible for latency,
|
|
bandwidth use or other gains in efficiency. To enable this, it should be
|
|
possible to assign cacheability in a variety of circumstances. For example,
|
|
"read" caching might be used to store messages at intermediaries for reuse in
|
|
the response phase of the request/response message exchange pattern. Such
|
|
caching might be on the scope of an entire message, an XMLP module, or scoped
|
|
to individual XMLP module elements.</p>
|
|
<p>Similarly, "write" caching may be useful in situations when a
|
|
request message in a request/response message exchange pattern (as well as
|
|
similar messages in other message exchange patterns) does not need to be
|
|
immediately forwarded or responded to. Such cachability might be scoped by
|
|
different methods, as outlined above.</p>
|
|
<p>Cacheability scoped by different elements might be associated by
|
|
an attribute to the target element, through use of XML Query or XPath to
|
|
describe the target elements in a header, or implied by the document schema,
|
|
for example.</p>
|
|
<p>Cacheability mechanisms applied to messages, bodies or elements
|
|
might include time-to-live (delta time), expiry (absolute time), entity
|
|
validation, temporal validation, subscription to invalidation services, and
|
|
object update/purge.</p>
|
|
<p>Finally, some applications may be capable of describing the
|
|
dependencies and relationships between message elements. For example, a
|
|
response element may be applicable to a wide range of requests; it would be
|
|
beneficial to describe this element's relationship with request elements, so
|
|
that it may satisfy a wide range of requests in an economical fashion.
|
|
Similarly, the presence of a particular element may be a trigger for a
|
|
cacheability mechanism to be applied to another element, such as validation or
|
|
invalidation (see also <a href="#mail4">[16]</a>)</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="s805"></a>S805 Routing</dt>
|
|
<dd>
|
|
<p>A developer wishes to force an explicit message path through
|
|
certain intermediaries - for instance, he might use an anonymizing intermediary
|
|
to make a call to a specified remote service without allowing the target
|
|
service to track the identity/IP of the caller. In this case, the intermediary
|
|
is responsible for calling the target service and returning the results to the
|
|
caller, using its own authentication credentials if any are required by the
|
|
target service.</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="s807"></a>S807 Tracking</dt>
|
|
<dd>
|
|
<p>A service provider wishes to track incoming messages to see
|
|
exactly which processing intermediaries have touched it by the time it arrives
|
|
at its destination. It therefore requires a tracking extension to be included
|
|
by all clients, and by any processing intermediaries along the message paths
|
|
from the clients to the server.</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="s809"></a>S809 Caching with Expiration</dt>
|
|
<dd>
|
|
<p>BizCo updates their online price catalog every morning at 8AM.
|
|
Therefore, when remote clients access their XMLP inventory service, clients and
|
|
intermediaries may cache the results of any price queries until 8AM the next
|
|
day.</p>
|
|
</dd>
|
|
|
|
|
|
<dt class="label"><a name="s810"></a>S810 QoS</dt>
|
|
<dd>
|
|
<p>An XMLP sender (not necessarily the initial XMLP sender) wants
|
|
the XMLP message to be handled with specific quality of service as it traverses
|
|
the XMLP message path to include multiple XMLP Processing intermediaries.
|
|
Information in the XMLP message is used to select appropriate QoS mechanisms
|
|
(e.g.,
|
|
<a href="http://www.ietf.org/html.charters/rsvp-charter.html">RSVP</a>,
|
|
<a href="http://www.ietf.org/html.charters/OLD/diffserv-charter.html">Diffserv</a>,
|
|
<a href="http://www.ietf.org/html.charters/mpls-charter.html">MPLS</a>, etc.). Selection of QoS may be
|
|
constrained by
|
|
<a href="http://www.ietf.org/html.charters/policy-charter.html">QoS policies</a>,
|
|
<a href="http://www.dmtf.org/about/working/sla.php">Service Level Agreements</a> (SLAs),
|
|
<a href="http://www.ist-tequila.org/">Service Level Specifications</a> (SLS).</p>
|
|
</dd>
|
|
|
|
</dl>
|
|
</div>
|
|
<div class="div1">
|
|
|
|
<h2><a name="N2678"></a>7. References</h2>
|
|
<dl>
|
|
<dt class="label"><a name="xmlp-activity"></a>[1] </dt><dd>Web Services
|
|
Activity (See <a href="http://www.w3.org/2002/ws/Activity.html">http://www.w3.org/2002/ws/Activity.html</a>.)</dd>
|
|
<dt class="label"><a name="xmlp-wg"></a>[2] </dt><dd>XML Protocol Working
|
|
Group (See <a href="http://www.w3.org/2000/xp/Group/">http://www.w3.org/2000/xp/Group/</a>.)</dd>
|
|
<dt class="label"><a name="xmlp-charter"></a>[3] </dt><dd>XML
|
|
Protocol Working Group Charter (See <a href="http://www.w3.org/2002/10/XML-Protocol-Charter">http://www.w3.org/2002/10/XML-Protocol-Charter</a>.)</dd>
|
|
<dt class="label"><a name="xml-dist-app"></a>[4] </dt><dd>XML
|
|
Protocol Discussion Archive (See <a href="http://lists.w3.org/Archives/Public/xml-dist-app/">http://lists.w3.org/Archives/Public/xml-dist-app/</a>.)</dd>
|
|
<dt class="label"><a name="RFC2396"></a>[5] </dt><dd>IETF "RFC 2396: Uniform Resource
|
|
Identifiers (URI): Generic Syntax", T. Berners-Lee, R. Fielding, L. Masinter,
|
|
August 1998. (See <a href="http://www.ietf.org/rfc/rfc2396.txt">http://www.ietf.org/rfc/rfc2396.txt</a>.)</dd>
|
|
<dt class="label"><a name="RFC2616"></a>[6] </dt><dd>IETF "RFC 2616: Hypertext Transfer
|
|
Protocol -- HTTP/1.1", R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, T.
|
|
Berners-Lee, January 1997. (See <a href="http://www.ietf.org/rfc/rfc2616.txt">http://www.ietf.org/rfc/rfc2616.txt</a>.)</dd>
|
|
<dt class="label"><a name="soap11"></a>[7] </dt><dd>W3C Note "Simple Object Access Protocol
|
|
(SOAP) 1.1", Don Box, David Ehnebuske, Gopal Kakivaya, Andrew Layman, Noah
|
|
Mendelsohn, Henrik Nielsen, Satish Thatte, Dave Winer, 8 May 2000. (See <a href="http://www.w3.org/TR/SOAP/">http://www.w3.org/TR/SOAP/</a>.)</dd>
|
|
<dt class="label"><a name="XMLSchemaP1"></a>[8] </dt><dd>W3C
|
|
Recommendation "XML Schema Part 1: Structures", Henry S. Thompson, David Beech,
|
|
Murray Maloney, Noah Mendelsohn, 2 May 2001. (See <a href="http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/">http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/</a>.)</dd>
|
|
<dt class="label"><a name="XMLSchemaP2"></a>[9] </dt><dd>W3C
|
|
Recommendation "XML Schema Part 2: Datatypes", Paul V. Biron, Ashok Malhotra, 2
|
|
May 2001. (See <a href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/">http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/</a>.)</dd>
|
|
<dt class="label"><a name="XMLNS"></a>[10] </dt><dd>W3C
|
|
Recommendation "Namespaces in XML", Tim Bray, Dave Hollander, Andrew Layman, 14
|
|
January 1999. (See <a href="http://www.w3.org/TR/1999/REC-xml-names-19990114/">http://www.w3.org/TR/1999/REC-xml-names-19990114/</a>.)</dd>
|
|
<dt class="label"><a name="XML"></a>[11] </dt><dd>W3C Recommendation
|
|
"Extensible Markup Language (XML) 1.0 (Second Edition)", Tim Bray, Jean Paoli,
|
|
C. M. Sperberg-McQueen, Eve Maler, 6 October 2000. (See <a href="http://www.w3.org/TR/2000/REC-xml-20001006">http://www.w3.org/TR/2000/REC-xml-20001006</a>.)</dd>
|
|
<dt class="label"><a name="w3c-conformance"></a>[12] </dt><dd>W3C
|
|
Conformance requirements (W3C Members only) (See <a href="http://www.w3.org/Guide/Conformance.html">http://www.w3.org/Guide/Conformance.html</a>.)</dd>
|
|
<dt class="label"><a name="mail1"></a>[13] </dt><dd>Mail 1 (See <a href="http://lists.w3.org/Archives/Public/xml-dist-app/2000Dec/0208.html">http://lists.w3.org/Archives/Public/xml-dist-app/2000Dec/0208.html</a>.)</dd>
|
|
<dt class="label"><a name="mail2"></a>[14] </dt><dd>Mail 2 (See <a href="http://lists.w3.org/Archives/Public/xml-dist-app/2000Dec/0204.html">http://lists.w3.org/Archives/Public/xml-dist-app/2000Dec/0204.html</a>.)</dd>
|
|
<dt class="label"><a name="mail3"></a>[15] </dt><dd>Mail 3 (See <a href="http://lists.w3.org/Archives/Public/xml-dist-app/2001Jan/0070.html">http://lists.w3.org/Archives/Public/xml-dist-app/2001Jan/0070.html</a>.)</dd>
|
|
<dt class="label"><a name="mail4"></a>[16] </dt><dd>Mail 4 (See <a href="http://lists.w3.org/Archives/Public/xml-dist-app/2001Jan/0109.html">http://lists.w3.org/Archives/Public/xml-dist-app/2001Jan/0109.html</a>.)</dd>
|
|
</dl>
|
|
</div>
|
|
</div>
|
|
<div class="back">
|
|
<div class="div1">
|
|
|
|
<h2><a name="N2672"></a>A. Acknowledgments (Non-Normative)</h2>
|
|
<p>The WG thanks all participants of the
|
|
<a href="mailto:xml-dist-app@w3.org">xml-dist-app@w3.org</a> mailing list (Archives
|
|
<a href="#xml-dist-app">[4]</a>) for directly and indirectly contributing to this
|
|
document.</p>
|
|
</div>
|
|
</div>
|
|
</body></html>
|