XML Protocol WG DRAFT Requirements
Last Modified: $Date: 2000/12/07 17:57:06 $
- Latest revision
- http://www.w3.org/2000/xp/Group/xp-reqs
- This revision
- http://www.w3.org/2000/xp/Group/xp-reqs-03
- Previous revisions
- http://www.w3.org/2000/xp/Group/xp-reqs-02
http://www.w3.org/2000/xp/Group/xp-reqs-01
- http://www.w3.org/2000/xp/Group/requirements
- Editors:
- Vidur Apparao, Netscape, vidur@netscape.com
Alex Ceponkus, Bowstreet, aceponkus@bowstreet.com
Paul Cotton, Microsoft, pcotton@microsoft.com
David Ezell, Hewlett Packard, david_e3@verifone.com
David Fallside, IBM, fallside@us.ibm.com
Martin Gudgin, DevelopMentor, marting@develop.com
Oisin Hurley, IONA Technologies, ohurley@iona.com
John Ibbotson, IBM, ibbotson@uk.ibm.com
R. Alexander Milowski, Lexica, LLC, alex@milowski.com
Kevin Mitchell, XMLSolutions, kevin.mitchell@xmls.com
Jean-Jacques Moreau, Canon, moreau@crf.canon.fr
Eric Newcomer, IONA Technologies, eric.newcomer@iona.com
Henrik Frystyk Nielsen, Microsoft, frystyk@microsoft.com
Mark Nottingham, Akamai Technologies, mnot@akamai.com
Waqar Sadiq, Vitria Technology Inc., wsadiq@vitria.com
Stuart Williams, Hewlett Packard, skw@hplb.hpl.hp.com
Amr Yassin, Philips Research, amr.f.yassin@philips.com
This document specifies a set of DRAFT requirements for the XML Protocol
specification.
This document represents the current status and thinking of the XML Protocol WG's work on requirements and does not imply
concensus within the WG. The document will be updated in the near future as
the thinking evolves.
This document is not an official W3C Technical Report. It is to be
considered work in progress and does not imply endorsement by the W3C
membership nor by the XML Protocol WG. A future revision of this document will
become an official W3C Technical Report as a deliverable of the XML Protocol
WG in accordance with the WG
Charter.
Discussion of this document will take place on the public <xml-dist-app@w3.org> mailing list (Archives) as
indicated by the email
communiation rules provided in the WG charter.
The current organization of this document follows closely the WG charter which has a section on in scope requirements and out of scope requirements.
The exact organization of which items are in each section may change provided
that the work is within the WG
charter. The WG charter
provides a background for this organization and it is recommended that the
reader reads the charter before reading this document. The organization may
change in a later revision.
The WG has so far concentrated on the in scope requirements
and little efforts have been put into editing the current out of scope requirements. Please note the guidance given in
the section on Notations used in this document for more
details about the layout.
- 1 Notations
- 2 Requirements on Requirements
- 3 In-Scope Requirements
- 3.1 General Requirements (5xx)
- 3.2 Simplicity and Stability (3xx)
- 3.3 Data Encapsulation and Evolvability
(7xx)
- 3.4 Intermediaries (8xx)
- 3.5 Data Representation (4xx)
- 3.6 Protocol Bindings (6xx)
- 3.7 Convention for RPC (2xx)
- 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
- 5.2 P3P Requirements
- 6 Other Requirements
- 7 Glossary
- 7.1 General Protocol Concepts
- 7.2 Data Encapsulation Concepts
- 7.3 Message Sender and Receiver Concepts
- 7.4 Data Representation Concepts
- 8 Other Terms
- 9 Use Cases
The following terminology and typographical conventions have been used in
this document:
- The "Rnnn" notation indicates that the status is considered to be a
requirement (has reached rough concensus within
the WG)
- The "DRnnn" notation indicates that the contents is still under
consideration (has not reached rough concensus
within the WG)
- Italics indicates a paragraph taken
directly from the WG
charter
- Editor's note are marked with yellow
background
2 Requirements on Requirements
- R900
- 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.
- R500
- The specification will make reasonable efforts to support (but not
define) a broad range of programming models suitable for the
applications intended for XP.
- R501
- The specification will make reasonable efforts to support (but not
define) a broad range of protocol bindings between communicating peers
(see also section 3.6).
- R502
- 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.
- R503
- 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.
- R504
- 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.
- R505
- The specification must be suitable for use between communicating
parties that do not have a priori knowledge of each other.
- R506
- 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.
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 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.
- R307
- 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 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.
- R308
- 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. (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.
- 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 (DR308 references modularity, DR302
and DR700 reference extensibility, DR502 and DR800 reference transport
neutrality).
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
- R301
- 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.
- R301a
- 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
requirements).
- 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 a similar levels of
evolvability, extensibility and adaptability for interfaces between web
services.
- DR303 (Absorbs old DRs: DR108)
- The XML protocol should be easy to understand, use, extend and
implement.
- R304
- 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
to use.
- DR305 (Absorbs old DRs: DR003)
- 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
- 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.
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
message.
- 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 a XP envelope.
- R700a Requirement for Extensibility
- 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
envelope,
- referring to application specific payloads outside the XP
envelope,
- carrying nested XP envelopes as application specific data within
the XP envelope,
- referring to XP envelopes as application specific data outside the
XP envelope
- 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
predictable fashion.
- DR702 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
evolution. Furthermore, the XP envelope must support both optional and
mandatory extensibility of protocols build using the XP envelope.
- R703a Requirement for Encapsulation of Status
Information
- 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
model.
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
envelope.
- R803
- XML Protocol must not preclude the use of transport bindings that
define transport intermediary roles such as store-and-forward, proxy and
gateway.
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.
- DR811
- XML Protocol must define and accommodate processing
intermediaries.
To enable the interposition of processing intermediaries into the message
path, two core requirements must be met:
- R806
- Targeting - XML Protocol must define mechanisms that allow XP
processors, including intermediaries, to identify XP Modules which they
are eligible to process.
- R808
- 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
intermediaries.
- R802
- XML Protocol must also enable processing intermediaries to locate and
process XP modules intended for them without processing the entire
message.
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.
- R400
- The XML Protocol data encapsulation and data representation mechanisms
must be orthogonal.
- R401
- The XML Protocol data representation must support using XML Schema
simple and complex types.
- R402
- 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.
- R403
- 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).
- R404
- 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 Group.
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.
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
- R600
- 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.
- R604
- 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.
- R608
- 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.
- R609
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.
- R612
- 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.
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
- R200
- 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
called.
- Enable support for matching response messages to request messages
for cases in which matching is not provided by the underlying
protocol binding.
- 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.
- R201
- The RPC conventions within the XML Protocol should use the Data
Representation model discussed in section 3.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.
- R202
- The XML Protocol should allow applications to include custom encodings
for data types used for parameters and results in RPC messages.
The subsections contained within are the same as the subsections of the
out-of-scope section of the charter.
- DR119
- 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.
- DR008
- Support passing arbitrary content from third parties (send digitally
signed doc w/o touching data) [other than the mechanisms described under
3.5 Data Representation].
- DR040
- It is a requirement that binary data is supported.
Issue (i.040.01):
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.
Issue (i.040.02):
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?
- DR120
- 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.
- DR121
- 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.
- DR122
- 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.
- DR123
- 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.
- DR025
- Is multicast a requirement?
Issue (i.025.01):
This is a duplicate.
- DR022
- Requirement that it should be able to run on top of directly TCP - get
a port number (not HTTP on other port).
Issue (i.022.01):
This first part is a duplicate and the port number bit needs
discussion.
- DR028
- Multicast should be supported (not inventing multicast solutions)
Issue (i.028.01):
Duplicate.
- DR124
- 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.
- DR125
- 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.
- DR006
- Support uniquely identifying messages as entities, so that correlating
related message (such as requests and responses) is possible over any
transport.
Issue (i.006.01):
The use of the word "entity" is confusing with the XML use of the
term.
- DR019
- Support object references
Issue (i.019.01):
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.
Issue (i.019.02):
Everything on the Web is a resource. SOAP has the notion of passing
by a URI which has a specified lifetime.
- DR027
- There must be a way to deal with audit trails of the protocol flow.
Issue (i.027.01):
Dominant duplicate.
- DR031
- Requirement for support for routing information to be carried.
Issue (i.031.01):
Duplicate.
- DR033
- Requirement that doesn't preclude UI interactions but should not
define that UI.
Issue (i.033.01):
Do things put in XP should be human friendly or should it be possible
to use more human friendly or allow interaction with human.
- DR046
- xml protocol should work well with popular security mechanisms.
Issue (i.046.01):
Popular ones are smime/ssl/digital signatures.
Issue (i.046.02):
For example SSL, SMIME, DSIG.
- DR051
- A message must have a globally unique identifier.
- DR058
- Shall support multiple interaction patterns (e.g. request/response,
RPC, point-to-point, publish/subscribe).
- DR065
- Must not preclude transaction support, discovery of service
definitions and security.
- DR069
- Develop an XML-based messaging and remote procedure call system.
- DR126
- 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.
- DR127
- 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 not to be taken on by
this Working Group.
The subsections contained within have been submitted from other W3C Working
Groups and Activities.
These are the requirements that the XML Protocol WG has
received from the 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.
Requirements:
- 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.
- 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 XML Protocol WG has
received from the P3P WG:
- It must be possible to associate a P3P Privacy Policy with an XP
message.
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
- DR048
- 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.
- DR066
- message content.
- DR067
- other interaction patterns.
For a description of fundamental Web concepts including resources and
resource manifestations, see the "Web Characterization Terminology
& Definitions Sheet" W3C Working Draft. For many useful terms, see
also the Proposed
Telecom Glossary 2000.
The XML Protocol is a framework which can accommodate an
open-ended set of XML Protocol modules carrying a large
variety of functions and services. Typical functions and services carried by
XML Protocol modules can range from generic mechanisms for handling security,
caching, routing, and eventing to specific functions like submitting a
purchase order.
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.
Note: 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 say.
- application
- See the proposed
Telecom Glossary 2000's definition of the term application.
- protocol
- See the proposed
Telecom Glossary 2000's definition of the term protocol.
- 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 module
- A syntactic construct or structure used to delimit data that logically
constitutes a single computational unit as seen by the XP processor. Services carried by XP modules can range
from generic mechanisms for handling security, caching, routing, and
eventing to specific functions like submitting a purchase order. XP
Modules can be composed within an XP message to
provide the overall desired functionality of the message.
- 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
TCP.
The XML Protocol data encapsulation model describes how data 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 each contain zero, one or more XP modules. While an XP envelope by
itself provides a minimum set of services, XP modules can
provide an open-ended set of functions and services that can be composed
within an XP message.
- XP message
- The basic unit of communication within the XML
Protocol.
- XP processor
- An XP Processor processes an XP message according
to the formal set of conventions defined by the XML
Protocol and generate an XP fault if the
conventions are not followed. Insufficient or wrong data carried in an
XP module can cause an XP processor to generate a
fault (see also XP receiver and XP
sender)
- 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
enclosed.
- XP header
A collection or zero, or more XP modules which
may be intended for any XP receiver within the XP
message path.
- XP body
- A collection or zero, or more XP modules intended
for the ultimate XP receiver within the XP message path.
- XP fault
- A special XP module 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 receivers and an XP sender which
allows them to forward a message on behalf of the previous sender.
Note: Especially in some b2b interactions, more complicated message
path models are 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
message.
- 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 that a single XP message passes on its
way from the initial XP sender, through zero or more
XP intermediaries, and to 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
path.
- 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:
- 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
modules.
- XP data encoding
- The syntactic representation of data described by the XP data model within one or more XP modules in an XP message.
- binary data
- Data which is represented using a non-XML based, non-human readable
syntax
This will become a list of terms that we often use but not
directly define as part of the XP WG.
- DR805
- Routing - in-message dictation of a complete or partial path through
processing intermediaries
- R807
- Tracking - enabling message recipients to determine a message's path
through preceding intermediates
- DR809
- Caching - defining mechanisms to allow intermediates to reuse messages
or parts of messages
- DR810
- Quality of Service - defining required and requested service levels in
messages
- XML Protocol
Working Group Charter