Copyright © 2002 W3C® (MIT,INRIA,Keio), All Rights Reserved. W3Cliability,trademark,document use, andsoftware licensing rules apply.
This document describes the XML Protocol Working Group's requirementsfor the XML Protocol (XMLP) specification.
This document is an editors' copy that has no official standing.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.
This is the secondW3C Working Draft of theXML Protocol requirements document. It is achartered deliverable of the XML ProtocolWorking Group (WG)[2], which is part of the XML ProtocolActivity[1]. The Working Group has agreed to publishthis document, although this document does not necessarily represent consensuswithin the Working Group about XMLP requirements. This new version contains anupdated glossary, some new requirements and usage scenarios.
Discussion of this document takes place on the public <xml-dist-app@w3.org> mailing list (Archives[4]) per theemail communication rules in the XML Protocol Working Group Charter[3].
This is a public W3C Working Draft for review by W3C members and otherinterested parties. It is a draft document and may be updated, replaced, orobsoleted by other documents at any time. It is inappropriate to use W3CWorking Drafts as reference material or to cite them as other than "work inprogress". Alist of all W3C technical reports can be foundat http://www.w3.org/TR/.
1Notations
2Relationship to WG Charter
3Requirements on Requirements
4Requirements
4.1General Requirements
4.2Simplicity and Stability
4.2.1The XMLP Specification Documents
4.2.2The XMLP Technologies
4.3Data Encapsulation and Evolvability
4.4Intermediaries
4.4.1Transport Intermediaries
4.4.2Processing Intermediaries
4.5Data Representation
4.6Protocol Bindings
4.7Convention for RPC
5Requirements from other W3C WGs
5.1XForms Requirements
5.2P3P Requirements
5.3RDF and UML Requirements
6Usage Scenarios
7References
AAcknowledgments (Non-Normative)
The following terminology and typographical conventions have been usedin this document.
Each requirement and scenario has a three digit number with a prefixindicating the status as follows:
A "DRnnn" notation indicates a requirement that the WG is actively considering (has not reachedrough consensus within the WG)
An "Rnnn" notation indicates a requirement that the WG is not actively considering at present (has reachedrough consensus within the WG)
A "DSnnn" notation indicates a usage scenario that the WG is actively considering (has not reachedrough consensus within the WG)
An "Snnn" notation indicates a usage scenario that the WG is not actively considering at present (has rough consensus within the WG)
The numbers used to identify requirements are arbitrary and does notimply any ordering or significance.
The document includes several verbatim quotes from the XML Protocol WGCharter[3] which provide context for therequirements. The quoted text isemphasized and prefixed withCharter.
The XML Protocol WG Charter[3] has twosections describing what isin-scopeand what isout-of-scopeof the problem space defined for the WG. The WG considers all the requirementsin4 Requirements to be in-scope per the Charter.
Reviewers and readers should be familiar with the XML Protocol WGCharter[3] because it provides the critical contextfor the requirements and any discussion of them.
The XMLP requirements must include usage scenarios that describe how XMLP is used in various environments (see6 Usage Scenarios). The set of usage scenarios must represent the expected range of XMLP'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 XMLP.
Charter:"The envelope and the serialization mechanisms developed by the Working Group may not preclude any programming model nor assume any particular mode of communication between peers."
The specification will make reasonable efforts to support (butnot define) a broad range of programming models suitable for the applicationsintended for XMLP.
The specification will make reasonable efforts to support (butnot define) a broad range of protocol bindings between communicating peers (seealso section4.6 Protocol Bindings).
The specification developed by the Working Group must supporteither directly or via well defined extension mechanisms different messagingpatterns and scenarios. The specification will directly support One-way andRequest-response patterns as part of permanently and intermittently connectedscenarios. The specification will not preclude the development of otherpatterns at either the application or transport layers. Examples of suchpatterns may include publish-subscribe or multicast delivery. All patterns andscenarios will be described by relevant usage scenarios (see6 Usage Scenarios).
The Working Group will coordinate with theW3C XML Activity through theXML Coordination Group (W3C members only) andshall use available XML technologies whenever possible. If there are caseswhere this is not possible, the reasons must be documented thoroughly.
The specification developed by the XML Protocol Working GroupWG[2] shall be as lightweight as possible keeping partsthat are mandatory to the minimum. Optional parts of the specification shouldbe orthogonal to each other allowing non-conflicting configurations to beimplemented.
The specification must be suitable for use betweencommunicating parties that donot havea prioriknowledge of each other.
The specification must focus on the encapsulation andrepresentation of data being transferred between parties capable of generatingand/or accepting an XMLP envelope.
Charter:"Focus must be put on simplicity and modularity and must support the kind of extensibility actually seen on the Web. In particular, it must support distributed extensibility where the communicating parties do not have a priori knowledge of each other."
Charter:"Simplicity is a key element in making distributed systems easy to understand, implement, maintain, and evolve. Modularity and layering are two important design principles for achieving simplicity. Although simplicity can only be measured in relative terms, the Working Group must ensure that the complexity of any solution produced is comparable to that of other current and widespread Web solutions."
Charter:"Another important aspect of simplicity is ease of deployment. The Working Group will look at various ways of deploying XML Protocol in a manner that is compatible with the existing Web 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 organizational boundaries. The design center for XMLP must include the interoperation of systems across organizational boundaries. The aim is to exploit Web philosophy and Web design principles in order to help foster widespread decentralized computing on the Web.
XMLP must be suitable for widespread use across organizationalboundaries in support of the application usage scenarios supplied elsewhere inthis document (see6 Usage Scenarios). This suitability requirementimplies simplicity in the language of the XMLP specification, which itselfdescribes a technology that is simple to understand and to implement correctly(see also[R301],[R301]). Although simplicitycan only be measured in relative terms, the Working Group should ensure thatthe complexity of any solution produced is comparable to that of other currentand widespread Web solutions.
Since XMLP is intended to be a foundation protocol, itsdefinition should remain simple and stable over time. Explicit use ofmodularity and layering in the resulting design will help assure longevity.Such a framework will allow subsequent extension of the design while leavingthe foundation of the design intact. ([R300 (absorbs old DRs: DR023, DR053,DR088)] and[R302 (Absorbs old DR's: DR107)] 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.
Simplicity in XMLP implies that many potentially important features are out of scope for XMLP proper. However, the XML Protocol Working Group recognizes that providing consistent ways to support these out of scope features will help keep XMLP stable.
Examples of such features are:
message authentication and encryption (perhaps using SMIME, SSL, or digital signatures),
sessions and transactions (possibly by providing globally unique identifiers for messages), and
service definition and discovery.
Facilities to support features like these may resemble SOAP/1.1[7] facilities such as the "Header" element.
The requirements that XMLP support the use of layering and be modular, extensible, and transport independent imply that there is an architectural design model behind XMLP. This architecture and the extensibility framework must be explicitly defined ([R308] references modularity,[R302 (Absorbs old DR's: DR107)] and[R700a Requirement for Extensibility] reference extensibility,[R502] and[R600] reference transport neutrality).
In this context, layering refers to both XMLP's support of XMLP modules (the layer(s) "above") as well as the capability of XMLP to define services required (the layer(s) "below") for implementation across a variety of underlying protocols
The XMLP specifications should be clear and easy to understand. This clarity implies that considerable editorial effort will be required in the structuring of the narrative through both outline/overview and normative reference material.
The XMLP specification must clearly identify conformance requirements in a way that enables the conformance of an implementation of the specification to be tested (see also[12]).
XMLP must support extensibility of vocabulary between communicating parties in a way that allows for decentralized extensibility without prior agreement. The WG must demonstrate through usage scenarios that the solution supports decentralized extensibility in a modular and layered manner (see6 Usage Scenarios).
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 XMLP is to achieve similar levels of evolvability, extensibility and adaptability for interfaces between web services.
XMLP 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.
XMLP and applications of XMLP must be easy to deployespecially in systems already supporting XML technologies like XML namespaces[10] and XML schemas[8][9].
The ease with which XMLP applications can be deployed will be crucial to the success of XMLP. 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.
The specification should make reasonable efforts to support applications that operate on resource constrained devices. Even though any practical device is resource constrained in any number of dimensions including but not limited to bandwidth, computational power and storage, the term "resource constrained device" often refers to hand-portable devices. This document does not attempt to define the term "resource constrained" nor what the constraints are for the available resources.
Charter:"For two peers to communicate in a distributed environment, they must first agree on a unit of communication. The XML Protocol Working Group must define such a unit by defining an encapsulation language that allows for applications to independently introduce extensions and new features. In this context, the following requirements for extensions and features must be met:"
"They are or can be orthogonal to otherextensions."
"They can be deployed automatically and dynamically acrossthe Web with no prior coordination and no central authority."
"The sender can require that the recipient either obeysthe semantics defined by an extension or aborts the processing of themessage."
The XMLP specification must define the concept of an envelopeor outermost syntactical construct or structure within which all othersyntactical elements of the message must be enclosed. The envelope must bedescribed with XML Schema[8][9].
The XMLP specification must also define a processing modelthat defines what it means to properly process an XMLP envelope or produce afault. This processing model must be independent of any extensions carriedwithin the envelope. The processing model must apply equally to intermediariesas well as ultimate destinations of an XMLP envelope.
The XMLP specification must define a mechanism ormechanisms that allow applications to submit application-specific content orinformation for delivery by XMLP. In forming the standard for the mechanisms,the XMLP specification may consider support for:
carrying application specific payloads inside the XMLP envelope,
referring to application specific payloads outside the XMLP envelope,
carrying nested XMLP envelopes as application specific data within the XMLP envelope,
referring to XMLP envelopes as application specific data outside the XMLP envelope
Regarding the handling of binary data in particular, the XMLProtocol WG Charter[3] has the following to say:
Charter:"Note that XML Namespaces provide a flexible and lightweight mechanism for handling language mixing as long as those languages are expressed in XML. In contrast, there is only very rudimentary support (base-64 encodings etc.) for including data languages expressed in binary formats. Such formats include commonly used image formats like PNG, JPEG etc. Although it is inconceivable to imagine a Web without such data formats, it is not considered a priority of this Working Group to solve this problem. This is in part because other organizations (e.g.ebXML andRosettaNet) 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."
To manage the mechanisms, the XMLP specification must define aset of directives which will unambiguously indicate to an XMLP processor whichextensions are optional and which are mandatory so that it can:
process all of the extensions in an XMLP envelope or fail,
process a subset of the extensions in an XMLP envelope or fail.
In both cases above, the XMLP processor must fail in astandard and predictable fashion.
The XMLP specification must define the concept of protocolevolution and define a mechanism or mechanisms for identifying XMLP revisions.This mechanism or mechanisms must ensure that an XMLP processor, by simpleinspection of an XMLP envelope, may determine whether or not the envelope iscompatible with its processing ability. The specification must define theconcepts of backwards compatible and backwards incompatible evolution.
The XMLP specification must define a means to convey errorinformation as a fault. The capability of XMLP carrying a fault message mustnot depend on any particular protocol binding.
The XMLP specification must define a mechanism or mechanismsto allow the transfer of status information within an XMLP message withoutresort to use of XMLP fault messages or dependence on any particularinteraction model.
Charter:"Intermediaries are essential parts of building distributed systems that scale to the Web. Intermediaries can act in different capacities ranging from proxies, caches, store-and-forward hops, to gateways. Experience from HTTP[6] 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 XMLP 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 XMLP envelope.
Processing intermediaries are full XMLP processors; they process the message, but are not the ultimate recipient of it. They may be colocated with transport intermediaries, using them as a routing mechanism, or they may use in-message routing mechanisms.
To enable the interposition of processing intermediaries into the message path, two core requirements must be met:
Targeting - XMLP must define mechanisms that allow XMLP processors, including intermediaries, to identify XMLP extensions which they are eligible to process.
Reporting - XMLP 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.
In addition
Charter:"With the introduction of XML and Resource Description Framework (RDF) schema languages, and the existing capabilities of object and type modeling languages such as Unified Modeling Language (UML), applications can model data at either a syntactic or a more abstract level. In order to propagate these data models in a distributed environment, it is required that data conforming to a syntactic schema can be transported directly, and that data conforming to an abstract schema can be converted to and from XML for transport."
Charter:"The Working Group should propose a mechanism for serializing data representing non-syntactic data models in a manner that maximizes the interoperability of independently developed Web applications. Furthermore, as data models change, the serialization of such data models may also change. Therefore it is important that the data encapsulation and data representation mechanisms are designed to be orthogonal."
Charter:"Examples of relationships that will have to be serialized include subordinate relationships known from attachments and manifests. Any general mechanism produced by the Working Group for serializing data models must also be able to support this particular case."
The XMLP data encapsulation and data representation mechanismsmust be orthogonal.
The XMLP data representation must support using XML Schemasimple and complex types[8][9].
The XMLP data representation must be able to serialize databased on data models not directly representable by XML Schema simple andcomplex types. These data models include object graphs and directed labeledgraphs. It must be possible to reconstruct the original data from the datarepresentation.
Data serialized according to the XMLP data representation maycontain references to data outside the serialization. These references must beUniform Resource Identifiers (URIs)[5].
The XMLP data representation must be able to encode arrayswhich may be nested.
Charter:"A mechanism for using HTTP transport in the context of an XML Protocol. This does not mean that HTTP is the only transport mechanism that can be used for the technologies developed, nor that support for HTTP transport is mandatory. This component merely addresses the fact that HTTP transport is expected to be widely used, and so should be addressed by this Working Group."
Charter:"Mapping onto existing application layer protocols may lead to scalability problems, security problems and semantic complications when the application semantics defined by those protocols interfere with the semantics defined by an XML Protocol. The WG may consider issuing a warning about the possible problems of reusing non-safe "transports" like SMTP and others. A mapping onto transport services other than HTTP will only be started if enough interest is shown and time is available."
Charter:"General transport issues were investigated by the HTTP-NG Activity, which designed a general transport mechanism for handling out-of-order delivery of message streams between two peers. While we do strongly encourage work to be undertaken in this area, it is expected that work in this area will be done in collaboration with theIETF and not as part of this Working Group"
The XMLP specification must not mandate any dependency onspecific features or mechanisms provided by a particular transport protocolbeyond the basic requirement that the transport protocol must have the abilityto deliver the XMLP envelope as a whole unit. This requirement does notpreclude a mapping or binding to a transport protocol taking advantages of suchfeatures. It is intended to ensure that the basic XMLP specification will betransport neutral.
The XMLP specification must consider the scenario where anXMLP message may be routed over possibly many different transport orapplication protocols as it moves between intermediaries on the message path.This requirement implies it must be possible to apply many transport orapplication protocol bindings to the XMLP message without information loss fromthe XMLP message content.
The XMLP binding mechanism should not preclude the possibilityof constructing bindings to protocols that provide a security mechanism.
Typical examples of such protocols are SSL providing a securechannel,and S/MIME which provides a secure wrapper. It should be possible tospecify XMLP bindings for such security protocols.
The XMLP specification may mandate the use of a specificcharacter encoding, such as UTF-8, at some point in the future.
The Working Group is aware of the complexity resulting in theuse of a large set of character encodings and is actively seeking feedback inthis area. Until all the feedback has been evaluated, the Working Group willnot make a decision in favor of restriction.
The XMLP specification must provide a normative description ofthe default binding of XMLP to HTTP[6]. This binding,while normative, is not to be exclusive. The binding provided by the WorkingGroup will respect the semantics of HTTP and will demonstrate that it canco-exist with existing HTTP/1.0 and HTTP/1.1 implementations.
Charter:"A convention for the content of the envelope when used for RPC (Remote Procedure Call) applications. The protocol aspects of this should be coordinated closely with theIETF and make an effort to leverage any work they are doing"
XMLP must contain a convention for representing calls andreplies between RPC (Remote Procedure Call) applications and services. Theconventions must include the following:
Complete and unique identification, by means of URI syntax[5], 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[R703a Requirement for Encapsulation of Error Information] and[R703b Requirement for Encapsulation of Status])
Where possible, an attempt will be made to leverage anyrelated work done by theIETF.
The RPC conventions within XMLP should use the DataRepresentation model discussed in4.5 Data Representation to represent parametersto 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 awide variety of widely deployed programming languages and object systems.
XMLP should allow applications to include custom encodings fordata types used for parameters and results in RPC messages.
These are requirements submitted by other W3C Working Groups andActivities.
These are the requirements that the XML Protocol WG[2] has received from the (W3C Members only)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[2] has received from theP3P WG:
It must be possible to associate a P3P Privacy Policy with an XMLP message.
The XML Protocol WG has not directly received a set of requirements from theRDF WG and from the UML group similar to what was received from theP3P and theXForms WGs. However, the WG believes that[R402] andsection 1.4 of the XML Protocol WG charter addresses the primary concerns of these groups. The WG has dealt with these concerns as part ofissue 29.
Usage scenarios are intended to provide representative examples ofsituations where XMLP might be applicable. The purpose of usage scenarios is tohelp ensure that XMLP is capable of dealing with applications and servicesactually seen in the Web. Hence, usage scenario specifications should be at acoarse-grain level of an end user's desired XML document/message interchange,rather than at a detailed, implementation or transport specific level. Usagescenarios often make assumptions about the specific environments in which theuse cases are described that the requirements cannot.
In other words, the requirements are explicitly targeted to the designof XMLP; usage scenarios are targeted to systems in which XMLP is most likelypart of an overall solution. Not all requirements need to be referenced by anexample usage scenario, since, in addition to higher-level, applicationspecific requirements for use, there are internal, architectural requirementsindependent of any specific higher-level use (e.g., using XML, schemas, andnamespaces imposes certain requirements irrespective of use).
A sender wishes to send an unacknowledged message to a single receiver (e.g. send a stock price update every 15 minutes)
Note:
S1 Originates from splitting theebXML use case 1.1 into 2 scenarios (S1 andS2).
A sender wishes to send unacknowledged messages to a set of receivers (e.g. send a stock price update every 15 minutes)
Note:
S2 Originates from splitting theebXML use case 1.1 into 2 scenarios (S1 andS2). Note that S2 may be decomposed into Multiple instances of S1 under thecontrol of some "higher-level" process such as multicast orpublish/subscribe.
Two parties wish to conduct electronic business by the exchange of business documents. The sending party packages one or more documents into a request message which is then sent to the receiving party. The receiving party then processes the message contents and responds to the sending party. Examples of the sending party's documents may be purchase order requests, manufacturing information and patient healthcase information. Examples of the receiving party's responses may include order confirmations, change control information and contractual acknowledgements.
The sender invokes the service by passing parameters that are serialised into a message for transmission to the receiving server.
A sender wishes to reliably exchange data with a receiver. It wishes to be notified of the status of the data delivery to the receiver. The status may take the form of:
The data has been successfully delivered to the receiver, or
Some failure has occurred which prevents the sucessful delivery to the receiver.
Note:
This scenario does not imply that reliable message deliverywill be supported by the XMLP core specification.
A sender wishes to exchange data with a receiver and has agreed to encrypt the payload. The sending and receiving applications agree on the encryption methodology. Data is encrypted by the originating application and sent to the receiver via XMLP.The data reaches the receiving application untouched, and may then be decrypted in the agreed-upon manner.
A blind auction marketplace serves as a broker between buyers and suppliers. Buyers submit their requirements to the marketplace hub, which broadcasts this information to multiple suppliers. Suppliers respond to the marketplace hub where the information is logged and ultimately delivered to the buyer.
Two partners are engaged in a long-running process which involves multiple message exchanges. Examples of such processes may be complex supply chain management, dynamic manufacturing scheduling or information retrieval. There may be multiple instances of the same process in progress between the same two partners.
Two trading partners engaged in a message exchange may agree to cryptographically sign and verify either the message header, the routing header(s) and/ or the payload. The sender or originating application may perform the siging of the payload. The sending message extension signs the message header. A routing header may be appended to the message header. The routing header may also be signed by a message service extension.
An intermediary forwards a message to the ultimate receiver on behalf of an initial sender. The initial sender wishes to enforce the non-repudiation property of the route. Any intermediate message service extension that appends a routing message must log the routing header information. Signed routing headers and the message headers must be logged at the intermediary which passes the message to the ultimate receiver to provide the evidence of non-repudiation.
A sender sends a message asynchronously to a receiver expecting some response at a later time. The sender tags the request with an identifier allowing the response to be correlated with the originating request. The sender may also tag the message with an identifier for another service (other than the originating sender) which will be the recipient of the response.
A digital camera wishes to transmit image data over a wireless link using XMLP to a remote server. The binary image data (non-XML) accompanies the message. The digital camara represents a situation in which connections from the receiver to the sender may not be permitted due to device limitations or firewalls.
An application requests some information from a server, which is returned at a later time in multiple responses. This can be because the requested information was not available all at once (e.g., distributed web searches). (based on[13])
An XMLP sender generates a lengthy XMLP message that is incrementally transmitted and received by an XMLP receiver. The XMLP receiver processes the body as it is received (e.g., employing a SAX-style XML parser on the body as it arrives). Note that the entire message need not be present at one time at any point in its existence.
This would be particularly helpful for memory-limited processors. It is also very efficient for services which are consistent with incremental, real-time transformations of the data, direct archiving of received data, etc. It would also be useful in scenarios in which voluminous body data can be directly transduced into application data structures or events by an XMLP (module) processor. In particular, there is no need for the explicit construction of a DOM model of the data. Support for XMLP data models might still be possible even with incremental processing if the models are incrementally constructible (copied in its entirety from[14])
An application subscribes to notifications of certain named events from an event source. When such events occur, notifications are sent back to the originating application (first party notification) or to another application (third party notification). For example, an application can subscribe to notification of various aspects of a printer's status (e.g., running out of paper, ink etc.). The notifications of such events could be delivered to a management application (based on: See item 2 of[15])
Some applications may wish to make caching possible for latency, bandwidth use or other gains in efficiency. To enable this, it should be possible to assign cacheability in a variety of circumstances. For example, "read" caching might be used to store messages at intermediaries for reuse in the response phase of the request/response message exchange pattern. Such caching might be on the scope of an entire message, an XMLP module, or scoped to individual XMLP module elements.
Similarly, "write" caching may be useful in situations when a request message in a request/response message exchange pattern (as well as similar messages in other message exchange patterns) does not need to be immediately forwarded or responded to. Such cachability might be scoped by different methods, as outlined above.
Cacheability scoped by different elements might be associated by an attribute to the target element, through use of XML Query or XPath to describe the target elements in a header, or implied by the document schema, for example.
Cacheability mechanisms applied to messages, bodies or elements might include time-to-live (delta time), expiry (absolute time), entity validation, temporal validation, subscription to invalidation services, and object update/purge.
Finally, some applications may be capable of describing the dependencies and relationships between message elements. For example, a response element may be applicable to a wide range of requests; it would be beneficial to describe this element's relationship with request elements, so that it may satisfy a wide range of requests in an economical fashion. Similarly, the presence of a particular element may be a trigger for a cacheability mechanism to be applied to another element, such as validation or invalidation (see also[16])
A developer wishes to force an explicit message path through certain intermediaries - for instance, he might use an anonymizing intermediary to make a call to a specified remote service without allowing the target service to track the identity/IP of the caller. In this case, the intermediary is responsible for calling the target service and returning the results to the caller, using its own authentication credentials if any are required by the target service.
A service provider wishes to track incoming messages to see exactly which processing intermediaries have touched it by the time it arrives at its destination. It therefore requires a tracking extension to be included by all clients, and by any processing intermediaries along the message paths from the clients to the server.
BizCo updates their online price catalog every morning at 8AM. Therefore, when remote clients access their XMLP inventory service, clients and intermediaries may cache the results of any price queries until 8AM the next day.
An XMLP sender (not necessarily the initial XMLP sender) wants the XMLP message to be handled with specific quality of service as it traverses the XMLP message path to include multiple XMLP Processing intermediaries. Information in the XMLP message is used to select appropriate QoS mechanisms (e.g.,RSVP,Diffserv,MPLS, etc.). Selection of QoS may be constrained byQoS policies,Service Level Agreements (SLAs),Service Level Specifications (SLS).
The WG thanks all participants of thexml-dist-app@w3.org mailing list (Archives[4]) for directly and indirectly contributing to thisdocument.