XML Protocol WG DRAFT Requirements
Last Modified: $Date: 2000/11/10 05:04:31 $
- Latest revision
- http://www.w3.org/2000/xp/Group/xp-reqs
- This revision
- http://www.w3.org/2000/xp/Group/xp-reqs-02
- Previous revisions
- 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
Paul Cotton, Microsoft, pcotton@microsoft.com
David Ezell, Hewlett Packard, david_e3@verifone.com
David Fallside, IBM, fallside@us.ibm.com
Oisin Hurley, IONA Technologies, ohurley@iona.com
John Ibbotson, IBM, ibbotson@uk.ibm.com
R. Alexander Milowski, Lexica, LLC, <alex@milowski.com>
Eric Newcomer, IONA Technologies, eric.newcomer@iona.com
Henrik Frystyk Nielsen, Microsoft, <frystyk@microsoft.com>
Mark Nottingham, Akamai Technologies, mnot@akamai.com
This document specifies a set of DRAFT requirements for the XML Protocol
specification.
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
- 6 Other Requirements
- 7 Glossary
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 a broad
range of programming models suitable for the applications intended for
XP.
- R501
- The specification developed by the Working Group may not preclude any
particular protocol binding between communicating peers.
- 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 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 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
- 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 (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
- XP is a foundation protocol, and therefore its definition MUST be
stable over time. Express use of modularity and layering in the
resulting design will help assure 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 (absorbs old DRs: DR023, DR0053, DR088)
The requirements that XP be modular, extensible, layered and
transport independent (or neutral) (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
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.
- DR301
- The XML protocol specifications MUST 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.
- DR301a
- 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).
- 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
interfaces between web services.
- 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.
- DR304
- The XML protocol MUST facilitate the creation of simple applications.
Simple applications are those with simple message exchange patterns:
one-way or event, synchronous, or two-way request response interactions.
The specification will make such simple exchange applications as easy as
possible to create and use.
- DR305 (Absorbs old DRs: DR003)
- The XML 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 provide facilities (possibly optional
standardised header and/or trailer elements) to encourage a common
approach for providing facilities such as: authentication, encryption,
reliable delivery, sessions and transactions.
- DR306 (Absorbs old DRs: DR090)
- The XML Protocol and applications of the XML Protocol MUST/SHOULD be
easy to deploy - especially in systems already supporting XML
technologies like XML namespaces and XML schemas.
The ease with which XP applications can be deployed will be crucial to
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 there is prior knowledge of the specific interactions
that will arise between given XP implementations, it should be possible
to create implementations supporting these interactions using only a
minimal amount of XML infrastructure.
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.
- 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 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.
- DR700 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,
- extending the message by extension of the XP envelope itself.
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.
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 XP messages it should
be possible, by simple inspection of the messages, to determine if they
are compatible. 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 using the XP envelope.
- DR703 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. 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).
- R800
- Intermediaries are essential parts of building distributed systems
that scale on the Web. As a result, XML Protocol must support
intermediaries.
Because XML Protocol separates the message envelope from the transport
binding, two types of intermediaries are possible; transport intermediaries
and processing intermediaries.
Transport intermediaries are interposed by a transport binding, as part of
the message exchange pattern that it implies. They do not define a processing
model for messages; they only operate as part of the transport binding, as a
message routing mechanism and they can not be addressed from within an XP
envelope.
- R803
- 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:
- R806
- 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.
- R808
- Reporting - XML Protocol must enable the generation of status and/or
error messages by processing intermediaries, and propagation and proper
identification of status and/or error messages through processing
intermediaries.
- R802
- XML Protocol must enable processing intermediaries to locate and
process the portions of messages intended for them without reading or
processing the entire message. This allows them to operate
efficiently.
To assure scalability and functionality, XML Protocol must also
accommodate, but not define, these processing intermediary mechanisms;
- 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
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
- 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 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
- 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 apply many transport or
application protocol bindings to the XP message without information loss
from the message.
- DR608
- The XP specification should not preclude the use of XP messaging over
popular security mechanisms.
Discussion: Whatever this means, I think it may be
more suitable to do something like define a standard extension to deal
with forms of security mechanisms.
- DR609
- The XP specification should mandate the use of UTF-8 as its character
set of choice.
Discussion: There is a very good discussion currently
on the WG private mailing list about this topic, when this discussion
recedes we can formulate the requirement from the consensus.
- DR612
- The XP specification must provide a normative description of the
default binding of XP to the HTTP transport. This binding, while
normative, is not to be exclusive. Any protocol binding to HTTP must
respect the semantics of HTTP and should demonstrate that it can
interoperate with existing HTTP applications.
This requirement does not extend to the provision of normative
bindings to other important Internet protocols such as TCP/IP, UDP and
SMTP in the XP specification.
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.
Discussion: The latter paragraph, regarding the
subset of HTTP, needs use case.
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
- The XML Protocol will contain a convention for representing calls and
replies between RPC (Remote Procedure Call) applications. The
conventions will include the following:
- Unique specification of the program or object and procedure or
method to be called based on URI syntax.
- 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.
Where possible, an attempt will be made to leverage any related work
done by the IETF. .
- DR201
- The RPC conventions within the XML Protocol will 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 be straightforward mappings of the
data types used to a wide variety of widely deployed programming
languages and object systems
- DR202
- 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.
- DR203
- 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.
Sent to XP
WG mailing list:
XForms models the data to be obtained from the user, specifies how a user
interface for obtaining the data is declared using XHTML markup, and finally
specifies how the populated data is shipped backed to the server. The [SEND]
subgroup is responsible for the interactions between the XForms client and the
backend server.
The work on [SEND] could be a replacement for the various methods for
posting data to an HTTP server such as application/x-www-form-urlencoded or
multipart/form-data.
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).
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.
- application
- Need Definition.
- async
- Need Definition.
- binary data
- Need Definition.
- body
- Need Definition.
- composability
- Need Definition.
- connection oriented
- Need Definition.
- envelope
- Need Definition.
- envelope process model
- Need Definition.
- faults
- Need Definition.
- gateway
- Need Definition.
- header
- Need Definition.
- intermediary
- Need Definition.
- message
- Need Definition.
- message path
- Need Definition.
- message pattern
- Need Definition.
- metadata
- Need Definition.
- non-syntactic data
- Need Definition.
- one-way
- Need Definition.
- protocol
- Need Definition.
- protocol binding
- Need Definition.
- receiver
- Need Definition.
- references (uris)
- Need Definition.
- request/multi-response
- Need Definition.
- request/response
- Need Definition.
- resource and resource manifestation
- Need Definition.
- rpc convention (programming model)
- Need Definition.
- sender
- Need Definition.
- serialization/encoding
- Need Definition.
- session oriented
- Need Definition.
- sync
- Need Definition.
- transport
- Need Definition.
- tunnel
- Need Definition.
- ultimate receiver
- Need Definition.
- wire format
- Need Definition.
- XML Protocol
Working Group Charter>