XML Protocol WG DRAFT Requirements

Last Modified: $Date: 2000/11/03 21:40:08 $

Latest revision
This revision
Previous revision
Vidur Apparao, Netscape, vidur@netscape.com
Paul Cotton, Microsoft, pcotton@microsoft.com
David Ezell, Hewlett Packard, david_e3@verifone.com
David Fallside, IBM, fallside@us.ibm.com
Oisin Hurley, IONA Technologies, ohurley@iona.com
John Ibbotson, IBM, ibbotson@uk.ibm.com
R. Alexander Milowski, Lexica, LLC, <alex@milowski.com>
Eric Newcomer, IONA Technologies, eric.newcomer@iona.com
Henrik Frystyk Nielsen, Microsoft, <frystyk@microsoft.com>
Mark Nottingham, Akamai Technologies, mnot@akamai.com


This document specifies a set of DRAFT requirements for the XML Protocol specification.

Status of this Document

This represents the current status of the XML Protocol WG's work on requirements. It does not imply concensus at this point in time. The document will be updated or made obsolete by other documents at a later time. This is work in progress and does not imply endorsement by the W3C membership.

Table of Contents

1 Notations
2 Requirements on Requirements
3 In-Scope Requirements
3.1 General Requirements
3.2 Simplicity and Stability
3.3 Data Encapsulation and Evolvability
3.4 Intermediaries
3.5 Data Representation
3.6 Protocol Bindings
3.7 Convention for RPC
4 Out-of-Scope Requirements
4.1 Direct Handling of Binary Data
4.2 Compact Encoding and Compression Issues
4.3 Additional Transport Services
4.4 Application Semantics
4.5 Metadata Descriptions of Services
5 External Requirements
5.1 XForms Requirements
6 Other Requirements
7 Glossary

1 Notations

The following terminology and typographical conventions have been used in this document:

2 Requirements on Requirements

The XML Protocol Requirements must include usage scenarios that describe how XML Protocol is used in various environments. The set of usage scenarios must represent the expected range of XML Protocol'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 XML Protocol.

3 In-Scope Requirements

The subsections here are the same as the subsections of the in-scope section of the charter except for two additional sections.

3.1 General Requirements

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.

The specification will make reasonable efforts to support a broad range programming models suitable for the applications intended for XP.
The specification developed by the Working Group may not preclude any particular protocol binding between communicating peers.
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 use cases.
The Working Group will coordinate with W3C XML Activities through the XML Coordination Group and shall use available XML technologies whenever possible. If there are cases where this is not possible, the reasons must be documented thoroughly.
The specification developed by the Working Group 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.
The specification must be suitable for use between communicating parties that do not have a priori knowledge of each other.
The specification must focus on the encapsulation and representation of data being transferred between peers. A peer is a party capable of generating and/or accepting an XP protocol envelope.

3.2 Simplicity and Stability

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.

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.

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 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 is aim to exploit web philosophy and web design principles to enable widespread distributed computing on the web.

XP MUST be suitable for widespread use across organisational boundaries in support of the application use cases supplied elsewhere in this document. This suitability requirement implies simplicity in the language of the XP specification, which itself describes a technology that is simple to understand and to implement *correctly* [refs DR301, DR301a, DR303]. 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.
XP is a foundation protocol and its definition MUST be stable over time. Express use of modularity and layering in its design will help assure its usability and longevity by enabling subsequent extension within a framework that leaves the foundation intact. [DR300, DR302 and DR305 relate to stability]

Requirements for simplicity (and stability?) arise in the context of the specification documents and in the context of the protocol technologies being defined.

3.2.1 The XML Protocol Specification(s) Documents

DR300 (absorbs old DRs: DR023, DR0053, DR088)
The requirements that XP be modular, extensible, layered and transport independent (or neutral) [cross refs to those specific requirements] imply that there is an architectural design model behind XP. This architecture and the extensibility framework MUST be explicitly defined.

In this context, layering refers to both XP's support of applications layered on top as well as the capability of XP to be layered on top of (or bound to) a variety of underlying protocols.
The XML protocol specification(s) MUST be clear and easy to understand and testing for conformance must be straightforward. This clarity implies that considerable editorial effort will be required in the structuring of the narrative through both outline/overview and normative reference material.
The XP specification MUST clearly identify conformance requirements in a way that enables the conformance of an implementation of the specification to be tested.

3.2.2 The XML Protocol Technology(ies)

DR302 (Absorbs old DR's: DR107)
The XML Protocol MUST support modular extensibility between communicating parties in a way that allows for decentralized extensibility without prior agreement. The WG must demonstrate through use cases that the solution supports decentralized extensibility in a modular and layered manner.

To date the web has been enormously successful because it has enabled the creators of web services to evolve and adapt the interfaces they provide to human clients of the web. A goal of XP is to achieve a similar levels of evolvability, extensibility and adaptability for programmatic interfaces between web service clients and web service providers.
DR303 (Absorbs old DRs: DR108)
The XML protocol MUST be easy to understand, use, extend and implement. This implies articulation of the concepts embodied in the protocol; modularity around those concepts so that optional features may be skipped if not relevant to a particular application of the protocol; an extensions framework that ensures extensions to the protocol are themselves modular. Modular specification should also provide a pattern for modular implementation.
The XML protocol MUST not preclude the creation of simple applications. Simple applications are those with simple message exchange patterns, either one-way or simple, synchronous, two-way request response interactions. The financial and/or social consequences of a failure ensure the integrity of a message or the complete failure to deliver a message in the context of a simple application is negligible.
DR305 (Absorbs old DRs: DR003)
The XML Protocol SHOULD provide functionality to enable the creation of complex applications. As the financial and/or social consequences of a failure increase, the need to ensure message integrity and privacy, the need to be aware of delivery semantics, and the need to support more complex exchange patterns for long-lived conversations (sessions) and transactional semantics also increase. The XML protocol SHOULD provide facilities (possibly optional standardised header and/or trailer elements) to encourage a common approach to the provision of facilities such as: authentication, encryption, reliable delivery, sessions and transactions.
DR306 (Absorbs old DRs: DR090)
The XML Protocol and applications of the XML Protocol MUST/SHOULD be easy to deploy - especially in systems already supporting XML technologies like XML namespaces and XML schemas

The ease with which XP applications can be deployed will be crucial to success of XP. The design of the protocol architecture must be sensitive to the practicalities of deployment and to the issue arising in the full spectrum of deployment environments ranging from resource constrained embedded devices (appliances) through to high throughput service engines.

3.3 Data Encapsulation and Evolvability

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:

DR700 Requirement for Extensibility
The XP specification must define standard mechanisms for extending an XP message. The form of these mechanisms must deal with To manage the mechanisms, the XP specification must define a set of directives which will require an XP processor to In both cases above, the XP processor must fail in a standard and predictable fashion.
DR701 Requirement for Encapsulation
The XP 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 . The specification must also define a mechanism to support the referencing of external payloads which are carried outside the envelope.
DR702 Requirement for Evolution
The XP specification must define the concept of protocol evolution and define a mechanism or mechanisms for establishing and recognizing XP versions. The specification must define the concepts of backwards compatible and backwards incompatible evolution and specify mechanisms and techniques to establish compatibility between XP versions.
DR703 Requirement for Encapsulation of Status Information
The XP specification must define a mechanism or mechanisms to allow the transfer of status information within an XP message without resort to use of XP fault messages or dependence on any particular interaction model.
DR704 Requirement for Vocabularies
The XP specification must define a list of acceptable syntax elements or vocabulary for the XP envelope and for any defined extension mechanism. The vocabulary may contain optional syntax elements and must be identified using an XML Namespace.

3.4 Intermediaries

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).

Intermediaries are essential parts of building distributed systems that scale on the Web. As a result, XML Protocol must support intermediaries.

Because XML Protocol separates the message envelope from the transport binding, two types of intermediaries are possible; transport intermediaries and processing intermediaries.

3.4.1 Transport Intermediaries

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 they can not be addressed from within an XP envelope.

XML Protocol must accommodate transport bindings that define transport intermediary roles such as store-and-forward, proxies and gateways.

3.4.2 Processing Intermediaries

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:

Targeting - XML Protocol must define mechanisms to enable determination of which message components are eligible for processing by a particular processing intermediary. Message components must be able to be targeted at one or more processing intermediaries.
Reporting - XML Protocol must enable the generation of status and/or error messages by processing intermediaries, and propagation and proper identification of status and/or error messages through processing intermediaries.
XML Protocol must enable processing intermediaries to locate and process the portions of messages intended for them without reading or processing the entire message. This allows them to operate efficiently.

To assure scalability and functionality, XML Protocol must also accommodate, but not define, these processing intermediary mechanisms;

Routing - in-message dictation of a complete or partial path through processing intermediaries
Tracking - enabling message recipients to determine a message's path through preceding intermediates
Caching - defining mechanisms to allow intermediates to reuse messages or parts of messages
Quality of Service - defining required and requested service levels in messages

3.5 Data Representation

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.

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.

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.

The XML Protocol data encapsulation and data representation mechanisms must be orthogonal.
The XML Protocol data representation must support using XML Schema simple and complex types.
The XML Protocol 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.
Data serialized according to the XML Protocol data representation may contain references to data outside the serialization. These references must be Uniform Resource Identifiers (URIs).
The XML Protocol data representation must be able to encode arrays which may be nested.

3.6 Protocol Bindings

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.

Needs serious editing!!!

3.7 Convention for RPC

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

The XML Protocol will contain a convention for representing calls and replies between RPC (Remote Procedure Call) applications. The conventions will include the following:
  1. Unique specification of the program or object and procedure or method to be called based on URI syntax [1].
  2. Provisions for matching response messages to request messages for cases in which matching is not provided by the underlying transport protocol.
  3. The ability to specify the parameters to a call in a request message and the results of a call in a reply messages.
  4. Provisions for specifying errors in a reply message.
Where possible, an attempt will be made to leverage any related work done by the IETF.
The RPC conventions within the XML Protocol will use the Data Representation schemes defined in section 3.5 to represent parameters to a call in the request message and results of the call in the reply message. There will be straightforward mappings of the data types used to a wide variety of widely deployed programming languages and object systems.
The XML Protocol will allow applications to include custom encodings for data types used for parameters and results in RPC messages. Mechanisms for automatically binding data represented in RPC messages to native constructs in a programming language will not be precluded.
The XML Protocol will guarantee that RPC messages that encode parameters and results using the default encoding for the base set of data types will be valid for any conformant binding of the RPC conventions. "Valid" in this context means that the semantics of the call should remain identical, irrespective of the programming language or object system used by the caller or receiver.

4 Out-of-Scope Requirements

The subsections contained within are the same as the subsections of the out-of-scope section of the charter.

4.1 Direct Handling of Binary Data

4.2 Compact Encoding and Compression Issues

4.3 Additional Transport Services

4.4 Application Semantics

4.5 Metadata Descriptions of Services

6 Other Requirements


These requirements have been placed here because it was not certain where they fit within the structure of this document.

5. External Requirements

The subsections contained within have been submitted from other W3C Working Groups.

5.1 XForms Requirements

Sent to XP WG mailing list:

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.


  1. 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.
  2. 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.
  3. 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).

7 Glossary


Issue (g.001):

Need Definition.


Issue (g.002):

Need Definition.

binary data

Issue (g.003):

Need Definition.


Issue (g.004):

Need Definition.


Issue (g.005):

Need Definition.

connection oriented

Issue (g.006):

Need Definition.


Issue (g.007):

Need Definition.

envelope process model

Issue (g.008):

Need Definition.


Issue (g.009):

Need Definition.


Issue (g.010):

Need Definition.


Issue (g.011):

Need Definition.


Issue (g.012):

Need Definition.


Issue (g.013):

Need Definition.

message path

Issue (g.014):

Need Definition.

message pattern

Issue (g.015):

Need Definition.


Issue (g.016):

Need Definition.

non-syntactic data

Issue (g.017):

Need Definition.


Issue (g.018):

Need Definition.


Issue (g.019):

Need Definition.

protocol binding

Issue (g.020):

Need Definition.


Issue (g.021):

Need Definition.

references (uris)

Issue (g.022):

Need Definition.


Issue (g.023):

Need Definition.


Issue (g.024):

Need Definition.

resource and resource manifestation

Issue (g.025):

Need Definition.

rpc convention (programming model)

Issue (g.026):

Need Definition.


Issue (g.027):

Need Definition.


Issue (g.028):

Need Definition.

session oriented

Issue (g.029):

Need Definition.


Issue (g.030):

Need Definition.


Issue (g.031):

Need Definition.


Issue (g.032):

Need Definition.

ultimate receiver

Issue (g.033):

Need Definition.

wire format

Issue (g.034):

Need Definition.

A Acknowledgments

B References

  1. XML Protocol Working Group Charter