Status: Sent to JTC 1 Secretariat January the 20th, 2011. Ballot passed with only positive votes, approved 25th July 2011.
Main Editor: Daniel Dardailler, Director of International Relations, W3C.
Nearby: W3C PAS Status, granted in Oct 2010
This document presents the W3C Web Services Package, being submitted by W3C for JTC 1 PAS transposition into several ISO/IEC International standards.
The package is formed of the following eight specifications:
The above order of individual specifications in the WS package should be preserved in the transposition ordering: SOAP 1.2 and its add-ons first, then WS Addressing, then WS Policy.
This WS package is within scope of the W3C PAS Submitter’s original application, that is, a part of the Core Web technology stack W3C has been developing. This WS Messaging Framework rests on widely accepted industry standards such as XML and http.
To our knowledge, the main JTC 1 committee in liaison with W3C and potentially interested in this submission is SC38 but potentially, since it's our first submission, all the JTC 1 Liaisons available on our public page should have an opportunity to review it.
The rest of this Introduction section focuses on the WS strategic interests in Interoperability, Cultural and Linguistic Adaptability, and the following sections address to the JTC1 PAS criteria listed in the Document Related Criteria (mapping to the section 7.4 in JTC 1 Standing Document on PAS).
Web Services (WS) are software systems that support interoperable machine-to-machine interactions over a network. They provide a universal glue between different applications within the enterprise, or between different companies and they enable fast development of distributed applications in heterogeneous systems.
Web services are characterized by their great interoperability and extensibility thanks to the use of XML. The core technology is an XML-based messaging framework, on which can be built a variety of applications using different architectural designs.
XML, itself an application of SGML, has been previously identified by ISO as an industry standard.
Web services offer an interface described in a machine processable way, making it easy for implementers to integrate their applications, as long as implementers follow the same standards and APIs, which has mostly been the case.
We hope that an ISO/IEC approval of these specifications will help promote an even greater level of interoperability for world wide Web Services, and a higher level of compliance to the same set of messaging notations and semantics.
These technologies are simple in their architecture, and their value is entirely in the interoperable global market of ICT service applications they help create.
As with all W3C technologies, the Web Services stack went through the review of our Internationalization activity as well as our Web Accessibility Initiative activity (which cares for people with disabilities). The base of the globalization framework is of course XML, which itself supports Unicode
In addition, our standard development process is open to all participants, regardless of cultural or linguistic origins, and as a result, today's Web Services provide a standard means of interoperating between different and independently designed software applications, running on a variety of platforms and/or frameworks, all independent of cultural or linguistic parameters.
Products using combinations of Web Services from various countries, cultural origins and languages are common place on the Internet, in global organizations as well as on the public Web.
The Web Services activity at W3C has defined several frameworks and this Web Services PAS package consists of only stable and implemented technologies, forming, in large parts, what is called the WS Messaging Framework :
The following picture describes how these main components fit together on top of other foundational Web and Internet technologies (XML, http, URI):
The choice of this particular set of our first PAS, as a subset of our Web Services stack, was made by our W3C Advisory Board (with representatives from the largest software companies, e.g. IBM, Oracle, Adobe, Apple, Microsoft, etc) in consultation of the W3C technical team and the larger W3C Member advisory representatives group.
Using the JTC 1 numbering below.
7.4.1 Quality
Within its scope the specification shall completely describe the functionality (in terms of interfaces, protocols, formats, etc) necessary for an implementation of the PAS. If it is based on a product, it shall include all the functionality necessary to achieve the stated level of compatibility or interoperability in a product independent manner.
7.4.1.1 Completeness
- How well are all interfaces specified?
- How easily can implementation take place without need of additional descriptions?
- What proof exists for successful implementations (e.g. availability of test results for media standards)?
The Web Services specifications being submitted have all followed the same W3C process and evolved in the same context, so the descriptions that follow are applicable to all of them.
One important resource, referenced several times below, can be used to judge the current quality of our specifications: it is the W3C QA Matrix, listing all our technical reports and the presence of validators, test suites, tutorials. See http://www.w3.org/QA/TheMatrix for live data.
In the rest of this document, examples will be extracted from various documents pointed by this QA Matrix, but the intent is not to duplicate it.
Our interfaces are defined in US English with semantics for terms imposed by various formal mechanisms, and we also provide specific authoring templates that help our groups raise the overall quality of their interface definitions, using the right normative referencing rules, wording for conformance sections, etc.
The WS specifications presented here describe data formats, and the rules for generating, exchanging, and processing messages using those formats.
They are self-sufficient in terms of compliant specifications and even though they do not mandate the scope of any particular implementation, they require that no implementation violates any mandatory requirement listed in their Conformance section.
These specific clauses rely on the detailed meaning of the adjective MUST/SHALL, SHOULD or MAY, as ISO specifications do (W3C always point at the IETF version of these definitions, RFC 2119).
See the next sections for details on test results, conformance criteria, etc.
7.4.1.2 Clarity
- What means are used to provide definitive descriptions beyond straight text?
- What tables, figures, and reference materials are used to remove ambiguity?
- What contextual material is provided to educate the reader?
These specifications mostly describe programmatic interfaces and are doing so using formal grammar languages such as SGML DTDs or XML Schema technologies, or BNF sometimes.
They include tables and call out their normative references as well as informative references in separate sections.
They each have tutorial or primers available free of charge on the W3C site.
For instance, "W3C SOAP Version 1.2 Part 0: Primer" is a non-normative document intended to provide an easily understandable tutorial on the features of SOAP Version 1.2. In particular, it describes the features through various usage scenarios, and is intended to complement the normative text contained in Part 1 and Part 2 of the SOAP 1.2 specifications.
7.4.1.3 Testability
The extent, use and availability of conformance/interoperability tests or means of implementation verification (e.g. availability of reference material for magnetic media) shall be described, as well as the provisions the specification has for testability.
The specification shall have had sufficient review over an extended time period to characterise it as being stable.
As detailed in the public W3C QA Matrix resource, these specifications have all received some level of test support, for which results should still be available. See http://www.w3.org/QA/TheMatrix for live data.
SOAP 1.2, for instance, has a Specification Assertions and Test Collection report attached to it, which draws on assertions found in the SOAP Version 1.2 specifications and provides a set of tests in order to show whether the assertions are implemented in a SOAP processor. A SOAP 1.2 implementation that passes all of the tests specified in this document may claim to conform to the SOAP 1.2 Test Suite.
7.4.1.4 Stability
- How long has the specification existed, unchanged, since some form of verification (e.g. prototype testing, paper analysis, full interoperability tests) has been achieved?
- To what extent and for how long have products been implemented using the specification?
- What mechanisms are in place to track versions, fixes, and addenda?
These specifications have been released with their test materials, implementation reports and interop test results since before they were endorsed as W3C Recommendation, since the end of their Candidate Recommendation phase, at least.
So the dates range from 2005 to 2007 for the WS package, but some of these technologies had been present in products (in earlier version) since at least 2000.
Commercial Products from all continents and Open Source implementations have been in operations for at least that long, and other international organizations, like the WS-I (Web Services Interoperability) or OASIS have started initiatives to make sure the W3C Web Services stack was interoperable, adding new layers of functionalities on top of WS (hence testing it) or creating specific profiling technologies.
Each WS specifications maintains a Web page to track known errata to the Recommendation, with the date it was added to the errata page, a classification of the error (e.g., editorial, clarification, bug, known problem with the document itself), a short description of the problem and what part of the Recommendation is affected, any proposed corrections and whether those corrections would affect conformance of documents or software and any normative corrections.
W3C wrote a specific section on Errata Management in the W3C Process Document.
7.4.1.5 Availability
- Where is the specification available (e.g. one source, multinational locations, what types of distributors)?
- How long has the specification been available?
- Has the distribution been widespread or restricted? (describe situation)
- What are the costs associated with specification availability?
All the W3C specifications, including our W3C Recommendation track (highest mark for a W3C standards), are available for free download, without registration, on the W3C public Web site at the address: http://www.w3.org/standards/
The 8 Web Services specifications specific URLs and first publication dates, along with the final International Standards ISO/IEC names numbers we are requesting, are:
| 40210 | W3C SOAP Version 1.2 Part 1: Messaging Framework (2nd Edition) | http://www.w3.org/TR/2007/REC-soap12-part1-20070427 |
| 40220 | W3C SOAP Version 1.2 Part 2: Adjuncts (2nd Edition) | http://www.w3.org/TR/2007/REC-soap12-part2-20070427 |
| 40230 | W3C SOAP MTOM (Message Transmission Optimization Mechanism) | http://www.w3.org/TR/2005/REC-soap12-mtom-20050125 |
| 40240 | W3C Web Services Addressing 1.0 - Core | http://www.w3.org/TR/2006/REC-ws-addr-core-20060509 |
| 40250 | W3C Web Services Addressing 1.0 - SOAP Binding | http://www.w3.org/TR/2006/REC-ws-addr-soap-20060509 |
| 40260 | W3C Web Services Addressing 1.0 - Metadata | http://www.w3.org/TR/2007/REC-ws-addr-metadata-20070904 |
| 40270 | W3C Web Services Policy 1.5 - Framework | http://www.w3.org/TR/2007/REC-ws-policy-20070904 |
| 40280 | W3C Web Services Policy 1.5 - Attachment | http://www.w3.org/TR/2007/REC-ws-policy-attach-20070904 |
The distribution for these important and stable Web Services standards, a subset of the larger W3C WS stack, has been global, and today they form the basis for all Web Services implementations.
There are also available translations for these specifications. Please check our live translation catalog for these specifications.
7.4.2 Consensus
The accompanying report shall describe the extent of (inter)national consensus that the document has already achieved.
7.4.2.1 Development Consensus
- Describe the process by which the specification was developed.
- Describe the process by which the specification was approved.
- What “levels” of approval have been obtained?
The W3C Process Document promotes the goals of quality and fairness in technical decisions by encouraging consensus, requiring reviews (by both Members and public) as part of the standard development process, obliging the WG to respond to all comments.
As explained in this foundational W3C document, Consensus is a core value of our community and to promote it, the W3C process requires its WG Chairs to ensure that groups consider all legitimate views and objections, and endeavor to resolve them, whether these views and objections are expressed by the active participants of the group or by others (e.g., another W3C group, a group in another organization, or the general public).
The W3C Process goes provides a simple definition for what Consensus means in our context, as a way to describe the level of support for a decision among a set of eligible individuals:
The chain of steps going from a Working Group draft to a final W3C Recommendation status, followed by all the Web Services specifications submitted in this package, is described in the W3C PAS submitter status file.
Here's a picture that summarizes these steps, or maturity levels:
Each specification in the WS package has a Status section describing its origin, and the name of the W3C working group in charge of it at the time it was done.
For instance, for SOAP 1.2, it starts by saying:
Status of this Document
This document is a W3C Recommendation. It has been produced by the XML Protocol Working Group, which is part of the Web Services Activity.
As required by our process, when all the issues raised during the various review steps have been resolved, these specifications have reached the highest mark in the W3C process, W3C Recommendations.
7.4.2.2 Response to User Requirements
- How and when were user requirements considered and utilised?
- To what extent have users demonstrated satisfaction?
In the case of the Web Services stack, the Users are the programmers of the Web platform, not regular Web end-users, and these technical people which have been present at the table of technical negotiations since the beginning of these groups in 2000, whether they were member of W3C or not, since the group had a public review requirement.
Most of the groups working on these specifications have started by collecting their technical requirements in a separate documents. See http://www.w3.org/TR/2003/NOTE-xmlp-reqs-20030728/ for instance, for SOAP.
To the extent that after several years of deployment, there is no SOAP 1.3 or similar new versions of these WS specifications in the work, we can reasonably hope that the users are satisfied with this stack of technologies.
7.4.2.3 Market Acceptance
- How widespread is the market acceptance today? Anticipated?
- What evidence is there of market acceptance in the literature?
The market acceptance is global, there is no competition for Web Services Messaging, everyone uses this framework. W3C has managed to successfully gather all the parties interested in a solid, free of charge, Web Services platform and as a result, we have now implementations in Open Source as well as by all the major commercial software editors.
On top of this Web Services stack, a set of industrial profiles have already been designed (e.g. WS-I Basic Profile 2.0) which lists them explicitly and which are also being transposed by JTC 1, so the support is unambiguous.
The QA Matrix (at http://www.w3.org/QA/TheMatrix) provides pointers to the various Implementation reports for these WS specifications.
7.4.2.4 Credibility
- What is the extent and use of conformance tests or means of implementation verification?
- What provisions does the specification have for testability?
W3C doesn't run or is associated with any certification program for Web Services, or for any other technologies it has developed.
We try our best to have all our standards develop test suites, validators, and conformance sections detailing their own criteria for testability, and that implementers are free to run and self-assess their programs against.
W3C has also developed a set of QA Specification Guidelines to help W3C editors write better specifications, by making them easier to interpret without ambiguity and clearer as to what is required in order to conform.
As indicated in the QA Matrix, all these specifications have a Conformance section, a test suite and test results available online.
7.4.3 Alignment
The specification should be aligned with existing JTC 1 standards or ongoing work and thus complement existing standards, architectures and style guides. Any conflicts with existing standards, architectures and style guides should be made clear and justified.
7.4.3.1 Relationship to Existing Standards
- What international standards are closely related to the specification and how?
- To what international standards is the proposed specification a natural extension?
- How is the specification related to emerging and ongoing JTC 1 projects?
The Web Services stack seats on top of the XML stack, which, without being an ISO standard, is widely recognized, including by ISO, as a de facto industry open standard. XML itself is based on SGML, an ISO standard.
There are no known WS conflicts with existing International Standards.
Several JTC 1 groups are working within the framework of XML, and several ISO/IEC standards are already using XML as their underlying syntax. Our understanding is that there are already ISO/IEC standard referencing pieces of the W3C WS stack, so the alignment is clear.
The JTC 1 SC 38 group is being tasked to identify which Web Services standards are relevant to the global ICT market and this package should help them in this task.
7.4.3.2 Adaptability and Migration
- What adaptations (migrations) of either the specification or international standards would improve the relationship between the specification and international standards?
- How much flexibility does the PAS submitter have ?
- What are the longer-range plans for new/evolving specifications?
There is no identified need for migrations or adaptations of either the WS specs or existing JTC 1 standards, the integration is already achieved.
Given the stability of these technologies, and their market acceptance as is, there isn't much flexibility in changing any of these specifications, and no reason to do so. There is flexibility on the other hand on the exact nature of the package, that is, deciding if a particular specification should or should not be part of it. The current choice is W3C's proposal, resulting from a consensus in our community.
There is no planned work for new versions of SOAP, WS Addressing or WS Policy, but the Web Services activity at W3C is working on more advanced layers, still within the WS framework.
For instance, the Web Services Resource Access Working Group recently published several revisions of the following Working Drafts: WS-Transfer, WS-MetadataExchange, WS-Eventing, WS-Enumeration, WS-Fragment.
7.4.3.3 Substitution and Replacement
- What needs exist, if any, to replace an existing international standard? Rationale?
- What is the need and feasibility of using only a portion of the specification as an international standard?
- What portions, if any, of the specification do not belong in an international standard (e.g. too implementation specific)?
There is no plan or expressed need to replace any existing IS with the transposition of the W3C WS package. Quite the opposite, the plan is to complement and enrich the WS system of standards (some of them being already JTC 1 standards, some not).
Furthermore, we think this set of eight WS specifications is the minimal set of stable technologies to cover Web Services messaging, and that each individual technology is complete and cannot be subsetted. Their conformance section indeed covers all the specification content, and implementation details are always left outside, in the already mentioned implementation reports.
7.4.3.4 Document Format and Style
- What plans, if any, exist to conform to JTC 1 document styles?
The production of all W3C specifications is driven by a set of automatic publication tools, using templates and semantics that are both standard related (close to ISO and standardization in general) and W3C related (close to our own process and community).
We are already capable of generating several different output formats using our specification sources (e.g. HTML, PDF, plain text) and the generation of a different set of documents from a a different set of styles, e.g. the ISO/IEC style, is clearly doable.
We haven't yet looked with enough details (or be asked to look) at the ISO/IEC JTC 1 styling constraints, or tools available for conversion or generation, to elaborate on a plan for such a conformance in styling, but we'll be happy to do so when the package is approved.
Regarding final names and numbers in the ISO/IEC style, the table in the section 7.4.1.5 above provides the list of final IS names and numbers we are requesting for the WS package (they all start with "W3C" and use the 40K numbering base we have been allocated).