XML Protocol Requirements
W3C Working Draft 19 December 2000
- This version:
- Latest version:
- Vidur Apparao, Netscape, firstname.lastname@example.org
Alex Ceponkus, Bowstreet, email@example.com
Paul Cotton, Microsoft, firstname.lastname@example.org
David Ezell, Hewlett Packard, email@example.com
David Fallside, IBM, firstname.lastname@example.org
Martin Gudgin, DevelopMentor, email@example.com
Oisin Hurley, IONA Technologies, firstname.lastname@example.org
John Ibbotson, IBM, email@example.com
R. Alexander Milowski, Lexica, LLC, firstname.lastname@example.org
Kevin Mitchell, XMLSolutions, email@example.com
Jean-Jacques Moreau, Canon, firstname.lastname@example.org
Eric Newcomer, IONA Technologies, email@example.com
Henrik Frystyk Nielsen, Microsoft, firstname.lastname@example.org
Mark Nottingham, Akamai Technologies, email@example.com
Waqar Sadiq, Vitria Technology Inc., firstname.lastname@example.org
Stuart Williams, Hewlett Packard, email@example.com
Amr Yassin, Philips Research, firstname.lastname@example.org
©2000 W3C® (MIT, INRIA,
Keio), All Rights Reserved. W3C liability,
use and software
licensing rules apply.
This document describes the XML Protocol Working Group's requirements for
the XML Protocol specification.
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.
This is the first W3C Working Draft of the XML Protocol (XP) requirements
It is a chartered deliverable of the XML Protocol Working Group (WG),
which is part of the XML Protocol Activity.
Although the Working Group agreed to request publication of this document, this document
does not necessarily represent consensus within the Working Group about XML Protocol requirements. The previous Working Group draft was the 7 December 2000 revision.
Discussion of this document takes place on the public <email@example.com> mailing list (Archives)
per the email
communication rules in the XP Working Group Charter.
This is a public W3C Working Draft for review by W3C members and other
interested parties. It is a draft document and may be updated, replaced, or
obsoleted by other documents at any time. It is inappropriate to use W3C
Working Drafts as reference material or to cite them as other than "work in
progress". A list of all W3C technical reports can be found at http://www.w3.org/TR/.
- 1 Notations
- 2 Relationship to WG Charter
- 3 Requirements on Requirements
- 4 Requirements
- 4.1 General Requirements (5xx)
- 4.2 Simplicity and Stability (3xx)
- 4.3 Data Encapsulation and Evolvability
- 4.4 Intermediaries (8xx)
- 4.5 Data Representation (4xx)
- 4.6 Protocol Bindings (6xx)
- 4.7 Convention for RPC (2xx)
- 5 External Requirements
- 5.1 XForms Requirements
- 5.2 P3P Requirements
- 6 Glossary
- 6.1 General Protocol Concepts
- 6.2 Data Encapsulation Concepts
- 6.3 Message Sender and Receiver Concepts
- 6.4 Data Representation Concepts
- 7 Other Terms
- 8 Use Cases
- A. Acknowledgements
- B. References
The following terminology and typographical conventions have been used in
Each requirement has a three digit number prefixed by either
"R" or "DR" indicating the status as
- A "DRnnn" notation indicates a requirement that the WG
is actively considering (has not reached
rough consensus within the WG)
- An "Rnnn" notation indicates a requirement that the WG
is not actively considering at present (has reached
rough consensus within the WG)
The document includes several verbatim quotes from the XP WG Charter which provide context
for the requirements. The quoted text is emphasized
and prefixed with "Charter".
Editorial notes are indicated with yellow
background (may not appear in all media) and prefixed with "Ednote".
2 Relationship to WG Charter
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.
3 Requirements on Requirements
- The XML Protocol Requirements must include usage
scenarios that describe how XML Protocol is used in various
environments (see section 8). 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.
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.
- The specification will make reasonable efforts to support (but not
define) a broad range of programming models suitable for the
applications intended for XP.
- The specification will make reasonable efforts to support (but not
define) a broad range of protocol bindings between communicating peers
(see also section 4.6).
- 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
- 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
- The specification must be suitable for use between communicating
parties that do not have a priori knowledge of each
- The specification must focus on the encapsulation and representation
of data being transferred between parties capable of generating and/or
accepting an XP protocol envelope.
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
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.
- XP must be suitable for widespread use across organizational
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 (see also R301, R301a).
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.
- Since XP 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. (R300, R302 and DR305 relate to
Requirements for simplicity and stability arise in the context of the
specification documents and in the context of the protocol technologies being
- R300 (absorbs old DRs: DR023, DR0053, DR088)
The requirements that XP support the use of layering and be
modular, extensible, and transport independent imply that there is an
architectural design model behind XP. This architecture and the
extensibility framework must be explicitly defined (R308 references modularity, R302
and R700 series reference extensibility, R502 and R600 reference transport
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
- The XML protocol 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.
- The XP specification must clearly identify conformance requirements in
a way that enables the conformance of an implementation of the
specification to be tested (see also the W3C Conformance
- R302 (Absorbs old DR's: DR107)
- The XML Protocol must support extensibility of vocabulary 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 adapt the user interfaces they provide to
human users of the web. A goal of XP is to achieve similar levels of
evolvability, extensibility and adaptability for interfaces between web
- The XML protocol 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
- DR305 (Absorbs old DRs: DR003) Ednote: Under consideration. Owner: David Ezell
- The XML protocol must provide facilities that encourage a common
approach for providing features such as authentication,
encryption,payment, reliable delivery, sessions and transactions. Such
facilities might include optional standardized header and/or trailer
elements. These facilities should encourage "best-practice" in
implementing the required features.
- R306 (Absorbs old DRs: DR090)
- The XML Protocol and applications of the XML Protocol must 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
the success of XP. 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.
- DR309 Ednote: Pending proposal.
Owner: David Ezell
- In cases where the contract between entities is well known, the use of
XP as a protocol to fulfill those application contracts should allow
processing without requiring a complex XML application infrastructure
provided the documents exchanged are well-formed and within the tenets
of the XML Infoset.
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:
- They are or can be orthogonal to other extensions.
- They can be deployed automatically and dynamically
across the Web with no prior coordination and no central authority.
- The sender can require that the recipient either obeys
the semantics defined by an extension or aborts the processing of the
- R701a 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.
- R701b Requirement for Encapsulation
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 an XP envelope.
- R700a Requirement for
Extensibility Ednote: Pending change. Owner: Oisin
- The XP specification must define a mechanism or mechanisms that allow
applications to submit application-specific content or information for
delivery by XP. In forming the standard for the mechanisms, the XP
specification may consider support for:
- carrying application specific payloads inside the XP
- referring to application specific payloads outside the XP
- carrying nested XP envelopes as application specific data within
the XP envelope,
- referring to XP envelopes as application specific data outside the
Regarding the handling of binary data in particular, the XP WG Charter has the following
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.
- R700b Requirement for Extensibility
- To manage the mechanisms, the XP specification must define a set of
directives which will unambiguously indicate to an XP processor which
extensions are optional and which are mandatory so that it can:
- process all of the extensions in an XP envelope or fail,
- process a subset of the extensions in an XP envelope or fail.
- R700c Requirement for Extensibility
- In both cases above, the XP processor must fail in a standard and
- R702 Requirement for Evolution
- The XP specification must define the concept of protocol evolution and
define a mechanism or mechanisms for identifying XP revisions. This
mechanism or mechanisms must ensure that an XP processor, by simple
inspection of an XP 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
- R703a Requirement for Encapsulation of Error
- The XP specification must define a means to convey error information
as a fault. The capability of XP carrying a fault message must not
depend on any particular protocol binding.
- R703b Requirement for Encapsulation of Status
- 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
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.
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
- XML Protocol must not preclude the use of transport bindings that
define transport intermediary roles such as store-and-forward, proxy and
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.
- XML Protocol must define and accommodate processing
To enable the interposition of processing intermediaries into the message
path, two core requirements must be met:
- Targeting - XML Protocol must define mechanisms that allow XP
processors, including intermediaries, to identify XP blocks which they
are eligible to process.
- Reporting - XML Protocol 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
- XML Protocol must also enable processing intermediaries to locate and
process XP blocks intended for them without processing the entire
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.
- 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.
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
- The XP 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 XP 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 XP
specification will be transport neutral.
- The XP specification must consider the scenario where an XP 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 XP message without information loss
from the XP message content.
- The XML Protocol binding mechanism should not preclude the possibility
of constructing bindings to protocols that provide a security mechanism.
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.
- The XP specification must provide a normative description of the
default binding of XP to HTTP. 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.
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
- The XML Protocol must contain a convention for representing calls and
replies between RPC (Remote Procedure Call) applications and services.
The conventions must include the following:
- Complete and unique identification, by means of URI syntax, of the
program, service or object and procedure or method to be
- Enable support for matching response messages to request messages
for cases in which matching is not provided by the underlying
- The ability to specify the parameters to a call in a request
message and the results of a call in a reply messages.
- Provisions for specifying errors in a reply message (see also 703a and 703b)
Where possible, an attempt will be made to leverage any related work
done by the IETF.
- The RPC conventions within the XML Protocol should use the Data
Representation model discussed in section 4.5 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.
- The XML Protocol should allow applications to include custom encodings
for data types used for parameters and results in RPC messages.
These are requirements submitted by other W3C Working Groups and
Ednote: These are the verbatim received texts. The WG has
not made any decisions regarding these requirements.
These are the requirements that the XP WG has received
from the (W3C Members only) XForms
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
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
- 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
- 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.
- 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).
These are the requirements that the XP WG has received
from the P3P WG:
Ednote: This is a glossary of terms expected to be defined
and used by the XP specification. Feedback is particularly welcome on this
For a description of fundamental Web concepts including resources and
resource manifestations, see the "Web Characterization Terminology
& Definitions Sheet" W3C Working Draft.
The XML Protocol is a framework which can accommodate an
open-ended set of XML Protocol modules defining a large
variety of functions and services. Typical functions and services defined by
XML Protocol modules can range from generic mechanisms for handling security,
caching, routing, and eventing to specific functions like submitting a
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
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.
Figure 1 XML Protocol Layering
Component oriented implementation models may take advantage of the layering
model illustrated above to provide a component oriented interface to
components driving specific XP modules. However, this is
strictly an implementation choice for which XML Protocol has nothing to
- XML Protocol (XP)
- The formal set of conventions governing the format and processing rules of an XP message
and basic control of interaction among applications generating and accepting XP
messages for the purpose of exchanging information along an XP message path.
- XP block
- A syntactic construct or structure used to delimit data that logically
constitutes a single computational unit as seen by an XP
- XP handler
- An abstraction for the processing and/or logic required to implement a
feature or function typically through the transmission or exchange of XP
- XP module
- Consists of an XP block and the associated XP handler. Services
defined by XP modules can range from generic mechanisms for handling
security, caching, routing, and eventing to specific functions like
submitting a purchase order.
- XP binding
- The formal set of rules for carrying an XP message within or on top of
another protocol for the purpose of transmission. Typical XP bindings
include carrying an XP message within an HTTP message, or on top of
The XML Protocol data encapsulation model describes how 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.
Figure 2 Encapsulation model
illustrating the parts of an XP message
An XP message is composed of an XP
envelope which contains an XP header and an XP body each of which can contain zero, one or more XP blocks.
- XP message
- The basic unit of communication within the XML
- XP processor
- An XP Processor processes an XP message according
to the formal set of conventions defined by the XML
Protocol and generates an XP fault if the
conventions are not followed. Insufficient or wrong data carried in an
XP block can cause an XP processor to generate a
fault (see also XP receiver and XP
- XP envelope
- The outermost syntactical construct or structure of an XP message defined by XML Protocol
within which all other syntactical elements of the message are
- XP header
A collection or zero or more XP blocks which
may be intended for any XP receiver within the XP
- XP body
- A collection or zero, or more XP blocks intended
for the ultimate XP receiver within the XP message path.
- XP fault
- A special XP block which contains fault
information generated by an XP processor.
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 receiver and an XP sender which allows
them to forward a message on behalf of the previous sender.
Figure 3 Illustration of XP message path
Note: In some interactions, more complicated message path models 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.
- XP sender
- An application that can generate an XP message and perform an XP
binding to a specific protocol for the purpose of transmitting the
- XP receiver
- An application that can accept an incoming XP message transmitted using some XP
binding, extract the message from the XP binding
and pass the message to an XP processor.
- XP message path
- The set of XP senders and XP
receivers through which a single XP message
passes. This includes the initial XP sender, zero or
more XP intermediaries, and the ultimate XP receiver.
- initial XP sender
- The XP sender that originates an XP message as the starting point of an XP message path.
- XP intermediary
- An application that can act as both an XP sender
and an XP receiver with the purpose of forwarding an
XP message along an XP message
- ultimate XP receiver
- The XP receiver that the initial
sender specifies as the final destination of the XP
message within an XP message path. An XP message may not reach the ultimate recipient because
of an XP fault generated by an XP
processor along the XP message path.
The relationship between an XP sender and an XP processor and an XP receiver and an XP processor respectively can be illustrated as follows:
Figure 4 Abstract relationship between
XP sender, XP receiver and XP processor
- XP data model
- A set of abstract constructs that can be used to describe common data
types and link relationships in data defined by XP
- XP data encoding
- The syntactic representation of data described by the XP data model within one or more XP blocks in an XP message.
- binary data
- Data which is represented using a non-XML based, non-human readable
Ednote: A list of commonly used terms that are not defined
by the WG.
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 firstname.lastname@example.org mailing list, use
cases should be sent to the email@example.com 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.
- Routing - in-message dictation of a complete or partial path through
- 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
The WG thanks all participants of the firstname.lastname@example.org mailing list (archives) for
directly and indirectly contributing to this document.
- XML Protocol
- XML Protocol Working
- XML Protocol
Working Group Charter
Telecom Glossary 2000