This document specifies a set of DRAFT describes the XML Protocol Working Group's requirements for the XML Protocol specification.<h1>
This document represents section describes the deleted text: current status deleted text: and thinking of this document at the <a href="./"> XML Protocol WG </a> 's work on requirements and does not imply concensus within the WG. time of its publication. Other documents may supersede this document. The latest status of this document will be updated in the near future as series is maintained at the thinking evolves. W3C.
This deleted text: document is not an official the first W3C Technical Report. Working Draft of the XML Protocol (XP) requirements document. It is to be considered work in progress and does not imply endorsement by a chartered deliverable of the W3C membership nor by XML Protocol Working Group (WG), which is part of the XML Protocol WG. A future revision Activity . Although the Working Group agreed to request publication of this document, this document will become an official W3C Technical Report as a deliverable of does not necessarily represent consensus within the Working Group about XML Protocol WG in accordance with requirements. The previous Working Group draft was the <a href="../../09/XML-Protocol-Charter#schedule"> WG Charter </a>. 7 December 2000 revision.
Discussion of this document will take takes place on the public < firstname.lastname@example.org > mailing list ( Archives ) as indicated by per the <a href="../../09/XML-Protocol-Charter#email"> email communiation communication rules deleted text: provided in the WG charter. XP Working Group Charter.
The current organization of this document follows closely the <a href="../../09/XML-Protocol-Charter"> WG charter </a> which has a section on <a href="../../09/XML-Protocol-Charter#scope"> in scope requirements </a> and <a href="../../09/XML-Protocol-Charter#outofscope"> out of scope requirements </a>. The exact organization of which items are in each section may change provided that the work This is deleted text: within the <a href="../../09/XML-Protocol-Charter"> WG charter </a>. The <a href="../../09/XML-Protocol-Charter"> WG charter </a> provides a background public W3C Working Draft for this organization review by W3C members and it other interested parties. It is deleted text: recommended that the reader reads the charter before reading this document. The organization may change in a later revision. </p> <p> The WG has so far concentrated on the <a href="#N435"> in scope requirements </a> draft document and little efforts have been put into editing the current <a href="#N1674"> out of scope requirements. </a> Please note the guidance given may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in the section on <a href="#N345"> Notations progress". A list of all W3C technical reports used in this document for more details about the layout. can be found at http://www.w3.org/TR/.<h1>
The following terminology and typographical conventions have been used in this document: document.
Each requirement has a three digit number prefixed by either " R " or " DR " indicating the status as follows:
The document includes several verbatim quotes from the <a href="../../09/XML-Protocol-Charter"> XP WG charter Charter </li> <li> Editor's note which provide context for the requirements. The quoted text is emphasized and prefixed with " Charter ".
Editorial notes are marked indicated with yellow background (may not appear in all media) and prefixed with " Ednote ".
The XP WG Charter 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 section 4 to be in-scope per the Charter.
Reviewers and readers should be familiar with the XP WG Charter because it provides the critical context for the requirements and any discussion of them.
Charter: 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.
Charter: 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.
Charter: 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.
Charter: 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.
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 organisational boundaries. The design centre for XP must include the interoperation of systems across organisational boundaries. The aim is to exploit Web philosophy and Web design principles in order to help foster widespread decentralized computing on the Web.
Requirements for simplicity and stability arise in the context of the specification documents and in the context of the protocol technologies being defined.<h3>
In this context, layering refers to both XP's support of XP modules (the layer(s) "above") as well as the capability of XP to define services required (the layer(s) "below") for implementation across a variety of underlying protocols
Charter: 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:
The XP specification must also define a processing model that defines what it means to properly process an XP 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 a an XP envelope.
Regarding the handling of binary data in particular, the XP WG Charter has the following to say:
Charter: 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. ebXML and RosettaNet) 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.
Charter: 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 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).
Because XML Protocol separates the message envelope from the transport binding, two types of intermediaries are possible; transport intermediaries and processing intermediaries.<h3>
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 XP envelope.
Processing intermediaries are full XML Protocol 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.
To enable the interposition of processing intermediaries into the message path, two core requirements must be met:
Charter: 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.
Charter: 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.
Charter: 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.
Charter: 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.
Charter: 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.
Charter: 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 IETF and not as part of this Working Group
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 XP bindings for such security protocols.
The XP specification may mandate the use of a specific character encoding, such as UTF-8, at some point in the future.
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.
Charter: 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 IETF and make an effort to leverage any work they are doing
Where possible, an attempt will be made to leverage any related work done by the IETF.
Duplicate (Does support mean must specify one or more mechanisms?. Lots of discussion of whether this is needed it not). Is this is a part of the core or not? The charter says that we should make this a low-level priority. It is not clear that we should actually do this. It is not fair to say that we have nailed it simply because of demonstrating that it can be done on top. Glossary: what is binary and what is the use cases. What are the ways that SOAP can do it? </p> </div> </dd> </dl> <h3> <a name="N1734"> 4.2 Compact Encoding and Compression Issues </a> </h3> <dl> <dt> <a name="z120"> DR120 </a> </dt> <dd class="charter"> Compact Encoding and Compression Issues: One of the guiding design goals of XML has been that "terseness in XML markup is of minimal importance." Meanwhile, XML is being applied in extremely bandwidth-sensitive environments such as wireless devices. While we recognize the importance of bandwidth optimizations, it is seen as being out of scope of this Working Group to investigate specific compression and encoding mechanisms of XML payloads. In particular, it is outside the scope of this Working Group to define an XML subset. </dd> </dl> <h3> <a name="N1753"> 4.3 Additional Transport Services </a> </h3> <dl> <dt> <a name="z121"> DR121 </a> </dt> <dd class="charter"> Additional Transport Services: Transport services are extremely important in order to actually deliver packages in an efficient and scalable manner. Many current XML messaging proposals use existing application layer protocols such as SMTP, HTTP and BEEP. The XML Protocol Working Group will initially focus on providing a (non-exclusive) mapping to HTTP. Other transports can be addressed if the WG has sufficient resources and time, but These are a low priority. </dd> <dt> <a name="z122"> DR122 </a> </dt> <dd class="charter"> 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. </dd> <dt> <a name="z123"> DR123 </a> </dt> <dd class="charter"> General transport issues were investigated requirements submitted by deleted text: 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 IETF and not as part of this Working Group. </dd> <dt> <a name="z025"> DR025 </a> </dt> <dd> Is multicast a requirement? <div class="issue"> <p class="prefix"> <a name="i.025.01"> </a> <b> Issue (i.025.01): </b> </p> <p> This is a duplicate. </p> </div> </dd> <dt> <a name="z022"> DR022 </a> </dt> <dd> Requirement that it should be able to run on top of directly TCP - get a port number (not HTTP on other port). <div class="issue"> <p class="prefix"> <a name="i.022.01"> </a> <b> Issue (i.022.01): </b> </p> <p> This first part is a duplicate and the port number bit needs discussion. </p> </div> </dd> <dt> <a name="z028"> DR028 </a> </dt> <dd> Multicast should be supported (not inventing multicast solutions) <div class="issue"> <p class="prefix"> <a name="i.028.01"> </a> <b> Issue (i.028.01): </b> </p> <p> Duplicate. </p> </div> </dd> </dl> <h3> <a name="N1840"> 4.4 Application Semantics </a> </h3> <dl> <dt> <a name="z124"> DR124 </a> </dt> <dd class="charter"> Application Semantics: The introduction mentioned several additional types of semantic that we expect would be required for common applications including transactions, security etc. Many of the existing XML based protocol proposals include clear application layer semantics that make them well suited for specific tasks including defining specific message exchange patterns, message integrity, user authentication etc. However, the purpose of the Working Group is to provide a framework that can support a vide variety of applications and application protocol semantics including the aforementioned. </dd> <dt> <a name="z125"> DR125 </a> </dt> <dd class="charter"> We do not expect the Working Group to actively take on defining application layer semantics except where such semantics are general enough to accommodate a large set of applications. In particular, it is anticipated that other initiatives including other W3C deleted text: Activities and potentially other Working Groups deleted text: within this Activity (if approved by the W3C Membership) will undertake the important work of defining application layer semantics that use the XML Protocol framework. These work efforts may take place at the same time as those of the Working Group. </dd> <dt> <a name="z006"> DR006 </a> </dt> <dd> Support uniquely identifying messages as entities, so that correlating related message (such as requests and responses) is possible over any transport. <div class="issue"> <p class="prefix"> <a name="i.006.01"> </a> <b> Issue (i.006.01): </b> </p> <p> The use of the word "entity" is confusing with the XML use of the term. </p> </div> </dd> <dt> <a name="z019"> DR019 </a> </dt> <dd> Support object references <div class="issue"> <p class="prefix"> <a name="i.019.01"> </a> <b> Issue (i.019.01): </b> </p> <p> Maybe split into targeting on the request and identifying the data in response. Define "object". One definition is that it is a "resource". This may be specific to a programming model and therefore be out of scope. This needs discussion. </p> </div> <div class="issue"> <p class="prefix"> <a name="i.019.02"> </a> <b> Issue (i.019.02): </b> </p> <p> Everything on the Web is a resource. SOAP has the notion of passing by a URI which has a specified lifetime. </p> </div> </dd> <dt> <a name="z027"> DR027 </a> </dt> <dd> There must be a way to deal with audit trails of the protocol flow. <div class="issue"> <p class="prefix"> <a name="i.027.01"> </a> <b> Issue (i.027.01): </b> </p> <p> Dominant duplicate. </p> </div> </dd> <dt> <a name="z031"> DR031 </a> </dt> <dd> Requirement for support for routing information to be carried. <div class="issue"> <p class="prefix"> <a name="i.031.01"> </a> <b> Issue (i.031.01): </b> </p> <p> Duplicate. </p> </div> </dd> <dt> <a name="z033"> DR033 </a> </dt> <dd> Requirement that doesn't preclude UI interactions but should not define that UI. <div class="issue"> <p class="prefix"> <a name="i.033.01"> </a> <b> Issue (i.033.01): </b> </p> <p> Do things put in XP should be human friendly or should it be possible to use more human friendly or allow interaction with human. </p> </div> </dd> <dt> <a name="z046"> DR046 </a> </dt> <dd> xml protocol should work well with popular security mechanisms. <div class="issue"> <p class="prefix"> <a name="i.046.01"> </a> <b> Issue (i.046.01): </b> Activities.<p> Popular ones
Ednote: These are deleted text: smime/ssl/digital signatures. </p> </div> <div class="issue"> <p class="prefix"> <a name="i.046.02"> </a> <b> Issue (i.046.02): </b> </p> <p> For example SSL, SMIME, DSIG. </p> </div> </dd> <dt> <a name="z051"> DR051 </a> </dt> <dd> A message must have a globally unique identifier. </dd> <dt> <a name="z058"> DR058 </a> </dt> <dd> Shall support multiple interaction patterns (e.g. request/response, RPC, point-to-point, publish/subscribe). </dd> <dt> <a name="z065"> DR065 </a> </dt> <dd> Must not preclude transaction support, discovery of service definitions and security. </dd> <dt> <a name="z069"> DR069 </a> </dt> <dd> Develop an XML-based messaging and remote procedure call system. </dd> </dl> <h3> <a name="N2006"> 4.5 Metadata Descriptions of Services </a> </h3> <dl> <dt> <a name="z126"> DR126 </a> </dt> <dd class="charter"> Metadata Descriptions of Services: An important feature of communicating in a distributed environment is the ability to discover and exchange information that describes how communication between peers can occur. </dd> <dt> <a name="z127"> DR127 </a> </dt> <dd class="charter"> verbatim received texts. The focus of the Working Group is generally seen as being the encapsulation and data representation aspect of a larger area of data exchange and processing. As such, we do not expect to distinguish between metadata and data, as we believe this is a choice of the application rather than of the data itself, and the act of communicating about how to communicate is itself communication. Therefore, service discovery and description will WG has not to be taken on by this Working Group. </dd> </dl> <h1> <a name="N2100"> 5. External Requirements </a> </h1> <p> The subsections contained within have been submitted from other W3C Working Groups and Activities. made any decisions regarding these requirements.<h2>
These are the requirements that the <a href="./"> XML Protocol XP WG has received from the (W3C Members only) XForms WG :
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.
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.
These are the requirements that the <a href="./"> XML Protocol XP WG has received from the <a href="../../../P3P/"> P3P WG :
Ed Note: These requirements have been placed here because it was not certain where they fit within the structure of this document. They will be deleted if left unclaimed </p> <dl> <dt> <a name="z048"> DR048 </a> </dt> <dd> What is the fundamental minimum business message that is necessary for business-level exchange? Or, what minimum level of messaging fundamentals are required for best-effort and guaranteed processing? Ednote: This is a the fundamental difference between component-level RPC glossary of terms expected to be defined and business-level messaging. </dd> <dt> <a name="z066"> DR066 </a> </dt> <dd> message content. </dd> <dt> <a name="z067"> DR067 </a> </dt> <dd> other interaction patterns. </dd> </dl> <h1> <a name="N2082"> 7 Glossary </a> </h1> used by the XP specification. Feedback is particularly welcome on this section.
For a description of fundamental Web concepts including resources and resource manifestations, see the " <a href="../../../1999/05/WCA-terms/#PRIMITIVE"> Web Characterization Terminology & Definitions Sheet " W3C Working Draft. deleted text: For many useful terms, see also the <a href="http://ntia.its.bldrdoc.gov/projects/t1glossary2000/t1g2k.html"> Proposed Telecom Glossary 2000 </a>.<h2>
While the XML Protocol itself is intended to be as simple and lightweight as possible, XML Protocol modules can be designed and composed to perform arbitrarily complex operations allowing the core protocol to remain simple.
The XML Protocol itself can be layered on top of a variety of transfer or application protocols that can help facilitate the transfer of XP Messages . Typical examples of protocols that XML Protocol might be layered on top of are HTTP and TCP. The exact rules and conventions for how to layer the XML Protocol on top of another protocol is defined by an XML Protocol Binding .
deleted text: <em> Note: Component oriented implementation models may take advantage of the layering model illustrated above to provide a component oriented interface to components driving specific deleted text: </em> deleted text: <em> XP modules </em> </a> <em>. . However, this is strictly an implementation choice for which XML Protocol has nothing to say. deleted text: </em>
The XML Protocol data encapsulation model describes how data XP blocks defined by XP modules can be carried within an XP message which is the fundamental unit of communication in the XML Protocol . The following diagram illustrates how an XP message is composed.
An XP message is composed of an XP envelope which contains an XP header and an XP body each of which can deleted text: each contain zero, one or more XP modules </a>. While an <a href="#g180"> XP envelope </a> by itself provides a minimum set of services, <a href="#g350"> XP modules </a> can provide an open-ended set of functions and services that can be composed within an <a href="#g170"> XP message blocks .
A collection or zero, zero or more XP modules blocks which may be intended for any XP receiver within the XP message path .
The XML Protocol message path model is defined in terms of XP senders and XP receivers who can generate and accept XP messages respectively. Behind each XP receiver is an XP processor that processes the message according to the rules of the XML Protocol.
A important part of the XML Protocol message path model is the concept of XP intermediaries . Intermediaries contain both an XP receivers receiver and an XP sender which allows them to forward a message on behalf of the previous sender.
Note: Especially in In some deleted text: b2b interactions, more complicated message path models are may be required to encapsulate the semantics of multi-party interactions like for example "fan-out" or "fan-in" models. Such models can be built using the basic XP message path model provided that the semantics of message "split" and "merge" are provided by higher layer semantics.
The relationship between an XP sender and an XP processor and an XP receiver and an XP processor respectively can be illustrated as follows:
This will become a Ednote: A list of commonly used terms that we often use but are not directly define as part of defined by the deleted text: XP WG.<h1> 9
Ednote: The XP WG is actively soliciting use cases that can be used to represent the expected range of XML Protocol's use (see section 3) . As described in the call for use cases which was sent to the public email@example.com mailing list, use cases should be sent to the firstname.lastname@example.org mailing list for consideration by the XP WG.
Ednote: All of the use cases listed below are under active consideration by the WG. They started out as requirements but were moved to this section when the WG decided they were better described as use cases.
The WG thanks all participants of the email@example.com mailing list ( archives ) for directly and indirectly contributing to this document.