XML Protocol WG DRAFT Requirements
Last Modified: $Date: 2000/11/03 21:40:08 $
- Latest revision
- This revision
- Previous revision
- Vidur Apparao, Netscape, email@example.com
Paul Cotton, Microsoft, firstname.lastname@example.org
David Ezell, Hewlett Packard, email@example.com
David Fallside, IBM, firstname.lastname@example.org
Oisin Hurley, IONA Technologies, email@example.com
John Ibbotson, IBM, firstname.lastname@example.org
R. Alexander Milowski, Lexica, LLC, <email@example.com>
Eric Newcomer, IONA Technologies, firstname.lastname@example.org
Henrik Frystyk Nielsen, Microsoft, <email@example.com>
Mark Nottingham, Akamai Technologies, firstname.lastname@example.org
This document specifies a set of DRAFT requirements for the XML Protocol
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.
- 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
- 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
The following terminology and typographical conventions have been used in
- "DR" means Draft Requirement
- "R" means Requirement
- Italics indicates a term taken directly from the charter .
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.
The subsections here are the same as the subsections of the in-scope
section of the charter except for two additional sections.
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
- 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
- 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.
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
- 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
- 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
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
- The XP specification MUST clearly identify conformance requirements in
a way that enables the conformance of an implementation of the
specification to be tested.
- 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
- 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
- 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
- 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
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
- 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 message.
- 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
- the possibility of extending the message by the addition of
payloads outside the independent XP envelope,
- the possibility of extending the message by the addition of XP
envelopes within the independent XP envelope,
- the possibility of extending the message by the addition of XP
headers within the independent and embedded XP envelopes.
In both cases above, the XP processor must fail in a standard and
- process all of the extensions in an XP envelope or fail,
- process a subset of the extensions in an XP envelope or fail.
- 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
- DR703 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
- 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.
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
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 they can not be addressed from within an XP
- XML Protocol must accommodate transport bindings that define transport
intermediary roles such as store-and-forward, proxies and gateways.
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
- 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
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
- 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
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.
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
Needs serious editing!!!
- [DR 002, DR 057, DR 070, DR 071, DR 073, DR 105] DR 600 Nothing in the
architecture should preclude running over a variety of protocols,
including at least standard internet ones such as: HTTP, Asynchronous
messaging, TCP, SMTP, message queuing [LIST TBD], 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 are a low
- [DR 006] DR 601 Support uniquely identifying messages as entities, so
that correlating related message (such as requests and responses) is
possible over any transport.
- [DR 008] DR 602 Support passing arbitrary content from third parties
(send digitally signed doc w/o touching data)
- [DR 016] DR 603 Support intermittently connected scenarios such as
mobile devices. This is extraordinarily important in the case where TCP
is converted to UDP for package transmission as bandwidth permits, such as
in the case of CDPD wireless connectivity.
- [DR 017] DR 604 Support messages where multiple transports along a
message path are allowed.
- [DR 021, DR 022, DR 121] DR 605 XP should be able to run on top of
various transport/transfer bindings Requirement that it should be able to
run on top of directly TCP -get a port number (not HTTP on other port).
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 are a low priority.
- [DR 030, DR 056] DR 606 Requirement for support of multiple message
exchange patterns (connection oriented and session oriented, async).
Enable bindings to be created to multiple protocols, especially http/s
(may consider requirements for bindings to smtp tcp file messaging).
- [DR 031] DR 607 Requirement for support for routing information to be
- [DR 046] DR 608 XML protocol should work well with popular security
- [DR 047] DR 609 Requirement restricted to UTF-8.
- [DR 049] DR 610 There must be a clear separation of messaging semantics
and transport issues or bindings such that the message creator need not
know how the message will be delivered to the intended recipient.
- [DR 050] DR 611 URI Tracker Use Case: You request to be notified when a
URI changes but you request via HTTP and want to be notified via SMTP
- [DR 072] DR 612 Must support a subset of HTTP that can be effectively
generated by a browser
- [DR 105] DR 613 Bindings to Transports: 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. For
coordination with the IETF, see below.
- [DR 122] DR 614 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.
- [DR 123] DR 615 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.
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
- The XML Protocol will contain a convention for representing calls and
replies between RPC (Remote Procedure Call) applications. The
conventions will include the following:
Where possible, an attempt will be made to leverage any related work
done by the IETF.
- Unique specification of the program or object and procedure or
method to be called based on URI syntax .
- Provisions for matching response messages to request messages for
cases in which matching is not provided by the underlying transport
- 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.
- 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
- 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
DR 119 - Direct Handling of Binary Data: 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.
DR 008 - Support passing arbitrary content from third
parties (send digitally signed doc w/o touching data) [other than the
mechanisms described under 3.5 Data
DR 040 - It is a requirement that binary data is
Do we need to support explicit binary data (or just base64 encoding is
fine). Absolute NO on one side, yes on other side. (open for discussion)
We should get requirements for binary binding.
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?
4.2 Compact Encoding and Compression Issues
DR 120 - 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.
4.3 Additional Transport Services
DR 121 - 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 are a low priority.
DR 122 - 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.
DR 123 - 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
DR 025 - Is multicast a requirement?
This is a duplicate.
DR 022 - Requirement that it should be able to run on top
of directly TCP - get a port number (not HTTP on other port).
This first part is a duplicate and the port number bit needs
DR 028 - Multicast should be supported (not inventing
4.4 Application Semantics
DR 124 - 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.
DR 125 - 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 Activities and potentially other Working Groups
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.
DR 006 - Support uniquely identifying messages as
entities, so that correlating related message (such as requests and
responses) is possible over any transport.
The use of the word "entity" is confusing with the XML use of the
DR 019 - Support object references
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
Everything on the Web is a resource. SOAP has the notion of passing by
a URI which has a specified lifetime.
DR 027 - There must be a way to deal with audit trails of
the protocol flow.
DR 031 - Requirement for support for routing information
to be carried.
DR 033 - Requirement that doesn't preclude UI interactions
but should not define that UI.
Do things put in XP should be human friendly or should it be possible
to use more human friendly or allow interaction with human.
DR 046 - xml protocol should work well with popular
Popular ones are smime/ssl/digital signatures.
For example SSL, SMIME, DSIG.
DR 051 - A message must have a globally unique
DR 058 - Shall support multiple interaction patterns (e.g.
request/response, RPC, point-to-point, publish/subscribe).
DR 065 - Must not preclude transaction support, discovery
of service definitions and security.
DR 069 - Develop an XML-based messaging and remote
procedure call system.
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.
DR 048 - 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? This is a the fundamental difference between component-level
RPC and business-level messaging.
Items which are out of scope.
The subsections contained within have been submitted from other W3C Working
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
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).
- binary data
- connection oriented
- envelope process model
- message path
- message pattern
- non-syntactic data
- protocol binding
- references (uris)
- resource and resource manifestation
- rpc convention (programming model)
- session oriented
- ultimate receiver
- wire format