XML Protocol (XMLP) provides simple protocols that can be ubiquitously deployed and easily programmed through scripting languages, XML tools, interactive Web development tools, etc. The goal is a layered system which will directly meet the needs of applications with simple interfaces (e.g. getStockQuote, validateCreditCard), and which can be incrementally extended to provide the security, scalability, and robustness required for more complex application interfaces.
Specifically, the XML Protocol Working Group is chartered to design the following four components:
- An envelope for encapsulating XML data to be transferred in an interoperable manner that allows for distributed extensibility.
- 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, see below for details.
- A mechanism for serializing data representing non-syntactic data models such as object graphs and directed labeled graphs, based on the data types of XML Schema.
- 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. There will be coordination with the Internet Engineering Task Force (IETF), see Blocks Extensible Exchange Protocol (BEEP) (new window).
Furthermore, the following two general requirements must be met by the work produced by this Working Group:
- 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.
- 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.
The Working Group shall start by developing a requirements document, and then evaluate the technical solutions proposed in the SOAP/1.1 submission against these requirements. If in this process the Working Group finds solutions that are agreed to be improvements over solutions suggested by SOAP 1.1, those improved solutions should be used.
Organization: W3C
More information: XMLP page on the W3C website (new window)
![]()
More detail for the current topic: XML Protocol (XMLP)
More on the general topic: Messaging specifications
- Asynchronous Application Service Protocol (ASAP) for SOAP
- Message Service Specification (MSS)
- Representational State Transfer (REST)
- RosettaNet Business Message
- SOAP
- Web Distributed Data Exchange (WDDX)
- Web Services Addressing (WS-Addressing)
- Web Services Eventing (WS-Eventing)
- Web Services Notification (WSN)
- Web Services Reliability (WS-Reliability)
- Web Services Reliable Messaging (WS-ReliableMessaging)

