XML Protocol Working Group Charter
- Scope
- Out of Scope
- Deliverables and Schedule
- Relationship with Other Activities
- Membership, Meetings, and Logistics
1. Scope of XML Protocol Working Group
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:
- An envelope for encapsulating XML data to be transferred in an interoperable manner that allows for distributed extensibility and evolvability as well as intermediaries.
- 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 datatypes 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. For coordination with the IETF, see below.
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.
The chair of the Working Group will be David Fallside (IBM).
The remainder of this section describes the requirements and deliverables in more detail.
1.1 Simplicity
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).
1.2 Data Encapsulation and Evolvability
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.
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.
1.3 Intermediaries
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).
1.4 Data Representation
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.
2. Out of Scope
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.
2.1 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.
2.2 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.
2.3 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.
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.
2.4 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.
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.
2.5 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.
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.
3. Deliverables and Schedule
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.
- September 2000
- Activity start and Working Group formation
- October 2000
- Working Group face-to-face meeting
- October 2000
- Publish requirements Working Draft for XML Protocol WG
- November 2000
- Working Group face-to-face meeting
- January 2001
- Publish initial Working Draft for XML Protocol proposal
- March 2001
- Working Group face-to-face meeting
- April 2001
- Candidate Recommendation for XML Protocol proposal
- June 2001
- Working Group face-to-face meeting
- August 2001
- Proposed Recommendation for XML Protocol
- September 2001
- Recommendation for XML Protocol
- April 2002
- WG terminates work
The expected duration of the working group is 1.5 years, through April 2002.
Note that public working drafts will be made available at least once every three months, per W3C Process.
4. Relationship with Other Work
4.1 W3C Activities
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.
- XML Activity
- The XML Protocol Working Group will be represented in the XML Coordination Group to
coordinate with other activities represented in this group. In
particular, the following activies are concerned:
- XML Schema WG
- The XML Schema specifications are currently Working Drafts in Last Call. The serialization functionality developed by the XML Protocol Working Group will be based on XML Schema.
- XML Linking WG
- XPointer and XLink are both in last call for Candidate Recommendation.
- XForms WG
- The XForms Working Group has published its first public working drafts. The XForms Working Group should be able to use results of the XML Protocol Working Group for form submission, suspend/resume, and prefill.
- RDF Schema WG
- The RDF schema specification is also currently a Candidate Recommendation.
- HTTP-NG WG (defunct)
- The now defunct HTTP-NG Activity served as an initial investigation using a layered and modularized approach to designing a protocol suitable for the Web. This work was an important precursor to the proposed XML Protocol Working Group and has helped to define its scope in much clearer terms.
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.
4.2 External Groups
The XML Protocol Working Group should liaise with at least the following groups outside W3C:
- IETF
- The Working Group will cooperate closely with the IETF
on the use of HTTP as a transport mechanism. To achieve this, work on
this item should be conducted exclusively on the public mailing list xml-dist-app@w3.org. In the
IETF/W3C coordination call on 21 August 2000, the IETF announced plans
for an IETF Working Group addressing use of HTTP as a transport
protocol, based on an existing
draft. Once this Working Group has been established, the XML
Protocol WG should follow the guidelines developed by the IETF Group.
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.
- ebXML
- The Working Group will attempt to liaise via cross-participation with the Transport, Routing and Packaging project team within ebXML (electronic business XML). ebXML is a joint activity of UN/CEFACT (the United Nations body responsible for UN/EDIFACT), the international EDI standard, and OASIS (Organization for the Advancement of Structured Information Standards).
- RosettaNet
- The Working Group will attempt to liaise with work done on RNIF (RosettaNet Implementation Framework).
5. Membership, Meetings, and Logistics
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.
5.1 Email Communication
The Working Group will utilize a member-confidential mailing list <w3c-xml-protocol-wg@w3.org>, and a public mailing list <xml-dist-app@w3.org>. The public mailing list, with its wider audience, exists to promote openness and interoperability, and is the preferred channel of communication.
5.2 Group Home Page
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.
5.3 Telephone Meetings
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.
5.4 Face-to-Face Meetings
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.
5.5 Resources
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.
5.6 W3C Team Involvement
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.
5.7 Intellectual Property
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: patent-issues@w3.org. Members must disclose all IPR claims to this mailing list but they may also copy other recipients.
David Fallside <fallside@us.ibm.com>, Yves Lafon <yves@w3.org> (with major contributions from Henrik Frystyk Nielsen <frystyk@microsoft.com>)
$Id: XML-Protocol-Charter.html,v 1.59 2000/09/13
09:05:42 yves Exp $