Today, the principal use of the World Wide Web is for interactive access to documents and applications. In almost all cases, such access is by human users, typically working through Web browsers, audio players, or other interactive front-end systems. The Web can grow significantly in power and scope if it is extended to support communication between applications, from one program to another. The purpose of this Working Group is to create a simple foundation to support the needs of such communicating applications.
A broad range of applications will eventually be interconnected through the Web. The initial focus of this Working Group is to create 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. Experience with SOAP, XML-RPC, WebBroker, etc. suggests that simple XML-based messaging and remote procedure call (RPC) systems, layered on standard Web transports such as HTTP and SMTP, can effectively meet these requirements. Specifically, the XML Protocol Working Group is chartered to design the following four components:
Furthermore, the following two general requirements must be met by the work produced by this Working Group:
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.
The chair of the Working Group will be David Fallside (IBM).
The remainder of this section describes the requirements and deliverables in more detail.
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.
By limiting the scope to include neither transport nor application specific features, it is believed that the Working Group is in a better position to achieve its goal of producing a simple mechanism for encapsulating and representing data that is transferred between communicating peers.
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 (see the relationship with other external groups).
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:
Experience from HTTP (including the HTTP Extension Framework) and HTML has shown how difficult it is to retrofit support for evolvability into an existing solution and the importance of providing this feature as an integral part of the initial infrastructure.
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).
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.
The general area of XML protocols is very broad as it can potentially include any XML based exchange between any two nodes in a distributed environment. Therefore, only those work items that we find absolutely essential for a minimalist design are listed in the proposed scope of the Working Group.
This section describes out-of-scope work items. In general, the Working Group will also consider items out of scope that are being addressed as part of other W3C Ativities, and it will reuse existing specifications wherever possible, including XML Namespaces and XML Schemas, Parts One and Two.
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.
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.
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.
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.
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.
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.
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.
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.
These are subject to revision due to editorial needs and external scheduling issues; updates will be negotiated with the related groups and recorded on the XML Protocol Working Group home page. Meeting dates are mentioned here for planning purposes.
The expected duration of the working group is 1.5 years, through April 2002.
30 April 2002: The W3C has extended the duration of the working group until 31 July 2002.
Note that public working drafts will be made available at least once every three months, per W3C Process.
XML and XML derived activities have become a strategic technology in W3C and elsewhere. Each deliverable of any Working Group must satisfy the dependencies from other W3C Working Groups before it can advance to Candidate Recommendation.
At the current time, there are no known dependencies on the work produced by the Working Group. However, it is expected that both the P3P Specification Working Group, the CC/PP Working Group and the XML Signature Activities will have close ties to this group.
The XML Protocol Working Group should liaise with at least the following groups outside W3C:
Furthermore, the Working Group will cooperate closely with the IETF on the design of the protocol aspects of the RPC mechanism.
The XML Protocol Working Group will also informally liaise with the IETF "Blocks Extensible Exchange Protocol" (BEEP) Working Group, created as a result of the recent BLOCKS proposal.
The XML Protocol WG will liaise with the IETF to discuss all transport protocol issues that are relevant for XML Protocol. For issues that are not clearly in the realm of an existing IETF WG, the IETF/W3C coordination call should be used as the discussion forum.
To become a member of the XML Protocol Working Group, a representative of a W3C Member organization must be nominated by their Advisory Committee Representative (please send email to the Working Group chair and the W3C team contact). The nomination must include explicit agreement to this charter, including its goals, an IPR disclosure and the level of effort required of the representative.
Each W3C Member organization is limited to at most one principal member and one alternate member of this Working Group. Attendance by an alternate discharges the principal's attendance obligations. The W3C team is considered to be a W3C member organization for purposes of this charter.
Membership is also open to invited experts from the community, selected by the chair in order to balance the technical experience of the group. Invited experts participate as principal members.
Participation is expected to consume at least one day per week of each Working Group member's time.
The Working Group will utilize a member-confidential mailing list <[email protected]>, and a public mailing list <[email protected]>. The public mailing list, with its wider audience, exists to promote openness and interoperability, and is the preferred channel of communication.
The Working Group will have a home page that records the history of the group, provides access to the archives, meeting minutes, updated schedule of deliverables, membership list, and relevant documents and resources. The page will be available to the public and will be maintained by the Chair in collaboration with the W3C team contact.
A one to two hour Working Group phone conference will be held every week. When necessary to meet agreed-upon deadlines, phone conferences may be held twice a week. Participation in phone conferences is limited to principal members and alternates, or alternates acting in stead of principals. The Chair may, at his discretion, invite guest experts to attend particular phone conferences.
Meeting records should be made available within three days of each telephone meeting. Meeting records must be made publicly available except for non-technical issues that do not directly affect the output of the Working Group. The Chair decides which issues are not made public.
Participation in face-to-face meetings is limited to principal members, alternates, and observers invited by the Chair. Decisions may be taken in face-to-face meetings but must be announced on the Working Group mailing list. Observers may take part in decision-making at the discretion of the Chair.
In addition to the required three annual face-to-face meetings, the Working Group may schedule other face-to-face meetings in a manner that maximizes co-location with events that Working Group members would be attending anyway.
The Chair makes Working Group meeting dates and locations available to the group at least eight weeks before the meeting, per W3C Process.
To be successful, we expect the Working Group to have approximately 10 to 15 active principal members for its 18-month duration. We also expect a large public review group that will participate in the mailing list discussions.
The W3C Team expects to dedicate the services of one engineer, full-time, for the 1.5-year duration of the Working Group. Yves Lafon and Hugo Haas will probably provide this effort.
W3C promotes an open working environment. Whenever possible, technical decisions should be made unencumbered by intellectual property right (IPR) claims. W3C's policy for intellectual property is set out in section 1.5 of the W3C Process document.
Members of the XML Protocol Working Group and any other Working Group constituted within the XML Protocol Activity are expected to disclose any intellectual property they have in this area. Any intellectual property essential to implement specifications produced by this Activity must be at least available for licensing on a royalty-free basis. At the suggestion of the Working Group, and at the discretion of the Director of W3C, technologies may be accepted if they are licensed on reasonable, non-discriminatory terms.
Members disclose patent and other IPR claims by sending email to an archived mailing list that is readable by Members and the W3C team: [email protected]. Members must disclose all IPR claims to this mailing list but they may also copy other recipients.
$Id: XML-Protocol-Charter.html,v 1.79 2002/05/08 00:47:34 ylafon Exp $