XML Protocol WG DRAFT Requirements
Last Modified: $Date: 2000/11/10
05:04:31 2000/12/07 17:57:06
$
- Latest revision
-
http://www.w3.org/2000/xp/Group/xp-reqs
- This revision
- <a
href="http://www.w3.org/2000/xp/Group/xp-reqs-02">
http://www.w3.org/2000/xp/Group/xp-reqs-02
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>
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> 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
<h2>
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 developed by the
Working Group may will make
reasonable efforts to support (but not preclude any particular
define) a broad range of protocol
binding bindings between
communicating peers. 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
publish-subscribe or Multicast
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 peers. A peer is a party
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.
- DR307 R307
- XP MUST
must be suitable for widespread use across organisational
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.
- DR308 R308
- Since XP is intended to be a foundation protocol, deleted text: and
therefore its definition MUST
be should remain simple and
stable over time. Express Explicit use of modularity and layering in
the resulting design will help assure
deleted text: usability and
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.
- DR300 R300 (absorbs old DRs: DR023, DR0053,
DR088)
-
The requirements that XP support the use
of layering and be modular, extensible, deleted text:
layered and transport independent (or
neutral) 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) imply that there is an
architectural design model behind XP. This architecture and the
extensibility framework MUST be explicitly defined neutrality).
In this context, layering refers to both XP's support of applications layered on top XP modules (the layer(s) "above") as well as the
capability of XP to be layered on top of (or
bound to) define services required
(the layer(s) "below") for implementation across a variety
of underlying protocols. protocols
- DR301 R301
- The XML protocol specifications
MUST 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.
- <a name="z301"> DR301a R301a
- The XP specification MUST 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 ).
- DR302 R302 (Absorbs old DR's: DR107)
- The XML Protocol MUST must support
deleted text: modular
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
deleted text: to evolve and
adapt the user interfaces they
provide to human clients 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 MUST should be easy to understand, use, extend
and implement. deleted text: 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.
- DR304 R304
- The XML protocol MUST should facilitate the creation of simple
applications. Simple applications are those
with simple often characterized
by message exchange patterns:
patterns such as one-way or event, synchronous, or
(or event), and two-way (or
synchronous) request response interactions. The
specification will should make such simple exchange applications as
easy as possible to create and to
use.
- DR305 (Absorbs old DRs: DR003)
- The XML deleted text: Protocol SHOULD provide functionality to enable
the creation of complex applications. As the 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 sessions and for
transactional semantics also increase. The XML protocol
SHOULD
must provide facilities (possibly
optional standardised header and/or trailer elements) to
that encourage a common approach for
providing facilities features such as:
as authentication, encryption,
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.
- DR306 R306 (Absorbs old DRs: DR090)
- The XML Protocol and applications of the XML Protocol MUST/SHOULD
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..
engines.
- DR309
- In cases where deleted text:
there is prior knowledge of the specific interactions that will arise contract between
given entities is well known, the use
of XP implementations, it should be
possible as a protocol to
create implementations supporting these
interactions using only fulfill those
application contracts should allow processing without
requiring a minimal amount
complex XML application infrastructure
provided the documents exchanged are well-formed and within the
tenets of the XML infrastructure.
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.
- <a name="z701"> DR701 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.
<p>
- R701b Requirement for Encapsulation
- deleted text: </p>
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.
- <a name="z700"> DR700 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 deleted text: envelope, </li> <li> extending the message
by extension of the XP envelope
deleted text: itself.
- 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 given two an
XP messages it should be possible,
processor, by simple inspection of
the messages, to an XP envelope, may determine if they are compatible.
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
applications protocols build
using the XP envelope.
- <a name="z703"> DR703 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).
deleted text: <dl> <dt> <a name="z800"> R800
</a> </dt> <dd> Intermediaries are essential
parts of building distributed systems that scale on the Web. As a
result, XML Protocol must support intermediaries. </dd>
</dl>
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
cannot be addressed from within an XP envelope.
- R803
- XML Protocol must accommodate
not preclude the use of transport
bindings that define transport intermediary roles such as
store-and-forward, proxies proxy and
gateways. 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 enable
determination of identify XP
Modules which message
components they are eligible
deleted text: for processing by a particular processing intermediary.
Message components must be able to be
targeted at one or more processing intermediaries. 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 the portions of messages
XP modules intended for them without deleted text: reading
or processing the entire message.
deleted text: This allows them to
operate efficiently. </dd> </dl> <p> To assure
scalability and functionality, XML Protocol must also accommodate,
but not define, these processing intermediary mechanisms;
</p> <dl> <dt> <a name="z805"> DR805
</a> </dt> <dd> Routing - in-message dictation of
a complete or partial path through processing intermediaries
</dd> <dt> <a name="z807"> R807 </a>
</dt> <dd> Tracking - enabling message recipients to
determine a message's path through preceding intermediates
</dd> <dt> <a name="z809"> DR809 </a>
</dt> <dd> Caching - defining mechanisms to allow
intermediates to reuse messages or parts of messages </dd>
<dt> <a name="z810"> DR810 </a> </dt>
<dd> Quality of Service - defining required and requested
service levels in messages
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
- DR600 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 an 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.
- DR604 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 message.
XP message content.
- DR608 R608
- The XP specification XML Protocol binding mechanism should not
preclude the use possibility of XP
messaging over popular security mechanisms. <p
class="ednote"> Discussion: Whatever this means, I think it may
be more suitable constructing
bindings to do something like
define protocols that provide
a standard extension to deal with
forms 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 mechanisms.
protocols.
- DR609 R609
-
The XP specification should may mandate the use of UTF-8 as its 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 choice. <p class="ednote"> Discussion:
There character encodings and
is a very good discussion currently on the
WG private mailing list about this topic, when actively seeking feedback in this discussion recedes we can formulate area. Until all the
requirement from feedback has been
evaluated, the consensus.
Working Group will not make a decision in
favor of restriction.
- DR612 R612
- The XP specification must provide a normative description of
the default binding of XP to the HTTP
transport. HTTP. This binding,
while normative, is not to be exclusive. Any
protocol The binding to HTTP must
provided by the Working Group will respect the semantics of
HTTP and should will demonstrate that it can interoperate
co-exist with existing HTTP
applications. <p> This requirement does not extend to the
provision of normative bindings to other important Internet
protocols such as TCP/IP, UDP
HTTP/1.0 and SMTP in the XP
specification. </p> <p> Furthermore, the XP
specification must provide a normative description of a binding of
XP to a subset of HTTP that is compatible with pre-XP Internet
browser technology. </p> <p> <span
class="ednote"> Discussion: The latter paragraph, regarding the
subset of HTTP, needs use case. </span> </p>
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
- DR200 R200
- The XML Protocol will must contain a convention for representing
calls and replies between RPC (Remote Procedure Call) applications. applications
and services. The conventions
will must include the
following:
- Unique specification Complete and unique identification, by means of
URI syntax , of the
program program, service or
object and procedure or method to be called
based on <a href="http://www.ietf.org/rfc/rfc2396.txt"> URI
syntax </a>.
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. message (see
also 703a
and 703b
Where possible, an attempt will be made to leverage any related
work done by the IETF. deleted
text: .
- DR201 R201
- The RPC conventions within the XML Protocol will 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. There will It must
be convenient to create
straightforward mappings of the data types deleted text:
used to a wide variety of widely deployed programming
languages and object systems systems.
- DR202 R202
- The XML Protocol will should allow applications to include custom
encodings for data types used for parameters and results in RPC
messages. deleted text: Mechanisms for automatically binding data
represented in RPC messages to native constructs in a programming
language will not be precluded. </dd> <dt> <a
name="z203"> DR203 </a> </dt> <dd> 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.
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. Groups and Activities.
Sent to <a
href="http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2000Oct/0065.html">
XP
These are the requirements that
the XML Protocol
WG deleted text: mailing list: 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
- Need Definition. </dd> <dt>
async </dt> <dd> Need Definition. See the
proposed Telecom Glossary 2000
's definition of the term
application .
- binary data protocol
- Need Definition. See the
proposed Telecom Glossary 2000
's definition of the term
protocol .
- body XML Protocol (XP)
- Need Definition. 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 .
- composability
XP module
- Need Definition. 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.
- connection oriented XP binding
- Need Definition. 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.
- <dt>
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 </dt> <dd> Need
Definition. </dd> <dt> 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 process model 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
- Need Definition. The basic unit of communication within the XML Protocol .
- faults XP processor
- Need Definition. 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 )
- gateway XP envelope
- Need Definition. 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
- Need Definition.
A collection or zero, or more XP modules which may be intended for any XP receiver within
the XP message
path .
- intermediary XP body
- Need Definition. A collection or zero, or more
XP modules intended for the ultimate XP receiver
within the XP message
path .
- message XP fault
- Need Definition. A special
XP module which contains fault
information generated by an XP processor .
- <dt>
The XML Protocol message path
</dt> <dd> Need Definition.
</dd> <dt> 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 pattern </dt>
<dd> Need Definition. </dd> <dt> metadata
</dt> <dd> Need Definition. </dd> <dt>
non-syntactic data </dt> <dd> Need Definition.
</dd> <dt> one-way </dt> <dd> Need
Definition. </dd> 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.
- protocol XP sender
- Need Definition. </dd> <dt>
protocol An
application that can generate an XP message and perform
an XP binding
</dt> <dd> Need
Definition. to a specific
protocol for the purpose of transmitting the message.
- XP
receiver
- Need Definition. 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 .
- references (uris)
XP message path
- Need Definition. 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 .
- request/multi-response initial XP sender
- Need Definition. The XP
sender that originates an
XP message as the starting point of an XP message path .
- request/response
XP intermediary
- Need Definition. </dd> <dt>
resource An application that can act
as both an XP
sender and resource manifestation
</dt> <dd> Need Definition. an XP
receiver with the purpose of
forwarding an XP
message along an XP message path .
- rpc convention (programming
model) ultimate XP
receiver
- Need Definition. </dd>
<dt> The XP receiver that the
initial sender </dt> <dd>
Need Definition. 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:
- serialization/encoding XP data model
- Need Definition. A set of abstract constructs that can be used to
describe common data types and link relationships in data defined
by XP
modules .
- session oriented
XP data encoding
- Need Definition. The syntactic representation of data described by
the XP data
model within one or more XP
modules in an XP
message .
- sync binary data
- Need Definition. 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.
- transport DR805
- Need Definition. Routing - in-message dictation of a complete or partial
path through processing intermediaries
- tunnel R807
- Need Definition. Tracking - enabling message recipients to determine a
message's path through preceding intermediates
- ultimate receiver
DR809
- Need Definition. Caching - defining mechanisms to allow intermediates to
reuse messages or parts of messages
- wire format DR810
- Need Definition. Quality of Service - defining required and requested
service levels in messages
- XML
Protocol Working Group Charter
>